DE102021206410A1

DE102021206410A1 - Techniken zum durchführen einer beschleunigten punktabtastung in einer texturverarbeitungs-pipeline

Info

Publication number: DE102021206410A1
Application number: DE102021206410.8A
Authority: DE
Inventors: Michael Fetterman; Shirish Gadre; Mark GEBHART; Ramesh Jandhyala; William Newhall; Omkar PARANJAPE; Stefano Pescador; Poorna Rao; Heinrich Steven J
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2020-06-23
Filing date: 2021-06-22
Publication date: 2021-12-23
Also published as: US11379944B2; US20210398241A1; CN113835753A

Abstract

Eine Texturverarbeitungs-Pipeline in einer Graphikverarbeitungseinheit erzeugt das Aussehen der Oberfläche für Objekte in einer computererzeugten Szene. Diese Texturverarbeitungs-Pipeline bestimmt bei mehreren Stufen innerhalb der Texturverarbeitungs-Pipeline, ob Texturoperationen und Texturlasten mit einer beschleunigten Rate verarbeitet werden können. Bei jeder Stufe, die einen Entscheidungspunkt umfasst, nimmt die Texturverarbeitungs-Pipeline an, dass die aktuelle Texturoperation oder Texturlast beschleunigt werden kann, es sei denn, das spezifische bekannte Information angibt, dass die Texturoperation oder die Texturlast nicht beschleunigt werden kann. Als Ergebnis vergrößert die Texturverarbeitungs-Pipeline die Anzahl von Texturoperationen und Texturlasten, die beschleunigt werden, im Verhältnis zu der Anzahl von Texturoperationen und Texturlasten, die nicht beschleunigt werden.

Description

Gebiet der verschiedener Ausführungsformen
Verschiedene Ausführungsformen betreffen im Allgemeinen Parallelverarbeitungsarchitekturen, genauer gesagt Techniken zum Durchführen beschleunigter Punktabtastung in einer Texturverarbeitungs-Pipeline.
Beschreibung der verwandten Technik
Graphikverarbeitungseinheiten (GPUs) werden eingesetzt, um dreidimensionale (3D) Graphikobjekte und zweidimensionale (2D) Graphikobjekte für eine Vielfalt von Anwendungen zu erzeugen, die Spielfilme, Computerspiele, Virtuelle-Realität (VR)- und Erweiterte-Realität (AR)-Erlebnisse, mechanische Ausgestaltung und/oder dergleichen umfassen. Eine moderne GPU umfasst Texturverarbeitungshardware, um das Aussehen der Oberfläche, die hier als die „Oberflächentextur“ bezeichnet wird, für 3D-Objekte in einer 3D-Graphikszene zu erzeugen. Die Texturverarbeitungshardware wendet das Aussehen der Oberfläche auf ein 3D-Objekt durch „Wickeln“ der entsprechenden Oberflächentextur um das 3D-Objekt an. Dieser Prozess des Erzeugens und Anwendens von Oberflächentexturen auf 3D-Objekte führt zu einem hochrealistischen Erscheinungsbild für diese 3D-Objekte in der 3D-Graphikszene.
Die Texturverarbeitungshardware ist konfiguriert, um eine Vielfalt von Textur-bezogenen Anweisungen durchzuführen, die Texturoperationen und Texturlasten umfassen. Die Texturverarbeitungshardware erzeugt Zugriffe auf Texturinformationen durch Erzeugen von Speicherreferenzen, die hier als „Abfragen“ bezeichnet werden, auf einen Texturspeicher. Die Texturverarbeitungshardware ruft Oberflächen-Texturinformationen der Texturspeicher unter variierenden Umständen ab, wie beispielsweise während des Renderns von Objektoberflächen in einer 3D-Graphikszene zur Anzeige auf einer Anzeigevorrichtung, während des Renderns von 2D-Graphikszene oder während Rechenoperationen.
Oberflächen-Texturinformationen umfassen Texturelemente (hier als „Texel“ bezeichnet), die verwendet werden, um Objektoberflächen in einer 3D-Graphikszene zu texturieren oder zu schattieren. Die Texturverarbeitungshardware und zugeordneter Textur-Cache werden für effizienten, Nur-Lese-Zugriff hohen Durchsatzes optimiert, um die hohe Nachfrage nach Texturinformationen während des Graphik-Renderns mit wenig oder keiner Unterstützung für Schreiboperationen zu unterstützen. Ferner umfasst die Texturverarbeitungshardware spezialisierte Funktionseinheiten, um verschiedene Texturoperationen durchzuführen, wie beispielsweise Berechnung des Detaillierungsgrades (level of detail; LOD), Texturabtastung und Texturfilterung.
Im Allgemeinen beinhaltet eine Texturoperation das Abfragen mehrere Texel um einen bestimmten Punkt von Interesse im 3D-Raum und dann das Durchführen verschiedener Filterungs- und Interpolationsoperationen, um eine endgültige Farbe an dem Punkt von Interesse zu bestimmen. Im Gegensatz dazu fragt eine Texturlast typischerweise ein einziges Texel ab und gibt dies direkt an die Benutzeranwendung zur weiteren Verarbeitung zurück. Weil Filterungs- und Interpolationsoperationen typischerweise das Abfragen von vier oder mehr Texeln pro Verarbeitungs-Thread beinhaltet, ist die Texturverarbeitungshardware herkömmlicherweise aufgebaut, um das Erzeugen mehrere Abfragen pro Thread unterzubringen. Beispielsweise könnte die Texturverarbeitungshardware aufgebaut sein, um bis zu vier Texturspeicherabfragen in einem einzigen Speicherzyklus unterzubringen. Auf diese Art und Weise ist die Texturverarbeitungshardware in der Lage, die meisten oder sämtliche der benötigten Texturinformationen in einem Speicherzyklus abzufragen und zu empfangen.
Ein Nachteil mit dieser Vorgehensweise zum Abfragen des Texturspeichers ist, dass, wenn die Texturverarbeitungshardware für Texturlasten verwendet wird, lediglich eine der vier möglichen Texturspeicherabfragen in einem einzigen Speicherzyklus durchgeführt wird. Als Ergebnis wird lediglich ein Viertel der Speicherzugriffsfähigkeit der Texturverarbeitungshardware während Texturlasten benutzt. Außerdem müssen bestimmte Texturoperationen, die hier als Punkt-abgetastete Texturoperationen bezeichnet werden, lediglich ein oder zwei Texturspeicherabfragen im gegebenen Speicherzyklus durchführen, um dadurch lediglich ein Viertel bis die Hälfte der Speicherzugriffsfähigkeit der Texturverarbeitungshardware zu benutzen. Eine derartige Unterbenutzung der Texturverarbeitungshardware führt zu verringerter Effizienz und Leistung, wenn die GPU Texturlasten und Punkt-abgetastete Texturoperationen durchführt.
Wie das Vorhergehende veranschaulicht, sind das, was in der Technik benötigt wird, wirksamere Techniken zum Abfragen von Texturinformationen in einer Graphikverarbeitungseinheit.
ZUSAMMENFASSUNG
Verschiedene Ausführungsformen der vorliegenden Offenbarung legen ein computerimplementiertes Verfahren zum Zugreifen auf Texturspeicher in einer Graphikverarbeitungseinheit dar. Das Verfahren umfasst das Erzeugen, bei einer ersten Stufe in einer Texturverarbeitungs-Pipeline, einer ersten Bestimmung, dass eine Texturspeicherabfrage für eine Beschleunigung innerhalb der Texturverarbeitungs-Pipeline berechtigt ist. Das Verfahren umfasst ferner das Veranlassen, basierend auf der ersten Bestimmung, der Texturspeicherabfrage zu einer zweiten Stufe in der Texturverarbeitungs-Pipeline weiterzuschreiten. Das Verfahren umfasst ferner das Erzeugen, bei der zweiten Stufe in der Texturverarbeitungs-Pipeline, einer zweiten Bestimmung, dass die Texturspeicherabfrage für Beschleunigung innerhalb der Texturverarbeitungs-Pipeline berechtigt ist. Das Verfahren umfasst ferner das Verarbeiten der Texturspeicherabfrage innerhalb der Texturverarbeitungs-Pipeline basierend auf mindestens einer der ersten Bestimmung und der zweiten Bestimmung.
Andere Ausführungsformen umfassen, ohne Einschränkung, ein System, das ein oder mehrere Aspekte der offenbarten Techniken implementiert, und ein oder mehrere computerlesbare Medien, die Anweisungen zum Durchführen eines oder mehrerer Aspekte der offenbarten Techniken umfassen.
Mindestens ein technischer Vorteil der offenbarten Techniken im Verhältnis zu der früheren Technik ist, dass mit den offenbarten Techniken ein größerer Prozentsatz von Texturspeicher-Zugriffsfähigkeit während Texturlasten und während einfacher Texturoperationen benutzt wird. Als Ergebnis wird die Effizienz und Leistung der Texturverarbeitungshardware während Texturlasten und Texturoperationen im Verhältnis zu früheren Vorgehensweisen erhöht. Ein anderer technischer Vorteil der offenbarten Techniken ist, dass die Texturverarbeitungshardware mehrere Stufen zum Bestimmen umfasst, ob die Speicherzugriffsfähigkeit der Texturverarbeitungshardware effizienter genutzt werden könnte. Als Ergebnis sind eine größere Anzahl von Texturlasten und Texturoperationen in der Lage, Nutzen aus den offenbarten Techniken im Verhältnis zu einer Vorgehensweise zu ziehen, bei der diese Bestimmung lediglich bei einer einzigen Stufe der Texturverarbeitungshardware vorgenommen wird. Diese Vorteile stellen ein oder mehrere technologische Verbesserungen gegenüber Vorgehensweisen des Standes der Technik bereit.
Figurenliste
So dass die Weise, in welcher die oben rezitierten Merkmale der vorliegenden Erfindung im Detail verstanden werden können, kann eine spezifischere Beschreibung der Erfindung, welche oben kurz beschrieben ist, mittels Bezugnahme auf Ausführungsformen gegeben werden, von welchen einige in den angehängten Zeichnungen illustriert sind. Es ist jedoch zu bemerken, dass die angehängten Zeichnungen nur typische Ausführungsformen dieser Erfindung illustrieren und daher nicht zu betrachten sind, ihren Geltungsbereich zu begrenzen, da die Erfindung andere gleich effektive Ausführungsformen zulassen kann.

1 ist ein Blockdiagramm eines Computersystems, das konfiguriert ist, um ein oder mehrere Aspekte der verschiedenen Ausführungsformen zu implementieren;
2 ist ein Blockdiagramm einer Parallelverarbeitungseinheit (PPU), die in dem Parallelverarbeitungs-Teilsystem von 1 umfasst ist, gemäß verschiedener Ausführungsformen;
3A ist ein Blockdiagramm eines allgemeinen Verarbeitungsclusters, der in der Parallelverarbeitungseinheit von 2 umfass ist, gemäß verschiedener Ausführungsformen;
3B ist ein Konzeptdiagramm einer Graphikverarbeitungs-Pipeline, die innerhalb der Parallelverarbeitungseinheit von 2 implementiert werden kann, gemäß verschiedener Ausführungsformen;
4 ist ein Konzeptdiagramm einer Texturverarbeitungs-Pipeline, die eine Textureinheit innerhalb des allgemeinen Verarbeitungsclusters von 3A konfiguriert sein kann, zu implementieren, gemäß verschiedener Ausführungsformen; und
5 ist ein Ablaufdiagramm von Verfahrensschritten zum Durchführen von Speicherzugriffsoperationen in einer Texturverarbeitungs-Pipeline gemäß verschiedener Ausführungsformen.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein tieferes Verständnis der verschiedenen Ausführungsformen zu ermöglichen. Für den Fachmann versteht es sich jedoch, dass die erfinderischen Konzepte auch ohne eine oder mehrere dieser spezifischen Einzelheiten in die Praxis umsetzbar sind.
Systemüberblick
1 ist ein Blockdiagramm eines Computersystems 100, das konfiguriert ist, um einen oder mehrere Aspekte der verschiedenen Ausführungsformen zu implementieren. Wie gezeigt, umfasst das Computersystem 100, ohne darauf beschränkt zu sein, eine Zentralverarbeitungseinheit (CPU) 102 und einen Systemspeicher 104, der über eine Speicherbrücke 105 und einen Kommunikationspfad 113 mit einem Parallelverarbeitungs-Teilsystem 112 gekoppelt ist. Die Speicherbrücke 105 ist ferner über einen Kommunikationspfad 106 mit einer E/A (Eingabe/Ausgabe)-Brücke 107 gekoppelt, und die E/A-Brücke 107 ist ihrerseits wiederum mit einem Schalter 116 gekoppelt.
Im Betrieb ist die E/A-Brücke 107 konfiguriert, um Benutzereingabeinformationen von Eingabevorrichtungen 108, wie z.B. einer Tastatur oder einer Maus, zu empfangen, und die Eingabeinformationen zur Verarbeitung über den Kommunikationspfad 106 und die Speicherbrücke 105 an die CPU 102 weiterzuleiten. Der Schalter 116 ist konfiguriert, um Verbindungen zwischen der E/A-Brücke 107 und anderen Komponenten des Computersystems 100, wie z.B. einem Netzwerkadapter 118 und verschiedenen Zusatzkarten 120 und 121, bereitzustellen.
Wie ebenfalls gezeigt, ist die E/A-Brücke 107 mit einer Systemplatte 114 gekoppelt, die konfiguriert sein kann, um Inhalte und Anwendungen sowie Daten zur Verwendung durch die CPU 102 und das Parallelverarbeitungs-Teilsystem 112 zu speichern. Im Allgemeinen stellt die Systemplatte 114 nichtflüchtigen Speicherplatz für Anwendungen und Daten bereit und kann feste oder austauschbare Festplattenlaufwerke, Flash-Speichervorrichtungen und CD-ROM (Compact-Disc Festspeicher), DVD-ROM (Digital Versatile Disc ROM), Blu-ray, HD-DVD (High Definition DVD) oder andere magnetische, optische oder Festkörper-Speichervorrichtungen umfassen. Schließlich können, obwohl nicht explizit gezeigt, andere Komponenten, wie z. B. universelle serielle Bus- oder andere Portverbindungen, Compact-Disc-Laufwerke, Digital Versatile Disc-Laufwerke, Filmaufnahmevorrichtungen und dergleichen ebenso mit der E/A-Brücke 107 verbunden sein.
In verschiedenen Ausführungsformen kann die Speicherbrücke 105 ein Northbridge-Chip und die E/A-Brücke 107 ein Southbridge-Chip sein. Darüber hinaus können die Kommunikationspfade 106 und 113 sowie andere Kommunikationspfade innerhalb des Computersystems 100 unter Verwendung beliebiger technisch geeigneter Protokolle implementiert sein, einschließlich, jedoch nicht beschränkt auf, AGP (Accelerated Graphics Port), HyperTransport oder jedes andere bekannte Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll.
In einigen Ausführungsformen umfasst das Parallelverarbeitungs-Teilsystem 112 ein Graphik-Teilsystem, das Pixel an eine Anzeigevorrichtung 110 liefert, die eine beliebige herkömmliche Kathodenstrahlröhre, eine Flüssigkristallanzeige, eine Leuchtdiodenanzeige oder dergleichen sein kann. In derartigen Ausführungsformen integriert das Parallelverarbeitungs-Teilsystem 112 Schaltungen, die für die Graphik- und Videoüberarbeitung optimiert sind, einschließlich z.B. einer Videoausgabeschaltung. Wie in 2 weiter unten ausführlicher beschrieben wird, können derartige Schaltungen über eine oder mehrere Parallelverarbeitungseinheiten (PPUs), die in dem Parallelverarbeitungs-Teilsystem 112 umfasst sind, integriert sein. In anderen Ausführungsformen integriert das Parallelverarbeitungs-Teilsystem 112 Schaltungen, die für allgemeine Zwecke und/oder Rechenverarbeitung optimiert sind. Auch hier können derartige Schaltungen über eine oder mehrere PPUs des Parallelverarbeitungs-Teilsystems 112 integriert sein, die konfiguriert sind, derartige allgemeinen Operationen und/oder Rechenoperationen durchzuführen. In nochmals anderen Ausführungsformen können die eine oder die mehreren PPUs, die innerhalb des Parallelverarbeitungs-Teilsystems 112 umfasst sind, konfiguriert sein, um Graphikverarbeitung, allgemeine Verarbeitung und Rechenverarbeitungsoperationen durchzuführen. Der Systemspeicher 104 umfasst zumindest einen Vorrichtungstreiber 103, der konfiguriert ist, um die Verarbeitungsoperationen der einen oder der mehreren PPUs innerhalb des Parallelverarbeitungs-Teilsystems 112 zu verwalten.
In verschiedenen Ausführungsformen kann das Parallelverarbeitungs-Teilsystem 112 mit einem oder mehreren der anderen Elemente aus 1 zu einem einzigen System integriert sein. Beispielsweise kann das Parallelverarbeitungs-Teilsystem 112 mit der CPU 102 und anderen Verbindungsschaltungen auf einem einzigen Chip integriert sein, um ein System auf einem Chip („SoC“) zu bilden.
Es versteht sich, dass das hier gezeigte System veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und der Anordnung von Brücken, der Anzahl von CPUs 102 und der Anzahl von Parallelverarbeitungs-Teilsystemen 112, kann beliebig modifiziert werden. In einigen Ausführungsformen könnte z.B. der Systemspeicher 104 direkt mit der CPU 102 statt über die Speicherbrücke 105 verbunden sein, und andere Vorrichtungen würden mit dem Systemspeicher 104 über die Speicherbrücke 105 und die CPU 102 kommunizieren. In anderen alternativen Topologien könnte das Parallelverarbeitungs-Teilsystem 112 mit der E/A-Brücke 107 oder direkt mit der CPU 102 statt mit der Speicherbrücke 105 verbunden sein. In noch anderen Ausführungsformen können die E/A-Brücke 107 und die Speicherbrücke 105 in einem einzigen Chip integriert sein, anstatt als eine oder mehrere diskrete Vorrichtungen zu existieren. Schließlich können in bestimmten Ausführungsformen eine oder mehrere der in 1 gezeigten Komponenten nicht vorhanden sein. Beispielsweise könnte der Schalter 116 eliminiert sein und der Netzwerkadapter 118 und die- Zusatzkarten 120, 121 würden direkt mit der E/A-Brücke 107 verbunden sein.
2 ist ein Blockdiagramm einer Parallelverarbeitungseinheit (PPU) 202, die in dem Parallelverarbeitungs-Teilsystem 112 von 1 umfasst ist, gemäß verschiedener Ausführungsformen. Obwohl 2 eine PPU 202 darstellt, wie vorstehend angegeben, kann das Parallelverarbeitungs-Teilsystem 112 eine beliebige Anzahl von PPUs 202 umfassen. Wie gezeigt, ist die PPU 202 an einen lokalen Parallelverarbeitungs(PP)-Speicher 204 gekoppelt. Die PPU 202 und der PP-Speicher 204 können unter Verwendung einer oder mehreren integrierten Schaltungsvorrichtungen, wie beispielsweise programmierbaren Prozessoren, anwendungsspezifischen integrierten Schaltungen („ASICs“) oder Speicherbausteinen oder auf jede andere technisch machbare Weise implementiert sein.
In einigen Ausführungsformen umfasst die PPU 202 eine Graphikverarbeitungseinheit („GPU“), die konfiguriert sein kann, eine Graphik-Render-Pipeline zu implementieren, um verschiedene Operationen mit Bezug zu der Erzeugung von Pixeldaten auf der Grundlage von Graphikdaten, die von der CPU 102 und/oder dem Systemspeicher 104 geliefert werden, durchzuführen. Wenn Graphikdaten verarbeitet werden, kann der PP-Speicher 204 als Graphikspeicher verwendet werden, der einen oder mehrere konventionelle Frame-Puffer und bei Bedarf auch ein oder mehrere andere Render-Ziele speichert. Unter anderem kann der PP-Speicher 204 dazu verwendet werden, Pixeldaten zu speichern und zu aktualisieren und endgültige Pixeldaten oder Anzeige-Frames an die Anzeigevorrichtung 110 zur Anzeige zu liefern. In einigen Ausführungsformen kann die PPU 202 auch für allgemeine Verarbeitung und Rechenoperationen konfiguriert sein.
Im Betrieb ist die CPU 102 der Hauptprozessor des Computersystems 100, der Betriebsabläufe anderer Systemkomponenten steuert und koordiniert. Insbesondere gibt die CPU 102 Anweisungen aus, die den Betrieb der PPU 202 steuern. In einigen Ausführungsformen schreibt die CPU 102 einen Strom von Befehlen für die PPU 202 in eine Datenstruktur (weder in 1 noch in 2 explizit gezeigt), die sich in dem Systemspeicher 104, in dem PP-Speicher 204 oder an einem anderen Speicherort befinden kann, auf den sowohl die CPU 102 als auch die PPU 202 zugreifen können. Ein Zeiger auf die Datenstruktur wird in einen Schiebepuffer geschrieben, um die Verarbeitung des Befehlsstroms in der Datenstruktur einzuleiten. Die PPU 202 liest Befehlsströme aus dem Schiebepuffer und führt dann Befehle asynchron im Verhältnis zu dem Betrieb der CPU 102 aus. In Ausführungsformen, in denen mehrere Schiebepuffer erzeugt werden, können Ausführungsprioritäten für jeden Schiebepuffer von einem Anwendungsprogramm über den Vorrichtungstreiber 103 spezifiziert sein, um die Terminierung der verschiedenen Schiebepuffer zu steuern.
Wie ebenfalls gezeigt, umfasst die PPU 202 eine E/A (Eingabe-/Ausgabe)-Einheit 205, die über den Kommunikationspfad 113 und die Speicherbrücke 105 mit dem Rest des Computersystems 100 kommuniziert. Die E/A-Einheit 205 erzeugt Pakete (oder andere Signale) zur Übertragung auf dem Kommunikationspfad 113 und empfängt darüber hinaus alle eingehenden Pakete (oder anderen Signale) von dem Kommunikationspfad 113 und leitet die eingehenden Pakete an die entsprechenden Komponenten der PPU 202 weiter. Zum Beispiel können Befehle, die sich auf Verarbeitungsaufgaben beziehen, an eine Host-Schnittstelle 206 geleitet werden, während Befehle, die sich auf Speicheroperationen (z.B. Lesen aus dem oder Schreiben in den PP-Speicher 204) beziehen, an eine Kreuzschieneneinheit 210 geleitet werden können. Die Host-Schnittstelle 206 liest jeden Schiebepuffer aus und überträgt den in dem Schiebepuffer gespeicherten Befehlsstrom an ein Frontend 212.
Wie vorstehend in Verbindung mit 1 erwähnt, kann die Verbindung der PPU 202 mit dem Rest des Computersystems 100 variiert werden. In einigen Ausführungsformen ist das Parallelverarbeitungs-Teilsystem 112, das zumindest eine PPU 202 umfasst, als eine Steck- bzw. Zusatzkarte implementiert, die in einen Erweiterungssteckplatz des Computersystems 100 gesteckt werden kann. In anderen Ausführungsformen kann die PPU 202 auf einem einzigen Chip mit einer Busbrücke, wie z.B. der Speicherbrücke 105 oder der E/A-Brücke 107, integriert sein. In noch anderen Ausführungsformen können einige oder alle Elemente der PPU 202 zusammen mit der CPU 102 auch in einer einzigen integrierten Schaltung oder in einem System auf einem Chip (SoC) umfasst sein.
Im Betrieb überträgt das Frontend 212 von der Host-Schnittstelle 206 empfangene Verarbeitungsaufgaben an eine Arbeitsverteilungseinheit (nicht gezeigt) innerhalb einer Aufgaben-/Arbeits-Einheit 207. Die Arbeitsverteilungseinheit empfängt Zeiger auf Verarbeitungsaufgaben, die als Aufgabenmetadaten (Task Metadata; TMD) codiert und im Speicher abgelegt sind. Die Zeiger auf TMDs sind in einem Befehlsstrom umfasst, der als ein Pufferspeicher („pushbuffer“) gespeichert ist und von der Frontend-Einheit 212 der Host-Schnittstelle 206 empfangen wird. Zu den Verarbeitungsaufgaben, die als TMDs codiert werden können, gehören Indizes, die mit den zu verarbeitenden Daten verknüpft sind, sowie Zustandsparameter und Befehle, die festlegen, wie die Daten zu verarbeiten sind. Beispielsweise könnten die Zustandsparameter und Befehle das Programm definieren, das auf den Daten auszuführen ist. Die Aufgaben-/Arbeits-Einheit 207 empfängt Aufgaben von dem Frontend 212 und stellt sicher, dass Universalverarbeitungscluster (General Processing Clusters; GPCs) 208 in einen gültigen Zustand konfiguriert sind, bevor die von jeden der TMDs spezifizierte Verarbeitungsaufgabe initiiert wird. Für jede TMD, die zur Planung der Ausführung der Verarbeitungsaufgabe verwendet wird, kann eine Priorität festgelegt sein. Verarbeitungsaufgaben können auch von dem Verarbeitungsclusterarray 230 empfangen werden. Optional können die TMD einen Parameter umfassen, der steuert, ob die TMD am Anfang oder am Ende einer Liste von Verarbeitungsaufgaben (oder zu einer Liste von Zeigern auf die Verarbeitungsaufgaben) hinzugefügt werden, wodurch eine weitere Ebene der Steuerung über Ausführungspriorität bereitgestellt wird.
Die PPU 202 implementiert vorteilhafterweise eine hochparallele Verarbeitungsarchitektur, die auf einem Verarbeitungsclusterarray 230 basiert, das einen Satz von C GPCs 208 umfasst, wobei C ≥ 1. Jeder GPC 208 ist in der Lage, eine große Anzahl (z.B. Hunderte oder Tausende) von Threads gleichzeitig auszuführen, wobei jeder Thread eine Instanz eines Programms ist. In verschiedenen Anwendungen können verschiedene GPCs 208 zur Verarbeitung verschiedener Arten von Programmen oder zur Durchführung verschiedener Arten von Berechnungen allokiert werden. Die Zuweisung von GPCs 208 kann je nach der für die einzelnen Programm- oder Berechnungsarten anfallenden Arbeitsbelastung variieren.
Die Speicherschnittstelle 214 umfasst einen Satz von D Partitionseinheiten 215, wobei D ≥ 1. Jede Partitionseinheit 215 ist mit einem oder mehreren dynamischen Direktzugriffsspeichern („DRAMs“) 220 gekoppelt, die sich in dem PP-Speicher 204 befinden. In einer Ausführungsform entspricht die Anzahl von Partitionseinheiten 215 der Anzahl von DRAMs 220, und ist jede Partitionseinheit 215 mit einem anderen DRAM 220 gekoppelt. In anderen Ausführungsformen kann die Anzahl von Partitionseinheiten 215 von der Anzahl von DRAMs 220 abweichen. Fachleute werden zu schätzen wissen, dass ein DRAM 220 durch eine beliebige andere, technisch geeignete Speichervorrichtung ersetzt werden kann. Im Betrieb können verschiedene Render-Ziele, wie Texturkarten und Einzelbild- bzw. Framepuffer, über DRAMs 220 hinweg gespeichert werden, so dass die Partitionseinheiten 215 Teile jedes Renderziels parallel schreiben können, um die verfügbare Bandbreite des PP-Speichers 204 effizient zu nutzen.
Ein bestimmter GPC 208 kann Daten verarbeiten, die auf einen der DRAMs 220 in dem PP-Speicher 204 zu schreiben sind. Die Kreuzschieneneinheit 210 ist konfiguriert, die Ausgabe jedes GPC 208 an den Eingang jeder Partitionseinheit 215 oder an jeden anderen GPC 208 zur weiteren Verarbeitung weiterzuleiten. Die GPCs 208 kommunizieren über die Kreuzschieneneinheit 210 mit der Speicherschnittstelle 214, um aus verschiedenen DRAMs 220 zu lesen oder in diese zu schreiben. In einer Ausführungsform weist die Kreuzschieneneinheit 210 eine Verbindung zu der E/A-Einheit 205 zusätzlich zu einer Verbindung zu dem PP-Speicher 204 über die Speicherschnittstelle 214 auf, wodurch die Verarbeitungskerne innerhalb der verschiedenen GPCs 208 mit dem Systemspeicher 104 oder einem anderen, nicht lokal zu der PPU 202 befindlichen Speicher kommunizieren können. In der Ausführungsform von 2 ist die Kreuzschieneneinheit 210 direkt mit der E/A-Einheit 205 verbunden. In verschiedenen Ausführungsformen kann die Kreuzschieneneinheit 210 virtuelle Kanäle verwenden, um Verkehrsströme zwischen den GPCs 208 und den Partitionseinheiten 215 zu trennen.
Die GPCs 208 können auch programmiert sein, um Verarbeitungsaufgaben in Bezug auf eine breite Vielfalt von Anwendungen auszuführen, einschließlich, jedoch nicht beschränkt auf, lineare und nichtlineare Datentransformationen, Filterung von Video- und/oder Audiodaten, Modellierungsoperationen (z.B. Anwendung physikalischer Gesetze zur Bestimmung von Position, Geschwindigkeit und anderen Eigenschaften von Objekten), Bildwiedergabeoperationen (z.B. Tesselations-Shader-, Vertex-Shader-, Geometrie-Shader- und/oder Pixel-/Fragment-Shader-Programme), allgemeine Rechenoperationen usw. Im Betrieb ist die PPU 202 konfiguriert, Daten von dem Systemspeicher 104 und/oder dem PP-Speicher 204 in eine oder mehrere On-Chip-Speichereinheiten zu übertragen, die Daten zu verarbeiten und Ergebnisdaten zurück in den Systemspeicher 104 und/oder den PP-Speicher 204 zu schreiben. Auf die Ergebnisdaten kann dann von anderen Systemkomponenten, einschließlich der CPU 102, einer anderen PPU 202 innerhalb des Parallelverarbeitungs-Teilsystems 112 oder eines anderen Parallelverarbeitungs-Teilsystems 112 innerhalb des Computersystems 100, zugegriffen werden.
Wie vorstehend erwähnt, kann eine beliebige Anzahl von PPUs 202 in einem Parallelverarbeitungs-Teilsystem 112 umfasst sein. Beispielsweise können mehrere PPUs 202 auf einer einzigen Zusatzsteckkarte bereitgestellt sein oder können mehrere Zusatzsteckkarten an den Kommunikationspfad 113 angeschlossen sein oder können eine oder mehrere PPUs 202 in einen Brücken-Chip integriert sein. Die PPUs 202 in einem- Multi-PPU-System können identisch oder voneinander verschieden sein. Beispielsweise können unterschiedliche PPUs 202 eine unterschiedliche Anzahl von Prozessorkernen und/oder unterschiedliche Mengen an PP-Speicher 204 aufweisen. In Implementierungen, in denen mehrere PPUs 202 vorhanden sind, können diese PPUs 202 parallel betrieben werden, um Daten mit einem höheren Durchsatz zu verarbeiten, als dies mit einer einzelnen PPU 202 möglich ist. Systeme, die eine oder mehrere PPUs 202 integrieren, können in einer Vielzahl von Konfigurationen und Formfaktoren implementiert sein, einschließlich, ohne darauf beschränkt zu sein darauf, Desktops, Laptops, Handheld-Personal Computer oder andere Handheld-Geräte, Server, Workstations, Spielkonsolen, eingebettete Systeme und dergleichen.
3A ist ein Blockdiagramm eines allgemeinen Verarbeitungsclusters 208, der in der PPU 202 von 2 umfasst ist, gemäß verschiedenen Ausführungsformen. Im Betrieb kann der GPC 208 konfiguriert sein, um eine große Anzahl von Threads parallel durchzuführen, um Graphiken, allgemeine Verarbeitung und/oder Rechenoperationen durchzuführen. Wie hier verwendet, bezieht sich ein „Thread“ auf eine Instanz eines bestimmten Programms, die auf einem bestimmten Satz von Eingangsdaten ausgeführt wird. In einigen Ausführungsformen werden Einzelanweisung-Mehrfachdaten (Single-Instruction, Multiple Data; SIMD)-Anweisungsausgabe-Techniken verwendet, um eine parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Anweisungseinheiten bereitzustellen. In anderen Ausführungsformen werden Einzelanweisung-Mehrfachthread (Single Instruction, Multiple Thread; SIMT)-Techniken verwendet um eine parallele Ausführung einer großen Anzahl allgemein synchronisierter Threads zu unterstützen, unter Verwendung einer gemeinsamen Befehlseinheit, die konfiguriert ist, Befehle an einen Satz von Verarbeitungsmaschinen innerhalb des GPC 208 auszugeben. Anders als ein SIMD-Ausführungsregime, bei dem alle Verarbeitungsmaschinen in der Regel identische Befehle ausführen, ermöglicht die SIMT-Ausführung, dass verschiedene Threads divergenten Ausführungspfaden durch ein gegebenes Programm leichter folgen können. Der Fachmann versteht, dass ein SIMD-Verarbeitungsregime eine funktionelle Teilmenge eines SIMT-Verarbeitungsregimes darstellt.
Der Betrieb des GPC 208 wird über einen Pipeline-Manager 305 gesteuert, der Verarbeitungsaufgaben, die von einer Arbeitsverteilungseinheit (nicht gezeigt) innerhalb der Aufgabe/Arbeitseinheit 207 empfangen werden, auf einen oder mehrere Streaming-Multiprozessoren (SMs) 310 verteilt. Der Pipeline-Manager 305 kann auch konfiguriert sein, eine Arbeitsverteilungs-Kreuzschiene 330 zu steuern, indem er Ziele für von SMs 310 ausgegebenen verarbeiteten Daten spezifiziert.
In einer Ausführungsform umfasst der GPC 208 einen Satz M von SMs 310, wobei M ≥ 1. Außerdem enthält jeder SM 310 einen Satz funktioneller Einheiten (nicht gezeigt), wie z.B. Ausführungseinheiten und Lade-Speicher-Einheiten. Verarbeitungsvorgänge, die für jede der Funktionseinheiten spezifisch sind, können in eine Pipeline gestellt werden, wodurch eine neue Anweisung zur Ausführung ausgegeben werden kann, bevor eine vorherige Anweisung die Ausführung abgeschlossen hat. Jede beliebige Kombination von Funktionseinheiten innerhalb eines bestimmten SM 310 kann bereitgestellt werden. In verschiedenen Ausführungsformen können die Funktionseinheiten konfiguriert sein, um eine Vielzahl verschiedener Operationen zu unterstützen, einschließlich Ganzzahl- und Gleitkommaarithmetik (z.B. Addition und Multiplikation), Vergleichsoperationen, Boolesche Operationen (AND, OR, XOR), Bitverschiebung und Berechnung verschiedener algebraischer Funktionen (z.B. planare Interpolation und trigonometrische, exponentielle und logarithmische Funktionen usw.). Vorteilhafterweise kann dieselbe Funktionseinheit konfiguriert sein, um verschiedene Operationen auszuführen.
Im Betrieb ist jeder SM 310 konfiguriert, um eine oder mehrere Threadgruppen zu verarbeiten. Wie hier verwendet, bezieht sich eine „Threadgruppe“ oder ein „Warp“ auf eine Gruppe von Threads, die gleichzeitig dasselbe Programm mit unterschiedlichen Eingangsdaten ausführen, wobei ein Thread der Gruppe einer anderen Ausführungseinheit innerhalb eines SM 310 zugeordnet ist. Eine Threadgruppe kann weniger Threads umfassen als die Anzahl der Ausführungseinheiten innerhalb des SM 310. In diesem Fall können einige der Ausführungseinheiten während der Zyklen, in denen diese Threadgruppe verarbeitet wird, untätig sein. Eine Threadgruppe kann auch mehr Threads als die Anzahl der Ausführungseinheiten innerhalb des SM 310 beinhalten, in welchem Fall die Verarbeitung über aufeinanderfolgende Taktzyklen erfolgen kann. Da jeder SM 310 bis zu G Threadgruppen gleichlaufend unterstützen kann, folgt daraus, dass bis zu G*M Threadgruppen in einem GPC 208 zu jedem beliebigen Zeitpunkt ausgeführt werden können.
Darüber hinaus können mehrere verwandte Threadgruppen (in verschiedenen Phasen der Ausführung) innerhalb eines SM 310 gleichzeitig aktiv sein. Diese Sammlung von Threadgruppen wird hier als ein „kooperatives Thread-Array“ („CTA“) oder „Thread-Array“ bezeichnet. Die Größe eines bestimmten CTA ist gleich m*k, wobei k die Anzahl der gleichlaufend ausführenden Threads in einer Threadgruppe ist, welches typischerweise ein ganzzahliges Vielfaches der Anzahl der Ausführungseinheiten innerhalb des SM 310 ist, und m die Anzahl der gleichzeitig aktiven Threadgruppen innerhalb des SM 310 ist.
Obwohl in 3A nicht gezeigt, enthält jeder SM 310 einen Cache der Ebene eins (L1) oder verwendet Platz in einem entsprechenden L1-Cache außerhalb des SM 310, um unter anderem Lade- und Speicheroperationen zu unterstützen, die von den Ausführungseinheiten durchgeführt werden. Jeder SM 310 weist darüber hinaus Zugriff auf Caches der Ebene zwei (L2) auf (nicht gezeigt), die von allen GPCs 208 in der PPU 202 gemeinsam genutzt werden. Die L2-Caches können zur Übertragung von Daten zwischen Threads verwendet werden. Schließlich weisen SMs 310 auch Zugriff auf „globale“ Speicher außerhalb des Chips auf, zu dem der PP-Speicher 204 und/oder der Systemspeicher 104 gehören kann. Es versteht sich, dass jeder beliebige Speicher außerhalb der PPU 202 als globaler Speicher verwendet werden kann. Zusätzlich kann, wie in 3 gezeigt ist, ein Cache der Ebene Eins Komma Fünf (L1.5-Cache) 335 in dem GPC 208 umfasst sein, der konfiguriert ist, um Daten zu empfangen und zu halten, die aus Speicher über die Speicherschnittstelle 214 von dem SM 310 angefordert wurden. Derartige Daten können, ohne darauf beschränkt zu sein, Anweisungen, einheitliche Daten und konstante Daten umfassen. In Ausführungsformen mit mehreren SMs 310 innerhalb des GPC 208 können die SMs 310 vorteilhafterweise gemeinsame Befehle und Daten, die in dem L1.5-Cache 335 zwischengespeichert sind, gemeinsam nutzen.
Jeder GPC 208 kann eine zugehörige Speicherverwaltungseinheit (Memory Management Unit; MMU) 320 aufweisen, die konfiguriert ist, um virtuelle Adressen in physische Adressen abzubilden. In verschiedenen Ausführungsformen kann sich die MMU 320 entweder innerhalb des GPC 208 oder innerhalb der Speicherschnittstelle 214 befinden. Die MMU 320 umfasst einen Satz von Seitentabelleneinträgen (Page Table Entries; PTEs), die verwendet werden, um eine virtuelle Adresse auf eine physische Adresse einer Kachel oder einer Speicherseite abzubilden, und optional einen Cachezeilen-Index. Die MMU 320 kann Adressübersetzungs-Lookaside-Puffer (Translation Lookaside Buffer; TLB) oder Caches beinhalten, die sich innerhalb von SMs 310, innerhalb eines oder mehrerer L1-Caches oder innerhalb des GPC 208 befinden können.
In Graphik- und Rechenanwendungen kann der GPC 208 konfiguriert sein, dass jeder SM 310 mit einer Textureinheit 315 gekoppelt ist, um Texturabbildungsoperationen durchzuführen, wie z.B. eine Bestimmung von Texturprobenpositionen, ein Lesen von Texturdaten und ein Filtern von Texturdaten.
Im Betrieb überträgt jeder SM 310 eine verarbeitete Aufgabe an die Arbeitsverteilungs-Kreuzschiene 330, um die verarbeitete Aufgabe für einen anderen GPC 208 zur weiteren Verarbeitung zur Verfügung zu stellen oder die verarbeitete Aufgabe in einem L2-Cache (nicht gezeigt) in dem Parallelverarbeitungsspeicher 204 oder in dem Systemspeicher 104 über die Kreuzschieneneinheit 210 zu speichern. Darüber hinaus ist eine Pre-Rasteroperationen (preROP)-Einheit 325 konfiguriert, Daten von dem SM 310 zu empfangen, Daten an eine oder mehrere Rasteroperationen (ROP)-Einheiten innerhalb der Partitionseinheiten 215 zu leiten, um Optimierungen für die Farbmischung durchzuführen, Pixel-Farbdaten zu organisieren und Adressübersetzungen durchzuführen.
Es versteht sich, dass die hier beschriebene Kernarchitektur veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Unter anderem kann eine beliebige Anzahl von Verarbeitungseinheiten, wie beispielsweise SMs 310, Textur-Einheiten 315 oder preROP-Einheiten 325, in dem GPC 208 umfasst sein. Darüber hinaus kann, wie vorstehend in Verbindung mit 2 beschrieben wurde, die PPU 202 eine beliebige Anzahl von GPCs 208 beinhalten, die konfiguriert sind, so dass sie einander funktionell ähnlich sind, so dass das Ausführungsverhalten nicht davon abhängt, welcher GPC 208 eine bestimmte Verarbeitungsaufgabe erhält. Außerdem arbeitet jeder GPC 208 unabhängig von den anderen GPCs 208 in der PPU 202, um Aufgaben für ein oder mehrere Anwendungsprogramme auszuführen. In Anbetracht des Vorstehenden versteht sich für den Fachmann, dass die in 1-3A beschriebene Architektur den Umfang der vorliegenden Offenbarung in keiner Weise beschränkt.
Graphik-Pipeline-Architektur
3B ist ein konzeptionelles Diagramm einer Graphikverarbeitungs-Pipeline 350, die in der Parallelverarbeitungseinheit 202 von 2 gemäß einer verschiedener Ausführungsformen implementiert sein kann. Wie gezeigt, umfasst die Graphikverarbeitungs-Pipeline 350 ohne Einschränkung einen Primitiv-Verteiler (Primitive Distributor; PD) 355, eine Vertex-Attribut-Hol-Einheit (Vertex Attribute Fetch; VAF)) 360; eine Vertex-, Tessellations-, Geometrie-Verarbeitungseinheit (Vertex, Tessellation, Geometry; VTG)) 365, eine Viewport-Skalierungs-, Auswahl(„cull“)- und Abschneide(„clip“)-Einheit (VPC) 370; eine Tiling-Einheit 375; eine Setup-Einheit 380; einen Rasterisierer 385; eine Fragment-Verarbeitungseinheit, welche auch als eine Pixel-Shading-Einheit (Pixel Shading; PS) 390 gekennzeichnet ist, und eine Raster-Operations-Einheit 395 (Raster Operation; ROP) auf.
Der PD 355 sammelt Vertex-Daten, welche Oberflächen einer hohen Ordnung, Graphik-Primitiven und Ähnlichem zugeordnet sind, von dem Frontend 212 und überträgt die Vertex-Daten an die VHF 360.
Die VHF 360 empfängt Vertex-Attribute, welche jeweils den eingehenden Vertices zugeordnet sind, von einem gemeinsam genutzten Speicher und speichert die Vertex-Daten zusammen mit den zugehörigen Vertex-Attributen in dem gemeinsam genutzten Speicher.
Die VTG 365 ist eine programmierbare Ausführungs-Einheit, die konfiguriert ist, um Vertex-Shader-Programme, Tessellations-Programme und Geometrie-Programme auszuführen. Diese Programme verarbeiten die Vertex-Daten und Vertex-Attribute, welche von der VHF 360 empfangen werden, und erzeugen Graphik-Primitive wie auch Farbenwerte, Oberflächen-Normalenvektoren und Transparenzwerte bei jedem Vertex für die Graphik-Primitive zur weiteren Verarbeitung in der Graphikverarbeitungs-Pipeline 350. Obwohl es nicht explizit dargestellt ist, kann die VTG 365 bei einigen Ausführungsformen eine oder mehrere von einer Vertex-Verarbeitungseinheit, einer Tessellations-Initialisierungs-Verarbeitungseinheit, einer Aufgaben-Erzeugungs-Einheit, einem Aufgaben-Verteiler, einer Topologie-Erzeugungs-Einheit, einer Tessellations-Verarbeitungseinheit und einer Geometrie-Verarbeitungseinheit umfassen.
Die Vertex-Verarbeitungseinheit in der VTG 365 ist eine programmierbare Ausführungs-Einheit, die konfiguriert ist, um Vertex-Shader-Programme auszuführen, Beleuchtungs- und Vertex-Daten zu transformieren, wie durch die Vertex-Shader-Programme spezifiziert. Zum Beispiel kann die Vertex-Verarbeitungseinheit programmiert sein, um die Vertex-Daten von einer Objekt-basierten Koordinatendarstellung (Objektraum) in ein Koordinatensystem mit einer alternativen Basis, wie etwa einem Worldspace oder einem Raum mit normalisierten Geräte-Koordinaten (Normalized Device Coordinates; NDC), zu transformieren. Die Vertex-Verarbeitungseinheit kann Vertex-Daten und Vertex-Attribute, welche in dem gemeinsam genutzten Speicher durch die VHF gespeichert sind, lesen und kann die Vertex-Daten und die Vertex-Attribute verarbeiten. Die Vertex-Verarbeitungseinheit 415 speichert die verarbeiteten Vertices in dem gemeinsam genutzten Speicher.
Die Tessellation-Initialisierungs-Verarbeitungseinheit in der VTG 365 ist eine programmierbare Ausführungs-Einheit, die konfiguriert ist, um Tessellation-Initialisierungs-Shader-Programme auszuführen. Die Tessellation-Initialisierungs-Verarbeitungseinheit verarbeitet Vertices, welche von der Vertex-Verarbeitungseinheit erzeugt werden, und erzeugt Graphik-Primitive, welche als Patches bekannt sind. Die Tessellation-Initialisierungs-Verarbeitungseinheit erzeugt auch verschiedene Patch-Attribute. Die Tessellation-Initialisierungs-Verarbeitungseinheit speichert die Patch-Daten und Patch-Attribute in dem gemeinsam genutzten Speicher. Bei einigen Ausführungsformen wird das Tessellation-Initialisierungs-Shader-Programm auch Hull-Shader oder Tessellation-Steuer-Shader genannt.
Die Aufgaben-Erzeugungs-Einheit in der VTG 365 ruft Daten und Attribute für Vertices und Patche von dem gemeinsam genutzten Speicher ab. Die Aufgaben-Erzeugungs-Einheit erzeugt Aufgaben zur Verarbeitung der Vertices und Patches, um diese in späteren Stufen in der Graphikverarbeitungs-Pipeline 350 zu verarbeiten. Der Aufgaben-Verteiler in der VTG 365 verteilt die Aufgaben neu, welche von der Aufgaben-Erzeugungs-Einheit erzeugt werden. Die Aufgaben, welche von den unterschiedlichen Instanzen des Vertex-Shader-Programms und des Tessellation-Initialisierungs-Programms erzeugt werden, können deutlich zwischen einer Graphikverarbeitungs-Pipeline 350 und einer anderen variieren. Der Aufgaben-Verteiler verteilt diese Aufgaben wiederholt, so dass jede Graphikverarbeitungs-Pipeline 350 näherungsweise dieselbe Arbeitslast während späterer Pipeline-Stufen aufweist.
Die Topologie-Erzeugungs-Einheit in der VTG 365 ruft Aufgaben, welche von dem Aufgaben-Verteiler verteilt werden, ab. Die Topologie-Erzeugungs-Einheit indiziert die Vertices einschließlich der Vertices, welche Patches zugeordnet sind, und berechnet (U, V) Koordinaten für Tessellation-Vertices und die Indices, welche die tessellierten Vertices verbinden, um Graphik-Primitive auszubilden. Die Topologie-Erzeugungs-Einheit speichert dann die indizierten Vertices in dem gemeinsam genutzten Speicher.
Die Tessellation-Verarbeitungseinheit ist eine programmierbare Ausführungs-Einheit, die konfiguriert ist, um Tessellation-Shader-Programme auszuführen. Die Tessellation-Verarbeitungseinheit liest Eingabedaten von dem gemeinsam genutzten Speicher und schreibt Ausgabedaten in diesen. Diese Ausgabedaten in dem gemeinsam genutzten Speicher werden zu der nächsten Shader-Stufe, der Geometrie-Verarbeitungseinheit 445, als Eingabedaten geführt. Bei einigen Ausführungsformen wird das Tessellation-Shader-Programm Domain-Shader oder Tessellation-Evaluierungs-Shader genannt.
Die Geometrie-Verarbeitungseinheit ist eine programmierbare Ausführungs-Einheit, die konfiguriert ist, um Geometrie-Shader-Programme auszuführen, wobei Graphik-Primitive transformiert werden. Die Vertices werden gruppiert, um Graphik-Primitive zur Verarbeitung zu konstruieren, wobei die Graphik-Primitive Dreiecke, Liniensegmente, Punkte und Ähnliches umfassen. Zum Beispiel kann die Geometrie-Verarbeitungseinheit programmiert werden, um die Graphik-Primitive in ein oder in mehrere neue Graphik-Primitive zu unterteilen und um Parameter zu berechnen, wie beispielsweise Ebenengleichungs-Koeffizienten, welche eingesetzt werden, um die neuen Graphik-Primitive zu rastern.
Die Geometrie-Verarbeitungseinheit überträgt die Parameter und die Vertices, welche neue Graphik-Primitive spezifizieren, zu der VPC 370. Die Geometrie-Verarbeitungseinheit kann Daten, die in dem gemeinsam genutzten Speicher gespeichert sind, zur Verwendung bei der Verarbeitung der Geometrie-Daten lesen. Die VPC 370 führt ein Abschneiden („Clipping“), ein Culling, eine Perspektiv-Korrektur und eine Viewport-Transformation durch, um zu bestimmen, welche Graphik-Primitive potenziell in dem endgültig gerenderten Bild sichtbar und welche Graphik-Primitive potenziell nicht sichtbar sind. Die VPC 370 überträgt dann die verarbeiteten Graphik-Primitive zu der Tiling-Einheit 375.
Die Tiling-Einheit 375 ist eine Graphik-Primitive-Sortierungs-Maschine, die sich zwischen einer Worldspace-Pipeline 352 und einer Bildschirmraum-Pipeline 354 befindet, wie es im Folgenden beschrieben wird. Die Graphik-Primitive werden in der Worldspace-Pipeline 352 verarbeitet und dann zu der Tiling-Einheit 375 übertragen. Der Bildschirmraum wird in Cache-Abschnitte („cache tiles“) aufgeteilt, wobei jeder Cache-Abschnitt einem Abschnitt des Bildschirmraum zugeordnet ist. Für jedes Graphik-Primitiv kennzeichnet die Tiling-Einheit 375 die Gruppe von Cache-Abschnitten, welche sich mit den Graphik-Primitiven überschneidet, ein Vorgehen, welches hier als „Tiling“ bezeichnet wird. Nach dem Tiling einer bestimmten Anzahl von Graphik-Primitiven, verarbeitet die Tiling-Einheit 375 die Graphik-Primitive auf einer Cache-Abschnitt-Basis, wobei die Graphik-Primitive, welche einem bestimmten Cache-Abschnitt zugeordnet sind, zu der Setup-Einheit 380 übertragen werden. Die Tiling-Einheit 375 überträgt die Graphik-Primitive zu der Setup-Einheit 380, wobei jeweils ein Cache-Abschnitt übertragen wird. Graphik-Primitive, welche sich mit mehreren Cache-Abschnitten überschneiden, werden typischerweise einmal in der Worldspace-Pipeline 352 verarbeitet, aber dann mehrfach zu der Bildschirmraum-Pipeline 354 übertragen.
Eine derartige Technik verbessert die Cache-Speicher-Gebundenheit während der Verarbeitung in der Bildschirmraum-Pipeline 354, wobei mehrere Speicher-Operationen, welche einem ersten Cache-Abschnitt zugeordnet sind, auf einen Bereich der L2-Caches oder jeden anderen technisch praktikablen Cache-Speicher zugreifen, der während der Bildschirmraum-Verarbeitung des ersten Cache-Abschnitts vorhanden sein kann. Wenn die Graphik-Primitive, die dem ersten Cache-Abschnitt zugeordnet sind, einmal durch die Bildschirmraum-Pipeline 354 verarbeitet werden, kann der Abschnitt der L2-Caches, der dem ersten Cache-Abschnitt zugeordnet ist, geräumt („flushed“) werden, und die Tiling-Einheit kann die Graphik-Primitive übertragen, die einem zweiten Cache-Abschnitt zugeordnet sind. Zahlreiche Speicher-Operationen, welche einem zweiten Cache-Abschnitt zugeordnet sind, können dann auf den Bereich der L2-Caches zugreifen, die während der Bildschirmraum-Verarbeitung des zweiten Cache-Abschnitts vorhanden sind. Dementsprechend kann der gesamte Speicher-Verkehr zu den L2-Caches und zu den Render-Ziele verringert werden. Bei einigen Ausführungsformen wird die Worldspace-Berechnung einmal für ein bestimmtes Graphik-Primitiv durchgeführt, unabhängig von der Anzahl der Cache-Abschnitte in dem Bildschirmraum, welche sich mit dem Graphik-Primitiv überschneiden.
Die Setup-Einheit 380 empfängt die Vertex-Daten von der VPC 370 über die Tiling-Einheit 375 und berechnet Parameter, welche sich auf die Graphik-Primitive beziehen, was ohne Einschränkung Kantengleichungen, partielle Ebenengleichungen und Tiefenebenen-(depth plane)-Gleichungen umfasst. Die Setup-Einheit 380 überträgt die verarbeiteten Graphik-Primitive zu dem Rasterisierer 385.
Der Rasterisierer 385 Scan-wandelt die neuen Graphik-Primitive um und überträgt Fragmente und Abdeckungsdaten zu der Pixel-Shading-Einheit 390. Darüber hinaus kann der Rasterisierer 385 konfiguriert sein, um ein z-Culling und andere z-basierte Optimierungen durchzuführen.
Die Pixel-Shading-Einheit 390 ist eine programmierbare Ausführungs-Einheit, welche ausgestaltet ist, um Fragment-Shader-Programme auszuführen, um Fragmente, welche von dem Rasterisierer 385 empfangen werden, zu transformieren, wie es durch die Fragment-Shader-Programme spezifiziert ist. Die Fragment-Shader-Programme können Fragmente auf einer Pixel-Niveau-Granularität schattieren, wobei derartige Shader-Programme auch als Pixel-Shader-Programme bekannt sind. Alternativ können die Fragment-Shader-Programme Fragmente auf einer Sample-Niveau-Granularität schattieren, wobei jedes Pixel mehrere Samples umfasst und jedes Sample einen Teil eines Pixels repräsentiert. Alternativ können die Fragment-Shader-Programme Fragmente mit jeder anderen technisch praktikablen Granularität abhängig von der programmierten Abtastrate schattieren.
Bei verschiedenen Ausführungsformen kann die Fragment-Verarbeitungseinheit 460 programmiert sein, um Operationen, wie Perspektiv-Korrektur, Musterabbildung („texture mapping“), Shading, Blending (Vermischen) und Ähnliches, durchzuführen, um schattierte Fragmente zu erzeugen, welche zu der ROP 385 übertragen werden. Die Pixel-Shading-Einheit 390 kann Daten, welche in dem gemeinsam genutzten Speicher gespeichert sind, lesen.
Die ROP 395 ist eine Verarbeitungseinheit, die Raster-Operationen durchführt, wie Schablonieren („stencil“), z-Test, Blending und Ähnliches, und überträgt die Pixeldaten als verarbeitete Graphikdaten über die Speicherschnittstelle 214 zum Speicher in den Graphikspeicher, wobei der Graphikspeicher typischerweise als ein oder mehrere Render-Ziele strukturiert ist. Die verarbeiteten Graphikdaten können in dem Graphikspeicher, dem Parallelverarbeitungs-Speicher 204 oder dem Systemspeicher 104 zur Darstellung auf einem Anzeigegerät 110 oder zur weiteren Verarbeitung durch die CPU 102 oder durch das Parallelverarbeitungs-Teilsystem 112 gespeichert werden. Bei einigen Ausführungsformen ist die ROP 395 konfiguriert, um z-Daten und Farbdaten, welche in den Speicher geschrieben werden, zu komprimieren und z-Daten und Farbdaten, welche von dem Speicher gelesen werden, zu dekomprimieren. Bei verschiedenen Ausführungsformen kann die ROP 395 in der Speicherschnittstelle 214, in den GPCs 208, in der Verarbeitungs-Cluster-Anordnung 230 außerhalb der GPCs oder in einer separaten Einheit (nicht dargestellt) innerhalb der PPUs 202 angeordnet sein.
Die Graphikverarbeitungs-Pipeline 350 kann durch irgendeines oder durch mehrere Verarbeitungs-Elemente innerhalb der PPU 202 implementiert werden. Zum Beispiel kann einer der SMs 310 der 3A konfiguriert sein, um die Funktionen von einer oder von mehreren der VTG 365 und der Pixel-Shading-Einheit 390 durchzuführen. Die Funktionen des PD 355, der VHF 360, der VPC 450, der Tiling-Einheit 375, der Setup-Einheit 380, des Rasterisierers 385 und der ROP 395 können auch durch Verarbeitungs-Elemente in einem bestimmten GPC 208 in Verbindung mit einer entsprechenden Partitions-Einheit 215 durchgeführt werden. Alternativ kann die Graphikverarbeitungs-Pipeline 350 unter Verwendung von bestimmten Verarbeitungs-Elementen mit festgelegter Funktion für eine oder für mehrere der vorab gelisteten Funktionen implementiert werden. Bei verschiedenen Ausführungsformen kann die PPU 202 konfiguriert sein, um eine oder um mehrere Graphikverarbeitungs-Pipelines 350 zu implementieren.
Bei einigen Ausführungsformen kann die Graphikverarbeitungs-Pipeline 350 in eine Worldspace-Pipeline 352 und eine Bildschirmraum-Pipeline 354 unterteilt werden. Die Worldspace-Pipeline 352 verarbeitet Graphik-Objekte im dreidimensionalen Raum, wobei die Position von jedem Graphik-Objekt im Verhältnis zu anderen Graphik-Objekten und im Verhältnis zu einem 3D-Koordinatensystem bekannt ist. Die Bildschirmraum-Pipeline 354 verarbeitet Graphik-Objekte, welche von dem 3D-Koordinatensystem auf eine zweidimensionale ebene Oberfläche, welche die Oberfläche der Anzeigevorrichtung 110 repräsentiert, projiziert worden sind. Zum Beispiel kann die Worldspace-Pipeline 352 Pipeline-Stufen in der Graphikverarbeitungs-Pipeline 350 von dem PD 355 bis zu dem VPC 370 umfassen. Die Bildschirmraum-Pipeline 354 kann Pipeline-Stufen in der Graphikverarbeitungs-Pipeline 350 von der Setup-Einheit 380 bis zu der ROP 395 umfassen. Die Tiling-Einheit 375 würde der letzten Stufe der Worldspace-Pipeline 352, nämlich der VPC 370, folgen. Die Tiling-Einheit 375 würde vor der ersten Stufe der Bildschirmraum-Pipeline 354, nämlich vor der Setup-Einheit 380, liegen.
Bei einigen Ausführungsformen kann die Worldspace-Pipeline 352 weiter in eine Alpha-Phasen-Pipeline und eine Beta-Phasen-Pipeline unterteilt werden. Zum Beispiel könnte die Alpha-Phasen-Pipeline Pipeline-Stufen in der Graphikverarbeitungs-Pipeline 350 von dem PD 355 bis zu der Aufgaben-Erzeugungs-Einheit umfassen. Die Beta-Phasen-Pipeline könnte Pipeline-Stufen in der Graphikverarbeitungs-Pipeline 350 von der Topologie-Erzeugungs-Einheit bis zu dem VPC 370 umfassen. Die Graphikverarbeitungs-Pipeline 350 führt einen ersten Satz von Operationen während der Verarbeitung in der Alpha-Phasen-Pipeline und einen zweiten Satz von Operationen während der Verarbeitung in der Beta-Phasen-Pipeline durch. Wie hier verwendet, ist ein Satz von Operationen als eine oder als mehrere Anweisungen definiert, welche durch einen einzigen Thread, durch eine Thread-Gruppe oder durch mehrere Thread-Gruppen, welche abgestimmt agieren, ausgeführt werden.
In einem System mit mehreren Graphikverarbeitungs-Pipelines 350, können die Vertex-Daten und die Vertex-Attribute, die einem Satz von Graphikobjekten zugeordnet sind, aufgeteilt werden, so dass jede Graphikverarbeitungs-Pipeline 350 näherungsweise denselben Umfang einer Arbeitslast während der Alpha-Phase aufweist. Die Alpha-Phasen-Verarbeitung kann den Umfang an Vertex-Daten und Vertex-Attributen deutlich vergrößern, so dass der Umfang von Vertex-Daten und Vertex-Attributen, die durch die Aufgaben-Erzeugungs-Einheit erzeugt werden, deutlich größer als der Umfang der Vertex-Daten und Vertex-Attribute ist, der durch den PD 355 und die VAF 360 verarbeitet werden. Ferner kann die Aufgaben-Erzeugungs-Einheit, die einer Graphikverarbeitungs-Pipeline 350 zugeordnet ist, eine deutlich größere Menge an Vertex-Daten und Vertex-Attributen als die Aufgaben-Erzeugungs-Einheit erzeugen, die einer anderen Graphikverarbeitungs-Pipeline 350 zugeordnet ist, sogar in Fällen, in denen die beiden Graphikverarbeitungs-Pipelines 350 am Anfang der Alpha-Phasen-Pipeline dieselbe Menge an Attributen verarbeiten. In derartigen Fällen verteilt der Aufgaben-Verteiler die Attribute, die durch die Alpha-Phasen-Pipeline erzeugt werden, erneut, so dass jede Graphikverarbeitungs-Pipeline 350 näherungsweise dieselbe Arbeitslast zu Beginn der Beta-Phasen-Pipeline aufweist.
Es sei bemerkt, dass, wie hier verwendet, Referenzen auf einen gemeinsam genutzten Speicher einen oder mehrere technisch machbaren Speicher umfassen können, was, ohne Einschränkung, einen lokalen Speicher, der mit einem oder mit mehreren SMs 310 gemeinsam genutzt wird, oder einen Speicher, der über die Speicherschnittstelle 214 zugreifbar ist, wie einen Cache-Speicher, einen Parallelverarbeitungs-Speicher 204 oder einen Systemspeicher 104, umfasst. Es sei ebenfalls bemerkt, dass, wie hier verwendet, Referenzen auf einen Cache-Speicher, wie er hier eingesetzt wird, einen oder mehrere technisch einsetzbare Speicher umfassen kann, was ohne Einschränkung einen L1-Cache, einen L1.5-Cache und die L2-Caches umfasst.
Bilder, die durch Anwenden einer oder mehrerer der hier offenbarten Techniken erzeugt werden, können auf einem Monitor oder einer anderen Anzeigevorrichtung angezeigt werden. In einigen Ausführungsformen kann die Anzeigevorrichtung direkt mit dem System oder Prozessor gekoppelt sein, welches/welcher die Bilder erzeugt oder rendert. In anderen Ausführungsformen kann die Anzeigevorrichtung indirekt mit dem System oder Prozessor, wie beispielsweise über ein Netzwerk, gekoppelt sein. Beispiele von derartigen Netzwerken umfassen das Internet, mobile Telekommunikations-Netzwerke, ein WIFI-Netzwerk, sowie auch jedes beliebige andere verdrahtete und/oder drahtlose Netzwerksystem. Wenn die Anzeigevorrichtung indirekt gekoppelt ist, können die Bilder, die durch das System oder den Prozessor erzeugt werden, über das Netzwerk zu der Anzeigevorrichtung gestreamt werden. Ein derartiges Streaming erlaubt beispielsweise Videospielen oder anderen Anwendungen, die Bilder rendern, auf einem Server oder in einem Rechenzentrum ausgeführt zu werden, und den gerenderten Bildern übertragen und auf einer oder mehreren Benutzervorrichtungen (wie beispielsweise einem Computer, Videospielkonsole, Smartphone, anderen mobilen Vorrichtung, usw.) angezeigt zu werden, die von dem Server oder Rechenzentrum physisch getrennt sind. Folglich können die hier offenbarten Techniken angewendet werden, um die Bilder zu verbessern, die gestreamt werden, und Dienste zu verbessern, die Bilder streamen, wie beispielsweise NVIDIA GeForce Now (GFN), Google Stadia und dergleichen.
Des Weiteren können Bilder, die durch Anwenden einer oder mehrerer der hier offenbarten Techniken erzeugt werden, verwendet werden, um tiefe neuronale Netzwerke (DNNs) zu trainieren, zu prüfen oder zu zertifizieren, die verwendet werden, um Objekte und Umgebungen in der realen Welt zu erkennen. Derartige Bilder können Szenen von Fahrbahnen, Fabriken, Gebäuden, städtische Einstellungen, ländlichen Einstellungen, Menschen, Tieren und eines beliebigen anderen physischen Objekts oder Einstellung der realen Welt umfassen. Derartige Bilder können verwendet werden, um DNNs zu trainieren, zu prüfen oder zu zertifizieren, die in Maschinen oder Robotern eingesetzt werden, um physische Objekte in die realen Welt zu manipulieren, zu handhaben oder zu modifizieren. Des Weiteren können derartige Bilder verwendet werden, um DNNs zu trainieren, zu prüfen oder zu zertifizieren, die in autonomen Fahrzeuge eingesetzt werden, um die Fahrzeuge durch die reale Welt zu navigieren und zu bewegen. Außerdem können Bilder, die durch Anwenden einer oder mehrerer der hier offenbarten Techniken erzeugt werden, verwendet werden, um Informationen an Benutzern derartiger Maschinen, Robotern und Fahrzeug zu übermitteln.
Texturspeicherabfragen für Texturoperationen und Texturlasten
4 ist ein Konzeptdiagramm einer Texturverarbeitungs-Pipeline 400, die eine Textureinheit 315 innerhalb des allgemeinen Verarbeitungsclusters 208 von 3A konfiguriert sein kann, zu implementieren, gemäß verschiedener Ausführungsformen. Wie gezeigt, umfasst die Texturverarbeitungs-Pipeline 400 eine TexturEingabe/Ausgabe(TEXIO)-Einheit 402, eine Textureingabe (TEXIN)-Einheit 404, eine Detaillierungsgrad(LOD)-Einheit 406, ein Abtaststeuerungs- und Adressiereinheit 408, eine Markierungseinheit 410, ein Fehltrefferverarbeitungseinheit 412, einen Daten-Firstin/First-out-Speicher (FIFO) 414, eine Recheneinheit 416, eine Filtergewichtungseinheit 418, ein Filtergewichtungs-FIFO 420, eine Filter- und Rückgabeeinheit 422 und einen beschleunigten Punktabtastung(APS)-Bypass-FIFO 424.
Wie hier beschrieben, ist eine Textur eine 2D-Abbildung oder ein 2D-Bild, das aus Pixeln zusammengesetzt und in einem Texturspeicher gespeichert ist. Ein Pixel, das in einer Textur umfasst ist, wird hier als ein „Texel“ bezeichnet. Ein Texel weist ebenfalls eine Position oder einen Ort auf, die/der kennzeichnet, wo das Texel in der Textur lokalisiert ist. Beispielsweise würde ein Texel, das in der zweiten Spalte der dritten Reihe in einer Textur ist, einen Ort von (2, 3) aufweisen. In einer Textur wird die Spaltenzahl einer Texel hier als die „u-Koordinate“ bezeichnet und die Reihenzahl einer Texel wird hier als die „v-Koordinate“ bezeichnet. Wenn der Ort als ein Paar von ganzzahligen Werten ausgedrückt wird, kennzeichnet der Ort ein einziges Texel in der Textur. Anwendungsprogramme führen Texturanweisungen durch, die auf ein oder mehrere Texel in Texturspeichern zugreifen. Derartige Texturanweisungen umfassen Texturoperationen und Texturlasten, die nun beschrieben werden.
Eine Texturoperation führt Berechnungen basierend auf ein oder mehreren Pixeln in einer Textur durch. Im Allgemeinen umfasst eine Texturoperation Gleitkommazahlen, um eine Position in einer Textur zu beschreiben, wie beispielsweise (2.4, 3.6). Ein Ort, der als ein Paar von Gleitkomma oder anderen nicht ganzzahligen Werten ausgedrückt wird, ist innerhalb der Grenzen von vier Texeln. Beispielsweise würde ein Ort von (2.4, 3.6) innerhalb der Grenzen der vier Texeln bei (2, 3), (3, 3), (2, 4) und (3, 4) lokalisiert sein. Als Ergebnis würde eine Texturoperation, die auf den Ort von (2.4, 3.6) gerichtet ist, diese vier Texel abrufen, ein gewichtetes Mittel des Farbenwerts an den vier Texelorten durchführen und dann eine endgültige Farbe basierend auf dem gewichteten Mittel berechnen. In einigen Ausführungsformen können bestimmte Filterungs-Funktionen auf mehr als vier Texel pro Thread zugreifen. Beispielsweise kann 16x trilineare anisotrope Filterung auf bis zu 128 Texel pro Thread zugreifen. Das gewichtete Mittel kann eine beliebige technisch machbare Operation sein, die, ohne Einschränkung, bilineare Interpolation, trilineare Interpolation und verschiedene Filteroperationen umfasst. Ein Anwendungsprogramm, das eine Texturoperation durchführt, empfängt im Gegenzug einen einzigen Farbenwert basierend auf dem gewichteten Mittel von vier Texeln.
Im Gegensatz dazu ruft eine Texturlast lediglich einen einzigen Texelwert an einem ganzzahlig adressierter Ort im Texturspeicher ab, wobei ein ganzzahlig adressierter Ort ein Texel ist, das durch ganzzahlige Koordinaten gekennzeichnet ist. In einigen Ausführungsformen können bestimmte Texturlasten und Punkt-abgetastete Texturoperationen Gleitkomma-Koordinaten benutzen, wobei die Gleitkomma-Koordinaten implizit vier unterschiedliche nächstgelegene Texel gleichzeitig adressieren. Mit Texturlasten und Punkt-abgetastete Texturoperationen führt die Texturverarbeitungs-Pipeline 400 keine Filteroperationen durch. Ein Anwendungsprogramm kann vorziehen, Texturlasten anstatt Texturoperationen durchzuführen, wie beispielsweise, wenn das Anwendungsprogramm eine angepasste gewichtete Mittelung, Interpolation und Filteroperationen durchführt, die nicht durch die eingebaute gewichtete Mittelung unterstützt werden, die von der Texturverarbeitungs-Pipeline 400 durchgeführt wird. Ein derartiges Anwendungsprogramm, das vier Texturlast-Operationen durchführt, die auf die Texel, die bei (2, 3), (3, 3) (2, 4) und (3, 4) lokalisiert sind, gerichtet sind, empfängt im Gegenzug die einzelnen Farbenwerte an diesen vier Texelorten. Das Anwendungsprogramm kann dann eine beliebige Misch- oder Kombinieroperation an den vier Texeln durchführen.
Im Allgemeinen ist die Texturverarbeitungs-Pipeline 400 optimiert, um Texturoperationen durchzuführen. Wenn ein bestimmter Thread eine Texturoperation durchführt, empfängt der Thread einen Farbenwert basierend auf dem gewichteten Mittel der Farbenwerte von vier separaten Texeln. Daher wird die Texturverarbeitungs-Pipeline 400 optimiert, um gleichzeitig auf bis zu vier Texeln in einem einzigen Speicherzugriffzyklus über vier separate Speicheranschlüsse zuzugreifen. Wenn ein Thread eine Texellast durchführt, die auf ein einziges Texel gerichtet ist, greift die Texturlast lediglich auf ein Texel in einem einzigen Speicherzyklus über einen einzigen Speicheranschluss zu. Als Ergebnis sind die verbleibenden drei Speicheranschlüsse unbenutzt. Um auf vier Texels über Texturlasten zuzugreifen, werden vier Texturlasten sequentiell durchgeführt, wobei jede Texturlast auf einen einzigen Speicheranschluss zu einem Zeitpunkt zugreift. Als Ergebnis führt eine einzige Texturoperation in ungefähr einem Viertel der Zeit aus, als es vier Texturlasten würden. Weil Texturlasten außerdem keine gewichtete Mittelung durchführen, um eine endgültige Farbe zu berechnen, sind die Abschnitte der Texturverarbeitungs-Pipeline 400, welche die gewichtete Mittelung durchführen, unbenutzt, was zu weiteren Ineffizienzen führt.
In einigen Ausführungsformen kann die Texturverarbeitungs-Pipeline 400 mehrere Threads gleichlaufend unterbringen. Wenn die Texturverarbeitungs-Pipeline 400 beispielsweise strukturiert ist, um vier gleichlaufende Threads zu unterstützen, dann weist die Texturverarbeitungs-Pipeline 400 sechzehn Speicheranschlüsse auf, um vier Threads zu unterstützen, die vier Texturoperationen durchführen, wobei jede Texturoperation auf vier Texel zugreift. Wenn die vier Threads eine Texturlast durchführen, dann werden vier der Speicheranschlüsse benutzt, um die vier Texturlasten zu unterstützen, und die verbleibenden zwölf Speicheranschlüsse sind unbenutzt. Als Ergebnis führen Texturlasten mit vier Texelzugriffen pro Taktzyklus aus, während Texturoperationen mit sechzehn Texelzugriffen pro Taktzyklus ausführen.
Wie ferner hier beschrieben, können Texturlasten für ‚N‘ unterschiedliche Threads in der Texturverarbeitungs-Pipeline 400 kombiniert werden, um die Nutzung von Texelzugriffen zu verbessern und dadurch die Leistung der Texturverarbeitungs-Pipeline während Texturlasten zu verbessern. Im Allgemeinen kann ‚N‘ eine beliebige Anzahl bis zu der Anzahl von Threads in einem Warp sein. In einigen Ausführungsformen, wenn eine Warp-weite Texturanweisung mit mehr als einer Texturlast pro Thread codiert ist, dann kann ‚N‘ die Anzahl von Threads überschreiten. In derartigen Ausführungsformen kann ‚N‘ eine beliebige Anzahl bis zu der Anzahl von Texturlasten sein, die in einer Warpweiten Texturanweisung codiert sind.
Außerdem können bestimmte Typen von Texturoperationen für ‚N‘ unterschiedliche Threads in der Texturverarbeitungs-Pipeline 400 kombiniert werden, um die Nutzung von Texelzugriffen zu verbessern, und um dadurch die Leistung der Texturverarbeitungs-Pipeline während dieser spezifischen Typen von Texturoperationen zu verbessern. Diese spezifischen Typen von Texturoperationen werden hier als Punkt-abgetastete Texturoperationen bezeichnet. Punkt-abgetastete Texturoperationen sind einfache Texturoperationen, die das Texel anfordern, das am nächsten zu einem bestimmten Gleitkommaort in dem Texturspeicher ist. Beispielsweise könnte eine Punkt-abgetastete Texturoperation, die auf den Ort (2.4, 3.6) gerichtet ist, die Farbe des bei (2, 4) lokalisierten Texels zurückgeben In einigen Ausführungsformen kann die Texturverarbeitungs-Pipeline 400 konfiguriert sein, um die Leistung von Textur-Gather-Operationen zu verbessern, wobei jeder Thread eine Punkt-abgetastete Last einer Komponente von vier umgebenden Texels durchführt. Genauer gesagt greift eine Textur-Gather-Operationen auf vier benachbarten Texturelemente in einem Texturspeicher zu, die am nächsten zu einem durch die Texturspeicherabfrage spezifizierten Ort sind. Beispielsweise könnte eine Textur-Gather-Operation, die auf den Ort (2.4, 3.6) gerichtet ist, eine Punkt-abgetastete Last der roten Farbkomponente für die bei (2, 3), (2, 4), (3, 3) und (3, 4) lokalisierten Texel durchführen. Wie ferner beschrieben, kann die Texturverarbeitungs-Pipeline 400 konfiguriert sein, um Punkt-abgetastete Texturoperationen und/oder Textur-Gather-Operationen für ‚N‘ unterschiedliche Threads zu kombinieren, um die Nutzung von Texelzugriffen zu verbessern.
Wenn ‚N‘ = 2, dann kann der Abschnitt der Texturverarbeitungs-Pipeline 400, der konfiguriert ist, um auf bis zu vier Texelzugriffe für ein Thread zuzugreifen, nun bis zu einem Texel für jeweils zwei Threads gleichzeitig zugreifen. Wenn dieser Abschnitt der Texturverarbeitungs-Pipeline 400 eine Texturlast für zwei Threads durchführt, dann greift die Texturverarbeitungs-Pipeline 400 auf zwei Texel zu, ein Texel für jedes der beiden Threads. Wenn die Texturverarbeitungs-Pipeline 400 beispielsweise strukturiert ist, um vier gleichlaufende Texturoperationen zu unterstützen, dann werden beim Durchführen von Texturlasten acht der Speicheranschlüsse benutzt, um acht Texturlasten für acht Threads zu unterstützen, und die verbleibenden acht Speicheranschlüsse sind unbenutzt. Als Ergebnis führen die Texturlasten mit acht Texelzugriffen pro Taktzyklus aus, während Texturoperationen mit sechzehn Texelzugriffen pro Taktzyklus ausführen. In einigen Ausführungsformen können Texel von mehreren Größen sein. Wenn Texel größer als die Speicheranschlüsse innerhalb der Texturverarbeitungs-Pipeline 400 sind, dann können mehrere Speicheranschlüsse für jedes Texel benutzt werden. Wenn die Texturverarbeitungs-Pipeline 400 beispielsweise 8-Byte-Speicheranschlüsse aufweist und die Texelgröße 16-Byte pro Texel ist, dann benutzt die Texturverarbeitungs-Pipeline 400 Paare von Speicheranschlüssen, um 8 Thread/Zyklus Texturlasten zu unterstützen, um dadurch alle 16 8-Byte-Speicheranschlüsse vollständig zu konsumieren.
Wenn ‚N‘ = 4, dann kann der Abschnitt der Texturverarbeitungs-Pipeline 400, der konfiguriert ist, um auf bis zu vier Texelzugriffe für einen Thread zuzugreifen, nun bis zu einem Texelzugriff für vier Threads zugreifen. Wenn dieser Abschnitt der Texturverarbeitungs-Pipeline 400 eine Texturlast für vier Threads durchführt, dann greift die Texturverarbeitungs-Pipeline 400 auf vier Texel zu, ein Texel für jeden der vier Threads. Wenn die Texturverarbeitungs-Pipeline 400 beispielsweise strukturiert ist, um vier gleichlaufende Texturoperationen zu unterstützen, dann werden, wenn Texturlasten durchgeführt werden, alle sechzehn der Speicheranschlüsse benutzt, um sechzehn Texturlasten für sechzehn Threads zu unterstützen und keine Speicheranschlüsse sind unbenutzt. Als Ergebnis führen Texturlasten mit sechzehn Texelzugriffen pro Taktzyklus aus und Texturoperationen führen ebenfalls mit sechzehn Texelzugriffen pro Taktzyklus aus.
Die Stufen der Texturverarbeitungs-Pipeline 400 werden nun beschrieben.
Im Betrieb verarbeitet die TEXIO-Einheit 402 Texturanweisungen, die Texturlasten und Texturoperationen umfassen. Die TEXIO-Einheit 402 empfängt eine Texturanweisung von dem SM 310 zur Ausführung durch die 32 Threads in einem Warp. Die TEXIO-Einheit 402 spaltet die Texturanweisung in mehrere Abschnitte auf, wobei jeder Abschnitt die Texturanweisung für eine Teilmenge der Threads in dem Warp umfasst. Die TEXIO-Einheit 402 analysiert den Texturanweisungs-Operationscode, hier ebenfalls als einen „Opcode“ bezeichnet, sowie auch bestimmte Parameter und Modifikatoren der Texturanweisung, um eine erste Bestimmung hinsichtlich dessen vorzunehmen, ob die Texturanweisung mit vier Threads pro Taktzyklus oder mit einer höheren Anzahl von Threads pro Taktzyklus ausführen kann.
Anfangs nimmt die TEXIO-Einheit 402 an, dass die Texturanweisung mit einer Rate ausführen kann, die größer als vier Threads pro Taktzyklus ist. Daher ruft die TEXIO-Einheit 402 die Parameter der Texturanweisung einer Parameterwarteschlange (nicht gezeigt) in einer Art und Weise ab, die das unterstützen kann, das größer als vier Threads pro Takt ist, wie beispielsweise, ohne Einschränkung, eine Ausführungsrate von acht Threads pro Zyklus. Als Ergebnis ist das Parameterpacken für eine Drei-Parameter-Texturanweisung anders als das Parameterpacken für eine Vier-Parameter-Texturanweisung. Im Fall einer Vier-Parameter-Texturanweisung werden die Texturanweisungs-Parameter mit Vier-Parameterpacken gepackt. Wenn Drei-Parameter-Texturanweisungen ebenfalls mit Vier-Parameterpacken gepackt werden, kann die Texturverarbeitungs-Pipeline 400 nicht in der Lage sein, die Parameter abzurufen und zu verarbeiten, wenn mit einer Rate von größer als vier Threads pro Taktzyklus ausgeführt wird. Das Parameterpacken ist jedoch effizienter, wenn Parameter in Gruppen von Zweierpotenzen gepackt werden. Daher werden im Fall einer Drei-Parameter-Texturanweisung die Texturanweisungs-Parameter mit Ein-Parameterpacken abwechselnd mit Zwei-Parameterpacken gepackt. Auf diese Art und Weise werden die Parameter für eine Drei-Parameter-Texturanweisung in Gruppen von Zweierpotenzen kompakt gepackt und die Texturverarbeitungs-Pipeline kann eine Ausführungsrate von größer als vier Threads pro Taktzyklus aufrechterhalten.
Wenn die TEXIO-Einheit 402 bestimmt, dass die Texturanweisung nicht mit einer höheren Rate der Ausführung als vier Threads pro Taktzyklus ausgeführt werden kann, dann legt die TEXIO-Einheit 402 ein „Veto“ gegen die Bestimmung ein, dass die Texturanweisung mit der Rate gemäß der aktuellen Konfiguration ausführen kann. Die TEXIO-Einheit 402 konfiguriert dann die Anweisung neu, um mit einer niedrigeren Rate auszuführen. Beispielsweise könnte die TEXIO-Einheit 402 ein Veto gegen die Konfiguration einer Texturanweisung aufrechterhalten, die mit acht Threads pro Taktzyklus ausführt, und die Texturanweisung neu konfigurieren, um mit vier Threads pro Taktzyklus auszuführen.
Wenn die TEXIO-Einheit 402 bestimmt, dass die Texturanweisung lediglich mit vier Threads pro Taktzyklus ausführen kann, dann spaltet die TEXIO-Einheit 402 die Texturanweisung in acht Abschnitte von jeweils vier Threads auf, um mit einer Rate von vier Threads pro Taktzyklus auszuführen. Wenn die TEXIO-Einheit 402 bestimmt, dass die Texturanweisung mit einer Rate größer als vier Threads pro Taktzyklus ausführen kann, wie beispielsweise mit einer Texturlast, dann spaltet die TEXIO-Einheit 402 die Texturanweisung in Abschnitte basierend auf dem Wert von ‚N‘ auf. Beispielsweise wird dann, wenn ‚N‘ = 2, eine Texturanweisung, die mit einer höheren Rate ausführen kann, in vier Abschnitte von jeweils acht Threads aufgeteilt und die Texturanweisung führt mit einer Rate von acht Threads pro Taktzyklus aus. Wenn ‚N‘ = 4, dann wird die Texturanweisung in zwei Abschnitte von jeweils sechzehn Threads aufgeteilt und die Texturanweisung führt mit einer Rate von sechzehn Threads pro Taktzyklus aus und so weiter. Für den Zweck der folgenden Erläuterung sei angenommen, dass ‚N‘ gleich 2 ist. ‚N‘ könnte jedoch eine beliebige technisch machbare Zahl sein.
In einigen Fällen kann die TEXIO-Einheit 402 nicht in der Lage sein, zu bestimmen, ob die Texturanweisung mit vier Threads pro Taktzyklus oder acht Threads pro Taktzyklus ausführen kann, basierend auf dem Opcode. In derartigen Fällen macht die TEXIO-Einheit 402 die optimistische Annahme, das anschließende Stufen der Texturverarbeitungs-Pipeline 400 in der Lage sind, die höhere Texturanweisung-Ausführungsrate zu unterstützen. Anschließend kann eine beliebige andere Stufe der Texturverarbeitungs-Pipeline 400 bestimmen, dass die Texturanweisung nicht mit der aktuellen Konfiguration ausführen kann. Wenn eine Stufe der Texturverarbeitungs-Pipeline 400 bestimmt, dass die Texturanweisung nicht mit der aktuell konfigurierten Rate ausführen kann, legt die Stufe ein Veto gegen die Bestimmung ein, dass die Texturanweisung mit der Rate gemäß der aktuellen Konfiguration ausführen kann. Genauer gesagt, wenn eine gegebene Stufe in der Texturverarbeitungs-Pipeline 400 eine Texturanweisung empfängt, in einem Taktzyklus auszuführen, wobei diese Stufe jedoch mehrere Taktzyklen benötigt, um die Texturanweisung auszuführen, blockiert die Stufe die Pipeline, spaltet die Texturanweisung in Unterstücke auf und führt jedes Unterstück der Texturanweisung nacheinander aus. Die Stufe konfiguriert die Texturanweisung neu, um mit einer niedrigeren Rate auszuführen. Beispielsweise könnte eine Stufe gegen die Konfiguration einer Texturanweisung ein Veto einlegen, die mit acht Threads pro Taktzyklus ausführt, und die Texturanweisung neu konfigurieren, um mit vier Threads pro Taktzyklus auszuführen. Wie hier beschrieben, ist die TEXIN-Einheit 404 in der Lage, gegen die Bestimmung ein Veto einzulegen, dass die Texturanweisung mit der Rate gemäß der aktuellen Konfiguration ausführen kann. Allgemeiner kann jede beliebige technisch machbare Stufe der Texturverarbeitungs-Pipeline ein Veto gegen die Bestimmung einlegen.
Die TEXIN-Einheit 404 empfängt aufgeteilte Texturanweisungen von der TEXIO-Einheit 402. Die TEXIN-Einheit 404 ruft den Textur-Header-Zustand und Textur-Sampler-Zustand eines Speichers basierend auf einem Textur Header-Index und einem Textur-Sampler-Index ab, die in der Texturanweisung umfasst sind. Der Textur-Header-Zustand und der Textur-Sampler-Zustand werden in einem Speicher gespeichert, der extern zu der Texturverarbeitungs-Pipeline 400 ist. Die TEXIN-Einheit 404 speichert den abgerufenen Textur-Header-Zustand und Textur-Sampler-Zustand in einem lokalen Speicher-Cache (nicht gezeigt). Jede Stufe in der Texturverarbeitungs-Pipeline 400 ruft den Textur-Header-Zustand und Textur-Sampler-Zustand nach Bedarf ab, um die Operationen für diese Stufe durchzuführen. Ferner kann dann, wenn eine anschließende Texturanweisung den gleichen Textur-Header-Index und/oder Textur-Sampler-Index wie eine vorherige Texturanweisung umfasst, die TEXIN-Einheit 404 auf die Textur-Header-Zustand und Textur-Sampler-Zustand über die lokalen Speicher-Cache zugreifen. Das Zugreifen auf den Textur-Header-Zustand und den Textur-Sampler-Zustand über den lokalen Speicher-Cache vermeidet das Abrufen des Textur-Header-Zustands und Textur-Sampler-Zustands von externen Speicher, wenn der Zustand im lokalen Speicher-Cache vorhanden ist.
Der Textur Header-Index ist ein Zeiger auf eine Tabelle von Textur-Header-Zustandsdaten, die das Format der Textur in dem Speicher beschreibt, einschließlich, ohne Einschränkung, den Ort der Textur in Speicher, die Maße der Textur, die Anzahl von Farbkomponenten pro Texel, die Anzahl von Bits pro Farbkomponente und ob die Texturdaten komprimiert sind. Der Sampler-Header-Index ist ein Zeiger auf eine Tabelle von Textur-Sampler-Zustandsdaten, die beschreiben, wie die Textur abzutasten ist und den Typ des Filtern, der auf die Texel anzuwenden ist, die von der Textur empfangen werden.
Die TEXIN-Einheit 404 analysiert den Textur-Header-Zustand und den Textur-Sampler-Zustand, die der Texturanweisung zugeordnet sind, um eine zweite Bestimmung hinsichtlich dessen vorzunehmen, ob die Texturanweisung mit acht Threads pro Taktzyklus oder mit vier Threads pro Taktzyklus ausführen kann. Wenn die TEXIN-Einheit 404 bestimmt, dass eine eingehende Texturanweisung, die konfiguriert ist, um mit acht Threads pro Taktzyklus auszuführen, lediglich mit vier Threads pro Taktzyklus ausführen kann, dann legt die TEXIN-Einheit 404 ein Veto gegen die Konfiguration ein. Die TEXIN-Einheit 404 konfiguriert die Texturanweisung neu, um mit vier Threads pro Taktzyklus auszuführen.
Beispielsweise könnte die TEXIN-Einheit 404 basierend auf dem Textur-Sampler-Zustand bestimmen, ob die Texturanweisung eine Punkt-abgetastete Texturoperation ist, die das nächstgelegenste Texel anfragt. Wenn die Texturanweisung eine Punkt-abgetastete Texturoperation ist, dann bestimmt die TEXIN-Einheit 404, dass die Texturanweisung mit acht Threads pro Taktzyklus ausführen kann. Andererseits kann die TEXIN-Einheit 404 basierend auf dem Textur-Sampler-Zustand bestimmen, dass die Texturanweisung einer komplexeren Abtastung oder Filteroperation zugeordnet ist. In derartigen Fällen legt die TEXIN-Einheit 404 ein Veto gegen die Texturanweisung ein und konfiguriert die Anweisung neu, um mit vier Threads pro Taktzyklus auszuführen. Auf ähnliche Weise, wenn die Textur-Header-Zustandsdaten angeben, dass die Texturanweisung auf eine Textur gerichtet ist, die komprimierte Daten umfasst, dann bestimmt die TEXIN-Einheit 404, dass die Texturanweisung mit vier Threads pro Taktzyklus ausgeführt werden kann.
Bestimmte Zustandsdaten sind ein Kreuzprodukt der Texturanweisung, des Header-Zustands und des Sampler-Zustands. In derartigen Fällen bestimmt die TEXIN-Einheit 404, ob ein Veto gegen eine Konfiguration einer Texturanweisung basierend auf bestimmten Kombinationen von Texturanweisung, Header-Zustand und Sampler-Zustand einzulegen ist. Die Texturverarbeitungs-Pipeline 400 behält die separate Speicherung für die Texturanweisung, den Header-Zustand und die Sampler-Zustand bei, um auf die Texturen ordnungsgemäß zuzugreifen. Das Beibehalten dieser separate Speicherung ermöglicht der TEXIN-Einheit 404 und anderen Stufen der Texturverarbeitungs-Pipeline 400, ein Veto gegen eine Entscheidung basierend auf derartigen Kreuzprodukt-Zustandsdaten einzulegen.
Wenn eine Texturanweisung weder eine Texturlast noch eine Punkt-abgetastete Texturoperation ist, dann überträgt die TEXIN-Einheit 404 die Anweisung an die LOD-Einheit 406, um mit vier Threads pro Taktzyklus auszuführen. Wenn die Texturanweisung eine Texturlast oder eine Punkt-abgetastete Texturoperation ist, überträgt die TEXIN-Einheit 404 die Anweisung an die APS-Umgehungseinheit 424, um mit ‚N‘ X vier Threads pro Taktzyklus auszuführen. Wenn beispielsweise ‚N‘ = 2 ist, dann überträgt die TEXIN-Einheit 404 die Anweisung an die APS-Umgehungseinheit 424, um mit acht Threads pro Taktzyklus auszuführen.
Die LOD-Einheit 406 ist konfiguriert, um einen „Detaillierungsgrad“ für die Textur zu berechnen, auf die von dem Speicher basierend auf der Position und Orientierung eines Satzes von Texelkoordinaten zuzugreifen ist, die innerhalb der Texturanweisung umfasst sind. Vier Threads, die zusammen arbeiten, können Texturanweisungen ausführen, die Koordinaten für vier Orte umfassen, die ein geometrisches Primitiv, wie beispielsweise ein Viereck, auf einer Oberfläche in einer 3D-Graphikszene definieren. Die LOD-Einheit 406 berechnet einen Detaillierungsgrad und wählt eine entsprechende Textur aus einem Satz von Texturen basierend auf dem Abstand der vier Orte voneinander aus. Jede Textur in dem Satz von Texturen definiert das gleiche Texturbild, jedoch bei unterschiedlichen räumlichen Auflösungen oder Detaillierungsdaten. Die LOD-Einheit 406 wählt die Textur aus, die, wenn die vier Orte in entsprechenden Texelorten abgebildet werden, den Abstand der vier Texels untereinander minimiert. Nach Berechnen des Detaillierungsgrades überträgt die LOD-Einheit 406 die Texturanweisung an die Abtaststeuerungs- und Adressiereinheit 408.
Der APS-Bypass-FIFO 424 ist ein Latenz-abgleichendes FIFO, um die Latenz der LOD-Einheit 406 abzugleichen. In einigen Ausführungsformen können einige Texturanweisungen, die innerhalb der Texturverarbeitungs-Pipeline 400 ausführen, die LOD-Einheit 406 einsetzen, während andere Texturanweisungen innerhalb der Texturverarbeitungs-Pipeline 400 ausführen, wie beispielsweise Texturlasten und Punkt-abgetastete Texturoperationen, welche die LOD-Einheit 406 nicht einsetzen können.
Texturanweisungen, welche die LOD-Einheit 406 einsetzen, laufen durch die LOD-Einheit 406. Texturanweisungen, welche die LOD-Einheit 406 nicht einsetzen, laufen nicht durch die LOD-Einheit 406. Wenn die LOD-Einheit 406 aktuell keine Texturoperation verarbeitet und die TEXIN-Einheit 404 eine Texturanweisung überträgt, welche die LOD-Einheit 406 nicht einsetzt, dann umgeht die Texturanweisung die LOD-Einheit 406. Die Texturanweisung durchquert den APS-Bypass-FIFO 424 mit wenig bis keiner Verzögerung und kommt an der Abtaststeuerungs- und Adressiereinheit 408 an. Wenn die LOD-Einheit 406 aktuell eine beliebige Texturoperation verarbeitet und die TEXIN-Einheit 404 eine Texturanweisung überträgt, welche die LOD-Einheit 406 nicht einsetzt, dann umgeht die Texturanweisung die LOD-Einheit 406. Die Texturanweisung tritt in den APS-Bypass-FIFO 424 ein und bleibt innerhalb des APS-Bypass-FIFO 424, bis die Texturanweisungs-Verarbeitung durch die LOD-Einheit 406 an der Abtaststeuerungs- und Adressiereinheit 408 ankommt. Anschließend kommt die Texturanweisung innerhalb des APS-Bypass-FIFO 424 an der Abtaststeuerungs- und Adressiereinheit 408 an. Auf diese Art und Weise bleibt Texturanweisungs-Verarbeitung durch die LOD-Einheit 406 und den APS-Bypass-FIFO 424 in der ursprünglichen Reihenfolge.
Im Betrieb empfängt die Abtaststeuerungs- und Adressiereinheit 408 Texturanweisungen der LOD-Einheit 406 und des APS-Bypass-FIFO 424. Der Stream von Texturanweisungen der LOD-Einheit 406 ist in Ordnung. Gleichermaßen ist der Stream von Texturanweisungen des APS-Bypass-FIFO 424 in Ordnung. Eine spätere Texturanweisung der LOD-Einheit 406 kann jedoch an die Abtaststeuerungs- und Adressiereinheit 408 vor einer früheren Texturanweisung des APS-Bypass-FIFO 424 ankommen. Gleichermaßen kann eine spätere Texturanweisung des APS-Bypass-FIFO 424 an der Abtaststeuerungs- und Adressiereinheit 408 vor einer früheren Texturanweisung der LOD-Einheit 406 ankommen. Weil die Abtaststeuerungs- und Adressiereinheit 408 Texturanweisungen von zwei unterschiedlichen Quellen empfängt, können die Texturanweisungen außer Ordnung geraten. Daher erfasst die Abtaststeuerungs- und Adressiereinheit 408 Texturanweisungen außerhalb der Reihenfolge und wählt die Texturanweisung der LOD-Einheit 406 und des APS-Bypass-FIFO 424 basierend darauf aus, welche Texturanweisung einen früheren Zeitstempel aufweist. Auf diese Art und Weise sortiert die Abtaststeuerungs- und Adressiereinheit 408 die Streams von Texturanweisungen der LOD-Einheit 406 und des APS-Bypass-FIFO 424 in der korrekten Reihenfolge, wie durch die TEXIN-Einheit 404 übertragen.
Die Abtaststeuerungs- und Adressiereinheit 408 führt verschiedene Abtast- und Filteroperationen für bestimmte Texturanweisungen durch. Die Abtaststeuerungs- und Adressiereinheit 408 stellt ebenfalls Information bereit, über wie Texturen für bestimmte Texturanweisungen abgetastet werden. Die Abtaststeuerungs- und Adressiereinheit 408 verarbeitet ebenfalls Texturanweisungen mit Texelkoordinaten, die sich über die Grenzen einer gegebene Textur hinaus erstrecken oder welche die Grenze zwischen zwei Texturen überspannen. Die Abtaststeuerungs- und Adressiereinheit 408 vergleicht die Texelkoordinaten mit der Größe der ausgewählten Textur. Wenn die Texelkoordinaten außerhalb der Grenzen der ausgewählten Textur sind, dann führt die Abtaststeuerungs- und Adressiereinheit 408 ein oder mehrere Operationen durch, um die Texelkoordinaten außerhalb der Grenzen zu verarbeiten. Die Abtaststeuerungs- und Adressiereinheit 408 kann Koordinaten außerhalb der Grenzen der Textur klemmen oder begrenzen. Zusätzlich oder alternativ kann die Abtaststeuerungs- und Adressiereinheit 408 Koordinaten außerhalb der Grenzen zu der gegenüberliegenden Seite der Textur durch Durchführen einer MOD-Operation an den Koordinaten außerhalb der Grenzen „wickeln“. Zusätzlich oder alternativ kann die Abtaststeuerungs- und Adressiereinheit 408 die Texturoperation zu nichte machen oder verwerfen, die eine oder mehrere Koordinaten außerhalb der Grenzen umfasst. Auf diese Art und Weise gewährleistet die Abtaststeuerungs- und Adressiereinheit 408, dass alle Texelkoordinaten innerhalb der Grenzen der relevanten Textur sind.
Wenn die aktuelle Texturoperation eine Texturlast oder eine Punkt-abgetastete Texturoperation ist, werden diese Filteroperationen nicht durchgeführt. Stattdessen wandelt, wenn die Koordinaten für die Texturlast oder Punkt-abgetastete Texturoperation im Gleitkommaformat sind, die Abtaststeuerungs- und Adressiereinheit 408 die Koordinaten in ganzzahligen Texelkoordinaten um. Diese Umwandlung in eine Oberflächen-Lastanweisung ermöglicht der Texturlast oder der Punkt-abgetasteten Texturoperation, existierende Schaltungen für Oberflächenanweisungen zu verwenden, die bereits optimiert sind, um acht Threads unterzubringen.
Ferner führt die Abtaststeuerungs- und Adressiereinheit 408 verschiedene Adressberechnungen basierend auf den Texelkoordinaten innerhalb der Texturanweisung und dem Detaillierungsgrad aus, um eine Markierung zu erzeugen. Die Markierung entspricht einem Eintrag in eine Markierungstabelle, die innerhalb der Markierungseinheit 410 umfasst ist. Die Markierung kennzeichnet eine eindeutige Cache-Zeile im Speicher, wo die relevanten Texels gespeichert sind. In einigen Ausführungsformen kann eine Cache-Zeile aus 128 Bytes bestehen. Ein zugeordneter Versatz kennzeichnet den Ort des ersten Byte des relevanten Texels innerhalb der Cache-Zeile. In einigen Ausführungsformen ist die Markierung ferner einem Wert zugeordnet, der die Größe des relevanten Texeis angibt. In einigen Ausführungsformen kann die Markierung basierend auf dem Index des Texels, dem Texturtyp und den oberen Bits der Koordinaten aller der Texels in der Cache-Zeile gespeicherten Texels gebildet sein. Alle Texel in einer bestimmter Cache-Zeile nutzen bestimmte obere Bits der Texelkoordinaten gemeinsam, wobei diese oberen Bits teilweise verwendet werden, um die Markierung zu bilden. Die Abtaststeuerungs- und Adressiereinheit 408 leitet die Texturanweisung, Adressenberechnungsergebnisse und Abtaststeuerinformation an die Markierungseinheit 410 und die Filtergewichtungseinheit 418. Die Abtaststeuerungs- und Adressiereinheit 408 kann bis zu 16 Texel-Markierung/Versatz/Satz-Kennzeichner-Kombinationen pro Taktzyklus erzeugen, um bis zu 16 Texels gleichlaufend abzurufen.
Die Markierungseinheit 410 empfängt bis zu 16 Texel-Markierung/Versatz/Satz-Kennzeichner-Kombinationen pro Taktzyklus der Abtaststeuerungs- und Adressiereinheit 408 und wiederum Zugriffe bis zu 16 Texel pro Taktzyklus. Die Markierungseinheit 410 umfasst eine Markierungstabelle, die einen Satz von Textur-Header-Einträgen speichert.
Jeder Textur-Header-Eintrag in der Markierungseinheit 410 stellt eine Cache-Zeile innerhalb der Recheneinheit 416 dar. Die Recheneinheit 416 kann einen Cache-Speicher darstellen, der sich innerhalb der Textureinheit 315 befindet, oder kann einen beliebigen technisch machbaren Cache-Speicher darstellen, der dem SM 310 zugeordnet ist. Bei Empfang der Speicherzugriffanfrage und Adressierungs-Berechnungsergebnisse der Abtaststeuerungs- und Adressiereinheit 408, bestimmt die Markierungseinheit 410, ob die Markierungstabelle einen Textur-Header-Eintrag umfasst, welcher den abgerufenen Texturdaten entspricht.
Wenn die Markierungstabelle einen Eintrag umfasst, der den Texturdaten entspricht, auf die zuzugreifen ist, findet ein Cache-Treffer statt und die Markierungseinheit 410 bestimmt, dass Texturdaten, auf die zuzugreifen sind, in der Recheneinheit 416 liegen. Die Markierungseinheit 410 ruft den Eintrag durch Durchsuchen der Markierungstabelle ab und ruft einen Zeiger auf die Daten innerhalb der Recheneinheit 416 ab, wo sich die Texturdaten tatsächlich befinden. Die Markierungseinheit 410 leitet den Versatz an den Daten-FIFO 414.
Wenn die Markierungstabelle keinen Textur-Header-Eintrag umfasst, der den Texturdaten entspricht, auf die zuzugreifen sind, tritt ein Cache-Fehltreffer auf und die Markierungseinheit 410 veranlasst die Fehltrefferverarbeitungseinheit 412, auf die angeforderten Texturdaten von einem externen Speicher zuzugreifen.
Der Daten-FIFO 414 verzögert zusammen mit dem Filtergewichtungs-FIFO 420 die Informationen der Markierungseinheit 410, um eine entsprechende Verzögerung einzusetzen. Als Ergebnis kommen die Daten der Markierungseinheit 410 und entsprechende Daten der Filtergewichtungseinheit 418 an der Recheneinheit 416 zur gleichen Zeit an.
Die Filtergewichtungseinheit 418 bereitet die Pro-Texelgewichtungen zum Interpolieren und/oder Filtern der Texelwerte in der Filter- und Rückgabeeinheit 422 vor.
Der Filtergewichtungs-FIFO 420 verzögert die Informationen der Filtergewichtungseinheit 418, um die Verzögerung durch die Markierungseinheit 410, den Daten-FIFO 414 und anderen zugeordneten Stufen der Texturverarbeitungs-Pipeline 400 abzugleichen. Als Ergebnis kommen die Daten der Filtergewichtungseinheit 418 und entsprechende Daten der Markierungseinheit 410 an der Recheneinheit 416 zur gleichen Zeit an.
Die Fehltrefferverarbeitungseinheit 412 greift auf die angeforderten Texel durch Berechnen einer virtuellen Adresse basierend auf Daten zu, die innerhalb der Texturanweisung, dem Textur-Header und den Texelkoordinaten umfasst sind, die durch die Abtaststeuerungs- und Adressiereinheit 408 berechnet werden. Die Fehltrefferverarbeitungseinheit 412 überträgt dann eine Leseanforderung, um die angeforderten Daten eines physischen Orts zu lesen. In verschiedenen Ausführungsformen kann sich die Fehltrefferverarbeitungseinheit 512 innerhalb der Textureinheit 315 oder innerhalb in der 3A gezeigten MMU 320 befinden. Die Recheneinheit 416 empfängt die Texeldaten von dem externen Speicher über die Speicherschnittstelle 214 und die Kreuzschieneneinheit 210. Die Recheneinheit 416 aktualisiert die Markierungstabelle innerhalb der Markierungseinheit 410, um das neu im Cache gespeicherte Texel zu reflektieren.
Die Recheneinheit 416 empfängt einen Zeiger auf eine Cache-Zeile für ein oder mehrere Texel von dem Daten-FIFO 414. Die Recheneinheit 416 empfängt ebenfalls entsprechende Filtergewichtungswerte, wenn überhaupt, von dem Filtergewichtungs-FIFO 420. Die Recheneinheit 416 ruft die ein oder mehrere Texel die dem einen oder mehrere Texeln zugeordneten Daten aus dem Cache-Speicher ab. Die Recheneinheit 416 leitet die abgerufenen Daten und zugeordneten Filtergewichtungs-Informationen an die Filter- und Rückgabeeinheit 422 weiter. In bestimmten Fällen kann die Recheneinheit 416 die Zugriffe auf die Texeldaten in mehreren Taktzyklen serialisieren, um bestimmte Zugriffsrandbedingungen auf dem Speicher-Cache innerhalb der Recheneinheit 416 unterzubringen. Die Recheneinheit 416 sammelt und deserialisiert derartige Texeldaten, bis sämtliche der Texeldaten, die benötigt werden, um jede einzelne von dem Daten-FIFO 414 empfangenen Anfrage abzuschließen, akkumuliert ist. Im Allgemeinen werden mehrere Anfragen von dem Daten-FIFO 414 durchgeführt, um ein Warp-weite Anweisung abzuschließen. Wenn eine Warp-Anweisung beispielsweise 32 Threads aufweist und Textur-Filteroperationen 4 Threads auf einmal verarbeiten, werden von der Daten-FIFO 414 empfangene 8 Anfragen oder mehr durchgeführt, um eine Texturanweisung abzuschließen. Außerdem können die in der Recheneinheit 416 gespeicherten Texeldaten über beliebige technisch machbare Kompressionstechniken komprimiert werden. In derartigen Fällen kann die Recheneinheit 416 die Texeldaten zur weiteren Verarbeitung dekomprimieren.
An diesem Punkt weist die Recheneinheit 416 nun die Texeldaten auf, die benötigt werden, um den Abschnitt der Texturanweisung zu vervollständigen, wobei der Abschnitt der Texturanweisung hier als eine „Wellenfront“ bezeichnet wird. Texturanweisungen schreiten durch die Texturverarbeitungs-Pipeline 400 als ein Reihe von derartigen Wellenfronten fort, wobei jede Wellenfront ‚M‘ Threads pro Taktzyklus verarbeitet. Eine Wellenfront wird pro Taktzyklus von Stufe zu Stufe innerhalb der Texturverarbeitungs-Pipeline 400 weitergeleitet. Wellenfronten für Punkt-abgetastete Texturoperationen und Texturlasten können 8 Threads von Datenwerten umfassen. Wellenfronten zum Filtern von Texturoperationen können Daten für bis zu 4 Threads umfassen. Für bestimmte Texturanweisungen umfassen die Texeldaten ein Texel für jeden Thread bis zu der Anzahl von verfügbaren Speicheranschlüssen. Für andere bestimmte Texturanweisungen umfassen die Texeldaten vier Texel für jeweils von bis zu 4 Threads.
Mit herkömmlichen Vorgehensweisen gibt eine Texturanweisung, die eine Texturlast oder eine Texturoperation umfasst, die gleiche Menge von Daten pro Thread zurück. Beispielsweise könnten die aktuellen Techniken bis zu vier 32-Bit-Datenkomponenten für jeden von vier Threads über zwei Taktzyklen für eine Gesamtzahl von vier Threads mal 64 Bits oder 256 Bits zurückgeben. Mit den offenbarten Techniken könnte eine Texturanweisung bis zu einer Gesamtzahl von acht Threads mal 64 Bits oder 512 Bits pro Taktzyklus zurückgeben.
Die Filter- und Rückgabeeinheit 422 empfängt Daten und zugeordnete Filtergewichtungswerte der Recheneinheit 416. Die Filter- und Rückgabeeinheit 422 wendet ein oder mehrere Filter auf die empfangenen Daten an, die, ohne Einschränkung, isotrope Filter und anisotrope Filter umfassen. Die Filter- und Rückgabeeinheit 422 berechnet den endgültigen Farbenwert für die verschiedenen Abschnitte der Texturanweisung, wobei jeder Abschnitt endgültige Farbenwerte für einen Abschnitt der 32 Threads in dem Warp umfasst. Für bestimmte Texturanweisungen kann die Filter- und Rückgabeeinheit 422 vier endgültige Farbendatenwerte für vier Threads pro Taktzyklus über acht Taktzyklen berechnen. Für bestimmte andere Texturanweisungen kann die Filter- und Rückgabeeinheit 422 acht endgültige Farbendatenwerte für acht Threads pro Taktzyklus über vier Taktzyklen berechnen. Die Filter- und Rückgabeeinheit 422 umfasst ferner einen Bypass-FIFO (nicht gezeigt), der die Filter und zugeordnete Logik für Texturlasten und Punkt-abgetastete Texturoperationen umgeht. Die Filter- und Rückgabeeinheit 422 stellt die endgültigen Farbendaten für jeden der 32 Threads in dem Warp zusammen. Die Filter- und Rückgabeeinheit 422 überträgt die endgültigen Farbendaten für alle 32 Threads an den SM 310.
Im Allgemeinen führen die Stufen der Texturverarbeitungs-Pipeline 400 mit acht Threads pro Zyklus aus, es sei denn, und bis, eine bestimmte Stufe nicht ausreichende Ressourcen aufweist, um die aktuelle Texturanweisung mit dieser Rate auszuführen. Die Stufe legt dann ein Veto gegen die aktuelle Konfiguration der Texturanweisung ein und konfiguriert die Texturanweisung neu, um mit vier Threads pro Zyklus auszuführen. Wie hier beschrieben, erzeugt die TEXIO-Einheit 402 Vetos basierend auf dem Texturanweisung-Opcode zusammen mit zugeordneten Anweisungs-Modifikatoren. Die TEXIN-Einheit 404 erzeugt Vetos basierend auf der Texturanweisung, dem Header-Zustand und dem Sampler-Zustand entweder allein oder in einer beliebigen Kombination. Verschiedene nicht exklusive Bedingungen, die zu einem Veto führen, werden nun beschrieben.
In einem Beispiel könnte die TEXIO-Einheit 402 eine Texturanweisung mit einem Opcode empfangen, der nicht berechtigt ist, mit mehr als vier Threads pro Taktzyklus auszuführen. Als Ergebnis legt die TEXIO-Einheit 402 ein Veto gegen die Konfiguration der Texturanweisung ein.
In einem anderen Beispiel könnte die TEXIO-Einheit 402 eine Texturlast empfangen und bestimmen, dass die Texturlast berechtigt sein kann, mit acht Threads pro Taktzyklus auszuführen. Anschließend greift die TEXIN-Einheit 404 auf die Headerzustandsdaten zu und bestimmt, das die Textur aus Texeln besteht, die jeweils 96-Bit weit sind. Weil die Texturverarbeitungs-Pipeline 400 nicht konfiguriert ist, um 8 Texel von 96-Bit in einem Taktzyklus abzurufen und zu verarbeiten, legt die TEXIN-Einheit 404 ein Veto gegen die Konfiguration der Texturlast ein.
In noch einem anderen Beispiel könnte die TEXIO-Einheit 402 eine Texturoperation empfangen und bestimmen, dass die Texturoperation berechtigt sein kann, mit acht Threads pro Taktzyklus auszuführen, wenn die Texturoperation die nächste Texelabtastung durchführt. Anschließend greift die TEXIN-Einheit 404 auf die Sampler-Zustandsdaten zu und bestimmt, ob die Texturoperation eine komplexere Abtastung und/oder Filterung durchführt. Weil die Texturverarbeitungs-Pipeline 400 nicht konfiguriert ist, um 8 Texel mit komplexer Abtastung und/oder Filterung in einem Taktzyklus zu verarbeiten, legt die TEXIN-Einheit 404 ein Veto gegen die Konfiguration einer Texturoperation ein, die eine derartige komplexe Abtastung und/oder Filterung umfasst. Wenn andererseits die Texturoperation die nächste Texelabtastung durchführt, dann ist die Texturoperation berechtigt, um mit acht Threads pro Taktzyklus auszuführen und die TEXIN-Einheit 404 legt gegen die Konfiguration der Texturoperation kein Veto ein.
In noch einem anderen Beispiel könnte die TEXIO-Einheit 402 eine Texturoperation empfangen und bestimmen, dass die Texturoperation berechtigt sein kann, mit acht Threads pro Taktzyklus auszuführen. Anschließend greift die TEXIN-Einheit 404 auf die Header-Zustandsdaten und bestimmt, dass die Texturoperation auf eine Textur gerichtet ist, die komprimierte Texturdaten umfasst. Weil die Texturverarbeitungs-Pipeline 400 nicht konfiguriert ist, um 8 Texel in einem Taktzyklus zu dekomprimieren und zu verarbeiten, legt die TEXIN-Einheit 404 ein Veto gegen die Konfiguration der Texturoperation ein.
In noch einem anderen Beispiel könnte die TEXIO-Einheit 402 eine Texturoperation empfangen und bestimmen, dass die Texturoperation berechtigt sein kann, um mit acht Threads pro Taktzyklus auszuführen. Anschließend greift die TEXIN-Einheit 404 auf die Header-Zustandsdaten zu und bestimmt, dass die Texturoperation auf die LOD-Einheit 406 zugreift, die in der Lage ist, lediglich mit vier Threads pro Taktzyklus auszuführen. Die TEXIN-Einheit 404 bestimmt aus den Header-Zustand Daten die Anzahl der Detaillierungsgrade, die in der Textur umfasst sind. Wenn die Textur mehrere Detaillierungsgrade umfasst und die Texturanweisung die Berechnung einer LOD spezifiziert, dann legt die TEXIN-Einheit 404 ein Veto gegen die Konfiguration der Texturoperation ein und richtet die Texturoperation auf die LOD-Einheit 406. Wenn andererseits die Textur lediglich einen Detaillierungsgrad umfasst, dann gibt es keinen Bedarf, die Texturoperation auf die LOD-Einheit 406 zu richten, weil es keinen Bedarf gibt, zu bestimmen, auf welchen Detaillierungsgrad zuzugreifen ist. Daher legt die TEXIN-Einheit 404 kein Veto gegen die Konfiguration der Texturoperation ein und richtet die Texturoperation auf den APS-Bypass-FIFO 424.
In noch einem anderen Beispiel könnte die TEXIO-Einheit 402 eine Texturoperation empfangen und bestimmen, dass die Texturoperation berechtigt sein kann, mit acht Threads pro Taktzyklus auszuführen. Anschließend greift die TEXIN-Einheit 404 auf die Header-Zustandsdaten zu und bestimmt den Adressiermodus der Texturoperation, wie durch die Abtaststeuerungs- und Adressiereinheit 408 bestimmt. Der Adressiermodus bestimmt, wie Texeladressen zu verarbeiten sind, welche die Abtaststeuerungs- und Adressiereinheit 408 bestimmt, außerhalb der Grenzen der Textur zu sein. Wenn der Adressiermodus der Texturoperation ein einfacher Adressiermodus ist, wie beispielsweise eine Klemme an dem Wert des nächsten Grenztexels, dann legt die TEXIN-Einheit 404 kein Veto gegen die Konfiguration der Texturoperation ein. Wenn andererseits der Adressiermodus der Texturoperation ein komplexerer Adressiermodus ist, der eine zusätzliche Verarbeitung für Texel außerhalb der Grenze erfordert, dann legt die TEXIN-Einheit 404 ein Veto gegen die Konfiguration der Texturoperation ein.
In noch einem anderen Beispiel könnte die TEXIO-Einheit 402 eine Texturoperation empfangen und bestimmen, dass die Texturoperation berechtigt sein kann, mit acht Threads pro Taktzyklus auszuführen. Anschließend greift die TEXIN-Einheit 404 auf die Header-Zustandsdaten zu und bestimmt, dass die Texturoperation auf Texel gerichtet ist, die von einem Farbenraum in einen anderen Farbenraum umgewandelt werden. Weil die Texturverarbeitungs-Pipeline 400 nicht konfiguriert ist, Farbenraumumwandlung auf 8 Texel in einem Taktzyklus zu verarbeiten und durchzuführen, legt die TEXIN-Einheit 404 ein Veto gegen die Konfiguration der Texturoperation ein.
In noch einem anderen Beispiel könnte die TEXIO-Einheit 402 eine Texturoperation empfangen und bestimmen, dass die Texturoperation berechtigt sein kann, mit acht Threads pro Taktzyklus auszuführen. Anschließend greift die TEXIN-Einheit 404 auf die Header-Zustandsdaten zu und bestimmt, dass die Texturoperation endgültige Farbenwerte erzeugt, die hochkonvertiert werden müssen, bevor die endgültigen Farbenwerte zu dem SM 310 zurückgegeben werden. Weil die Texturverarbeitungs-Pipeline 400 nicht konfiguriert ist, um 8 Texel zu verarbeiten und eine Hochkonvertierung an den endgültigen Farbenwerten in einem Taktzyklus durchzuführen, legt die TEXIN-Einheit 404 ein Veto gegen die Konfiguration der Texturoperation ein.
In einem anderen Beispiel könnte die TEXIO-Einheit 402 eine Textur-Gather-Operation empfangen und bestimmen, dass die Textur-Gather-Operation berechtigt sein kann, mit acht Threads pro Taktzyklus auszuführen. Anschließend greift die TEXIN-Einheit 404 auf die Header-Zustandsdaten zu und bestimmt, dass die bestimmte Textur-Gather-Operation nicht in der Lage ist, mit acht Threads pro Taktzyklus auszuführen. Beispielsweise könnten die Texturkomponenten, auf die von der Textur-Gather-Operation zugegriffen wird, ein bestimmtes Format und/oder Ausrichtung aufweisen, auf welche die Texturverarbeitungs-Pipeline 400 nicht in der Lage ist, bei einer beschleunigten Geschwindigkeit zuzugreifen. Daher legt die TEXIN-Einheit 404 ein Veto gegen die Konfiguration der Textur-Gather-Operation ein.
In noch einem anderen Beispiel könnte eine Stufe der Texturverarbeitungs-Pipeline 400, wie beispielsweise die Abtaststeuerungs- und Adressiereinheit 408, bestimmen, dass die Texturanweisung Gleitkomma-Texelkoordinaten umfasst, die genaue ganzzahligen Koordinaten darstellen. Die Stufe kann bestimmen, dass eine Texturanweisung mit derartigen Texelkoordinaten berechtigt ist, mit acht Threads pro Taktzyklus auszuführen.
5 ist ein Ablaufdiagramm von Verfahrensschritten zum Durchführen von Speicherzugriffsoperationen in einer Texturverarbeitungs-Pipeline 400 gemäß verschiedenen Ausführungsformen. Obwohl die Verfahrensschritten in Verbindung mit den Systemen von 1-4 beschrieben sind, werden Fachleute verstehen, dass eine beliebige System konfiguriert, um die Verfahrensschritten durchzuführen, in einer beliebigen Reihenfolge, ist innerhalb die Umfang der vorliegenden Offenbarung.
Wie gezeigt, beginnt ein Verfahren 500 bei Schritt 502, wobei eine erste Stufe in einer Texturverarbeitungs-Pipeline 400 eine erste Bestimmung erzeugt, dass eine Texturspeicherabfrage für eine Beschleunigung berechtigt ist. In einigen Ausführungsformen umfasst die erste Stufe die TEXIO-Einheit 402 der Texturverarbeitungs-Pipeline 400 von 4. Die TEXIO-Einheit 402 verarbeitet Texturanweisungen, die Texturlasten und Texturoperationen umfassen. Die TEXIO-Einheit 402 empfängt eine Texturanweisung der SM 310 zur Ausführung durch die 32 Threads in einem Warp. Die TEXIO-Einheit 402 spaltet die Texturanweisung in mehrere Abschnitte auf, wobei jeder Abschnitt die Texturanweisung für eine Teilmenge der Threads in dem Warp umfasst. Die TEXIO-Einheit 402 analysiert den Texturanweisung-Opcode sowie auch bestimmte Parameter und Modifikatoren der Texturanweisung, um eine erste Bestimmung hinsichtlich dessen vorzunehmen, ob die Texturanweisung mit vier Threads pro Taktzyklus oder mit einer höheren Anzahl von Threads pro Taktzyklus ausführen kann.
Anfangs nimmt die TEXIO-Einheit 402 an, dass die Texturanweisung mit einer Rate ausführen kann, die größer als vier Threads pro Taktzyklus ist. Wenn die TEXIO-Einheit 402 bestimmt, dass die Texturanweisung nicht mit einer höheren Rate der Ausführung als vier Threads pro Taktzyklus ausgeführt werden kann, dann legt die TEXIO-Einheit 402 gegen die Bestimmung ein „Veto“ ein, dass die Texturanweisung mit der Rate gemäß der aktuellen Konfiguration ausführen kann. Die TEXIO-Einheit 402 konfiguriert dann die Anweisung neu, um mit einer niedrigeren Rate ausgeführt zu werden. Beispielsweise könnte die TEXIO-Einheit 402 ein Veto gegen die Konfiguration einer Texturanweisung einlegen, die mit acht Threads pro Taktzyklus ausführt, und die Texturanweisung neu konfigurieren, um mit vier Threads pro Taktzyklus auszuführen.
Wenn die TEXIO-Einheit 402 bestimmt, dass die Texturanweisung lediglich bei vier Threads pro Taktzyklus ausführen kann, dann spaltet die TEXIO-Einheit 402 die Texturanweisung in acht Abschnitte von jeweils vier Threads auf, um mit einer Rate von vier Threads pro Taktzyklus auszuführen. Wenn die TEXIO-Einheit 402 bestimmt, dass die Texturanweisung bei einer Rate größer als vier Threads pro Taktzyklus ausführen kann, wie beispielsweise mit ein Texturlast, dann spaltet die TEXIO-Einheit 402 die Texturanweisung in Abschnitte basierend auf dem Wert von ‚N‘ auf. Beispielsweise wenn ‚N‘ = 2 ist, dann wird eine Texturanweisung, die mit einer höheren Rate ausführen kann, in vier Abschnitte von jeweils acht Threads aufgeteilt und die Texturanweisung führt mit einer Rate von acht Threads pro Taktzyklus aus. Wenn ‚N‘ = 4, dann wird die Texturanweisung in zwei Abschnitte von jeweils sechzehn Threads aufgeteilt und die Texturanweisung führt mit einer Rate von jeweils sechzehn Threads pro Taktzyklus aus und so weiter. Für den Zweck der folgenden Erläuterung wird angenommen, dass ‚N‘ gleich 2 ist. ‚N‘ könnte eine beliebige technisch machbare Anzahl sein.
In einigen Fällen kann die TEXIO-Einheit 402 nicht in der Lage sein, basierend auf dem Opcode zu bestimmen, ob die Texturanweisung mit vier Threads pro Taktzyklus oder acht Threads pro Taktzyklus ausführen kann. In derartigen Fällen spaltet die TEXIO-Einheit 402 die Texturanweisung in vier Abschnitte von jeweils acht Threads auf und nimmt an, dass die Texturanweisung mit einer Rate von acht Threads pro Taktzyklus ausführen kann. Anschließend kann eine beliebige andere Stufe der Texturverarbeitungs-Pipeline 400 bestimmen, dass die Texturanweisung nicht mit der aktuellen Konfiguration ausführen kann. Wenn eine Stufe der Texturverarbeitungs-Pipeline 400 bestimmt, dass die Texturanweisung nicht mit der aktuell konfigurierten Rate ausführen kann, legt die Stufe ein Veto gegen die Bestimmung ein, dass die Texturanweisung mit der Rate gemäß der aktuellen Konfiguration ausführen kann. Die Stufe konfiguriert die Anweisung neu, um mit einer niedrigeren Rate auszuführen. Beispielsweise könnte eine Stufe ein Veto gegen die Konfiguration einer Texturanweisung einlegen, die mit acht Threads pro Taktzyklus ausführt, und die Texturanweisung neu konfigurieren, um mit vier Threads pro Taktzyklus auszuführen.
Bei Schritt 504 veranlasst die erste Stufe der Texturverarbeitungs-Pipeline die Texturspeicherabfrage, zu einer folgenden Stufe in der Texturverarbeitungs-Pipeline 400 weiterzuschreiten. Bei Schritt 506 erzeugt eine zweite Stufe in der Texturverarbeitungs-Pipeline 400 eine zweite Bestimmung, dass die Texturspeicherabfrage für eine Beschleunigung berechtigt ist. In einigen Ausführungsformen umfasst die zweite Stufe die TEXIN-Einheit 404 der Texturverarbeitungs-Pipeline 400 von 4.
Die TEXIN-Einheit 404 empfängt aufgeteilte Texturanweisungen der TEXIO-Einheit 402. Die TEXIN-Einheit 404 ruft den Textur-Header-Zustand und Textur-Sampler-Zustand eines Speichers basierend auf einem Textur Header-Index und einem Textur-Sampler-Index ab, die in der Texturanweisung umfasst sind. Der Textur-Header-Zustand und Textur-Sampler-Zustand sind in einem Speicher gespeichert, der extern zu die Texturverarbeitungs-Pipeline 400 ist. Die TEXIN-Einheit 404 speichert den abgerufenen Textur-Header-Zustand und Textur-Sampler-Zustand in einem lokalen Speicher-Cache. Jede Stufe in der Texturverarbeitungs-Pipeline 400 ruft den Textur-Header-Zustand und Textur-Sampler-Zustand nach Bedarf ab, um die Operationen für diese Stufe durchzuführen. Wenn eine anschließende Texturanweisung den gleichen Textur-Header-Index und/oder Textur-Sampler-Index wie ein vorherige Texturanweisung umfasst, dann kann die TEXIN-Einheit 404 auf den Textur-Header-Zustand und Textur-Sampler-Zustand über den lokalen Speicher-Cache zugreifen. Das Zugreifen auf den Textur-Header-Zustand und Textur-Sampler-Zustand über den lokalen Speicher-Cache vermeidet das Abrufen des Textur-Header-Zustands und Textur-Sampler-Zustands aus dem externen Speicher, wenn der Zustand in dem lokalen Speicher-Cache vorhanden ist.
Die TEXIN-Einheit 404 analysiert den Textur-Header-Zustand und Textur-Sampler-Zustand, die der Texturanweisung zugeordnet sind, um eine zweite Bestimmung hinsichtlich dessen vorzunehmen, ob die Texturanweisung mit acht Threads pro Taktzyklus oder mit vier Threads pro Taktzyklus ausführen kann. Wenn die TEXIN-Einheit 404 bestimmt, dass eine eingehende Texturanweisung, die konfiguriert ist, um mit acht Threads pro Taktzyklus auszuführen, lediglich mit vier Threads pro Taktzyklus ausführen kann, dann legt die TEXIN-Einheit 404 ein Veto gegen die Konfiguration ein. Die TEXIN-Einheit 404 konfiguriert die Texturanweisung neu, um mit vier Threads pro Taktzyklus auszuführen.
Beispielsweise könnte die TEXIN-Einheit 404 basierend auf dem Textur-Sampler-Zustand bestimmen, ob die Texturanweisung eine Punkt-abgetastete Texturoperation ist, die das nächste Texel anfragt. Wenn die Texturanweisung eine Punkt-abgetastete Texturoperation ist, dann bestimmt die TEXIN-Einheit 404, dass die Texturanweisung mit acht Threads pro Taktzyklus ausführen kann. Andererseits kann die TEXIN-Einheit 404 basierend auf dem Textur-Sampler-Zustand bestimmen, dass die Texturanweisung einer komplexeren Abtastung oder Filteroperation zugeordnet ist. In derartigen Fällen legt die TEXIN-Einheit 404 ein Veto gegen die Texturanweisung ein und konfiguriert die Anweisung neu, um mit vier Threads pro Taktzyklus auszuführen. Auf ähnliche Weise bestimmt dann, wenn die Textur-Header-Zustandsdaten angeben, dass die Texturanweisung auf eine Textur gerichtet ist, die komprimierte Daten umfasst, die TEXIN-Einheit 404, dass die Texturanweisung mit vier Threads pro Taktzyklus ausführen kann.
Bei Schritt 508 verarbeiten eine oder mehrere Stufen in der Texturverarbeitungs-Pipeline 400 die Texturspeicherabfrage basierend auf einer oder sowohl der ersten Bestimmung als auch der zweiten Bestimmung. Das Verfahren 500 endet dann.
In der Summe umfassen verschiedene Ausführungsformen eine Texturverarbeitungs-Pipeline in einer GPU, die bei einer ersten Stufe der Texturverarbeitungs-Pipeline bestimmt, ob Texturoperationen und Texturlasten mit einer beschleunigten Rate verarbeitet werden können. Die Texturverarbeitungs-Pipeline bewertet dann die Entscheidung bei einer oder mehreren zusätzlichen Stufen der Texturverarbeitungs-Pipeline erneut. Bei jeder Stufe, die einen Entscheidungspunkt umfasst, nimmt die Texturverarbeitungs-Pipeline an, dass die aktuelle Texturoperation oder Texturlast beschleunigt werden kann, es sei denn, dass spezifische bekannte Information angibt, dass die Texturoperation oder Texturlast nicht beschleunigt werden kann. Wenn die Texturoperation oder Texturlast zu anderen Stufen weiterschreitet, erfasst die Texturverarbeitungs-Pipeline zusätzliche Informationen hinsichtlich der Texturoperation oder der Texturlast. Die Texturverarbeitungs-Pipeline bestimmt bei mehreren Stufen, ob Texturoperationen und Texturlasten mit einer beschleunigten Rate verarbeitet werden können. Als Ergebnis erhöht die Texturverarbeitungs-Pipeline die Anzahl von Texturoperationen und Texturlasten, die beschleunigt werden, relativ zu der Anzahl von Texturoperationen und Texturlasten, die nicht beschleunigt werden.
Mindestens ein technischer Vorteil der offenbarten Techniken im Verhältnis zum Stand der Technik ist, dass mit den offenbarten Techniken ein größerer Prozentsatz von Texturspeicher-Zugriffsfähigkeit während Texturlasten und während einfachen Texturoperationen benutzt wird. Als Ergebnis wird die Effizienz und Leistung der Texturverarbeitungshardware während der Texturlasten und Texturoperationen im Verhältnis zu früheren Vorgehensweisen erhöht. Ein anderer technischer Vorteil der offenbarten Techniken ist, dass die Texturverarbeitungshardware mehrere Stufen zum Bestimmen umfasst, ob die Speicherzugriffsfähigkeit der Texturverarbeitungshardware effizienter genutzt werden könnte. Als Ergebnis ist eine größere Anzahl von Texturlasten und Texturoperationen in der Lage, die offenbarten Techniken im Verhältnis zu einer Vorgehensweise auszunutzen, bei der diese Bestimmung bei lediglich einer einzigen Stufe der Texturverarbeitungshardware vorgenommen wird. Diese Vorteile stellen eine oder mehrere technologische Verbesserungen gegenüber Vorgehensweisen des Standes der Technik dar.
Aspekte der vorliegenden Offenbarung werden vorstehend mit Bezug auf Ablaufdiagramm-Veranschaulichungen und/oder Blockdiagrammen von Verfahren, Einrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Offenbarung beschrieben. Es versteht sich, dass jeder Block der Ablaufdiagramm-Veranschaulichungen und/oder der Blockdiagramme und der Kombinationen von Blöcken in den Ablaufdiagramm-Veranschaulichungen und/oder Blockdiagrammen durch Computerprogramm-Anweisungen implementiert werden können. Diese Computerprogramm-Anweisungen können einem Prozessor eines Allzweckcomputers, Spezialzweckcomputers oder einer sonstigen programmierbaren Datenverarbeitungseinrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Anweisungen, die über den Prozessor des Computer oder einer sonstigen programmierbare Datenverarbeitungseinrichtung ausgeführt werden, die Implementierung der in dem Ablaufdiagramm und/oder Blockdiagrammblock oder Blöcken spezifizierten Funktionen/Handlungen ermöglichen. Derartige Prozessoren können, ohne einschränkend zu sein, Allzweck-Prozessoren, Spezialzweck-Prozessoren, anwendungsspezifische Prozessoren oder feldprogrammierbare Prozessoren sein.
Das Ablaufdiagramm und die Blockdiagramme in den Figuren veranschaulichen die Architektur, Funktionalität und den Betrieb möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedener Ausführungsformen der vorliegenden Offenbarung. In dieser Hinsicht kann jeder Block in dem Ablaufdiagramm oder den Blockdiagrammen ein Modul, ein Segment oder einen Abschnitt eines Codes darstellen, der eine oder mehrere ausführbare Anweisungen zum Implementieren der spezifizierten logischen Funktion(en) umfasst. Es sei ebenfalls bemerkt, dass in einigen alternativen Implementierungen die in dem Block erwähnten Funktionen außerhalb der in den Figuren erwähnten Reihenfolge auftreten können. Beispielsweise können zwei aufeinanderfolgend gezeigte Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden oder die Blöcke können einige Male in umgekehrter Reihenfolge abhängig von der beteiligten Funktionalität ausgeführt werden. Es sei ebenfalls bemerkt, dass jeder Block der Blockdiagramme und/oder der Ablaufdiagramm-Veranschaulichung sowie Kombinationen von Blöcken in den Blockdiagrammen und/oder der Ablaufdiagramm-Veranschaulichung von Spezialzweck-Hardware-basierten Systemen implementiert werden können, welche die spezifizierten Funktionen oder Handlungen oder Kombinationen der Spezialzweck-Hardware und Computeranweisungen durchführen.
Während das Vorhergehende auf Ausführungsformen der vorliegenden Offenbarung gerichtet ist, können andere und weitere Ausführungsformen der Offenbarung erdacht werden, ohne von dem grundlegenden Schutzumfang derselben abzuweichen, und der Umfang derselben wird durch die Ansprüche bestimmt, die folgen.

Claims

Computerimplementes Verfahren zum Zugreifen auf einen Texturspeicher in einer Graphikverarbeitungseinheit, wobei das Verfahren umfasst: Erzeugen, bei einer ersten Stufe in einer Texturverarbeitungs-Pipeline, einer ersten Bestimmung, dass eine Texturspeicherabfrage für eine Beschleunigung innerhalb die Texturverarbeitungs-Pipeline berechtigt ist; Veranlassen, basierend auf der ersten Bestimmung, der Texturspeicherabfrage, zu einer zweiten Stufe in der Texturverarbeitungs-Pipeline weiterzuschreiten; Erzeugen, bei der zweiten Stufe in der Texturverarbeitungs-Pipeline, einer zweiten Bestimmung, dass die Texturspeicherabfrage für eine Beschleunigung innerhalb der Texturverarbeitungs-Pipeline berechtigt ist; Verarbeiten der Texturspeicherabfrage innerhalb der Texturverarbeitungs-Pipeline basierend auf mindestens der ersten Bestimmung und/oder der zweiten Bestimmung.
Computerimplementes Verfahren gemäß Anspruch 1, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist, die eine Texturlast eines einzigen Texturelements in einem Texturspeicher umfasst.
Computerimplementes Verfahren gemäß Anspruch 1 oder 2, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist, die eine Texturoperation umfasst, die einem einzigen Texturelement in einem Texturspeicher zugeordnet ist, das am nächsten zu einem durch die Texturspeicherabfrage spezifizierten Ort ist.
Computerimplementes Verfahren gemäß einem vorangehenden Anspruch, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist, und die erste Bestimmung auf einem Operationscode basiert, der in der Texturspeicheranweisung umfasst ist.
Computerimplementes Verfahren gemäß einem vorangehenden Anspruch, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist und die erste Bestimmung auf einem Operationscode basiert, der die Texturspeicheranweisung als eine Texturlast kennzeichnet, die auf ein einziges Texturelement in einem Texturspeicher gerichtet ist, wobei das einzige Texturelement an einer Speicheradresse lokalisiert ist, die durch die Texturspeicherabfrage spezifiziert ist.
Computerimplementes Verfahren gemäß einem vorangehenden Anspruch, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist und mindestens eine der ersten Bestimmung oder der zweiten Bestimmung auf einem Operationscode basiert, der die Texturspeicheranweisung als eine Texturoperation kennzeichnet, die auf ein einziges Texturelement in einem Texturspeicher gerichtet ist, wobei das einzige Texturelement am nächsten zu einer durch die Texturspeicherabfrage spezifizierten Speicheradresse ist.
Computerimplementes Verfahren gemäß einem vorangehenden Anspruch, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist und die zweite Bestimmung ist basierend auf einem oder mehreren von Header-Zustandsdaten oder Sampler-Zustandsdaten basiert, die der Texturspeicheranweisung zugeordnet sind.
Ein oder mehrere nicht-transitorische computerlesbare Medien, die Programmanweisungen speichern, die, wenn durch einen oder mehrere Prozessoren ausgeführt, den einen oder mehrere Prozessoren veranlassen, die folgenden Schritte durchzuführen: Erzeugen, bei einer ersten Stufe in einer Texturverarbeitungs-Pipeline, einer ersten Bestimmung, dass eine Texturspeicherabfrage für eine Beschleunigung innerhalb der Texturverarbeitungs-Pipeline berechtigt ist; Veranlassen, basierend auf der ersten Bestimmung, der Texturspeicherabfrage, zu einer zweiten Stufe in der Texturverarbeitungs-Pipeline weiterzuschreiten; Erzeugen, bei der zweiten Stufe in der Texturverarbeitungs-Pipeline, einer zweiten Bestimmung, dass die Texturspeicherabfrage für eine Beschleunigung innerhalb der Texturverarbeitungs-Pipeline berechtigt ist; Verarbeiten der Texturspeicherabfrage innerhalb der Texturverarbeitungs-Pipeline basierend auf mindestens eines der ersten Bestimmung und der zweiten Bestimmung.
Das eine oder mehrere nicht-transitorische computerlesbare Medien gemäß Anspruch 8, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist und die erste Bestimmung auf einem Operationscode basiert, der in der Texturspeicheranweisung umfasst ist.
Das eine oder mehrere nicht-transitorische computerlesbare Medien gemäß Anspruch 8 oder 9, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist und die erste Bestimmung auf einem Operationscode basiert, der die Texturspeicheranweisung als eine Texturlast kennzeichnet, die auf ein einziges Texturelement in einem Texturspeicher gerichtet ist, wobei das einzige Texturelement bei einer Speicheradresse lokalisiert ist, die durch die Texturspeicherabfrage spezifiziert ist.
Das eine oder mehrere nicht-transitorische computerlesbare Medien gemäß einem der Ansprüche 8 bis 10, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist und mindestens eine der ersten Bestimmung oder der zweiten Bestimmung auf einem Operationscode basiert, der die Texturspeicheranweisung als eine Texturoperation kennzeichnet, die auf ein einziges Texturelement in einem Texturspeicher gerichtet ist, wobei das einzige Texturelement am nächsten zu einer durch die Texturspeicherabfrage spezifizierten Speicheradresse ist.
Das eine oder die mehreren nicht-transitorischen computerlesbaren Medien gemäß einem der Ansprüche 8 bis 11, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist und die zweite Bestimmung auf einem oder mehreren von Header-Zustandsdaten oder Sampler-Zustandsdaten basiert, die der Texturspeicheranweisung zugeordnet sind.
Das eine oder mehrere nicht-transitorische computerlesbare Medien gemäß einem der Ansprüche 8 bis 12, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist und die zweite Bestimmung auf einer Anzahl von Detaillierungsgraden basiert, die in einer Textur umfasst sind, wie durch Header-Zustandsdaten spezifiziert.
Das eine oder mehrere nicht-transitorische computerlesbare Medien gemäß einem der Ansprüche 8 bis 13, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist und die zweite Bestimmung auf einer Größe eines Texturelements basiert, die durch Header-Zustandsdaten spezifiziert ist.
Das eine oder mehrere nicht-transitorische computerlesbare Medien gemäß einem der Ansprüche 8 bis 14, wobei eine Texturspeicherabfrage, die der Texturspeicheranweisung zugeordnet ist, mit einer ersten Anzahl von Threads pro Taktzyklus oder mit einer zweiten Anzahl von Threads pro Taktzyklus basierend auf mindestens einer der ersten Bestimmung und der zweiten Bestimmung ausführt
System, umfassend: einen Speicher, der Anweisungen speichert; und einen Prozessor, der mit dem Speicher gekoppelt ist und beim Ausführen der Anweisungen: erzeugt, bei ein erste Stufe in einer Texturverarbeitungs-Pipeline, eine erste Bestimmung, dass eine Texturspeicherabfrage für eine Beschleunigung innerhalb der Texturverarbeitungs-Pipeline berechtigt ist; veranlasst, basierend auf der ersten Bestimmung, die Texturspeicherabfrage zu einer zweiten Stufe in der Texturverarbeitungs-Pipeline fortzuschreiten; erzeugt, bei der zweiten Stufe in der Texturverarbeitungs-Pipeline, eine zweite Bestimmung, dass die Texturspeicherabfrage für eine Beschleunigung innerhalb der Texturverarbeitungs-Pipeline berechtigt ist; verarbeitet die Texturspeicherabfrage innerhalb der Texturverarbeitungs-Pipeline basierend auf mindestens einer der erste Bestimmung und der zweiten Bestimmung.
System gemäß Anspruch 16, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist, die eine Texturlast eines einzigen Texturelements in einem Texturspeicher umfasst.
System gemäß Anspruch 16 oder 17, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist, die eine Texturoperation umfasst, die einem einzigen Texturelement in einem Texturspeicher zugeordnet ist, das am nächsten zu einem durch die Texturspeicherabfrage spezifizierten Ort ist.
System gemäß einem der Ansprüche 16 bis 18, wobei die Texturspeicherabfrage einer Textur-Gather-Operation zugeordnet ist, die eine Texturoperation umfasst, die vier benachbarten Texturelementen in einem Texturspeicher zugeordnet ist, die am nächsten zu einem durch die Texturspeicherabfrage spezifizierten Ort sind.
System gemäß einem der Ansprüche 16 bis 19, wobei die Texturspeicherabfrage einer Texturanweisung zugeordnet ist und die erste Bestimmung auf einem Operationscode basiert, der die Texturspeicheranweisung als eine Texturlast kennzeichnet, die auf ein einziges Texturelement in einem Texturspeicher gerichtet ist, wobei das einzige Texturelement an einer Speicheradresse lokalisiert ist, die durch die Texturspeicherabfrage spezifiziert ist.