DE102019101720A1 - Techniken zur Darstellung und Verarbeitung von Geometrie innerhalb einer erweiterten Grafikverarbeitungspipeline - Google Patents

Techniken zur Darstellung und Verarbeitung von Geometrie innerhalb einer erweiterten Grafikverarbeitungspipeline Download PDF

Info

Publication number
DE102019101720A1
DE102019101720A1 DE102019101720.3A DE102019101720A DE102019101720A1 DE 102019101720 A1 DE102019101720 A1 DE 102019101720A1 DE 102019101720 A DE102019101720 A DE 102019101720A DE 102019101720 A1 DE102019101720 A1 DE 102019101720A1
Authority
DE
Germany
Prior art keywords
shader
grid
task
identifier
input
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019101720.3A
Other languages
English (en)
Inventor
Ziyad Hakura
Yury Uralsky
Christoph KUBISCH
Pierre Boudier
Henry Moreton
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/881,564 external-priority patent/US10600229B2/en
Priority claimed from US15/881,566 external-priority patent/US10909739B2/en
Priority claimed from US15/881,572 external-priority patent/US10878611B2/en
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE102019101720A1 publication Critical patent/DE102019101720A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/60—Memory management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/005—General purpose rendering architectures

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Graphics (AREA)
  • Image Generation (AREA)

Abstract

In verschiedenen Ausführungsbeispielen implementiert ein Parallelprozessor eine Grafikverarbeitungspipeline, die gerenderte Bilder erzeugt. Im Betrieb veranlasst der Parallelprozessor Ausführungs-Threads, ein Task-Shading-Programm auf einem Eingangs-Gitter auszuführen, um eine Task-Shader-Ausgabe zu erzeugen, die eine Gitter-Shader-Anzahl angibt. Der Parallelprozessor erzeugt dann Gitter-Shader-Identifikatoren, wobei die Gesamtzahl der Gitter-Shader-Identifikatoren gleich der Anzahl der Gitter-Shader ist. Für jeden Gitter-Shader-Identifikator ruft der Parallelprozessor basierend auf dem Gitter-Shader-Identifikator und der Task-Shader-Ausgabe einen Gitter-Shader auf, um eine Geometrie zu erzeugen, die dem Gitter-Shader-Identifikator zugeordnet ist. Anschließend führt der Parallelprozessor Operationen an den Geometrien durch, die den Gitter-Shader-Identifikatoren zugeordnet sind, um ein gerendertes Bild zu erzeugen. Vorteilhaft ist, dass im Gegensatz zu herkömmlichen Grafikverarbeitungspipelines die Leistung der Grafikverarbeitungspipeline nicht durch einen Stammfunktionen-Verteiler eingeschränkt ist.

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Ausführungsbeispiele der Erfindung beziehen sich allgemein auf Grafikverarbeitung und insbesondere auf Techniken zur Darstellung und Verarbeitung von Geometrie innerhalb einer erweiterten Grafikverarbeitungspipeline.
  • Beschreibung des verwandten Standes der Technik
  • Eine herkömmliche Grafikverarbeitungspipeline beinhaltet typischerweise eine einzelne Hardwareeinheit mit fester Funktion, die als der Stammfunktionen-Verteiler bekannt ist. Der Stammfunktionen-Verteiler sammelt Eckpunkt- bzw. Vertexdaten, die mit Oberflächen hoher Ordnung, grafischen Stammfunktionen und dergleichen verbunden sind, von einer Frontend-Einheit und baut entsprechende Arbeitsstapel auf, wobei jeder Arbeitsstapel Eckpunktdaten enthält, die mehrere Stammfunktionen definieren. Die Arbeitsstapel werden dann von programmierbaren Ausführungseinheiten verarbeitet, die ebenfalls in der Grafikverarbeitungspipeline enthalten sind. Während der Ausführung werden die Arbeitsstapel auf eine Reihe von Streaming-Multiprozessoren verteilt, die dazu konfiguriert sind, eine große Anzahl von Threads parallel auszuführen, um Grafikoperationen an den Eckpunktdaten basierend auf einem Programmiermodell durchzuführen. Oftmals wird entsprechend der Programmierung jeder Eckpunkt, der in einem bestimmten Arbeitsstapel enthalten ist, unabhängig von einem anderen Thread verarbeitet.
  • Eine Einschränkung herkömmlicher Grafikverarbeitungspipelines besteht darin, dass der Durchsatz der Grafikverarbeitungspipeline durch den Durchsatz des Stammfunktionen-Verteilers begrenzt wird. Genauer ist der Stammfunktionen-Verteiler typischerweise eine Hardwareeinheit mit fester Funktion, die einen festen Durchsatz und eine begrenzte Skalierbarkeit aufweist. Infolgedessen begrenzt dann, wenn die Speicherbandbreite und die Anzahl der Streaming-Multiprozessoren zunehmen, der Stammfunktionen-Verteiler die Gesamtleistung der Grafikverarbeitungspipeline. Wenn der Stammfunktionen-Verteiler beispielsweise einen Durchsatz von 16 Stammfunktionen pro Taktzyklus hat, dann ist der Gesamtdurchsatz der Grafikverarbeitungspipeline unabhängig von der Speicherbandbreite und/oder der Anzahl der Streaming-Multiprozessoren, die die Grafikpipeline unterstützen, auf 16 Stammfunktionen pro Taktzyklus begrenzt.
  • Eine weitere Einschränkung herkömmlicher Grafikverarbeitungspipelines besteht darin, dass das anwendbare Programmiermodell unflexibel ist. Unter anderem erlaubt das Programmiermodell Anwendungen nicht, bestimmte Operationen früher in der Pipeline auszuführen, um die Gesamtausführung effizienter zu gestalten. Wie bereits erwähnt wurde, erzwingt das Programmiermodell beispielsweise oft eine Eins-zu-Eins-Korrespondenz zwischen den Eckpunkten und den Threads, wobei jeder Eckpunkt, der in einem Arbeitsstapel enthalten ist, unabhängig von einem anderen Thread verarbeitet wird. Da ein bestimmter Thread einen bestimmten Eckpunkt unabhängig von den Eckpunkten verarbeitet, die von anderen Threads verarbeitet werden, gibt es keinen guten Weg, die Eckpunktverarbeitungseinheit dazu zu programmieren, Aussortieroperationen durchzuführen, um nicht sichtbare Stammfunktionen in der Eckpunktverarbeitungsphase der Grafikverarbeitungspipeline zu verwerfen. Beispielsweise kann ein Thread, der einen einzelnen Eckpunkt verarbeitet, der in einer bestimmten Dreiecksstammfunktion enthalten ist, nicht bestimmen, ob die Dreiecksstammfunktion in einem endgültigen Bild sichtbar ist, weil zwei weitere Eckpunkte, die von zwei anderen Threads verarbeitet werden, an dieser Bestimmung beteiligt sein müssen. Da die Eckpunktverarbeitungseinheit nicht dazu programmiert werden kann, nicht sichtbare Stammfunktionen zu entfernen, führen nachgelagerte Einheiten in der Grafikverarbeitungspipeline unnötige Grafikoperationen an diesen nicht sichtbaren Stammfunktionen durch und verschwenden so sowohl Verarbeitungsressourcen als auch Energie.
  • Wie das Vorstehende verdeutlicht, besteht im Stand der Technik Bedarf an effektiveren Techniken zur Verarbeitung von Bilddaten.
  • KURZBESCHREIBUNG DER ERFINDUNG
  • Ein Ausführungsbeispiel der Erfindung stellt ein Verfahren zur Verarbeitung von Bilddaten dar. Das Verfahren beinhaltet ein Veranlassen eines ersten Satzes von Ausführungs-Threads dazu, ein Task-Shading-Programm auf einem Eingangsnetz bzw. Eingangs-Gitter auszuführen, um eine erste Task-Shader-Ausgabe zu erzeugen, die eine erste Gitter-Shader-Anzahl angibt; ein Erzeugen eines ersten Satzes von Gitter-Shader-Identifikatoren, wobei eine Gesamtzahl von Gitter-Shader-Identifikatoren, die in dem ersten Satz von Gitter-Shader-Identifikatoren enthalten sind, gleich der ersten Gitter-Shader-Anzahl ist; für jeden Gitter-Shader-Identifikator, der in dem ersten Satz von Gitter-Shader-Identifikatoren enthalten ist, ein Aufrufen eines Gitter-Shaders basierend auf dem Gitter-Shader-Identifikator und der ersten Task-Shader-Ausgabe, um eine Geometrie zu erzeugen, die dem Gitter-Shader-Identifikator zugeordnet ist; und ein Ausführen einer oder mehrerer Operationen an den Geometrien, die dem ersten Satz von Gitter-Shader-Identifikatoren zugeordnet sind, um ein erstes gerendertes Bild zu erzeugen.
  • Ein Vorteil der offenbarten Techniken besteht darin, dass eine Grafikverarbeitungspipeline die Techniken implementieren kann, anstatt einen Stammfunktionen-Verteiler, Eckpunktverarbeitungseinheiten und Geometrie-Shading-Einheiten zu implementieren. Infolgedessen wird die Leistung der Grafikverarbeitungspipeline nicht durch den festen Durchsatz des Stammfunktionen-Verteilers begrenzt. Da mehrere kooperative Threads das Task-Shading-Programm ausführen, kann ferner die Grafikverarbeitungspipeline bestimmte Operationen früher und effizienter durchführen als eine herkömmliche Grafikverarbeitungspipeline.
  • Figurenliste
  • Die Art und Weise, in der die vorstehend wiedergegebenen Merkmale der Erfindung im Einzelnen verstanden werden können, ergibt sich aus einer spezifischeren Beschreibung der vorstehend kurz zusammengefassten Erfindung unter Bezugnahme auf Ausführungsbeispiele, von denen einige in den beigefügten Zeichnungen dargestellt sind. Es versteht sich jedoch, dass die beigefügten Zeichnungen nur typische Ausführungsbeispiele dieser Erfindung veranschaulichen und daher nicht als deren Schutzumfang beschränkend anzusehen sind, da die Erfindung Zugang zu anderen ebenso wirksamen Ausführungsbeispiele erlaubt.
    • 1 ist ein Blockdiagramm, das ein Computersystem veranschaulicht, das dazu konfiguriert ist, einen oder mehrere Aspekte der Erfindung zu implementieren;
    • 2 ist ein detaillierteres Blockdiagramm eines Parallelprozessors, der in dem Parallelverarbeitungs-Subsystem von 1 enthalten ist, gemäß verschiedenen Ausführungsbeispielen der Erfindung;
    • 3A ist ein detaillierteres Blockdiagramm eines allgemeinen Verarbeitungsclusters, der in dem Parallelprozessor von 2 enthalten ist, gemäß verschiedenen Ausführungsbeispielen der Erfindung;
    • 3B ist ein konzeptionelles Diagramm einer Grafikverarbeitungspipeline, die innerhalb des Parallelprozessors von 2 implementiert ist, gemäß verschiedenen Ausführungsbeispielen der Erfindung;
    • 4 ist ein detaillierteres Blockdiagramm des Meshlets von 3B, entsprechend verschiedenen Ausführungsbeispielen der Erfindung;
    • 5 ist ein Ablaufdiagramm von Verfahrensschritten zur Verarbeitung von Bilddaten über eine Grafikverarbeitungspipeline, gemäß verschiedenen Ausführungsbeispielen der Erfindung.
    • 6 ist ein konzeptionelles Diagramm einer erweiterten Grafikverarbeitungspipeline, die innerhalb des Parallelprozessors von 2 implementiert sein kann, gemäß verschiedenen anderen Ausführungsbeispielen der Erfindung;
    • 7 ist eine detailliertere Darstellung der Wechselwirkungen zwischen der Gitter-Shader-Eingabe und dem Gitter-Shader von 6 bei der Unterstützung eines Anwendungsdatenpuffers, gemäß verschiedenen Ausführungsbeispielen der Erfindungen;
    • 8A-8B zeigen ein Ablaufdiagramm von Verfahrensschritten zur Verarbeitung von Bilddaten über eine erweiterte Grafikverarbeitungspipeline, gemäß verschiedenen Ausführungsbeispielen der Erfindung;
    • 9A-B veranschaulichen, wie die Deduplizierungsanwendung von 1 einen Shaderstapel erzeugt, gemäß verschiedenen Ausführungsbeispielen der Erfindung; und
    • 10A-10B zeigen ein Ablaufdiagramm von Verfahrensschritten zur Vorverarbeitung von Index-Puffern zur Verwendung in einer Grafikverarbeitungspipeline, gemäß verschiedenen Ausführungsbeispielen der Erfindung.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung werden zahlreiche spezifische Details aufgezeigt, um ein besseres Verständnis der Erfindung zu ermöglichen. Für den Fachmann ist jedoch offensichtlich, dass die vorliegende Erfindung ohne eines oder mehrerer dieser spezifischen Details praktisch umgesetzt werden kann.
  • System Übersicht
  • 1 ist ein Blockdiagramm, das ein Computersystem 100 veranschaulicht, das dazu konfiguriert ist, einen oder mehrere Aspekte der Erfindung umzusetzen. Wie gezeigt ist, beinhaltet das Computersystem 100, ohne Einschränkung, eine Zentralverarbeitungseinheit (CPU) 102 und einen Systemspeicher 104, der über eine Speicherbrücke 105 und einen Kommunikationspfad 113 mit einem Parallelverarbeitungs-Subsystem 112 gekoppelt ist. In einigen Ausführungsbeispielen ist das Computersystem 100 eine Spielkonsole. Die Speicherbrücke 105 ist ferner über einen Kommunikationspfad 106 mit einer Eingabe/Ausgabe- bzw. I/O-Brücke 107 gekoppelt, und die I/O-Brücke 107 ist wiederum mit einem Schalter 116 gekoppelt.
  • Im Betrieb ist die I/O-Brücke 107 dazu konfiguriert, Benutzereingabeinformationen von Eingabegeräten 108, wie beispielsweise 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 dazu konfiguriert, Verbindungen zwischen der I/O-Brücke 107 und anderen Komponenten des Computersystems 100, wie beispielsweise ein Netzwerkadapter 118 und verschiedene Add-In-Karten 120 und 121, bereitzustellen.
  • Wie ebenfalls gezeigt ist, ist die I/O-Brücke 107 mit einer Systemplatte 114 gekoppelt, die dazu konfiguriert werden kann, Inhalte, Anwendungen und Daten zur Verwendung durch die CPU 102 und das Parallelverarbeitungs-Subsystem 112 zu speichern. Allgemein stellt die Systemdiskette 114 einen nichtflüchtigen Speicher für Anwendungen und Daten bereit und kann feste oder wechselbare Festplattenlaufwerke, Flash-Speichergeräte und CD-ROM (Compact Disc Read-only-Memory), DVD-ROM (Digital Versatile Disc-ROM), Blu-ray, HD-DVD (High Definition DVD) oder andere magnetische, optische oder Festkörper-Speichervorrichtungen beinhalten. Schließlich können, obwohl dies nicht ausdrücklich gezeigt ist, auch andere Komponenten, wie beispielsweise universelle serielle Bus- oder andere Portanschlüsse, Compact-Disc-Laufwerke, Digital Versatile Disc-Laufwerke, Filmaufnahmevorrichtungen und dergleichen, an die I/O-Brücke 107 angeschlossen werden.
  • In verschiedenen Ausführungsbeispielen können die Speicherbrücke 105 ein Northbridge-Chip und die I/O-Brücke 107 ein Southbridge-Chip sein. Darüber hinaus können Kommunikationspfade 106 und 113 sowie andere Kommunikationspfade innerhalb des Computersystems 100 unter Verwendung aller technisch geeigneten Protokolle, einschließlich, aber nicht beschränkt auf, AGP (Accelerated Graphics Port), HyperTransport oder jedes andere in der Technik bekannte Bus- oder- Punktpunktkommunikationsprotokoll, implementiert sein.
  • In einigen Ausführungsbeispielen umfasst das Parallelverarbeitungs-Subsystem 112 ein Grafik-Subsystem, das Pixel an eine Anzeigevorrichtung 110 liefert, die eine herkömmliche Kathodenstrahlröhre, eine Flüssigkristallanzeige, eine lichtemittierende Diodenanzeige oder dergleichen sein kann. In solchen Ausführungsbeispielen beinhaltet das Parallelverarbeitungs-Subsystem 112 eine für Grafik- und Videoverarbeitung optimierte Schaltung, die beispielsweise eine Videoausgabeschaltung beinhaltet. Wie nachstehend in 2 näher beschrieben wird, kann eine solche Schaltung über einen oder mehrere Parallelprozessoren (PPen), die zum Parallelverarbeitungs-Subsystem 112 gehören, hinweg integriert sein. In weiteren Ausführungsbeispielen beinhaltet das Parallelverarbeitungs-Subsystem 112 eine Schaltung, die für allgemeine Zwecke und/oder Rechenverarbeitung optimiert ist. Auch hier kann eine solche Schaltung über ein oder mehrere PPen hinweg integriert sein, die in das Parallelverarbeitungs-Subsystem 112 integriert sind und für die Durchführung solcher allgemeinen Zwecke und/oder Berechnungen konfiguriert sind. In nochmals weiteren Ausführungsbeispielen können der eine oder die mehreren PPen, die in dem Parallelverarbeitungs-Subsystem 112 enthalten sind, dazu konfiguriert sein, Grafikverarbeitungen, allgemeine Verarbeitungen und Rechenoperationen durchzuführen. Der Systemspeicher 104 beinhaltet zumindest einen Gerätetreiber 103, der dazu konfiguriert ist, die Verarbeitungsoperationen eines oder mehrerer PPen innerhalb des Parallelverarbeitungs-Subsystems 112 zu verwalten.
  • Wie gezeigt ist, beinhaltet der Systemspeicher 104, ohne Einschränkung, den Gerätetreiber 103, das Benutzeranwendungsprogramm 190 und eine Gitter-Shading-Bibliothek 180. Das Benutzeranwendungsprogramm 190 beinhaltet, ohne Einschränkung, ein Gitter-Shading-Programm 192 und ein Task-Shading-Programm 194. Wie in Verbindung mit den 3-8B beschrieben wird, wird in verschiedenen Ausführungsbeispielen das Gitter-Shading-Programm 192 und/oder das Task-Shading-Programm 194 auf einem oder mehreren PPen als Teil einer Grafikverarbeitungspipeline ausgeführt (in 1 nicht gezeigt). Im Allgemeinen beinhaltet die Gitter-Shading-Bibliothek 180 eine beliebige Anzahl von Anwendungen, die das Gitter-Shading-Programm 192 ausführen kann. Wie gezeigt ist, beinhaltet die Gitter-Shading-Bibliothek 180, ohne Einschränkung, eine Deduplizierungsanwendung 182. Die Deduplizierungsanwendung 182 wird in Verbindung mit den 9-10 beschrieben.
  • In verschiedenen Ausführungsbeispielen kann das Benutzeranwendungsprogramm 190 eine beliebige Anzahl (einschließlich 0) von jeweils dem Gitter-Shading-Programm 192 und dem Task-Shading-Programm 194 beinhalten. Beispielsweise könnte das Benutzeranwendungsprogramm 190 das Gitter-Shading-Programm 192 beinhalten und das Task-Shading-Programm 194 nicht beinhalten. In den gleichen oder anderen Ausführungsbeispielen kann das Computersystem 100 die Gitter-Shading-Bibliothek 180 weglassen, oder kann die Gitter-Shading-Bibliothek 180 die Deduplizierungsanwendung 182 weglassen.
  • In alternativen Ausführungsbeispielen kann der Systemspeicher 104 eine beliebige Anzahl (einschließlich 0) von jeweils dem Gerätetreiber 103, dem Benutzeranwendungsprogramm 190 und der Meshlet-Bibliothek 180 beinhalten. Ferner kann jede beliebige Anzahl des Gerätetreibers 103, des Benutzeranwendungsprogramms 190 und der Gitter-Shading-Bibliothek 180 in jeder beliebigen Anzahl und Art von externen Speichern gespeichert sein, die für den Prozessor 112 zugänglich sind. Beispielsweise können die externen Speicher, ohne Einschränkung, eine Secure Digital Card, einen externen Flash-Speicher, einen tragbaren Nur-Lese-Speicher für Compact Discs (CD-ROM), eine optische Speichervorrichtung, eine magnetische Speichervorrichtung oder eine geeignete Kombination der vorgenannten beinhalten. Darüber hinaus können die externen Speicher in einer Wolke bzw. Cloud oder einem anderen verteilten System implementiert sein.
  • In verschiedenen Ausführungsbeispielen kann das Parallelverarbeitungs-Subsystem 112 mit einem oder mehreren anderen der anderen Elemente von 1 zu einem einzigen System integriert sein. Beispielsweise kann das Parallelverarbeitungs-Subsystem 112 mit der CPU 102 und anderen Verbindungsschaltungen auf einem einzigen Chip integriert sein, um ein System on Chip (SoC) zu bilden.
  • Es wird darauf hingewiesen, 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 parallelen Verarbeitungs-Subsystemen 112, kann beliebig geändert werden. Beispielsweise könnte in einigen Ausführungsbeispielen der Systemspeicher 104 direkt und nicht über die Speicherbrücke 105 mit der CPU 102 verbunden sein, und würden andere Vorrichtungen über die Speicherbrücke 105 und die CPU 102 mit dem Systemspeicher 104 kommunizieren. In anderen alternativen Topologien kann das Parallelverarbeitungs-Subsystem 112 nicht an die Speicherbrücke 105, sondern an die I/O-Brücke 107 oder direkt an die CPU 102 angeschlossen sein. In nochmals weiteren Ausführungsbeispielen können die I/O-Brücke 107 und die Speicherbrücke 105 auf einem einzigen Chip integriert sein, anstatt als eine oder mehrere diskrete Vorrichtungen zu existieren. Schließlich können in bestimmten Ausführungsbeispielen eine oder mehrere der in 1 dargestellten Komponenten nicht vorhanden sein. Beispielsweise könnte der Schalter 116 eliminiert sein, und würden der Netzwerkadapter 118 und die Erweiterungskarten 120, 121 direkt mit der I/O-Brücke 107 verbunden sein.
  • 2 ist ein detaillierteres Blockdiagramm eines Parallelprozessors 202, der in dem Parallelverarbeitungs-Subsystem 112 von 1 enthalten ist, gemäß verschiedenen Ausführungsbeispielen der Erfindung. Obwohl 2 einem PP 202 darstellt, wie vorstehend angegeben, kann das Parallelverarbeitungs-Subsystem 112 eine beliebige Anzahl von PPen 202 beinhalten. Wie gezeigt ist, ist der PP 202 mit einem lokalen Parallelverarbeitungsspeicher (PP) 204 gekoppelt. Der PP 202 und der PP-Speicher 204 können mit einer oder mehreren integrierten Schaltungsvorrichtungen, wie programmierbaren Prozessoren, anwendungsspezifischen integrierten Schaltungen (ASICs) oder Speichervorrichtungen, oder auf jede andere technisch machbare Weise implementiert sein.
  • In einigen Ausführungsbeispielen umfasst der PP 202 eine Grafikverarbeitungseinheit (GPU), die dazu konfiguriert sein kann, eine Grafik-Rendering-Pipeline zu implementieren, um verschiedene Operationen im Zusammenhang mit der Erzeugung von Pixeldaten basierend auf von der CPU 102 und/oder dem Systemspeicher 104 bereitgestellten Bilddaten durchzuführen. Wenn Grafikdaten verarbeitet werden, kann der PP-Speicher 204 als Grafikspeicher verwendet werden, der einen oder mehrere herkömmliche Frame-Puffer und bei Bedarf auch ein oder mehrere andere Renderziele speichert. Unter anderem kann der PP-Speicher 204 dazu verwendet werden, Pixeldaten zu speichern und zu aktualisieren und endgültige Pixeldaten oder Anzeigebilder an die Anzeigevorrichtung 110 zur Anzeige zu liefern. In einigen Ausführungsbeispielen kann der PP 202 auch für allgemeine- Verarbeitungs- und Rechenoperationen konfiguriert sein.
  • Im Betrieb ist die CPU 102 der Masterprozessor des Computersystems 100, der die Vorgänge anderer Systemkomponenten steuert und koordiniert. Insbesondere gibt die CPU 102 Befehle aus, die den Betrieb des PPs 202 steuern. In einigen Ausführungsbeispielen schreibt die CPU 102 einen Befehlsstrom für den PP 202 in eine Datenstruktur (weder in 1 noch in 2 explizit gezeigt), die sich in dem Systemspeicher 104, dem PP-Speicher 204 oder einem anderen Speicherort befinden kann, der sowohl für die CPU 102 als auch den PP 202 zugänglich ist. Ein Zeiger auf die Datenstruktur wird in einen Schiebepuffer geschrieben, um die Verarbeitung des Befehlsstroms in der Datenstruktur einzuleiten. Der PP 202 liest Befehlsströme aus dem Schiebepuffer und führt dann Befehle asynchron zum Betrieb der CPU 102 aus. In Ausführungsbeispielen, in denen mehrere Schiebepuffer erzeugt sind, können für jeden Schiebepuffer von einem Anwendungsprogramm 190 über den Gerätetreiber 103 Ausführungsprioritäten festgelegt werden, um die Planung der verschiedenen Schiebepuffer zu steuern.
  • Wie ebenfalls gezeigt ist, beinhaltet der PP 202 eine I/O (Input/Output) Einheit 205, die mit dem Rest des Computersystems 100 über den Kommunikationspfad 113 und die Speicherbrücke 105 kommuniziert. Die I/O-Einheit 205 erzeugt Pakete (oder andere Signale) für die Übertragung auf dem Kommunikationspfad 113 und empfängt auch alle eingehenden Pakete (oder andere Signale) von dem Kommunikationspfad 113 und leitet die eingehenden Pakete zu den entsprechenden Komponenten des PPs 202. Beispielsweise können Befehle, die sich auf Verarbeitungsaufgaben beziehen, an eine Hostschnittstelle 206 gerichtet werden, während Befehle, die sich auf Speicheroperationen beziehen (z.B. Lesen von oder Schreiben in den PP-Speicher 204), an eine Crossbar- bzw. Kreuzschieneneinheit 210 gerichtet werden können. Die Hostschnittstelle 206 liest jeden Schiebepuffer und überträgt den in dem Schiebepuffer gespeicherten Befehlsstrom an ein Frontend 212.
  • Wie vorstehend in Verbindung mit 1 erwähnt, kann die Verbindung des PPs 202 zu dem Rest des Computersystems 100 variiert werden. In einigen Ausführungsbeispielen ist das Parallelverarbeitungs-Subsystem 112, das zumindest einen PP 202 beinhaltet, als eine Add-In-Karte implementiert, die in einen Erweiterungssteckplatz des Computersystems 100 eingesetzt werden kann. In weiteren Ausführungsbeispielen kann der PP 202 auf einem einzigen Chip mit einer Busbrücke, wie beispielsweise einer Speicherbrücke 105 oder einer I/O-Brücke 107, integriert sein. Auch in nochmals weiteren Ausführungsbeispielen können einige oder alle Elemente des PPs 202 zusammen mit der CPU 102 in einer einzigen integrierten Schaltung oder einem Chip-System (SoC) enthalten sein.
  • Im Betrieb überträgt das Frontend 212 von der Hostschnittstelle 206 empfangene Verarbeitungsaufgaben an eine Arbeitsverteilungseinheit (nicht gezeigt) innerhalb einer Aufgaben/Arbeits-Einheit 207. Die Arbeitsverteilungseinheit erhält Zeiger auf Verarbeitungsaufgaben, die als Aufgabenmetadaten (TMD) kodiert und in dem Speicher abgelegt sind. Die Zeiger auf TMDs sind in einem Befehlsstrom enthalten, der als ein Schiebepuffer gespeichert und von der Frontend-Einheit 212 von der Hostschnittstelle 206 empfangen wird. Verarbeitungsaufgaben, die als TMDs kodiert werden können, beinhalten Indizes, die den zu verarbeitenden Daten zugeordnet 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/ArbeitsEinheit 207 empfängt Aufgaben von dem Frontend 212 und stellt sicher, dass GPC 208 in einen gültigen Zustand konfiguriert sind, bevor die durch jede der TMDs spezifizierte Verarbeitungsaufgabe eingeleitet wird. Eine Priorität kann für jede TMD spezifiziert werden, die dazu verwendet wird, die Ausführung der Verarbeitungsaufgabe zu planen. Verarbeitungsaufgaben können auch von der Verarbeitungsclusteranordnung 230 empfangen werden. Optional kann die TMD einen Parameter beinhalten, der steuert, ob die TMD am Kopf oder am Ende einer Liste von Verarbeitungsaufgaben (oder zu einer Liste von Zeigern auf die Verarbeitungsaufgaben) hinzugefügt wird, wodurch eine weitere Ebene der Kontrolle über die Ausführungspriorität bereitgestellt wird.
  • Der PP 202 implementiert vorteilhaft eine hochparallele Verarbeitungsarchitektur basierend auf einer Verarbeitungsclusteranordnung 230, die einen Satz von C allgemeinen Verarbeitungsclustern (General Processing Clusters; GPCn) 208 beinhaltet, 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 GPC 208 zum Verarbeiten verschiedener Arten von Programmen oder zum Durchführen verschiedener Arten von Berechnungen zugeordnet sein. Die Zuordnung der GPC 208 kann abhängig von dem Arbeitsaufwand, der für jede Art von Programm oder Berechnung entsteht, variieren.
  • Die Speicherschnittstelle 214 beinhaltet einen Satz D von Partitionseinheiten 215, wobei D ≥ 1. Wie gezeigt ist, beinhaltet jede der Partitionseinheiten 215, ohne Einschränkung, einen Level 2 (L2) Cache 260. Jeder der L2-Caches 260 beinhaltet eine beliebige Anzahl von L2-Slices 270. Jede Partitionseinheit 215 ist mit einem oder mehreren dynamischen Direktzugriffsspeichern (DRAMs) 220 gekoppelt, die sich innerhalb des PP-Speichers 204 befinden. In einem Ausführungsbeispiel ist die Anzahl von Partitionseinheiten 215 gleich der Anzahl von DRAMs 220 und ist jede Partitionseinheit 215 mit einem anderen DRAM 220 gekoppelt. In anderen Ausführungsbeispielen kann sich die Anzahl von Partitionseinheiten 215 von der Anzahl von DRAMs 220 unterscheiden. Für den Fachmann versteht sich, dass ein DRAM 220 durch jedes andere technisch geeignete Speichermedium ersetzt werden kann. Im Betrieb können verschiedene Renderziele, wie beispielsweise Texturkarten und Frame-Puffer, über DRAMs 220 hinweg gespeichert werden, so dass Partitionseinheiten 215 Teile jedes Renderziels parallel schreiben können, um die verfügbare Bandbreite des PP-Speichers 204 effizient zu nutzen.
  • Ein gegebener GPC 208 kann Daten verarbeiten, die in einen der DRAMs 220 innerhalb des PP-Speichers 204 zu schreiben sind. Die Kreuzschieneneinheit 210 ist dazu konfiguriert, den Ausgang jedes GPCs 208 zu dem Eingang einer beliebigen Partitionseinheit 215 oder zu einem beliebigen anderen GPC 208 zur weiteren Verarbeitung zu leiten. GPC 208 kommunizieren mit der Speicherschnittstelle 214 über die Kreuzschieneneinheit 210, um aus verschiedenen DRAMs 220 zu lesen oder in diese zu schreiben. In einem Ausführungsbeispiel weist die Kreuzschieneneinheit 210 zusätzlich zu einer Verbindung zu dem PP-Speicher 204 über die Speicherschnittstelle 214 eine Verbindung zu der I/O-Einheit 205 auf, wodurch die Verarbeitungskerne innerhalb der verschiedenen GPC 208 mit dem Systemspeicher 104 oder einem anderen Speicher, der nicht lokal an dem PP 202 ist, kommunizieren können. In dem Ausführungsbeispiel von 2 ist die Kreuzschieneneinheit 210 direkt mit der I/O-Einheit 205 verbunden. In verschiedenen Ausführungsbeispielen kann die Kreuzschieneneinheit 210 virtuelle Kanäle verwenden, um Verkehrsströme zwischen den GPCn 208 und den Partitionseinheiten 215 zu trennen.
  • Wie gesagt können GPC 208 dazu programmiert werden, Verarbeitungsaufgaben mit Bezug zu einer Vielzahl von Anwendungen, einschließlich, aber nicht beschränkt auf, lineare und nichtlineare Datentransformationen, Filtern von Video- und/oder Audiodaten, Modellierungsoperationen (z.B. Anwenden von physikalischen Gesetzen zur Bestimmung von Position, Geschwindigkeit und anderen Attributen von Objekten), Bildwiedergabevorgänge (z.B. Tessellierungs-Shader, Vertex-Shader, Geometrie-Shader und/oder Pixel/Fragment-Shading-Programme), allgemeine Rechenoperationen, usw. auszuführen. Im Betrieb ist der PP 202 dazu konfiguriert, Daten aus dem Systemspeicher 104 und/oder dem PP-Speicher 204 an eine oder mehrere On-Chip-Speichereinheiten zu übertragen, die Daten zu verarbeiten und Ergebnisdaten in den Systemspeicher 104 und/oder den PP-Speicher 204 zurückzuschreiben. Auf die Ergebnisdaten können dann andere Systemkomponenten zugreifen, einschließlich der CPU 102, ein weiterer PP 202 in dem Parallelverarbeitungs-Subsystem 112 oder ein anderes Parallelverarbeitungs-Subsystem 112 in dem Computersystem 100.
  • Wie vorstehend erwähnt, kann eine beliebige Anzahl von PPen 202 in einem Parallelverarbeitungs-Subsystem 112 enthalten sein. Beispielsweise können mehrere PPen 202 auf einer einzigen Add-In-Karte bereitgestellt sein, oder können mehrere Add-In-Karten mit dem Kommunikationspfad 113 verbunden sein, oder können einer oder mehrere der PPen 202 in einen Brückenchip integriert sein. PPen 202 in einem Multi-PP-System können identisch oder voneinander verschieden sein. Beispielsweise können verschiedene PPen 202 unterschiedliche Anzahlen von Verarbeitungskernen und/oder unterschiedliche Mengen an PP-Speicher 204 aufweisen. In Implementierungen, in denen mehrere PPen 202 vorhanden sind, können diese PPen parallel zu den Prozessdaten mit einem höheren Durchsatz betrieben werden, als dies mit einem einzelnen PP 202 möglich ist. Systeme mit einem oder mehreren PPen 202 können in einer Vielzahl von Konfigurationen und Formfaktoren implementiert sein, einschließlich, aber nicht beschränkt auf, Desktops, Laptops, Handheld-PCs oder andere Handheld-Geräte, Server, Workstations, Spielkonsolen, eingebettete Systeme und dergleichen.
  • 3A ist ein detaillierteres Blockdiagramm eines General Processing Cluster (GPC) 208, der in dem Parallelprozessor 202 von 2 gemäß verschiedenen Ausführungsbeispielen der Erfindung enthalten ist. Im Betrieb kann der GPC 208 dazu konfiguriert werden, eine große Anzahl von Threads parallel auszuführen, um Grafiken, allgemeine Verarbeitungs- und/oder Rechenoperationen durchzuführen. Wie hierin verwendet, bezieht sich ein „Thread“ auf eine Instanz eines bestimmten Programms, das auf einem bestimmten Satz von Eingangsdaten ausgeführt wird. In einigen Ausführungsbeispielen werden Single Instruction Multiple Data (SIMD)-Anweisungsausgabetechniken verwendet, um die parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Befehlseinheiten bereitzustellen. In anderen Ausführungsbeispielen werden Single Instruction Multiple Thread (SIMT)-Techniken verwendet, um die parallele Ausführung einer großen Anzahl von im Allgemeinen synchronisierten Threads zu unterstützen, wobei eine gemeinsame Befehlseinheit verwendet wird, die dazu konfiguriert ist, Anweisungen an einen Satz von Verarbeitungsmaschinen innerhalb des GPCs 208 auszugeben. Im Gegensatz zu einem SIMD-Ausführungsregime, bei dem alle Verarbeitungsmaschinen typischerweise identische Anweisungen ausführen, ermöglicht die SIMT-Ausführung verschiedenen Threads, unterschiedlichen Ausführungspfaden durch ein bestimmtes Programm leichter zu folgen. Für den Fachmann versteht sich, dass ein SIMD-Verarbeitungsregime eine funktionale Teilmenge eines SIMT-Verarbeitungsregimes darstellt.
  • Der Betrieb des GPCs 208 wird über einen Pipelinemanager 305 gesteuert, der von einer Arbeitsverteilungseinheit (nicht dargestellt) innerhalb der Aufgaben/ArbeitsEinheit 207 empfangene Verarbeitungsaufgaben auf einen oder mehrere Streaming-Multiprozessoren (SMen) 310 verteilt. Der Pipelinemanager 305 kann auch dazu konfiguriert sein, durch Spezifizieren von Zielen für von SMen 310 ausgegebenen, verarbeiteten Daten eine Arbeitsverteilungs-Querschiene 330 zu steuern.
  • In einer Ausführungsbeispiel beinhaltet der GPC 208 einen Satz von M von SMen 310, wobei M ≥ 1. Außerdem enthält jeder SM 310 eine Reihe von funktionalen Ausführungseinheiten (nicht gezeigt), wie z.B. Ausführungseinheiten und Lade-Speicher-Einheiten. Verarbeitungsvorgänge, die für eine der funktionalen Ausführungseinheiten spezifisch sind, können in einer Pipeline zusammengefasst werden, so dass eine neue Anweisung zur Ausführung ausgegeben werden kann, bevor eine vorherige Anweisung ausgeführt wurde. Eine beliebige Kombination von funktionalen Ausführungseinheiten innerhalb eines bestimmten SMs 310 kann vorgesehen sein. In verschiedenen Ausführungsbeispielen können die funktionalen Ausführungseinheiten dazu konfiguriert sein, eine Vielzahl von verschiedenen Operationen zu unterstützen, einschließlich einer Ganzzahl- und Gleitkommaarithmetik (z.B. Addition und Multiplikation), Vergleichsoperationen, boolesche Operationen (AND, OR, XOR), Bitverschiebungen und Berechnung verschiedener algebraischer Funktionen (z.B. planare Interpolation und trigonometrische, exponentielle und logarithmische Funktionen, usw.). Vorteilhaft kann dieselbe funktionale Ausführungseinheit dazu konfiguriert werden, verschiedene Operationen durchzuführen.
  • Im Betrieb ist jeder SM 310 dazu konfiguriert, eine oder mehrere Thread-Gruppen zu verarbeiten. Wie hierin verwendet, bezieht sich eine „Thread-Gruppe“ oder ein „Warp“ auf eine Gruppe von Threads, die gleichzeitig dasselbe Programm auf verschiedenen Eingangsdaten ausführen, wobei ein Thread der Gruppe einer anderen Ausführungseinheit innerhalb eines SMs 310 zugeordnet ist. Eine Thread-Gruppe kann weniger Threads beinhalten als die Anzahl der Ausführungseinheiten innerhalb des SMs 310, wobei in diesem Fall ein Teil der Ausführung während der Zyklen, in denen diese Thread-Gruppe verarbeitet wird, untätig sein kann. Eine Thread-Gruppe kann auch mehr Threads beinhalten als die Anzahl der Ausführungseinheiten innerhalb des SMs 310, wobei in diesem Fall die Verarbeitung über aufeinanderfolgende Taktzyklen erfolgen kann. Da jeder SM 310 bis zu G Thread-Gruppen gleichzeitig unterstützen kann, folgt daraus, dass in dem GPC 208 jederzeit bis zu G*M-Thread-Gruppen ausgeführt werden können.
  • Zusätzlich kann eine Vielzahl von verwandten Thread-Gruppen innerhalb eines SMs 310 gleichzeitig (in verschiedenen Ausführungsphasen) aktiv sein. Diese Sammlung von Thread-Gruppen wird hierin als eine kooperative Thread-Anordnung bzw. „cooperative thread array“ („CTA“) oder „Thread-Array“ bezeichnet. Die Größe eines bestimmten CTA ist gleich m*k, wobei k die Anzahl von gleichzeitig ausgeführten Threads in einer Thread-Gruppe ist, die typischerweise ein ganzzahliges Vielfaches der Anzahl der Ausführungseinheiten innerhalb des SMs 310 ist, und m die Anzahl der gleichzeitig innerhalb des SMs 310 aktiven Thread-Gruppen ist.
  • Obwohl in 3A nicht dargestellt, enthält jeder SM 310 einen Level One (L1)-Cache oder verwendet Platz in einem entsprechenden L1-Cache außerhalb des SMs 310, um unter anderem Lade- und Speicher-Operationen, die von den Ausführungseinheiten durchgeführt werden, zu unterstützen. Jeder SM 310 hat darüber hinaus Zugriff auf die Level 2 (L2) Caches, die von allen GPCn 208 in dem PP 202 gemeinsam genutzt werden. Die L2-Caches können zum Übertragen von Daten zwischen Threads verwendet werden. Schließlich haben SMen 310 auch Zugriff auf Off-Chip „globalen“ Speicher, der PP-Speicher 204 und/oder Systemspeicher 104 beinhalten kann. Es versteht sich, dass jeder gegenüber dem PP 202 externe Speicher als globaler Speicher verwendet werden kann. Darüber hinaus kann, wie in 3A gezeigt ist, ein Level One-Point-5 (L1.5) Cache 335 in den GPCn 208 integriert und dazu konfiguriert sein, Daten zu empfangen und zu speichern, die über die Speicherschnittstelle 214 von dem SM 310 aus dem Speicher angefordert werden. Diese Daten können, ohne Einschränkung, Anweisungen, einheitliche Daten und konstante Daten beinhalten. In Ausführungsbeispielen mit mehreren SMen 310 innerhalb von GPCn 208 können die SMen 310 vorteilhaft gemeinsame Anweisungen und Daten, die in dem L1.5-Cache 335 zwischengespeichert sind, austauschen.
  • Jeder GPC 208 kann eine zugehörige Speicherverwaltungseinheit (MMU) 320 haben, die dazu konfiguriert ist, virtuelle Adressen auf physikalische Adressen abzubilden. In verschiedenen Ausführungsbeispielen kann sich die MMU 320 entweder innerhalb des GPCs 208 oder innerhalb der Speicherschnittstelle 214 befinden. Die MMU 320 beinhaltet einen Satz von Seitentabelleneinträgen (page table entries; PTE), die dazu verwendet werden, eine virtuelle Adresse einer physikalischen Adresse einer Kachel oder Speicherseite zuzuordnen, und optional einen Cache-Zeilenindex. Die MMU 320 kann Adressenübersetzungs-Lookaside-Puffer (translation lookaside buffer; TLB) oder Caches beinhalten, die sich innerhalb von SMen 310, innerhalb eines oder mehreren L1-Caches oder innerhalb GPCn 208 befinden können.
  • In Grafik- und Rechenanwendungen kann der GPC 208 so konfiguriert sein, dass jeder SM 310 mit einer Textureinheit 315 gekoppelt ist, um Texturmappingoperationen durchzuführen, wie z.B. das Bestimmen von Texturprobenpositionen, das Lesen von Texturdaten und das Filtern von Texturdaten.
  • Im Betrieb überträgt jeder SM 310 eine verarbeitete Aufgabe an eine Arbeitsverteilungsquerleiste 330, um die verarbeitete Aufgabe einem anderen GPC 208 zur weiteren Verarbeitung bereitzustellen oder die verarbeitete Aufgabe in einem der L2-Caches 260, dem Parallelverarbeitungsspeicher 204 oder dem Systemspeicher 104 über die Kreuzschieneneinheit 210 zu speichern. Darüber hinaus ist eine Pre-Raster-Operationen (preROP)-Einheit 325 dazu konfiguriert, Daten von dem SM 310 zu empfangen, Daten an eine oder mehrere Raster-Operationen (ROP)-Einheiten innerhalb der Partitionseinheiten 215 zu leiten, Optimierungen für ein Farbmischen durchzuführen, Pixelfarbdaten zu organisieren und Adressenübersetzungen durchzuführen.
  • Es versteht sich, dass die hierin beschriebene Kernarchitektur veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Unter anderem können beliebig viele Prozessoren, wie z.B. SMen 310, Textureinheiten 315 oder preROP-Einheiten 325, in GPCn 208 integriert werden. Darüber hinaus kann der PP 202, wie vorstehend in Verbindung mit 2 beschrieben wurde, eine beliebige Anzahl von GPCn 208 beinhalten, die so konfiguriert sind, dass sie einander funktional ähnlich sind, so dass das Ausführungsverhalten nicht davon abhängt, welcher GPC 208 eine bestimmte Verarbeitungsaufgabe erhält. Darüber hinaus arbeitet jeder GPC 208 unabhängig von den anderen GPCn 208 in dem PP 202, um Aufgaben für ein oder mehrere Anwendungsprogramme auszuführen. In Anbetracht des Vorstehenden versteht sich für den Fachmann, dass die in den 1-3A beschriebene Architektur den Anwendungsbereich der Erfindung in keiner Weise beschränkt.
  • Implementierung einer Grafikverarbeitungspipeline
  • 3B ist ein konzeptionelles Diagramm einer Grafikverarbeitungspipeline 320, die innerhalb des Parallelprozessors 202 von 2 implementiert ist, gemäß einem Ausführungsbeispiel der Erfindung. Wie sich für den Fachmann versteht, beinhaltet eine konventionelle Grafikverarbeitungspipeline typischerweise eine einzige Hardwareeinheit mit fester Funktion, die als Stammfunktionen-Verteiler bekannt ist. Der Stammfunktionen-Verteiler sammelt Eckpunkt- bzw. Vertexdaten, die mit Oberflächen hoher Ordnung, grafischen Stammfunktionen und dergleichen verbunden sind, von einer Frontend-Einheit und baut entsprechende Arbeitsstapel auf, wobei jeder Arbeitsstapel Eckpunktdaten enthält, die mehrere Stammfunktionen definieren. Die Arbeitsstapel werden dann von programmierbaren Ausführungseinheiten verarbeitet, die ebenfalls in der konventionellen Grafikverarbeitungspipeline enthalten sind. Während der Ausführung werden die Arbeitsstapel auf eine Reihe von Streaming-Multiprozessoren verteilt, die dazu konfiguriert sind, eine große Anzahl von Threads parallel auszuführen, um Grafikoperationen an den Eckpunktdaten basierend auf einem Programmiermodell durchzuführen. Oftmals wird in Übereinstimmung mit der Programmierung jeder Eckpunkt, der in einem bestimmten Arbeitsstapel bzw. Arbeitsgang enthalten ist, unabhängig von einem anderen Thread verarbeitet.
  • Eine Einschränkung herkömmlicher Grafikverarbeitungspipelines besteht darin, dass der Durchsatz der Grafikverarbeitungspipeline durch den Durchsatz des Stammfunktionen-Verteilers begrenzt wird. Insbesondere ist der Stammfunktionen-Verteiler typischerweise eine Hardwareeinheit mit fester Funktion, die einen festen Durchsatz und eine begrenzte Skalierbarkeit aufweist. Mit zunehmender Speicherbandbreite und Anzahl der Streaming-Multiprozessoren begrenzt der Stammfunktionen-Verteiler folglich die Gesamtleistung der konventionellen Grafikverarbeitungspipeline. Wenn beispielsweise der Stammfunktionen-Verteiler einen Durchsatz von 16 Stammfunktionen pro Taktzyklus hat, dann ist der Gesamtdurchsatz der konventionellen Grafikverarbeitungspipeline unabhängig von der Speicherbandbreite und/oder der Anzahl der Streaming-Multiprozessoren, die die Grafikpipeline unterstützen, auf 16 Stammfunktionen pro Taktzyklus begrenzt.
  • Eine weitere Beschränkung herkömmlicher Grafikverarbeitungspipelines besteht darin, dass das entsprechende Programmiermodell unflexibel ist. Das Programmiermodell erlaubt es Anwendungen unter anderem nicht, bestimmte Operationen früher in der Pipeline auszuführen, um die Gesamtausführung effizienter zu gestalten. Wie bereits erwähnt wurde, erzwingt das Programmiermodell beispielsweise oft eine Eins-zu-Eins-Korrespondenz zwischen den Eckpunkten und den Threads, wobei jeder Eckpunkt, der in einem Stapel von Arbeiten enthalten ist, unabhängig von einem anderen Thread verarbeitet wird. Da ein bestimmter Thread einen bestimmten Eckpunkt unabhängig von den Eckpunkten verarbeitet, die von anderen Threads verarbeitet werden, gibt es keinen guten Weg, die Eckpunktverarbeitungseinheit so zu programmieren, dass sie Aussortieroperationen durchführt, um nicht sichtbare Stammfunktionen in der Eckpunktverarbeitungsphase der konventionellen Grafikverarbeitungspipeline zu verwerfen. Beispielsweise kann ein Thread, der einen einzelnen Eckpunkt verarbeitet, der in einer bestimmten Dreiecksstammfunktion enthalten ist, nicht bestimmen, ob die Dreiecksstammfunktion in einem endgültigen Bild sichtbar ist, da zwei weitere Eckpunkte, die von zwei anderen Threads verarbeitet werden, an dieser Bestimmung beteiligt sein müssen. Da die Eckpunktverarbeitungseinheit nicht programmiert werden kann, um nicht sichtbare Stammfunktionen zu entfernen, führen nachgelagerte Einheiten in der konventionellen Grafikverarbeitungspipeline unnötige Grafikoperationen an diesen nicht sichtbaren Stammfunktionen durch und verschwenden so sowohl Verarbeitungsressourcen als auch Energie.
  • Um die Leistung und die Flexibilität der Grafikverarbeitungspipeline 320 im Vergleich zu herkömmlichen Grafikverarbeitungspipelines zu verbessern, bietet die Grafikverarbeitungspipeline 320 flexiblere Mechanismen zum Empfangen und Verarbeiten von Grafikdaten. Insbesondere beinhaltet die Grafikverarbeitungspipeline 320 ohne Einschränkung einen Gitter-Shader-Generator 330 und eine beliebige Anzahl von Gitter-Shadern 350, die den Stammfunktionen-Verteiler, die Vertex-Shading-Einheiten und die Geometrie-Shading-Einheiten in herkömmlichen Grafikverarbeitungspipelines ersetzen.
  • Jeder der Gitter-Shader 350 umfasst eine Gruppe von Threads, die das Gitter-Shading-Programm 192 basierend auf einem zugehörigen Gitter-Shading-Identifikator (ID) 340 kooperativ ausführen, um ein Meshlet 360 zu erzeugen. Jedes Meshlet 360 ist eine In-Pipe-Repräsentation einer Geometrie, die in einem Abschnitt eines Eingabegitters enthalten ist, das der Gitter-Shading-ID 340 zugeordnet ist. Im Allgemeinen beziehen sich „In-Pipe“-Daten auf Daten, die in einem On-Chip-Speicher gespeichert sind, der für die Grafikverarbeitungspipeline 320 zugänglich ist. Beispielsweise könnten die Meshlets 360 in dem L1.5-Cache 335 oder einem L1-Cache gespeichert werden, nicht aber in dem PP-Speicher 204. Wie in Verbindung mit 4 näher beschrieben wird, implementiert jedes der Meshlets 360 ein festes Format, das es nachfolgenden Einheiten in der Grafikverarbeitungspipeline 230 ermöglicht, sich ordnungsgemäß mit dem Meshlet 360 zu verbinden und dieses zu interpretieren.
  • Wie gezeigt ist, beinhaltet die Grafikverarbeitungspipeline 320, ohne Einschränkung, den Gitter-Shader-Generator 330, eine beliebige Anzahl der Gitter-Shader-Identifikatoren (ID) 340, eine beliebige Anzahl der Gitter-Shader 350, eine beliebige Anzahl der Meshlets 360, einen Rasterisierer 370, eine Pixel-Shading-Einheit 380 und einen Rasteroperationsprozessor (ROP) 390. Nur zur Erläuterung wird jede der Komponenten in der Grafikverarbeitungspipeline 320 im Folgenden auch als „Einheit“ bezeichnet, die eine „Stufe“ bzw „Phase“ in der Grafikverarbeitungspipeline 320 implementiert.
  • Der Gitter-Shader-Generator 330 ist eine Verarbeitungseinheit mit fester Funktion, die von dem Benutzeranwendungsprogramm 190 eine Gitter-Shader-Thread-Anzahl 312 und eine Gitter-Shader-Anzahl 314 empfängt. Die Gitter-Shader-Thread-Anzahl 312 gibt eine Anzahl von Threads an, die in jedem Gitter-Shader 350 enthalten sein sollen. Die Anzahl der Gitter-Shader 314 gibt eine Gesamtzahl von Gitter-Shadern 350 an, die der Gitter-Shader-Generator 330 aufrufen soll. Um jeden der Gitter-Shader 350 aufzurufen, stellt der Gitter-Shader-Generator 330 einer anderen Gruppe von Threads eine andere Gitter-Shader-ID 340 bereit und konfiguriert die Gruppe von Threads dazu, das Gitter-Shading-Programm 192 kooperativ auszuführen. Die Gesamtzahl der Threads in jeder Thread-Gruppe ist gleich der Anzahl der Gitter-Shader-Threads 312. Die Gitter-Shader-IDs 340 sind aufeinanderfolgende ganze Zahlen im Bereich von 0 bis N-1 (einschließlich), wobei N die Anzahl der Gitter-Shader 314 ist.
  • In einigen Ausführungsbeispielen ist jeder der Gitter-Shader 350 für einen anderen Abschnitt eines Eingangs-Gitters verantwortlich. Die Gitter-Shader-ID 340(i) ermöglicht es dem Gitter-Shader 350(i), Bilddaten für den Teil des Eingangs-Gitters zu lokalisieren, für den der Gitter-Shader 350(i) verantwortlich ist. Beispielsweise könnte das Gitter-Shading-Programm 192 den Gitter-Shader 350(i) dazu konfigurieren, basierend auf einer Basisbildadresse und der Gitter-Shader-ID 340(i) Attribute und die Topologie von Grafik-Stammfunktionen zu lokalisieren, die einem linken oberen Abschnitt eines Eingabe-Gitters zugeordnet sind. In alternativen Ausführungsbeispielen kann der Gitter-Shader 350(i) jede Art von Daten basierend auf der Gitter-Shader-ID 340(i) anstelle eines Teils eines Eingabe-Gitters lesen und verarbeiten.
  • Ein Gitter-Shader-Programmiermodell definiert, wie die Threads, die den Gitter-Shader 350 umfassen, das Gitter-Shading-Programm 192 ausführen. Das Gitter-Shader-Programmiermodell spezifiziert, dass die Threads, die den Gitter-Shader 350(i) umfassen, eine einzige Eingabe, die Gitter-Shader-ID 340(i), empfangen und kooperativ eine einzige Ausgabe, das Meshlet 360(i), erzeugen. Insbesondere erlaubt das Gitter-Shader-Programmiermodell dem Gitter-Shading-Programm 192, jede Beziehung zwischen Eckpunkten und Threads und jede Beziehung zwischen Grafik-Stammfunktionen und Threads zu definieren.
  • Das Gitter-Shader-Programmiermodell erlaubt es dem Gitter-Shading-Programm 192, einen gemeinsamen Meshlet-Puffer 352 in dem On-Chip-Speicher zuzuweisen. Der Gitter-Shader 350(i) weist den gemeinsamen Meshlet-Puffer 352(i) in dem On-Chip-Speicher zu, wenn der Gitter-Shader 350(i) aufgerufen wird. Während der Gitter-Shader 350 ausgeführt wird, erleichtert der gemeinsame Meshlet-Puffer 352(i) die Kommunikation zwischen den Threads, die den Gitter-Shader 350(i) umfassen. Wenn der Gitter-Shader 350(i) beendet wird, wird der gemeinsame Meshlet-Puffer 352(i) freigegeben.
  • Das Gitter-Shader-Programmiermodell definiert auch die Operationen, für die das Gitter-Shading-Programm 192 den Gitter-Shader 350 konfigurieren kann. Im Allgemeinen kann der Gitter-Shader 350 alle Operationen ausführen, die für ein kooperatives Thread-Array (CTA) verfügbar sind. Beispiele für Operationen, die der Gitter-Shader 350 ausführen kann, sind unter anderem Lese-/Lade-Operationen, allgemeine Rechenoperationen, Vertex-Shading-Operationen, Geometrie-Shading-Operationen und Schreib-/Speicher-Operationen. Wichtig ist, dass der Gitter-Shader 350 auch beliebig viele Synchronisationsoperationen, wie z.B. Barriereoperationen, zwischen den Threads, die den Gitter-Shader 350 bilden, durchführen kann. Darüber hinaus können die Threads, die den Gitter-Shader 250 umfassen, eine Anweisung, wie beispielsweise eine passende Anweisung, die eine oder mehrere kooperative Operationen über die Threads hinweg durchführt, ohne auf gemeinsamen bzw. gemeinsam genutzten Speicher zuzugreifen, ausführen.
  • Beispielsweise implementiert der Gitter-Shader 350 in einigen Ausführungsbeispielen einen dreiphasigen Rechenprozess. In einer ersten Phase holt jeder Thread die Positionen eines oder mehrerer Eckpunkte aus dem Off-Chip-Speicher, führt Transformationsoperationen an den Eckpunkten durch und schreibt die transformierten Eckpunktpositionen in das Meshlet 360. In einer zweiten Phase holt, nachdem alle Threads die erste Phase abgeschlossen haben, jeder Thread die Topologie einer Grafik-Stammfunktion aus dem Off-Chip-Speicher und bewertet, ob die Grafik-Stammfunktion basierend auf den transformierten Eckpunktpositionen aussortiert werden soll. Die Threads schreiben dann die Topologie der Grafik-Stammfunktion, die nicht aussortiert sind, in das Meshlet 360. In einer dritten Phase holt, nachdem alle Threads die zweite Phase abgeschlossen haben, jeder Thread zusätzliche Attribute für einen oder mehrere Eckpunkte, die in den nicht aussortierten Grafik-Stammfunktionen enthalten sind, verarbeitet die Attribute für die Eckpunkte und schreibt die verarbeiteten Eckpunktattribute in das Meshlet 360.
  • Insbesondere ist die Anzahl der Threads, die den Gitter-Shader 350 umfassen, nicht notwendigerweise gleich der Anzahl der von dem Gitter-Shader 350 verarbeiteten Eckpunkte. Ferner ist die Anzahl von Eckpunkten, für die der Gitter-Shader 350 Bilddaten abruft, nicht notwendigerweise gleich der Anzahl von Eckpunkten, die der Gitter-Shader 350 in dem Meshlet 360 beschreibt. Ebenso ist die Anzahl der Threads, die den Gitter-Shader 350 umfassen, nicht notwendigerweise gleich der Anzahl der von dem Gitter-Shader 350 verarbeiteten Grafik-Stammfunktionen. Ferner ist die Anzahl der Grafik-Stammfunktionen, für die der Gitter-Shader 350 Grafikdaten abruft, nicht notwendigerweise gleich der Anzahl von Grafik-Stammfunktionen, die der Gitter-Shader 350 in dem Meshlet 360 beschreibt.
  • Im Allgemeinen entsprechen die Gitter-Shader 350 einer beliebigen Anzahl von Einschränkungen, die mit der Grafikverarbeitungspipeline 320, dem PP 202 und dem On-Chip-Speicher verbunden sind. Beispielsweise wird in einigen Ausführungsbeispielen der Typ der von den Gitter-Shadern 350 verarbeiteten und in den Meshlets 360 beschriebenen Grafik-Stammfunktionen (z.B. Dreieck, Linie, Punkt) durch einen der Grafikverarbeitungspipeline 320 zugeordneten Zustand definiert. In den gleichen oder anderen Ausführungsbeispielen ist die Gitter-Shader-Thread-Anzahl 312 auf maximal 32 Threads beschränkt.
  • Die Gitter-Shader-IDs 340 definieren eine Verarbeitungsreihenfolge für die Meshlets 360. Insbesondere verarbeiten nachfolgende Einheiten in der Grafikverarbeitungspipeline 320 die Meshlets 360 basierend auf den Gitter-Shader-IDs 340. Beispielsweise liefert in einigen Ausführungsbeispielen die Grafikverarbeitungspipeline 320 die Meshlets 360 an den Rasterisierer 370, basierend auf einer aufsteigenden Reihenfolge der Gitter-Shader-IDs 340.
  • Der Rasterisierer 370 liest die Meshlets 360, scannt die Grafik-Stammfunktionen und überträgt Fragmente und Abdeckungsdaten an die Pixel-Shading-Einheit 380. Zusätzlich kann der Rasterisierer 385 dazu konfiguriert sein, ein z-Aussortieren bzw. z-Culling und andere z-basierte Optimierungen durchzuführen.
  • Die Pixel-Shading-Einheit 380 ist eine programmierbare Ausführungseinheit, die dazu konfiguriert ist, Fragment-Shading-Programme auszuführen und von dem Rasterisierer 370 empfangene Fragmente entsprechend den Vorgaben der Fragment-Shading-Programme zu transformieren. Fragment-Shading-Programme können Fragmente auf Pixelebene schattieren bzw. nuancieren, wobei solche Shading-Programme als Pixel-Shading-Programme bezeichnet werden können. Alternativ können Fragment-Shading-Programme Fragmente auf Sampleebenengranularität schattieren, wobei jedes Pixel mehrere Samples enthält und jedes Sample einen Teil eines Pixels darstellt. Alternativ können Fragment-Shading-Programme Fragmente in jeder anderen technisch möglichen Granularität schattieren, abhängig von der programmierten Abtastrate.
  • In verschiedenen Ausführungsbeispielen kann die Pixel-Shading-Einheit 380 dazu programmiert sein, Operationen wie beispielsweise perspektivische Korrektur, Texturmapping, Shading, Blending und dergleichen durchzuführen, um schattierte Fragmente zu erzeugen, die an die ROP 390 übertragen werden. Die Pixel-Shading-Einheit 380 kann Daten lesen, die in dem gemeinsamen Speicher gespeichert sind.
  • Die ROP 390 ist eine Verarbeitungseinheit, die Rasteroperationen wie Schablonen, Z-Test, Blending und dergleichen durchführt und Pixeldaten als verarbeitete Grafikdaten zur Speicherung in dem Grafikspeicher über die Speicherschnittstelle 214 überträgt, wobei der Grafikspeicher typischerweise als ein oder mehrere Renderziele strukturiert ist. Die verarbeiteten Bilddaten können in dem Grafikspeicher, dem Parallelverarbeitungsspeicher 204 oder dem Systemspeicher 104 zur Anzeige auf der Anzeigevorrichtung 110 oder zur Weiterverarbeitung durch die CPU 102 oder das Parallelverarbeitungs-Subsystem 112 gespeichert werden. In einigen Ausführungsbeispielen ist die ROP 390 dazu konfiguriert, z- oder Farbdaten, die in den Speicher geschrieben werden, zu komprimieren und z- oder Farbdaten, die aus dem Speicher gelesen werden, zu dekomprimieren. In einigen Ausführungsbeispielen kann sich die ROP 390 in der Speicherschnittstelle 214, in den GPCn 208, in der Verarbeitungsclusteranordnung 230 außerhalb der GPC 208 oder in einer separaten Einheit (nicht dargestellt) innerhalb der PPen 202 befinden.
  • Die Grafikverarbeitungspipeline 320 kann durch ein oder mehrere Verarbeitungselemente innerhalb des PPs 202 implementiert sein. Beispielsweise könnte einer der SMen 310 von 3A dazu konfiguriert sein, die Funktionen der Pixel-Shading-Einheit 390 auszuführen. Die Funktionen des Gitter-Shader-Generators 320, des Rasterisierers 370 und der ROP 390 können auch durch Verarbeitungselemente innerhalb eines bestimmten GPCs 208 in Verbindung mit einer entsprechenden Partitionseinheit 215 ausgeführt sein. Alternativ kann die Grafikverarbeitungspipeline 320 mit dedizierten Verarbeitungselementen mit fester Funktion für eine oder mehrere der vorstehend aufgeführten Funktionen implementiert sein. In verschiedenen Ausführungsbeispielen kann der PP 202 dazu konfiguriert sein, eine oder mehrere Grafikverarbeitungspipelines 320 zu realisieren.
  • Wie hierin verwendet, ist ein Satz von Operationen als eine oder mehrere Anweisungen definiert, die von einem einzelnen Thread, von einer Thread-Gruppe oder von mehreren Thread-Gruppen, die im Gleichklang wirken, ausgeführt werden. Es wird angemerkt, dass Referenzen auf gemeinsamen Speicher, wie hierin verwendet, einen oder mehrere technisch realisierbare Speicher beinhalten können, einschließlich, aber nicht beschränkt auf, einen lokalen Speicher, der von einem oder mehreren SMen 310 gemeinsam genutzt wird, oder einen Speicher, der über die Speicherschnittstelle 214 zugänglich ist, wie beispielsweise einen Cache-Speicher, einen Parallelverarbeitungsspeicher 204 oder einen Systemspeicher 104. Außerdem wird angemerkt, dass, wie hierin verwendet, Referenzen auf den Cache-Speicher einen oder mehrere technisch realisierbare Speicher beinhalten können, einschließlich, aber nicht beschränkt auf, einen L1-Cache, einen L1.5-Cache und die L2-Caches.
  • Es versteht sich, dass die hier gezeigte Grafikverarbeitungspipeline 320 veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Beispielsweise können in verschiedenen Ausführungsbeispielen beliebig viele der Einheiten in der Grafikverarbeitungspipeline 320 implementiert sein, während andere Elemente weggelassen oder in technisch machbarer Weise ersetzt sein können. Unter anderem kann jede einer Ansichtsbereichskalen-, Aussortier- bzw. Cull und Schneide- bzw. Clip-Einheit (viewport scale, cull and clip; VPC), einer Kachelungs- bzw. Tiling-Einheit und einer Einstell- bzw. Setup-Einheit in der Grafikverarbeitungspipeline 320 enthalten sein.
  • Es wird angemerkt, dass die hierin beschriebenen Techniken eher veranschaulichend als beschränkend sind und geändert werden können, ohne den breiteren Rahmen und Schutzumfang der Erfindung zu verlassen. Viele Modifikationen und Variationen der Funktionalität, die durch den Gitter-Shader-Generator 330, die Gitter-Shader 350 und das Gitter-Shader-Programmiermodell bereitgestellt werden, sind für den Fachmann offensichtlich, ohne den Schutzumfang und den Rahmen der beschriebenen Ausführungsbeispielen zu verlassen. Beispielsweise können in verschiedenen Ausführungsbeispielen beliebig viele der Techniken und/oder Beschränkungen implementiert sein, während andere Techniken und/oder Beschränkungen weggelassen oder in technisch machbarer Weise ersetzt sein können. In verschiedenen Ausführungsbeispielen können die Gitter-Shader 350 in jeder technisch machbaren Weise aufgerufen und programmiert werden.
  • 4 ist ein detaillierteres Blockdiagramm des Meshlets 360 von 3B, gemäß verschiedenen Ausführungsbeispielen der Erfindung. Obwohl 4 ein einzelnes Meshlet 360 beschreibt, erzwingt das Meshlet-Programmiermodell die zugehörige Architektur und Beschränkungen für alle der Meshlets 340. Wie gezeigt ist, beinhaltet das Meshlet 360, ohne Einschränkung, eine Anzahl von Stammfunktionen 410, einen Stammfunktionen-Topologieabschnitt 420, einen Pro-Eckpunkt-Attribute-Abschnitt 430, einen Pro-Stammfunktion-Attribute-Abschnitt 440 und einen Meshlet-Datenabschnitt 450.
  • Die Anzahl von Stammfunktionen 410 und der Stammfunktionen-Topologieabschnitt 420 werden zusammenfassend als der Meshlet-Kopfabschnitt bzw. „Meshlet Header“ bezeichnet. Demgegenüber werden der Pro-Eckpunkt-Attribute-Abschnitt 430, der Pro-Stammfunktion-Attribute-Abschnitt 440 und der Meshlet-Datenabschnitt 450 gemeinsam als der Meshlet-Körper bzw. „Meshlet Body“ bezeichnet. In alternativen Ausführungsbeispielen kann das Meshlet 360 eine beliebige Anzahl von Abschnitten beinhalten, während andere Abschnitte weggelassen oder in einer beliebigen Weise, die eine konsistente Schnittstelle zu nachfolgenden Komponenten in der Grafikverarbeitungspipeline 320 bereitstellt, ersetzt sein können.
  • In verschiedenen Ausführungsbeispielen unterliegen die Größe und/oder die Zusammensetzung des Meshlet-Körpers und jedes der in dem Meshlet 360 enthaltenen Abschnitte Einschränkungen. So ist beispielsweise in einigen Ausführungsbeispielen die kombinierte Größe des gemeinsamen Meshlet-Puffers 352 und des Meshlet-Körpers auf maximal 16 Kilobyte (KB) begrenzt. Ferner ist die Größe des Pro-Eckpunkt-Attribute-Abschnitts 430 auf 16 KB begrenzt, und ist die Größe des Pro-Stammfunktion-Attribute-Abschnitts 440 auf 16 KB begrenzt. Die Gesamtzahl von Attributen, die für jeden Eckpunkt in dem Pro-Eckpunkt-Attribute-Abschnitt 430 spezifiziert sind, ist auf 32 Vektorattribute oder 128 Skalarattribute beschränkt, und die Gesamtzahl der Attribute, die für jede Stammfunktion in dem Pro-Stammfunktion-Attribute-Abschnitt 440 spezifiziert sind, ist auf 32 Vektorattribute oder 128 Skalarattribute beschränkt.
  • Im Betrieb erlaubt, als Teil der Durchsetzung der mit dem Meshlet 360 verbundenen Einschränkungen, das Meshlet-Programmiermodell dem Entwickler, die maximale Anzahl von Eckpunkten und die maximale Anzahl von Grafik-Stammfunktionen auszudrücken, die in dem Meshlet 360 beschrieben sein können. Nachdem sichergestellt wurde, dass die maximale Anzahl von Eckpunkten und die maximale Anzahl von Grafik-Stammfunktionen beliebigen bestehenden Einschränkungen entspricht, definiert das Meshlet-Programmiermodell die Gesamtgröße und das Format des Meshlet-Kopfabschnitts. Genauer gesagt wird die Gesamtgröße des Meshlet-Kopfabschnitts basierend auf der maximalen Anzahl von Eckpunkten, der Anzahl von Attributen pro Eckpunkt bzw. Vertex, der maximalen Anzahl von Grafik-Stammfunktionen und der Anzahl von Attributen pro Stammfunktion definiert.
  • Die Anzahl von Stammfunktionen 410 spezifiziert eine Gesamtzahl von Grafik-Stammfunktionen, die in dem Meshlet 360 beschrieben sind. Die Anzahl von Stammfunktionen 410 kann gleich Null sein, um zu spezifizieren, dass der Gitter-Shader 330 alle von dem Gitter-Shader 330 verarbeiteten Grafik-Stammfunktionen aussortiert hat. Der Stammfunktion-Topologie-Abschnitt 420 spezifiziert die Eckpunkte, die in den Grafik-Stammfunktionen enthalten sind. Der Typ der Grafik-Stammfunktionen und damit die Anzahl der in den einzelnen Grafik-Stammfunktionen enthaltenen Eckpunkte wird durch den Zustand der Grafikverarbeitungspipeline 320 bestimmt. In alternativen Ausführungsbeispielen können die Typen der Grafik-Stammfunktionen variieren, und kann der Typ jeder Grafik-Stammfunktion auf jede technisch mögliche Weise spezifiziert sein.
  • Für jeden Eckpunkt, der in dem Stammfunktion-Topologie-Abschnitt 420 enthalten ist, enthält der Pro-Eckpunkt-Attribute-Abschnitt 430 Werte für jedes der beliebig vielen Vertex-Attribute. Beispiele für Eckpunktattribute sind, ohne Einschränkung, eine Flächennormale, eine Farbe, eine Position, ein Transparenzwert und so weiter. Für jede der in dem Stammfunktion-Topologie-Abschnitt 430 beschriebenen Stammfunktionen enthält der Pro-Stammfunktion-Attribute-Abschnitt 440 Werte für jedes von beliebig vielen Stammfunktion-Attributen. Beispiele für Stammfunktion-Attribute beinhalten, ohne Einschränkung, eine Flächennormale, eine Farbe, eine Texturkartenkoordinate, eine Ansichtsbereich-Feld- bzw. Viewport-Array-Maske und so weiter. Die Viewport-Array-Maske zeigt die Ansichtsbereiche bzw. Viewports an, an die die Stammfunktion über Bits zu senden ist, wobei jedes Bit einen Ansichtsbereich repräsentiert. Der Fachmann wird erkennen, dass im Gegensatz zu herkömmlichen Grafikverarbeitungspipelines, die indirekt Werte für Stammfunktion-Attribute über einen „provozierenden Eckpunkt“ einer Grafik-Stammfunktion assoziieren, das Meshlet 360 Werte für Stammfunktion-Attribute direkt einer Grafik-Stammfunktion zuordnet.
  • Der Meshlet-Datenabschnitt 450 kann eine beliebige Menge und Art von Informationen beinhalten, die dem Meshlet 360 zugeordnet sind. Beispielsweise kann in verschiedenen Ausführungsbeispielen der Meshlet-Datenabschnitt 450 eine beliebige Anzahl von Attributen pro Meshlet beinhalten. Beispiele für Pro-Meshlet-Attribute sind, ohne Einschränkung, ein Begrenzungsrahmen, eine Adresse innerhalb eines Frame-Puffers und eine Eigenschaft eines Tessellierungspatchs.
  • 5 ist ein Ablaufdiagramm von Verfahrensschritten zur Verarbeitung von Bilddaten über eine Grafikverarbeitungspipeline, gemäß verschiedenen Ausführungsbeispielen der Erfindung. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-4 beschrieben werden, versteht sich für den Fachmann, dass jedes System, das zur Durchführung der Verfahrensschritte in beliebiger Reihenfolge konfiguriert ist, in den Schutzumfang der Erfindung fällt.
  • Wie gezeigt ist, beginnt ein Verfahren 500 bei Schritt 502, in dem der Gitter-Shader-Generator 330 die Gitter-Shader-Thread-Anzahl 312 und die Gitter-Shader-Anzahl 314 empfängt. Bei Schritt 504 ruft der Gitter-Shader-Generator 330 die Gitter-Shader 350 auf, wobei eine Gesamtzahl der Gitter-Shader 350 gleich der Gitter-Shader-Anzahl 314 ist. Um jeden der Gitter-Shader 350 aufzurufen, stellt der Gitter-Shader-Generator 330 einer anderen Gruppe von Threads eine andere Gitter-Shader-ID 340 bereit und konfiguriert die Gruppe von Threads dazu, das Gitter-Shading-Programm 192 kooperativ auszuführen. Die Gesamtzahl der Threads in jeder Thread-Gruppe ist gleich der Anzahl der Gitter-Shader-Threads 312. Die Gitter-Shader-IDs 340 sind aufeinanderfolgende ganze Zahlen im Bereich von 0 bis N-1 (einschließlich), wobei N die Anzahl der Gitter-Shader 314 ist. Bei Schritt 506 allokiert gemäß dem Gitter-Shading-Programm 192 jeder der Gitter-Shader 350 einen anderen gemeinsamen Meshlet-Puffer 352 in einem On-Chip-Speicher.
  • Bei Schritt 508 lesen und verarbeiten für jeden der Gitter-Shader 350 die Threads, die den Gitter-Shader 350 umfassen, kooperativ Grafikdaten, die einem Abschnitt des Eingangs-Gitters zugeordnet sind, basierend auf der Gitter-Shader-ID 340. Als Teil von Schritt 508 kann der Gitter-Shader 350 eine beliebige Anzahl und Art von Operationen ausführen, die für ein kooperatives Thread-Array (CTA) verfügbar sind. Beispiele für Operationen, die der Gitter-Shader 350 ausführen kann, sind unter anderem Lese-/Lade-Vorgänge, allgemeine Rechenoperationen, Vertex-Shading-Operationen, Geometrie-Shading-Operationen, Synchronisierungsoperationen und Schreib-/Speicher-Operationen. In alternativen Ausführungsbeispielen kann der Gitter-Shader 350 jede Art von Daten basierend auf der Gitter-Shader-ID 340 anstelle eines Teils eines Eingangs-Gitters lesen und verarbeiten.
  • Bei Schritt 510 beendet jeder der Gitter-Shader 350 das Schreiben des zugehörigen Meshlets 360 und terminiert. Insbesondere wird jedes der Meshlets 360 in einem On-Chip-Speicher gespeichert und bleibt auch nach Beendigung des zugehörigen Gitter-Shaders 350 erhalten. Demgegenüber wird dann, wenn ein bestimmter Gitter-Shader 350 terminiert, der zugehörige gemeinsame Meshlet-Puffer 352 freigegeben. Bei Schritt 512 lesen und verarbeiten nachfolgende Einheiten in der Grafikverarbeitungspipeline 320 die Meshlets 360, um ein gerendertes Bild zu erzeugen, das von dem Eingangs-Gitter abgeleitet ist.
  • Wie der Fachmann erkennen wird, kann jeder der Gitter-Shader 360 gleichzeitig, sequentiell oder in beliebiger Kombination derselben mit den anderen Gitter-Shadern 360 zur Ausführung kommen. Demzufolge kann zu jedem Zeitpunkt eine beliebige Anzahl der Gitter-Shader 360 unabhängig voneinander die Verfahrensschritte 506-510 im Wesentlichen parallel zu einer beliebigen Anzahl anderer Gitter-Shader 360 ausführen. Wie hierin erwähnt, kommen zwei oder mehr Gitter-Shader 192 „im Wesentlichen parallel“ zur Ausführung, wenn der Parallelprozessor 202 verschiedene Operationen basierend auf dem Gitter-Shader-Programm 192 und zwei oder mehr Gitter-Shader-Identifikatoren 340 durchführt und sich zumindest ein Teil der verschiedenen Operationen teilweise oder vollständig zeitlich überlagern. Wie in Verbindung mit 3B beschrieben wurde, definieren die Gitter-Shader-IDs 340 jedoch eine Verarbeitungsreihenfolge für die Meshlets 360, die von den nachfolgenden Einheiten in der Grafikverarbeitungspipeline 320 als Teil von Schritt 512 beibehalten wird.
  • Implementierung einer erweiterten Grafikverarbeitungspipeline
  • Um die Flexibilität der Grafikverarbeitungspipeline 320 weiter zu erhöhen, wird die Grafikverarbeitungspipeline 320 in einigen Ausführungsbeispielen um einen oder mehrere zusätzliche Shader-Generatoren und eine beliebige Anzahl von zusätzlichen Shadern erweitert, die dem Gitter-Shader-Generator 330 vorgehen. Jeder zusätzliche Shader umfasst eine Vielzahl von Threads, die kooperativ ein Shading-Programm ausführen, um eine entsprechende Shader-Ausgabe zu erzeugen. Die Shader-Ausgabe spezifiziert eine Anzahl von Shadern, die von einem nachfolgenden Shader-Generator aufzurufen sind, und eine beliebige Anzahl von zusätzlichen Daten in jedem Format. Der Gitter-Shader-Generator 330 und die Gitter-Shader 350 sind so modifiziert, dass sie basierend auf den Shader-Ausgaben arbeiten, die von den vorangehenden zusätzlichen Shadern empfangen werden.
  • 6 ist ein konzeptionelles Diagramm einer erweiterten Grafikverarbeitungspipeline 620, die innerhalb des Parallelprozessors 202 von 2 implementiert sein kann, gemäß verschiedenen anderen Ausführungsbeispielen der Erfindung. Wie gezeigt ist, beinhaltet die erweiterte Grafikverarbeitungspipeline 620, ohne Einschränkung, einen Task-Shader-Generator 630, eine beliebige Anzahl von Task-Shader-Identifikatoren (ID) 640, eine beliebige Anzahl von Task-Shadern 650, den Gitter-Shader-Generator 330, eine beliebige Anzahl von Task-Shader-Ausgaben 660, eine beliebige Anzahl von Gitter-Shader-Identifikatoren (ID) 340, eine beliebige Anzahl von Gitter-Shader-Eingängen 670, eine beliebige Anzahl von Gitter-Shadern 350, eine beliebige Anzahl von Meshlets 360, den Rasterisierer 370, die Pixel-Shader-Einheit 380 und die ROP 390.
  • Der Task-Shader-Generator 630 ist eine Verarbeitungseinheit mit fester Funktion, die von dem Benutzeranwendungsprogramm 190 eine Task-Shader-Thread-Anzahl 612 und eine Task-Shader-Anzahl 614 empfängt. Die Task-Shader-Thread-Anzahl 612 spezifiziert eine Anzahl von Threads, die in jedem Task-Shader 650 enthalten sein sollen. Die Task-Shader-Anzahl 614 spezifiziert eine Gesamtzahl von Task-Shadern 650, die der Task-Shader-Generator 630 aufrufen soll. Um jeden der Task-Shader 650 aufzurufen, stellt der Task-Shader-Generator 630 einer anderen Gruppe von Threads eine andere Task-Shader-ID 640 bereit und konfiguriert die Gruppe von Threads dazu, das Task-Shading-Programm 394 kooperativ auszuführen. Die Gesamtzahl der Threads in jeder Thread-Gruppe ist gleich der Task-Shader-Thread-Anzahl 612. Die Task-Shader-IDs 640 sind aufeinanderfolgende ganze Zahlen im Bereich von 0 bis N-1 (einschließlich), wobei N die Anzahl der Task-Shader 614 ist.
  • Ein Task-Shader-Programmiermodell definiert, wie die Threads, die den Task-Shader 650 umfassen, das Task-Shading-Programm 194 ausführen. Das Task-Shader-Programmiermodell spezifiziert, dass die Threads, die den Task-Shader 650 umfassen, eine einzelne Eingabe, die Task-Shader-ID 340, empfangen und kooperativ eine einzelne Ausgabe, die Task-Ausgabe 660, erzeugen, die in dem On-Chip-Speicher gespeichert wird. Insbesondere erlaubt das Task-Shader-Programmiermodell dem Task-Shading-Programm 194, jede Beziehung zwischen Eckpunkten und Threads sowie jede Beziehung zwischen Grafik-Stammfunktionen und Threads zu definieren.
  • Wie gezeigt ist, beinhaltet die Task-Shader-Ausgabe 660, ohne Einschränkung, eine Gitter-Shader-Anzahl 314 und generische Daten 662. Die Gitter-Shader-Anzahl 314 spezifiziert die Anzahl der Gitter-Shader 314. Die generischen Daten 662 spezifizieren Zusatzdaten in beliebigen Formaten. Der Task-Shader 650 kann die Anzahl der Gitter-Shader 314 und die generischen Daten 662 in jeder technisch machbaren Weise bestimmen.
  • Als Teil der LOD (Dynamic Level of Detail)-Instanziierung könnte der Task-Shader 650 beispielsweise Grafikdaten, die einem Teil eines Eingangs-Gitters zugeordnet sind, basierend auf einer Basisbildadresse und der Task-Shader-ID 640 lokalisieren. Der Task-Shader 650 könnte basierend auf den Bilddaten und einer Ansicht ein LOD bestimmen. Dann könnte der Task-Shader 650 die Anzahl der Gitter-Shader 314 basierend auf dem LOD berechnen. Der Task-Shader 650 könnte dann die generischen Daten 662 erzeugen, die, ohne Einschränkung, eine Adresse beinhalten, die einem vorberechneten Netz bzw. Gitter zugeordnet ist, das dem Abschnitt des Eingangs-Gitters und dem LOD entspricht.
  • Das Task-Shader-Programmiermodell ermöglicht es dem Task-Shading-Programm 194, einen gemeinsamen Task-Puffer 652 in dem On-Chip-Speicher zuzuweisen. Der Task-Shader 350(i) weist den gemeinsamen Task-Puffer 652(i) in dem On-Chip-Speicher zu, wenn der Task-Shader 650(i) aufgerufen wird. Während der Task-Shader 650 ausgeführt wird, erleichtert der gemeinsame Task-Puffer 652(i) die Kommunikation zwischen den Threads, die den Task-Shader 650(i) umfassen. Wenn der Task-Shader 650(i) beendet wird, wird der gemeinsame Task-Puffer 652(i) freigegeben.
  • Das Task-Shader-Programmiermodell definiert darüber hinaus die Operationen, für die das Task-Shading-Programm 194 den Gitter-Shader 650 konfigurieren kann. Im Allgemeinen kann der Task-Shader 650 alle Operationen ausführen, die für ein kooperatives Thread-Array (CTA) verfügbar sind. Beispiele für Operationen, die der Task-Shader 650 ausführen kann, sind unter anderem Lese-/Lade-Vorgänge, allgemeine Rechenoperationen, Vertex-Shading-Operationen, Tesselierungsoperationen, Geometrie-Shading-Operationen und Schreib-/Speicher-Operationen. Wichtig ist, dass der Task-Shader 650 auch beliebig viele Synchronisationsoperationen, wie z.B. Barrierevorgänge, zwischen den Threads, aus denen der Task-Shader 650 besteht, durchführen kann. Darüber hinaus können die Threads, die den Task-Shader 650 umfassen, eine Anweisung, wie beispielsweise eine übereinstimmende Anweisung, ausführen, die eine oder mehrere kooperative Operationen über die Threads hinweg durchführt, ohne auf gemeinsamen Speicher zuzugreifen.
  • Im Allgemeinen entsprechen die Task-Shader 650 und die Task-Shader-Ausgaben 660 einer beliebigen Anzahl von Einschränkungen, die mit der Grafikverarbeitungspipeline 320, dem PP 208 und dem On-Chip-Speicher verbunden sind. Beispielsweise ist in einigen Ausführungsbeispielen die Task-Shader-Thread-Anzahl 314 auf maximal 32 Threads beschränkt. In den gleichen oder anderen Ausführungsbeispielen ist für jeden der Task-Shader-Ausgaben 660 die kombinierte Größe der Task-Shader-Ausgabe 660 und des gemeinsamen Task-Puffers 652 auf maximal 16 KB begrenzt.
  • Der Gitter-Shader-Generator 330 empfängt die Gitter-Shader-Thread-Anzahl 312 von dem Benutzeranwendungsprogramm 190. Die Gitter-Shader-Thread-Anzahl 312 spezifiziert eine Anzahl von Threads, die in jedem der Gitter-Shader 350 enthalten sein sollen. Darüber hinaus empfängt der Gitter-Shader-Generator 330 für jeden Task-Shader 650(i) die Task-Ausgabe 660(i). Die Task-Shader-IDs 340 definieren eine Verarbeitungsreihenfolge für die Task-Shader-Ausgaben 660. Insbesondere die Reihenfolge, in der der Gitter-Shader-Generator 330 die Task-Shader-Ausgaben 660 verarbeitet, basiert auf den Task-Shader-IDs 640. So liefert beispielsweise die Grafikverarbeitungspipeline 320 in einigen Ausführungsbeispielen die Task-Shader-Ausgaben 660 an den Gitter-Shader-Generator 330, basierend auf einer aufsteigenden Reihenfolge der Task-Shader-IDs 640.
  • Für jeden der Task-Ausgaben 660 ruft der Gitter-Shader-Generator 330 einen oder mehrere Gitter-Shader 350 auf. Genauer gesagt, erzeugt der Gitter-Shader-Generator 330 für die Task-Ausgabe 660(i) die zugehörigen Gitter-Shader-IDs 340. Die zugehörigen Gitter-Shader-IDs 340 sind aufeinanderfolgende ganze Zahlen im Bereich von 0 bis einschließlich N-1, wobei N die Anzahl der Gitter-Shader 314 ist, die in der Task-Ausgabe 660(i) angegeben ist. Für jede der Gitter-Shader-IDs 340 erzeugt der Gitter-Shader-Generator 330 dann den Gitter-Shader-Eingang 670, der die Gitter-Shader-ID 340, die Gesamtzahl der Gitter-Shader 314 und die generischen Daten 662 enthält, die in der Task-Ausgabe 660(i) enthalten sind. In einigen Ausführungsbeispielen kann der Gitter-Shader-Generator 330 zum Erzeugen der Gitter-Shader-Eingänge 670 N Kopien der Task-Ausgabe 660(i) erzeugen und dann jede der Kopien ändern, um eine andere der Gitter-Shader-IDs 340 zu spezifizieren.
  • Die Gitter-Shader-ID 340(i) ermöglicht es dem Gitter-Shader 350(i), Daten zu lokalisieren, die für den Abschnitt des Eingangs-Gitters gelten, für den der Gitter-Shader 350(i) verantwortlich ist. So könnte beispielsweise das Gitter-Shading-Programm 192 den Gitter-Shader 350(i) dazu konfigurieren, die Gitter-Shader-ID 340(i) als einen Index auf die generischen Daten 662, die in der zugehörigen Gitter-Shader-Eingabe 670 enthalten sind, anzuwenden.
  • Der Task-Shader-Generator, die Task-Shader, der Gitter-Shader-Generator und die Gitter-Shader können den Stammfunktionen-Verteiler, die Vertex-Shader, die Hüllkurven-Shading-Einheit, den Tessellator, die Domänen-Shading-Einheit und die Geometrie-Shading-Einheit in herkömmlichen Grafikverarbeitungspipelines ersetzen. Vorteilhaft ist, dass die Flexibilität der erweiterten Grafikverarbeitungspipeline 660 die Erzeugung, Erweiterung und Auswahl der Geometrie in der Pipeline ermöglicht.
  • Wie der Fachmann erkennen wird, ist die Manipulation der Geometrie in der Pipeline nützlich für dynamische LOD-Instanzen, programmierbare Tesselierungsmuster, die sich an Verschiebungskarten anpassen, prozedurale Geometrie, Iso-Oberflächen-Extraktion, hierarchisches Aussortieren usw.. Bei dem hierarchischen Aussortieren wird in einem ersten Schritt die Bewertung eines Imposters (z.B. eines Begrenzungsrahmens oder eines Kegels der Normalen) und in einem zweiten Schritt eine feinere Auswertung von Grafik-Stammfunktionen durchgeführt.
  • Nachdem die Gitter-Shader 350, die basierend auf einer bestimmten Task-Shader-Ausgabe 660 aufgerufen wurden, die Ausführung beendet haben, kann die Task-Shader-Ausgabe 660 freigegeben werden. Die Meshlets 360 bleiben jedoch durch den Rest der Grafikverarbeitungspipeline 360 hindurch bestehen. Der Rasterisierer 370, die Pixel-Shading-Einheit 380 und die ROP 390 verarbeiten jedes der Meshlets 360 wie in Verbindung mit 3B beschrieben, um gerenderte Bilder zu erzeugen. Wichtig ist, dass die Reihenfolge, in der nachfolgende Einheiten in der Grafikverarbeitungspipeline 320 die Meshlets 360 verarbeiten, auf den Task-Shader-IDs 640 und den Gitter-Shader-IDs 340 basiert. So liefert die Grafikverarbeitungspipeline 320 in einigen Ausführungsbeispielen die Meshlets 360 basierend auf einer aufsteigenden Reihenfolge der Task-Shader-IDs 640 an den Rasterisierer 370, und für jede der Task-Shader-IDs 640 basierend auf einer aufsteigenden Reihenfolge der Gitter-Shader-IDs 340.
  • Die erweiterte Grafikverarbeitungspipeline 320 kann durch ein oder mehrere Verarbeitungselemente innerhalb des PPs 202 implementiert sein. Beispielsweise könnte einer der SMen 310 von 3A dazu konfiguriert sein, die Funktionen der Pixel-Shading-Einheit 390 auszuführen. Die Funktionen des Gitter-Shader-Generators 320, des Task-Shader-Generators 620, des Rasterisierers 370 und der ROP 390 können auch durch Verarbeitungselemente innerhalb eines bestimmten GPCs 208 in Verbindung mit einer entsprechenden Partitionseinheit 215 ausgeführt werden. Alternativ kann die Grafikverarbeitungspipeline 320 mit speziellen Verarbeitungselementen mit fester Funktion für eine oder mehrere der vorstehend aufgeführten Funktionen implementiert sein. In verschiedenen Ausführungsbeispielen kann der PP 202 dazu konfiguriert sein, eine oder mehrere Grafikverarbeitungspipelines 320 zu realisieren.
  • Es versteht sich, dass die hierin dargestellte erweiterte Grafikverarbeitungspipeline 620 veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Beispielsweise können in verschiedenen Ausführungsbeispielen beliebig viele der Einheiten in der erweiterten Grafikverarbeitungspipeline 620 implementiert sein, während andere Einheiten weggelassen oder in technisch machbarer Weise ersetzt sein können. Unter anderem kann jede von einer Ansichtsbereichsskala, Cull- und Clip-Einheit (VPC), einer Tiling-Einheit und einer Setup-Einheit in der erweiterten Grafikverarbeitungspipeline 620 enthalten sein.
  • Es wird angemerkt, dass die hierin beschriebenen Techniken eher illustrativ als einschränkend sind und geändert werden können, ohne den breiteren Rahmen und den Schutzumfang der Erfindung zu verlassen. Viele Modifikationen und Variationen der Funktionalität, die durch den Task-Shader-Generator 630, die Task-Shader 650, den Gitter-Shader-Generator 330, die Gitter-Shader 350, das Gitter-Shader-Programmiermodell und das Task-Shader-Programmiermodell bereitgestellt werden, sind für den Fachmann offensichtlich, ohne den Rahmen und den Schutzumfang der beschriebenen Ausführungsbeispielen zu verlassen. Beispielsweise können in verschiedenen Ausführungsbeispielen beliebig viele der Techniken und/oder Einschränkungen implementiert sein, während andere Techniken und/oder Einschränkungen weggelassen oder in technisch machbarer Weise ersetzt sein können.
  • In verschiedenen Ausführungsbeispielen können die Task-Shader 650 und der Gitter-Shader 350 aufgerufen und in jeder technisch machbaren Weise programmiert werden. In einigen Ausführungsbeispielen kann das Benutzeranwendungsprogramm 190 eine maximale Anzahl von In-Flight Gitter-Shader-Eingängen 670 spezifizieren, und kann die Funktionalität des Gitter-Shader-Generators 330 entsprechend angepasst sein.
  • 7 ist eine detailliertere Darstellung der Wechselwirkungen zwischen dem Gitter-Shader-Eingang 670 und dem Gitter-Shader 650 von 6 bei der Unterstützung eines Anwendungsdatenpuffers 760 gemäß verschiedenen Ausführungsbeispielen der Erfindung Der Anwendungsdatenpuffer 760 ermöglicht den Transfer relativ großer Datenmengen (z.B. über 16 KB) zwischen einem der Task-Shader 650 und den zugehörigen Gitter-Shadern 350.
  • Im Betrieb allokiert das Benutzeranwendungsprogramm 190 dynamisch einen Teil eines anwendungsverwalteten Speichers 720, um den Anwendungsdatenpuffer 760 zu speichern. Wie gezeigt ist, beinhaltet der Anwendungsdatenpuffer 760 eine Referenzanzahl 762. In alternativen Ausführungsbeispielen kann die Referenzanzahl 762 in einem beliebigen Speicher gespeichert werden, der für das Benutzeranwendungsprogramm 190 zugänglich ist. Wenn der Task-Shader 650 die Task-Shader-Ausgabe 660 erzeugt, spezifiziert der Task-Shader 660 in den generischen Daten 662 eine Pufferadresse 712. Die Pufferadresse 712 spezifiziert die Adresse des Anwendungsdatenpuffers 760 und kann somit zum Lokalisieren des Anwendungsdatenpuffers 760 verwendet werden. Der Task-Shader 650 initialisiert auch die Referenzanzahl 762 auf die Gitter-Shader-Anzahl 314.
  • Wie in Verbindung mit 6 beschrieben wurde, kopiert als Teil der Erzeugung des Gitter-Shader-Eingangs 670 der Gitter-Shader-Generator 330 die generischen Daten 662 von der Task-Shader-Ausgabe 660 auf den Gitter-Shader-Eingang 670. Somit kann der Gitter-Shader 350 über die Pufferadresse 712 auf den Anwendungsdatenpuffer 760 zugreifen. Nachdem der Gitter-Shader 350 die Daten aus dem Anwendungsdatenpuffer 760 gelesen hat, verringert der Gitter-Shader 350 die Referenzanzahl 762 in einer atomaren Weise (z.B. unter Verwendung einer atomaren Anweisung). Nachdem alle von dem Task-Shader 650 aufgerufenen Gitter-Shader 350 ihre Ausführung beendet haben, ist die Referenzanzahl 762 gleich Null. Nachdem erfasst wurde, dass die Referenzanzahl 762 gleich Null ist, gibt das Benutzeranwendungsprogramm 190 den Anwendungsdatenpuffer 760 frei.
  • 8A-8B zeigen ein Ablaufdiagramm von Verfahrensschritten zur Verarbeitung von Bilddaten über eine erweiterte Grafikverarbeitungspipeline, gemäß verschiedenen Ausführungsbeispielen der Erfindung. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-3A, 6 und 7 beschrieben werden, versteht sich für den Fachmann, dass jedes System, das zur Durchführung der Verfahrensschritte in beliebiger Reihenfolge konfiguriert ist, in den Schutzumfang der Erfindung fällt.
  • Wie gezeigt ist, beginnt ein Verfahren 800 bei Schritt 802, in dem der Task-Shader-Generator 630 die Task-Shader-Thread-Anzahl 612 und die Task-Shader-Anzahl 614 empfängt. Bei Schritt 804 erzeugt der Task-Shader-Generator 630 die Task-Shader-IDs 640. Die Task-Shader-IDs 640 sind aufeinanderfolgende ganze Zahlen im Bereich von 0 bis N-1 (einschließlich), wobei N die Anzahl der Task-Shader 614 ist. Der Task-Shader-Generator 630 wählt dann die erste Task-Shader-ID 640 aus.
  • Bei Schritt 806 ruft der Task-Shader-Generator 630 den Task-Shader 650 auf, der der ausgewählten Task-Shader-ID 640 zugeordnet ist. Genauer gesagt stellt der Task-Shader-Generator 630 die ausgewählte Task-Shader-ID 640 einer Gruppe von Threads bereit und konfiguriert die Gruppe von Threads dazu, das Task-Shading-Programm 194 kooperativ auszuführen. Die Gesamtzahl der Threads in der Gruppe der Threads entspricht der Task-Shader-Thread-Anzahl 612. Gemäß dem Task-Shading-Programm 194 allokiert der Task-Shader 650 bei Aufruf des Task-Shaders 650 einen zugehörigen gemeinsamen Task-Puffer 652 in dem On-Chip-Speicher.
  • Bei Schritt 810 erzeugt der Task-Shader 650 gemäß dem Thread-Shading-Programm 194 die Task-Shader-Ausgabe 660. Die Task-Shader-Ausgabe 660 spezifiziert die Anzahl der Gitter-Shader 314 und wird in dem On-Chip-Speicher gespeichert. Nach Erzeugen der Task-Shader-Ausgabe 660 beendet sich der Task-Shader 650 und wird der zugehörige gemeinsame Task-Puffer 652 freigegeben. Bei Schritt 812 empfängt der Gitter-Shader-Generator 330 die Task-Shader-Ausgabe 660 von dem Task-Shader 650 und die Gitter-Shader-Thread-Anzahl 312 von dem Benutzeranwendungsprogramm 190.
  • Bei Schritt 814 erzeugt der Gitter-Shader-Generator 330 die Gitter-Shader-Eingänge 670 basierend auf der Task-Shader-Ausgabe 660. Die Gesamtzahl der Gitter-Shader-Eingänge 670 ist gleich der Anzahl der Gitter-Shader 314. Jeder der Gitter-Shader-Eingänge 670 beinhaltet zusätzlich zu einer anderen Gitter-Shader-ID 340 die in der Task-Shader-Ausgabe 660 angegebenen Daten. Die Gitter-Shader-IDs 340 sind aufeinanderfolgende ganze Zahlen im Bereich von 0 bis M-1 (einschließlich), wobei M die Anzahl der Gitter-Shader 314 ist.
  • Bei Schritt 816 ruft der Gitter-Shader-Generator 330 die Gitter-Shader 350 auf, wobei eine Gesamtzahl der Gitter-Shader 350 gleich der Gitter-Shader-Anzahl 314 ist. Um jeden der Gitter-Shader 350 aufzurufen, stellt der Gitter-Shader-Generator 330 einen anderen der Gitter-Shader-Eingänge 670 für eine andere Gruppe von Threads bereit und konfiguriert die Gruppe von Threads dazu, das Gitter-Shading-Programm 192 kooperativ auszuführen. Die Gesamtzahl der Threads in jeder Thread-Gruppe ist gleich der Anzahl der Gitter-Shader-Threads 312. Gemäß dem Gitter-Shading-Programm 192 weist der Gitter-Shader 350(i) den gemeinsamen Meshlet-Speicher 352(i) in dem On-Chip-Speicher zu, wenn der Gitter-Shader 350(i) aufgerufen wird.
  • Bei Schritt 818 lesen und verarbeiten die Threads, die den Gitter-Shader 350 umfassen, für jeden der Gitter-Shader 350 kooperativ die Gitter-Shader-Eingabe 670 basierend auf der Gitter-Shader-ID 340. Bei Schritt 820 beendet jeder der Gitter-Shader 350 das Schreiben des zugehörigen Meshlets 360 und beendet es. Insbesondere wird jedes der Meshlets 360 in einem On-Chip-Speicher gespeichert und bleibt auch nach Beendigung des zugehörigen Gitter-Shaders 350 erhalten. Demgegenüber wird bei Terminierung eines bestimmten Gitter-Shaders 350 der zugehörige gemeinsame Meshlet-Puffer 352 freigegeben.
  • Bei Schritt 822 ermittelt der Task-Shader-Generator 630, ob die ausgewählte Task-ID 640 die letzte Task-ID 640 ist. Wenn bei Schritt 822 der Task-Shader-Generator 630 ermittelt, dass die ausgewählte Task-ID 640 nicht die letzte Task-ID 640 ist, schreitet das Verfahren 800 zu Schritt 824 fort. Bei Schritt 824 wählt der Task-Shader-Generator 630 die nächste Task-ID 640 aus, und kehrt das Verfahren 800 zu Schritt 806 zurück, in dem der Task-Shader-Generator 630 einen anderen Task-Shader 650 aufruft.
  • Wenn jedoch bei Schritt 822 der Task-Shader-Generator 630 ermittelt, dass die ausgewählte Task-ID 640 die letzte Task-ID 640 ist, dann schreitet das Verfahren 800 direkt zu Schritt 826 fort. Bei Schritt 826 lesen und verarbeiten nachfolgende Einheiten in der Grafikverarbeitungspipeline 320 die Meshlets 360, um ein gerendertes Bild zu erzeugen, das von dem Eingangs-Gitter abgeleitet ist.
  • Wie der Fachmann erkennen wird, kann jeder der Task-Shader 660 gleichzeitig, sequentiell oder in beliebiger Kombination mit den anderen Task-Shadern 660 ausgeführt werden. Folglich kann zu jedem Zeitpunkt eine beliebige Anzahl von Task-Shadern 660 unabhängig voneinander die Verfahrensschritte 808-810 im Wesentlichen parallel zu einer beliebigen Anzahl von anderen Task-Shadern 660 ausführen. Wie hierin erwähnt wurde, kommen zwei oder mehr Task-Shader 660 „im Wesentlichen parallel“ zur Ausführung, wenn der Parallelprozessor 202 verschiedene Operationen basierend auf dem Task-Shader-Programm 194 und zwei oder mehr Task-Shader-Identifikatoren 640 durchführt, und sich zumindest ein Teil der verschiedenen Operationen teilweise oder vollständig zeitlich überlagern.
  • Wie in Verbindung mit 6 beschrieben wurde, definieren die Task-Shader-IDs 640 jedoch eine Verarbeitungsreihenfolge für die Task-Shader-Ausgaben 660, die von den nachfolgenden Einheiten in der Grafikverarbeitungspipeline 320 beibehalten wird. Ferner können die nachfolgenden Einheiten in der Grafikverarbeitungspipeline die Meshlets 360 verarbeiten, bevor, während oder nachdem andere Meshlets 360 erzeugt wurden, und werden die Verfahrensschritte 822-826 entsprechend modifiziert.
  • Deduplizieren eines Index-Puffers
  • 9A-9B veranschaulichen, wie die Deduplizierungsanwendung 182 von 1 einen Shaderstapel 990 generiert, gemäß verschiedenen Ausführungsbeispielen der Erfindung. In einer herkömmlichen Grafikverarbeitungspipeline erzeugt der Stammfunktionen-Verteiler Arbeitsstapel basierend auf einem Index-Puffer 940, der die Eckpunkte angibt, aus denen sich mehrere Grafik-Stammfunktionen zusammensetzen. Jeder Arbeitsstapel repräsentiert einen anderen Teil des Index-Puffers 940 und wird von nachfolgenden programmierbaren Einheiten, die in der konventionellen Grafikverarbeitungspipeline enthalten sind, verarbeitet.
  • Um den Speicherbedarf, der erforderlich ist, um den Index-Puffer 940 zu speichern, zu reduzieren, führt der Stammfunktionen-Verteiler häufig On-The-Fly-Deduplizierungsoperationen durch, wenn er die Arbeitsstapel bildet. Anstatt mehrere Kopien desselben Eckpunktidentifikators zu speichern, erzeugt der Stammfunktionen-Verteiler einen Eckpunkt-Puffer 992, der eindeutige Eckpunktidentifikatoren enthält, und einen indirekten Index-Puffer 994, der Einträge in dem Eckpunkt-Puffer 992 referenziert. Wenn beispielsweise der Index-Puffer 940 die Eckpunktidentifikatoren 576, 324, 129, 129, 129, 324, 23 enthielte, dann würde der Eckpunkt-Puffer 992 die Eckpunktidentifikatoren 576, 324, 129, 23 und der indirekte Index-Puffer 994 die indirekten Indizes 0, 1, 2, 2, 2, 1, 3 enthalten.
  • In einigen Ausführungsbeispielen der Grafikverarbeitungspipeline 320 kann das Gitter-Shading-Programm 192 einen Shaderstapel 990 von Arbeit für jeden Gitter-Shader 350 basierend auf den Gitter-Shader-IDs 340 definieren. Ebenso kann das Task-Shading-Programm 194 in einigen Ausführungsbeispielen der erweiterten Grafikverarbeitungspipeline 620 den Shaderstapel 990 von Arbeit für jeden Task-Shader 650 basierend auf den Task-Shader-IDs 640 definieren. Jeder der Shaderstapel 990 ist einem anderen Abschnitt des Index-Puffers 940 zugeordnet.
  • Um den Speicherbedarf, der erforderlich ist, um die Shaderstapel 990 zu speichern, zu reduzieren, beinhaltet das Computersystem 100 die Deduplizierungsanwendung 182. Im Allgemeinen führt die Deduplizierungsanwendung 182 Deduplizierungsoperationen auf dem Index-Puffer 940 durch, um optimierte Shaderstapel 990 zu erzeugen. Insbesondere führt die Deduplizierungsanwendung 182 die Deduplizierungsvorgänge auf der Grundlage einer MATCH.ANY-Anweisung 920 durch, die auf dem PP 202 zur Ausführung kommt. In alternativen Ausführungsbeispielen kann die Deduplizierungsanwendung 182 Deduplizierungsoperationen basierend auf einer beliebigen Anweisung oder einem beliebigen Übereinstimmungs-Algorithmus in jeder technisch machbaren Weise durchführen.
  • Im Allgemeinen führt die MATCH.ANY-Anweisung 920 Vergleichsoperationen über die Werte durch, die jedem der Threads 910, die in einer Thread-Gruppe enthalten sind, zugeordnet sind (d.h. in diese geladen sind). Für jeden Thread 910, der über ein Eingangsprädikat 912 spezifiziert ist, führt die MATCH.ANY-Anweisung 920 umfassende Vergleichsoperationen mit den anderen Threads 910 durch und erzeugt eine Übereinstimmungsmaske 930. Für jeden vorgegebenen Thread 910(x) wird dann, wenn der in der Übereinstimmungsmaske 930(x) enthaltene führende eine an dem Bit x liegt, der dem Thread 910(x) zugeordnete Wert von keinem Thread 910(y) spezifiziert, wobei y kleiner als x ist. Demzufolge wird ein Satz eindeutiger Werte durch den Satz von Threads 910(x) mit führenden einen in der Übereinstimmungsmaske 930(x) an dem Bit x spezifiziert. Für die nicht vorgegebenen Threads 910 führt die MATCH.ANY-Anweisung 920 keine erschöpfenden Vergleichsoperationen durch und erzeugt keine Übereinstimmungsmasken 930. Für jeden nicht vorgegebenen Thread 910(x) führt die MATCH.ANY-Anweisung 920 jedoch umfassende Vergleichsoperationen zwischen dem nicht vorgegebenen Thread 910(x) und den vorgegebenen Threads 910 durch. In alternativen Ausführungsbeispielen unterstützt die MATCH.ANY-Anweisung 920 das Eingangsprädikat 912 nicht und führt die MATCH.ANY-Anweisung 920 umfassende Vergleiche zwischen den einzelnen Ausführungsbeispielen durch und erzeugt die Übereinstimmungsmasken 930 für alle in der Thread-Gruppe enthaltenen Threads 910.
  • Die Größe der Thread-Gruppe, auf der die MATCH.ANY-Anweisung 920 arbeitet, variiert mit der Implementierung des PPs 202. Zum Beispiel kann die MATCH.ANY-Anweisung 920 in einigen Ausführungsbeispielen auf einer Thread-Gruppe mit 32 Threads 910 arbeiten. In alternativen Ausführungsbeispielen kann die Anzahl der Threads 910, auf welchen die MATCH.ANY-Anweisung 930 arbeitet, je nach Hardwarefähigkeiten, Softwarefähigkeiten, Benutzerpräferenzen und dergleichen variieren.
  • Nur zur Erläuterung zeigt 9A eine beispielhafte Ausführung der MATCH.ANY-Anweisung 920 auf einer Thread-Gruppe, die die Threads 910(7)-910(0) beinhaltet. Die Threads 910(7)-910(0) spezifizieren jeweils die Werte 137, 423, 137, 53, 423, 9, 97 und 53. Das Eingangsprädikat 912 spezifiziert die Threads 910(5)-910(0). Nur zur Erläuterung sind die nicht präparierten Threads 910 als gefüllte Kästen dargestellt. Basierend auf den resultierenden Übereinstimmungsmasken 930 sind die eindeutigen Werte, die in den vorgegebenen Threads 910 enthalten sind, 53, 9 und 97.
  • Nur zur Erläuterung zeigt 9B eine Sequenz von Ereignissen, die bei der Übersetzung des Index-Puffers 940 in die Shaderstapel 990 involviert sind, als eine Reihe von nummerierten Blasen. Die in 9B dargestellte MATCH.ANY-Anweisung 920 arbeitet auf einer Thread-Gruppe, die 4 Threads 910 beinhaltet und das Eingangsprädikat 912 unterstützt. Die Shaderstapel 990 unterliegen den Stapelbeschränkungen dahingehend, dass jede Shaderstapel 990 maximal 4 Eckpunkte und maximal 4 Grafik-Stammfunktionen beinhaltet. Der dem Eingangspuffer 940 zugeordnete Stammfunktionen-Typ ist ein Dreieck 942, wobei jedes Dreieck 942 in dem Index-Puffer 940 als drei Eckpunkte dargestellt ist.
  • In einigen Ausführungsbeispielen kann die MATCH.ANY-Anweisung 920 über eine Thread-Gruppe arbeiten, die eine andere Anzahl von Threads als 4 enthält. In dem gleichen oder in anderen Ausführungsbeispielen unterstützt die MATCH.ANY-Anweisung 920 möglicherweise nicht das Eingangsprädikat 912. In einigen alternativen Ausführungsbeispielen führt die Deduplizierungsanwendung 182 Deduplizierungsoperationen basierend auf einer anderen Anweisung als der MATCH.ANY-Anweisung 920 durch. In verschiedenen Ausführungsbeispielen kann die Anzahl und die Art der mit den Shaderstapeln 990 verbundenen Einschränkungen je nach Hardwarefähigkeiten, Softwarefähigkeiten, Benutzerpräferenzen und dergleichen variieren.
  • Bei Empfangen des Index-Puffers 940 identifiziert die Deduplizierungsanwendung 182, dass die Threads 910(3)-910(0) eine Thread-Gruppe umfassen, und erzeugt den leeren Eckpunkt-Puffer 992 und den leeren indirekten Index-Puffer 994. Wie mit der mit 1 nummerierten Blase dargestellt ist, führt die Deduplizierungsanwendung 182 Ladevorgänge 945(1) aus, die Eckpunkte aus dem Index-Puffer 940 in die Threads 910(3)-910(0) laden. Genauer gesagt lädt die Deduplizierungsanwendung 182 die vier linken Eckpunkte 123, 457, 789 und 123, die in dem Index-Puffer 940 angegeben sind, in die Threads 910(3), 910(2), 910(1) und 910(0).
  • Wie mit der mit 2 nummerierten Blase 2 dargestellt ist, führt die Deduplizierungsanwendung 182 dann die Übereinstimmungsoperationen 950(1) über die Threads 910(3)-910(0) basierend auf der MATCH.ANY-Anweisung 920 aus, wobei alle Threads 910(3)-910(0) in dem Eingangsprädikat 912 spezifiziert sind. Nach Ausführung der Übereinstimmungsoperationen 950(1) spezifizieren die Werte der Threads 910(3)-910(0) indirekte Indizes, die den vier linksten Eckpunkten zugeordnet sind, die in dem Index-Puffer 940 enthalten sind. Genauer gesagt wendet, um zu veranlassen, dass die Threads 910(3)-910(0) die indirekten Indizes spezifizieren, die Deduplizierungsanwendung 182 die MATCH.ANY-Anweisung 920 an und findet dann die führenden einen in der resultierenden Maske. Wie gezeigt ist, sind die Werte der Threads 910(3)-910(0) 0, 1, 2, 0, welches anzeigt, dass die vier linkste Eckpunkte, die in dem Index-Puffer 940 enthalten sind, drei eindeutige Eckpunkte beinhalten.
  • Anschließend führt die Deduplizierungsanwendung 182, wie mit der mit 3 nummerierten Blase dargestellt ist, Abbildungs- bzw. Abbildungsoperationen 960(1) durch, die den Eckpunkt-Puffer 992 und den indirekten Index-Puffer 994 aktualisieren. Um den Eckpunkt-Puffer 994 zu aktualisieren, hängt die Deduplizierungsanwendung 182 die drei neu identifizierten eindeutigen Eckpunkte an den Eckpunkt-Puffer 992 an. Um den indirekten Index-Puffer 994 zu aktualisieren, hängt die Deduplizierungsanwendung 182 die neu identifizierten indirekten Indizes an den indirekten Index-Puffer 994 an.
  • Wie mit der mit 4 nummerierten Blase dargestellt ist, führt die Deduplizierungsanwendung 182 dann Verdichtungsoperationen 970(1) durch, die die indirekten Indizes für die eindeutigen Eckpunkte in den Threads 910 konsolidieren, die den Bits höchster Ordnung in der Übereinstimmungsmaske 930 entsprechen. Als Teil der Verdichtungsoperationen 970(1) wählt die Deduplizierungsanwendung 182 die Threads 910 aus, die nicht mit eindeutigen Eckpunkten verknüpft sind, und setzt das Eingangsprädikat 912, um die ausgewählten Threads 910 zu spezifizieren. Zu Zwecken der Erklärung sind die nicht ausgewählten Threads 910 als gefüllte Kästen dargestellt.
  • Obwohl nicht dargestellt, ermittelt die Deduplizierungsanwendung 182 dann auf der Grundlage der Stapelbeschränkungen, dass der Shaderstapel 990 noch nicht gefüllt ist. Insbesondere ermittelt die Deduplizierungsanwendung 182, dass die Anzahl von in dem Eckpunkt-Puffer 992 spezifizierten eindeutigen Eckpunkten kleiner als 4 ist und die Anzahl der in dem indirekten Index-Puffer 994 angegebenen Grafik-Stammfunktionen kleiner als 4 ist.
  • Demgemäß wiederholt die Deduplizierungsanwendung 182 iterativ die Ladeoperationen 945, die Übereinstimmungsoperationen 950, die Abbildungsoperationen 960 und die Verdichtungsoperationen 970. Wie mit der mit 5 nummerierten Blase dargestellt ist, führt die Deduplizierungsanwendung 182 die Ladevorgänge 945(2) aus. Für die nicht ausgewählten Threads 910(3)-910(1) lädt die Deduplizierungsanwendung 182 die in dem Eckpunkt-Puffer 992 angegebenen Eckpunkte. Demgegenüber lädt die Deduplizierungsanwendung 182 für den ausgewählten Thread 910(0) den ersten unverarbeiteten Eckpunkt (789), der in dem Index-Puffer 940 spezifiziert ist.
  • Wie mit der mit 6 nummerierten Blase dargestellt ist, führt die Deduplizierungsanwendung 182 dann die Übereinstimmungsoperationen 950(2) über die Threads 910(3)-910(0) basierend auf der MATCH.ANY-Anweisung 920 mit dem Thread 910(0), der über das Eingangsprädikat 912 vorgegeben ist, aus. Wie in einem fettgedruckten Kasten dargestellt, ist das Ergebnis der Übereinstimmungsvorgänge 950(2) der indirekte Index 2, welches anzeigt, dass der Eckpunkt 789 ein Duplikat eines zuvor identifizierten eindeutigen Eckpunkts ist.
  • Anschließend führt die Deduplizierungsanwendung 182, wie mit der mit 7 nummerierten Blase dargestellt ist, die Abbildungsoperationen 960(2) aus, die den neu identifizierten indirekten Index 2 an den indirekten Index-Puffer 994 anhängen. Im Allgemeinen hängt die Deduplizierungsanwendung 182 als Teil der Abbildungsoperationen 960 auch alle neu identifizierten eindeutigen Eckpunkte an den Eckpunkt-Puffer 992 an. Da es jedoch keine neu identifizierten eindeutigen Eckpunkte gibt, modifiziert die Deduplizierungsanwendung 182 den Eckpunkt-Puffer 992 nicht.
  • Wie mit der mit 8 nummerierten Blase dargestellt ist, führt die Deduplizierungsanwendung 182 dann die Verdichtungsoperationen 970(2) durch, die die eindeutigen Indizes in den Threads 910 konsolidieren, die den Bits höchster Ordnung in der Übereinstimmungsmaske 930 entsprechen. Als Teil der Verdichtungsoperationen 970(2) wählt die Deduplizierungsanwendung 182 die Threads 910 aus, die nicht mit eindeutigen Eckpunkten verknüpft sind, und setzt das Eingangsprädikat 912, um die ausgewählten Threads 910 zu spezifizieren.
  • Obwohl nicht dargestellt, ermittelt die Deduplizierungsanwendung 182 dann aufgrund der Stapelbeschränkungen, dass der Shaderstapel 990 noch nicht voll ist. Insbesondere ermittelt die Deduplizierungsanwendung 182, dass die Anzahl der in dem Eckpunkt-Puffer 992 angegebenen eindeutigen Eckpunkte kleiner als 4 ist und die Anzahl der in dem indirekten Index-Puffer 994 angegebenen Grafik-Stammfunktionen kleiner als 4 ist.
  • Demgemäß wiederholt, wie mit den mit 9, 10, 11 und 12 nummerierten Blasen dargestellt ist, die Deduplizierungsanwendung 182 iterativ das Laden 945, das Vergleichen 950, die Abbildungsoperationen 960 und die Verdichtungsoperationen 970. Da die Anzahl der in dem Eckpunkt-Puffer 992 spezifizierten eindeutigen Eckpunkte größer als 4 ist, ermittelt die Deduplizierungsanwendung 182, dass der Shaderstapel 990 voll ist.
  • Wie durch die mit 13 nummerierte Blase 13 dargestellt ist, führt die Deduplizierungsanwendung 182 dann die Stapeloperationen 980(1) durch, die den Shaderstapel 990 erzeugen. Der Shaderstapel 990 beinhaltet, ohne Einschränkung, den Eckpunkt-Puffer 992 und den indirekten Index-Puffer 994. Die Deduplizierungsanwendung 182 wiederholt dann den iterativen Prozess, der die Ladevorgänge 945(3), die Übereinstimmungsoperationen 950(3), die Abbildungsvorgänge 960(3) und die Verdichtungsvorgänge 970(3) beinhaltet, um neue Shaderstapel 990 zu erzeugen, bis die Deduplizierungsanwendung 182 die Verarbeitung des Index-Puffers 940 abgeschlossen hat.
  • Es wird angemerkt, dass die hierin beschriebenen Techniken eher illustrativ als beschränkend sind und geändert werden können, ohne den breiteren Rahmen und den Schutzumfang der Erfindung zu verlassen. Viele Modifikationen und Variationen der Funktionalität der Deduplizierungsanwendung 182 und der MATCH.ANY-Anweisung 920 sind für den Fachmann offensichtlich, ohne den Schutzbereich und den Rahmen der beschriebenen Ausführungsbeispiele zu verlassen. Beispielsweise kann die Deduplizierungsanwendung 182 in einigen alternativen Ausführungsbeispielen Shaderstapel erzeugen, die einen Versatz bzw. Offset in dem indirekten Index-Puffer 994 anstelle des indirekten Index-Puffers 994 und des Eckpunkt-Puffers 990 beinhalten. Der Offset spezifiziert den Anfang des Abschnitts des Index-Puffers 940, der dem Shaderstapel 990 zugeordnet ist. In solchen Ausführungsbeispielen können der indirekte Index-Puffer 994 und der Eckpunkt-Puffer 992 von beliebig vielen Shaderstapeln 990 gemeinsam genutzt werden.
  • In alternativen Ausführungsbeispielen implementiert die Deduplizierungsanwendung 182 einen nicht-iterativen Algorithmus, um der Shaderstapel 990 basierend auf einer beliebigen Anzahl von nicht vorgegebenen MATCH.ANY-Anweisungen 920 zu erzeugen. Im Betrieb wählt die Deduplizierungsanwendung 182 ein Vielfaches M der Thread-Gruppengröße T aus und lädt die Werte von (M*T)-Eckpunkten aus dem Index-Puffer in (M*T)-Threads 910. Die Deduplizierungsanwendung 182 führt dann M MATCH.ANY-Anweisungen 920 aus, wobei jede MATCH.ANY-Anweisung 920 auf einer anderen Thread-Gruppe arbeitet. Anschließend identifiziert die Deduplizierungsanwendung 182 für jede MATCH.ANY-Anweisung 920 einen Satz eindeutiger Eckpunkte basierend auf den resultierenden Übereinstimmungsmasken 930.
  • Nachdem die Deduplizierungsanwendung 182 die M-Sätze eindeutiger Eckpunkte identifiziert hat, vergleicht sie die Gesamtzahl der Eckpunkte, die in den M Sätzen eindeutiger Eckpunkte spezifiziert sind, mit der Anzahl der zugehörigen Grafik-Stammfunktionen, um zu bestimmen, ob die Stapelbeschränkungen erfüllt sind. Wenn die Stapelbeschränkungen erfüllt sind, erzeugt die Deduplizierungsanwendung 182 einen einzelnen Shaderstapel 990, der auf den M-Sätzen von eindeutigen Eckpunkten basiert. Wenn jedoch die Stapelbeschränkungen nicht erfüllt sind, dann partitioniert die Deduplizierungsanwendung 182 die M Sätze von eindeutigen Eckpunkten, um mehrere Shaderstapel 990 zu erzeugen, wobei jeder Shaderstapel 990 die Stapelbeschränkungen erfüllt. Die Deduplizierungsanwendung 182 schreitet auf diese Weise fort, bis die Deduplizierungsanwendung 182 alle in dem Index-Puffer 940 angegebenen Eckpunkte verarbeitet hat.
  • Vorteilhaft können, nachdem die Deduplizierungsanwendung 182 die Shaderstapel 990 erzeugt hat, die Shaderstapel 990 dazu verwendet werden, Einzelbilder, die aus einem Eingangs-Gitter abgeleitet wurden, zu rendern, bis sich die Topologie des Eingangs-Gitters ändert. In verschiedenen Ausführungsbeispielen ermittelt das Benutzeranwendungsprogramm 190 vor dem Rendern jedes Einzelbilds, ob sich die Topologie des Eingangs-Gitters geändert hat. Wenn sich die Topologie des Eingangs-Gitters nicht geändert hat, verwendet das Anwendungsprogramm 190 den Shaderstapel 990 wieder. Hat sich jedoch die Topologie des Eingangs-Gitters geändert, führt das Anwendungsprogramm 190 die Deduplizierungsanwendung 192 erneut aus, um neue Shaderstapel 990 zu erzeugen. Demgegenüber führt der Stammfunktionen-Verteiler im Rahmen des Renderns jedes Einzelbilds Deduplizierungsoperationen erneut durch und generiert Arbeitsstapel neu, unabhängig davon, ob sich die Topologie des Eingangs-Gitters ändert.
  • 10A-10B zeigen ein Ablaufdiagramm der Verfahrensschritte zur Vorverarbeitung von Index-Puffern zur Verwendung in einer Grafikverarbeitungspipeline, gemäß verschiedenen Ausführungsbeispielen der Erfindung. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-3B und 9 beschrieben werden, versteht sich für den Fachmann, dass jedes System, das zur Durchführung der Verfahrensschritte in beliebiger Reihenfolge konfiguriert ist, in den Anwendungsbereich der Erfindung fällt.
  • Wie gezeigt ist, beginnt ein Verfahren 1000 bei Schritt 1002, in dem die Deduplizierungsanwendung 182 den Index-Puffer 940 empfängt, einen leeren Eckpunkt-Puffer 992 und einen leeren indirekten Index-Puffer 994 erzeugt und die in einer oder mehreren Thread-Gruppen enthaltenen Threads 910 auswählt. Es wird angemerkt, dass die Anzahl der Threads 910 in jeder Thread-Gruppe mit der Anzahl der Threads übereinstimmt, auf denen die MATCH.ANY-Anweisung 920 arbeitet. Wenn die Deduplizierungsanwendung 182 einen iterativen Deduplizierungsalgorithmus implementiert, dann wählt der Deduplizierungsalgorithmus 182 typischerweise die Threads 910 aus, die in einer Thread-Gruppe enthalten sind. Demgegenüber wählt dann, wenn die Deduplizierungsanwendung 182 einen nicht-iterativen Deduplizierungsalgorithmus implementiert, der Deduplizierungsalgorithmus 182 typischerweise die Threads 910 aus, die in mehreren Thread-Gruppen (z.B. drei Thread-Gruppen) enthalten sind, um die Wahrscheinlichkeit zu verringern, dass einer der Shaderstapel 990 ungefüllt ist.
  • Bei Schritt 1004 lädt die Deduplizierungsanwendung 182 für jeden ausgewählten Thread einen unverarbeiteten Eckpunkt, der in dem Index-Puffer 940 spezifiziert ist. Bei Schritt 1006 führt die Deduplizierungsanwendung 182 für jede Thread-Gruppe die Übereinstimmungsoperationen 950 über die ausgewählten Threads basierend auf der MATCH.ANY-Anweisung 920 aus, wobei die ausgewählten Threads in dem Eingangsprädikat 912 angegeben sind. Für jede Thread-Gruppe hängt die Deduplizierungsanwendung 182 dann die neu identifizierten eindeutigen Eckpunkte an den Eckpunkt-Puffer 992 an. Bei Schritt 1008 hängt die Deduplizierungsanwendung 182 für jeden ausgewählten Thread 910 den entsprechenden indirekten Index an den indirekten Index-Puffer 994 an.
  • Bei Schritt 1010 ermittelt die Deduplizierungsanwendung 182, ob die Deduplizierungsanwendung 182 einen iterativen Deduplizierungsalgorithmus ausführt. Falls bei Schritt 1010 die Deduplizierungsanwendung 182 ermittelt, dass die Deduplizierungsanwendung 182 einen iterativen Deduplizierungsalgorithmus ausführt, schreitet das Verfahren 1000 zu Schritt 1012 fort.
  • Bei Schritt 1012 führt die Deduplizierungsanwendung 182 die Verdichtungsoperationen 970 über die gesamte Thread-Gruppe durch. Die Verdichtungsoperationen 970 konsolidieren die indirekten Indizes für die eindeutigen Eckpunkte in den Threads 910, die den Bits höchster Ordnung in der Übereinstimmungsmaske 930 entsprechen. Als Teil der Durchführung der Verdichtungsoperationen 970 wählt die Deduplizierungsanwendung 182 die Threads 910 aus, die nicht mit eindeutigen Eckpunkten verknüpft sind, und setzt das Eingangsprädikat 912, um die ausgewählten Threads 910 zu spezifizieren.
  • Bei Schritt 1014 wertet die Deduplizierungsanwendung 182 die Stapelbeschränkungen aus, um festzustellen, ob der Stapel voll ist. Wenn bei Schritt 1014 die Deduplizierungsanwendung 182 ermittelt, dass der Stapel nicht voll ist, kehrt das Verfahren 100 zu Schritt 1004 zurück, in dem die Deduplizierungsanwendung 182 unverarbeitete Eckpunkte aus dem Index-Puffer in die ausgewählten Threads 1010 lädt. Wenn jedoch bei Schritt 1014 die Deduplizierungsanwendungen 182 ermittelt, dass der Stapel voll ist, schreitet das Verfahren 1000 zu Schritt 1016 fort.
  • Nun zu Schritt 1010 zurückkehrend schreitet dann, wenn die Deduplizierungsanwendung 182 ermittelt, dass die Deduplizierungsanwendung 182 keinen iterativen Deduplizierungsalgorithmus ausführt, das Verfahren 1000 direkt zu Schritt 1016 fort. In Schritt 1016 erzeugt die Deduplizierungsanwendung 182 Gitter-Shaderstapel 990 basierend auf dem Eckpunkt-Puffer 992 und dem indirekten Index-Puffer 994.
  • Bei Schritt 1018 ermittelt die Deduplizierungsanwendung 182, ob der Index-Puffer 910 unverarbeitete Eckpunkte enthält. Wenn bei Schritt 1018 die Deduplizierungsanwendung 182 ermittelt, dass der Index-Puffer 910 unverarbeitete Eckpunkte enthält, schreitet das Verfahren 1000 zu Schritt 1020 fort. In Schritt 1020 wählt die Deduplizierungsanwendung 182 alle in den Thread-Gruppen enthaltenen Threads 910 aus und erzeugt einen leeren Eckpunkt-Puffer 992 und einen leeren indirekten Index-Puffer 994. Das Verfahren 1000 kehrt dann zu Schritt 1004 zurück, in dem die Deduplizierungsanwendung 182 unverarbeitete Eckpunkte aus dem Index-Puffer 940 in die ausgewählten Threads 910 lädt.
  • Falls jedoch bei Schritt 1018 die Deduplizierungsanwendung 182 bestimmt, dass der Index-Puffer 910 keine unverarbeiteten Eckpunkte enthält, dann schreitet das Verfahren 1000 direkt zu Schritt 1022 fort. Bei Schritt 1022 erzeugt die Grafikverarbeitungspipeline 320 oder die erweiterte Grafikverarbeitungspipeline 620 gerenderte Bildrahmen, die von einem dem Eingangspuffer 940 zugeordneten Eingangsnetz abgeleitet sind, bis sich eine Topologie des Eingangs-Gitters ändert. Das Verfahren 1000 wird dann beendet.
  • insgesamt werden in verschiedenen Ausführungsbeispielen Meshlets in die Grafikverarbeitungspipeline eingeführt, um einen flexibleren Weg zum Strukturieren und Verarbeiten von Grafikdaten, die von verschiedenen Thread-Gruppen in der Anfangsphase der Pipeline erzeugt wurden, bereitzustellen. Um Meshlets zu implementieren, beinhaltet die Grafikverarbeitungspipeline einen Hardware-Gitter-Shader-Generator mit fester Funktion und eine beliebige Anzahl programmierbarer Gitter-Shader, die den Stammfunktionen-Verteiler, die Vertex-Shading-Einheiten und die Geometrie-Shading-Einheiten in herkömmlichen Grafikverarbeitungspipelines ersetzen. Jeder Gitter-Shader umfasst eine unterschiedliche kooperative Thread-Gruppe, die für die Verarbeitung eines anderen Satzes von Eckpunkten in einem Eingangs-Gitter verantwortlich ist, um ein entsprechendes Meshlet zu erzeugen.
  • Im Betrieb spezifiziert eine Benutzeranwendung eine Anzahl von Threads, die in einer Thread-Gruppe enthalten sind, die einen Gitter-Shader und eine Gesamtzahl von Gitter-Shadern umfasst. Der Gitter-Shader-Generator weist jeder der Thread-Gruppen einen anderen Gitter-Identifikator bzw. eine andere Gitter-Kennung zu und führt über die zugehörige Thread-Gruppe ein Gitter-Shading-Programm aus. Genauer gesagt führt, wie von dem Gitter-Shading-Programm festgelegt, jede Thread-Gruppe Lesevorgänge auf einem Frame-Puffer basierend auf dem zugewiesenen Gitter-Identifikator durch, um den Satz von Eckpunkten zu bestimmen, für welchen die Thread-Gruppe verantwortlich ist. Insbesondere ist die Anzahl der in der Thread-Gruppe enthaltenen Threads nicht notwendigerweise gleich der Anzahl der in dem Satz von Eckpunkten enthaltenen Eckpunkte. Ferner kann jeder der in einer Thread-Gruppe enthaltenen Threads mit anderen Threads in der Thread-Gruppe kommunizieren. Wie von dem Gitter-Shading-Programm festgelegt, führt die Thread-Gruppe dann eine oder mehrere Transformationsoperationen an dem Satz von Eckpunkten durch, um ein zugehöriges Meshlet zu erzeugen. Anschließend greifen spätere Verarbeitungseinheiten, die in der Grafikverarbeitungspipeline enthalten sind, auf die verschiedenen Meshlets zu, um Grafikverarbeitungen, allgemeine Verarbeitungs- und/oder Rechenoperationen durchzuführen, um endgültige Ausgabedaten zu erzeugen.
  • Verschiedene Ausführungsbeispiele implementieren eine erweiterte Grafikverarbeitungspipeline, die einen Task-Shader-Generator mit fester Funktion und eine beliebige Anzahl von programmierbaren Task-Shadern beinhaltet, die vor dem Meshlet-Generator mit fester Funktion zur Ausführung kommen. Im Betrieb spezifiziert eine Benutzeranwendung eine Anzahl von Threads, die in einer kooperativen Thread-Gruppe enthalten sind, die einen Task-Shader und eine Gesamtzahl von Task-Shadern umfasst. Der Task-Shader-Generator weist jeder der Thread-Gruppen einen anderen Task-Identifikator zu und führt über die zugehörige Thread-Gruppe ein Task-Shading-Programm aus. Jeder Task-Shader erzeugt eine andere Task-Ausgabe, die zumindest eine Gesamtzahl von Gitter-Shadern spezifiziert. Für jede Task-Ausgabe konfiguriert der Gitter-Shader-Generator die Gesamtzahl der Gitter-Shader basierend auf einer Kopie der Task-Ausgabe unter Angabe eines anderen Gitter-Shader-Identifikators. Jeder Gitter-Shader erzeugt ein anderes Meshlet basierend auf der Task-Ausgabe. Zusammen ersetzen der Task-Shader-Generator, die Task-Shader, der Task-Shader-Generator, der Gitter-Shader-Generator und die Gitter-Shader den Stammfunktionen-Verteiler, die Eckpunkt-Shader, die Hüllkurven-Shading-Einheit, den Tessellator, die Domänen-Shading-Einheit und die Geometrie-Shading-Einheit in herkömmlichen Grafikverarbeitungspipelines.
  • In verschiedenen Ausführungsbeispielen führt eine Benutzeranwendung zur Verbesserung der Leistung der Grafikverarbeitungspipeline eine Deduplizierungsanwendung aus, die einen dem Eingangs-Gitter zugeordneten Index-Puffer vorverarbeitet. Der Index-Puffer definiert Grafik-Stammfunktionen basierend auf Eckpunkten. Für jeden Gitter-Shader identifiziert die Deduplizierungsanwendung einen Satz eindeutiger Eckpunkte, die in dem Index-Puffer enthalten sind, über eine passende Anweisung, die auf dem Parallelprozessor ausgeführt wird. Die Deduplizierungsanwendung erzeugt dann einen Eckpunkt-Puffer, der nur den Satz eindeutiger Eckpunkte enthält. Der Eckpunkt-Puffer definiert die Eckpunkte, für die der Gitter-Shader verantwortlich ist. Ergänzend erzeugt die Deduplizierungsanwendung für jeden Eckpunkt-Puffer einen entsprechenden indirekten Index-Puffer, der auf Einträge in dem Eckpunkt-Puffer verweist, um die dem Gitter-Shader zugeordneten Grafik-Stammfunktionen zu definieren. Für jedes Einzelbild wiederverwenden dann, wenn sich die Topologie des Eingangs-Gitter-Puffers nicht ändert, die Gitter-Shader die Eckpunkt-Puffer und die Stammfunktionen-Puffer. Wenn sich jedoch die Topologie des Eingangs-Gitters ändert, führt die Benutzeranwendung die Deduplizierungsanwendung erneut aus, um einen neuen Index-Puffer vorzuverarbeiten.
  • Weil eine Grafikverarbeitungspipeline, die Gitter-Shader beinhaltet, keinen Stammfunktionen-Verteiler beinhaltet, skaliert vorteilhaft der Durchsatz der Grafikverarbeitungspipeline basierend auf der Speicherbandbreite und/oder der Anzahl der Streaming-Multiprozessoren, die die Grafikpipeline unterstützen. Ferner kann, da ein Gitter-Shader mehrere Eckpunkte kooperativ verarbeiten kann, die Grafikverarbeitungspipeline so programmiert werden, dass sie bestimmte Operationen (z.B. Stammfunktion-Aussortieroperationen) früher und effizienter als eine herkömmliche Grafikverarbeitungspipeline durchführt. Schließlich kann eine Benutzeranwendung die Deduplizierungsanwendung auf einem Index-Puffer ausführen, um Eckpunkt-Puffer und indirekte Index-Puffer zu erzeugen, die die Gitter-Shader wiederverwenden können, bis sich die Topologie des Eingangs-Gitters ändert. Im Allgemeinen ändert sich die Topologie eines Eingangsgitters nur selten. Die Wiederverwendung der Eckpunkt-Puffer und der indirekten Index-Puffer eliminiert folglich wiederholte Deduplizierungsoperationen, die sowohl Verarbeitungsressourcen als auch Energie in einer herkömmlichen Grafikverarbeitungspipeline verschwenden.
    1. 1. In einigen Ausführungsbeispielen umfasst ein Verfahren zur Verarbeitung von Bilddaten ein Veranlassen einer ersten Vielzahl von Ausführungs-Threads, ein Task-Shading-Programm auf einem Eingangs-Gitter auszuführen, um eine erste Task-Shader-Ausgabe zu erzeugen, die eine ersten Gitter-Shader-Anzahl angibt; Erzeugen einer ersten Vielzahl von Gitter-Shader-Identifikatoren, wobei eine Gesamtzahl von Gitter-Shader-Identifikatoren, die in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten sind, gleich der ersten Gitter-Shader-Anzahl ist; für jeden Gitter-Shader-Identifikator, der in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten ist, Aufrufen eines Gitter-Shaders basierend auf dem Gitter-Shader-Identifikator und der ersten Task-Shader-Ausgabe, um eine Geometrie zu erzeugen, die dem Gitter-Shader-Identifikator zugeordnet ist; und Durchführen einer oder mehrerer Operationen an den Geometrien, die der ersten Vielzahl von Gitter-Shader-Identifikatoren zugeordnet sind, um ein erstes gerendertes Bild zu erzeugen.
    2. 2. Verfahren nach Absatz 1, wobei das Task-Shading-Programm eine oder mehrere Tesselierungsoperationen spezifiziert, die auf dem Eingangs-Gitter auszuführen sind.
    3. 3. Verfahren nach Absatz 1 oder 2, wobei das Veranlassen der ersten Vielzahl von Ausführungs-Threads, das Task-Shading-Programm auszuführen, ein Bereitstellen eines ersten Task-Identifikators, der einem ersten Abschnitt des Eingangs-Gitters zugeordnet ist, als eine Eingabe für das Task-Shading-Programm umfasst.
    4. 4. Verfahren nach einem der Absätze 1 bis 3, wobei dann, wenn der erste Task-Identifikator in das Task-Shading-Programm eingegeben ist, die erste Vielzahl von Ausführungs-Threads eine erste Detailstufe (LOD) basierend auf dem ersten Task-Identifikator bestimmt und die erste Gitter-Shader-Anzahl basierend auf der ersten LOD berechnet.
    5. 5. Verfahren nach einem der Absätze 1 bis 4, wobei das Veranlassen der ersten Vielzahl von Ausführungs-Threads, das Task-Shading-Programm auszuführen, umfasst: Erzeugen eines Anwendungsdatenpuffers basierend auf dem Eingangs-Gitter; Speichern des Anwendungsdatenpuffers in einem ersten Speicher; und Speichern der ersten Gitter-Shader-Anzahl und einer dem Anwendungsdatenpuffer zugeordneten Adresse in einem On-Chip-Speicher als zumindest einen Teil der ersten Task-Shader-Ausgabe.
    6. 6. Verfahren nach einem der Absätze 1 bis 5, ferner umfassend ein Festlegen einer Referenzanzahl, die in dem Anwendungsdatenpuffer enthalten ist, gleich der ersten Gitter-Shader-Anzahl.
    7. 7. Verfahren nach einem der Absätze 1 bis 6, wobei das Aufrufen des Gitter-Shaders basierend auf dem Gitter-Shader-Identifikator und dem ersten Task-Shader umfasst: Lesen der dem Anwendungsdatenpuffer zugeordneten Adresse aus dem On-Chip-Speicher; Zugreifen auf Daten, die in dem Anwendungsdatenpuffer enthalten sind, basierend auf der Adresse, die dem Anwendungsdatenpuffer und dem Gitter-Shader-Identifikator zugeordnet ist, um die dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen; und Verringern der Referenzanzahl, der in dem Anwendungsdatenpuffer gespeichert ist.
    8. 8. Verfahren nach einem der Absätze 1 bis 7, wobei dann, wenn das Task-Shading-Programm ausgeführt wird, die erste Vielzahl von Ausführungs-Threads eine oder mehrere Transformationsoperationen an einer ersten Vielzahl von Eckpunkten durchführt, die in dem Eingangs-Gitter enthalten sind, und die Anzahl der Ausführungs-Threads, die in der ersten Vielzahl von Ausführungs-Threads enthalten sind, nicht gleich der Anzahl von Eckpunkten ist, die in der ersten Vielzahl von Eckpunkten enthalten sind.
    9. 9. Verfahren nach einem der Absätze 1 bis 8, wobei das Aufrufen des Gitter-Shaders basierend auf dem Gitter-Shader-Identifikator und der ersten Task-Shader-Ausgabe umfasst: Modifizieren der ersten Task-Shader-Ausgabe, um eine Gitter-Shader-Eingabe zu erzeugen, die den Gitter-Shader-Identifikator angibt; Speichern der Gitter-Shader-Eingabe in einem On-Chip-Speicher; und anschließend Veranlassen einer zweiten Vielzahl von Ausführungs-Threads, ein Gitter-Shading-Programm basierend auf der Gitter-Shader-Eingabe auszuführen und die dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen.
    10. 10. Verfahren nach einem der Absätze 1 bis 9, wobei dann, wenn das Gitter-Shading-Programm ausgeführt wird, die zweite Vielzahl von Ausführungs-Threads eine oder mehrere Transformationsoperationen an einer ersten Vielzahl von Grafik-Stammfunktionen durchführt, die in dem Eingangs-Gitter enthalten sind, und die Anzahl der Ausführungs-Threads, die in der zweiten Vielzahl von Ausführungs-Threads enthalten sind, nicht gleich der Anzahl von Grafik-Stammfunktionen ist, die in der ersten Vielzahl von Grafik-Stammfunktionen enthalten sind.
    11. 11. In einigen Ausführungsbeispielen umfasst ein System einen Off-Chip-Speicher, der ein Task-Shading-Programm speichert; und einen Parallelprozessor, der: veranlasst, dass eine erste Vielzahl von Ausführungs-Threads das Task-Shading-Programm auf einem Eingangs-Gitter ausführen, um eine erste Task-Shader-Ausgabe zu erzeugen, die eine erste Gitter-Shader-Anzahl angibt; eine erste Vielzahl von Gitter-Shader-Identifikatoren erzeugt, wobei eine Gesamtzahl von Gitter-Shader-Identifikatoren, die in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten sind, gleich der ersten Gitter-Shader-Anzahl ist; für jeden Gitter-Shader-Identifikator, der in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten ist, einen Gitter-Shader basierend auf dem Gitter-Shader-Identifikator und der ersten Task-Shader-Ausgabe aufruft, um eine dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen, wobei die Geometrie in einem On-Chip-Speicher gespeichert wird; und eine oder mehrere Operationen an den Geometrien durchführt, die der ersten Vielzahl von Gitter-Shader-Identifikatoren zugeordnet sind, um ein erstes gerendertes Bild zu erzeugen.
    12. 12. System nach Absatz 11, wobei das Task-Shading-Programm eine oder mehrere Tesselierungsoperationen spezifiziert, die auf dem Eingangs-Gitter auszuführen sind.
    13. 13. System nach Absatz 11 oder 12, wobei das Veranlassen der ersten Vielzahl von Ausführungs-Threads, das Task-Shading-Programm auszuführen, ein Bereitstellen eines ersten Task-Identifikators, der einem ersten Abschnitt des Eingangs-Gitters zugeordnet ist, als eine Eingabe in das Task-Shading-Programm umfasst.
    14. 14. System nach einem der Absätze 11 bis 13, wobei der Prozessor die erste Vielzahl von Ausführungs-Threads veranlasst, das Task-Shading-Programm auszuführen durch: Erzeugen eines Anwendungsdatenpuffers basierend auf dem Eingangs-Gitter; Speichern des Anwendungsdatenpuffers in dem Off-Chip-Speicher; und Speichern der ersten Gitter-Shader-Anzahl und einer dem Anwendungsdatenpuffer zugeordneten Adresse in dem On-Chip-Speicher als zumindest einen Teil der ersten Task-Shader-Ausgabe.
    15. 15. System nach einem der Absätze 11 bis 14, wobei der Prozessor eine Referenzanzahl, die in dem Anwendungsdatenpuffer enthalten ist, gleich der ersten Gitter-Shader-Anzahl festlegt.
    16. 16. System einem der Absätze 11 bis 15, wobei der Prozessor den Gitter-Shader basierend auf dem Gitter-Shader-Identifikator und dem ersten Task-Shader aufruft durch: Lesen der dem Anwendungsdatenpuffer zugeordneten Adresse aus dem On-Chip-Speicher; Zugreifen auf Daten, die in dem Anwendungsdatenpuffer enthalten sind, basierend auf der Adresse, die dem Anwendungsdatenpuffer und dem Gitter-Shader-Identifikator zugeordnet ist, um die dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen; und Verringern der Referenzanzahl, der in dem Anwendungsdatenpuffer gespeichert ist.
    17. 17. System nach einem der Absätze 11 bis 16, wobei dann, wenn das Task-Shading-Programm ausgeführt wird, die erste Vielzahl von Ausführungs-Threads eine oder mehrere Transformationsoperationen an einer ersten Vielzahl von Eckpunkten, die in dem Eingangs-Gitter enthalten sind, durchführt und die Anzahl von Ausführungs-Threads, die in der ersten Vielzahl von Ausführungs-Threads enthalten ist, nicht gleich der Anzahl von Eckpunkten ist, die in der ersten Vielzahl von Eckpunkten enthalten ist.
    18. 18. System nach einem der Absätze 11 bis 17, wobei der Prozessor den Gitter-Shader basierend auf dem Gitter-Shader-Identifikator und der ersten Task-Shader-Ausgabe aufruft durch: Modifizieren der ersten Task-Shader-Ausgabe, um eine Gitter-Shader-Eingabe zu erzeugen, die den Gitter-Shader-Identifikator angibt; Speichern der Gitter-Shader-Eingabe in dem On-Chip-Speicher; und anschließend Veranlassen einer zweiten Vielzahl von Ausführungs-Threads, ein Gitter-Shading-Programm basierend auf der Gitter-Shader-Eingabe auszuführen, um die dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen.
    19. 19. System nach einem der Absätze 11 bis 18, wobei der Prozessor die zweite Vielzahl von Ausführungs-Threads veranlasst, das Gitter-Shading-Programm durch Bereitstellen der Gitter-Shader-Eingabe als eine Eingabe für das Gitter-Shading-Programm auszuführen.
    20. 20. In einigen Ausführungsbeispielen umfasst ein Verfahren zur Verarbeitung von Bilddaten ein Veranlassen einer ersten Vielzahl von Ausführungs-Threads, ein Task-Shading-Programm auf einem Eingangs-Gitter auszuführen, um eine erste Task-Shader-Ausgabe zu erzeugen, die eine erste Gitter-Shader-Anzahl angibt, wobei die erste Task-Shader-Ausgabe einem ersten Task-Shader-Identifikator zugeordnet ist; Erzeugen einer ersten Vielzahl von Gitter-Shader-Identifikatoren, wobei eine Gesamtzahl von Gitter-Shader-Identifikatoren, die in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten sind, gleich der ersten Gitter-Shader-Anzahl ist; für jeden Gitter-Shader-Identifikator, der in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten ist, Aufrufen eines Gitter-Shaders basierend auf dem Gitter-Shader-Identifikator und der ersten Task-Shader-Ausgabe, um eine dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen; Bestimmen einer Verarbeitungsreihenfolge basierend auf der ersten Vielzahl von Gitter-Shader-Identifikatoren und dem ersten Task-Shader-Identifikator; und Durchführen einer oder mehrerer Rasterungsoperationen an den Geometrien, die der ersten Vielzahl von Gitter-Shader-Identifikatoren zugeordnet sind, basierend auf der Verarbeitungsreihenfolge, um ein erstes gerendertes Bild zu erzeugen.
  • Jede beliebige und alle Kombinationen eines beliebigen der in einem beliebigen der Ansprüche rezitierten Anspruchselemente und/oder beliebiger in dieser Anmeldung beschriebener Elemente fallen in irgendeiner Weise in den vorgesehenen Schutzumfang der Erfindung und des Schutzes.
  • Die Beschreibungen der verschiedenen Ausführungsbeispiele wurden zu Zwecken der Veranschaulichung präsentiert, sollen aber nicht abschließend oder auf die offenbarten Ausführungsbeispiele beschränkt sein. Viele Modifikationen und Variationen sind für den Fachmann offensichtlich, ohne den Schutzumfang und den Rahmen der beschriebenen Ausführungsbeispiele zu verlassen. Beispielsweise können die verschiedenen hierin beschriebenen Ausführungsbeispiele in Cloud-Computing-Umgebungen, innerhalb einer oder mehrerer Server-Maschinen für Spiel-, Grafik-, Video-Streaming-Zwecke usw. oder in einem Fahrzeugnavigations-, Infotainment- oder Kombi-Steuerungssystem (z.B. wie in Automobilen gefunden) implementiert werden. Die NVIDIA GeForce NOW® ist ein Beispiel für einen vernetzten Gaming-Dienst, der die verschiedenen Ausführungsbeispiele nutzen kann, um die Leistung und das insgesamte Benutzererlebnis zu verbessern. Die verschiedenen Ausführungsbeispiele können darüber hinaus in beliebigen Systemen oder Maschinen implementiert werden, die für Virtual-Reality-Anwendungen oder zur Generierung von Ausgaben für stereoskopische Anzeigen konfiguriert sind.
  • Aspekte der vorliegenden Ausführungsbeispiele können als ein System, Verfahren oder Computerprogrammprodukt ausgeführt sein. Demgemäß können Aspekte der Erfindung die Form eines vollständigen Hardware-Ausführungsbeispiels, eines vollständigen Software-Ausführungsbeispiels (einschließlich Firmware, residenter Software, Mikrocode usw.) oder eines Ausführungsbeispiels, das Soft- und Hardwareaspekte kombiniert, die alle im Allgemeinen als „„Modul“ oder „System“ bezeichnet werden können, annehmen. Darüber hinaus können Aspekte der Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Datenträgern mit einem darauf enthaltenen computerlesbaren Programmcode verkörpert ist.
  • Jede beliebige Kombination aus einem oder mehreren computerlesbaren Medien kann verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann beispielsweise, ohne darauf beschränkt zu sein, ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleiter-System, eine Vorrichtung oder eine Einrichtung oder eine geeignete Kombination der vorgenannten sein. Konkretere Beispiele (eine nicht abschließende Liste) des computerlesbaren Speichermediums würden Folgendes beinhalten: eine elektrische Verbindung mit einem oder mehreren Kabeln, eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM oder Flash-Speicher), eine Glasfaser, ein tragbarer Compact Disc-Nur-Lese-Speicher (CD-ROM), eine optische Speichervorrichtung, eine magnetische Speichervorrichtung oder eine beliebige geeignete Kombination der vorgenannten. Im Kontext dieses Dokuments kann ein computerlesbares Speichermedium jedes beliebige dinghafte Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem Befehlsausführungssystem, einer Befehlsausführungsvorrichtung oder einer Befehlsausführungseinrichtung enthalten oder speichern kann.
  • Aspekte der Erfindung sind vorstehend unter Bezugnahme auf Ablaufdiagrammdarstellungen und/oder Blockdiagramme von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß den Ausführungsbeispielen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Ablaufdiagrammdarstellungen und/oder Blockdiagramme, und Kombinationen von Blöcken in den Ablaufdiagrammdarstellungen und/oder Blockdiagrammen durch Computerprogrammanweisungen implementiert sein können. Diese Computerprogrammanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung zur Herstellung einer Maschine bereitgestellt werden. Die Anweisungen, wenn sie über den Prozessor des Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, ermöglichen die Ausführung der in dem Ablaufdiagramm und/oder Blockschaltbild oder in den Blocks angegebenen Funktionen/Aktionen. Solche Prozessoren können, ohne Einschränkung, Universalprozessoren, Spezialprozessoren, anwendungsspezifische Prozessoren oder feldprogrammierbare Gate-Arrays sein.
  • Das Ablaufdiagramm und die Blockdiagramme in den Figuren veranschaulichen die Architektur, die Funktionalität und die Bedienung möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsbeispielen der Erfindung. In diesem Zusammenhang kann jeder Block in dem Ablaufdiagramm oder in den Blockdiagrammen ein Modul, ein Segment oder einen Teil von Code darstellen, das bzw. der eine oder mehrere ausführbare Anweisungen zur Implementierung der angegebenen logischen Funktionen umfasst. Es wird darüber hinaus angemerkt, dass in einigen alternativen Implementierungen die in dem Block angegebenen Funktionen außerhalb der in den Figuren angegebenen Reihenfolge auftreten können. Beispielsweise können zwei aufeinanderfolgende Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder können die Blöcke abhängig von der involvierten Funktionalität manchmal in umgekehrter Reihenfolge ausgeführt werden. Es wird darüber hinaus angemerkt, dass jeder Block der Blockdiagramme und/oder der Ablaufdiagrammdarstellung, und Kombinationen von Blöcken in den Blockdiagrammen und/oder der Ablaufdiagrammdarstellung durch spezielle hardwarebasierte Systeme, die die spezifizierten Funktionen oder Handlungen ausführen, oder durch Kombinationen von spezieller Hardware und Computeranweisungen implementiert werden kann.
  • Während das Vorstehende auf Ausführungsbeispiele der Erfindung gerichtet ist, können andere und weitere Ausführungsbeispiele der Erfindung dargestellt werden, ohne den grundlegenden Schutzumfang derselben zu verlassen, und wird der Schutzumfang derselben durch die nachfolgenden Ansprüche bestimmt.

Claims (18)

  1. Computerimplementiertes Verfahren zur Verarbeitung von Bilddaten, wobei das Verfahren umfasst: Veranlassen einer ersten Vielzahl von Ausführungs-Threads, ein Task-Shading-Programm auf einem Eingangs-Gitter auszuführen, um eine erste Task-Shader-Ausgabe zu erzeugen, die eine ersten Gitter-Shader-Anzahl angibt; Erzeugen einer ersten Vielzahl von Gitter-Shader-Identifikatoren, wobei eine Gesamtzahl von Gitter-Shader-Identifikatoren, die in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten sind, gleich der ersten Gitter-Shader-Anzahl ist; für jeden Gitter-Shader-Identifikator, der in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten ist, Aufrufen eines Gitter-Shaders basierend auf dem Gitter-Shader-Identifikator und der ersten Task-Shader-Ausgabe, um eine Geometrie zu erzeugen, die dem Gitter-Shader-Identifikator zugeordnet ist; und Durchführen einer oder mehrerer Operationen an den Geometrien, die der ersten Vielzahl von Gitter-Shader-Identifikatoren zugeordnet sind, um ein erstes gerendertes Bild zu erzeugen.
  2. Computerimplementiertes Verfahren nach Anspruch 1, wobei das Task-Shading-Programm eine oder mehrere Tesselierungsoperationen spezifiziert, die auf dem Eingangs-Gitter auszuführen sind.
  3. Computerimplementiertes Verfahren nach Anspruch 1 oder 2, wobei das Veranlassen der ersten Vielzahl von Ausführungs-Threads, das Task-Shading-Programm auszuführen, ein Bereitstellen eines ersten Task-Identifikators, der einem ersten Abschnitt des Eingangs-Gitters zugeordnet ist, als eine Eingabe für das Task-Shading-Programm umfasst.
  4. Computerimplementiertes Verfahren nach Anspruch 3, wobei dann, wenn der erste Task-Identifikator in das Task-Shading-Programm eingegeben ist, die erste Vielzahl von Ausführungs-Threads eine erste Detailstufe (LOD) basierend auf dem ersten Task-Identifikator bestimmt und die erste Gitter-Shader-Anzahl basierend auf der ersten LOD berechnet.
  5. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprüche, wobei das Veranlassen der ersten Vielzahl von Ausführungs-Threads, das Task-Shading-Programm auszuführen, umfasst: Erzeugen eines Anwendungsdatenpuffers basierend auf dem Eingangs-Gitter; Speichern des Anwendungsdatenpuffers in einem ersten Speicher; und Speichern der ersten Gitter-Shader-Anzahl und einer dem Anwendungsdatenpuffer zugeordneten Adresse in einem On-Chip-Speicher als zumindest einen Teil der ersten Task-Shader-Ausgabe.
  6. Computerimplementiertes Verfahren nach Anspruch 5, ferner umfassend ein Festlegen einer Referenzanzahl, die in dem Anwendungsdatenpuffer enthalten ist, gleich der ersten Gitter-Shader-Anzahl.
  7. Computerimplementiertes Verfahren nach Anspruch 6, wobei das Aufrufen des Gitter-Shaders basierend auf dem Gitter-Shader-Identifikator und dem ersten Task-Shader umfasst: Lesen der dem Anwendungsdatenpuffer zugeordneten Adresse aus dem On-Chip-Speicher; Zugreifen auf Daten, die in dem Anwendungsdatenpuffer enthalten sind, basierend auf der Adresse, die dem Anwendungsdatenpuffer und dem Gitter-Shader-Identifikator zugeordnet ist, um die dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen; und Verringern der Referenzanzahl, der in dem Anwendungsdatenpuffer gespeichert ist.
  8. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprüche, wobei dann, wenn das Task-Shading-Programm ausgeführt wird, die erste Vielzahl von Ausführungs-Threads eine oder mehrere Transformationsoperationen an einer ersten Vielzahl von Eckpunkten durchführt, die in dem Eingangs-Gitter enthalten sind, und die Anzahl der Ausführungs-Threads, die in der ersten Vielzahl von Ausführungs-Threads enthalten sind, nicht gleich der Anzahl von Eckpunkten ist, die in der ersten Vielzahl von Eckpunkten enthalten sind.
  9. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprüche, wobei das Aufrufen des Gitter-Shaders basierend auf dem Gitter-Shader-Identifikator und der ersten Task-Shader-Ausgabe umfasst: Modifizieren der ersten Task-Shader-Ausgabe, um eine Gitter-Shader-Eingabe zu erzeugen, die den Gitter-Shader-Identifikator angibt; Speichern der Gitter-Shader-Eingabe in einem On-Chip-Speicher; und anschließend Veranlassen einer zweiten Vielzahl von Ausführungs-Threads, ein Gitter-Shading-Programm basierend auf der Gitter-Shader-Eingabe auszuführen und die dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen.
  10. Computerimplementiertes Verfahren nach Anspruch 9, wobei dann, wenn das Gitter-Shading-Programm ausgeführt wird, die zweite Vielzahl von Ausführungs-Threads eine oder mehrere Transformationsoperationen an einer ersten Vielzahl von Grafik-Stammfunktionen durchführt, die in dem Eingangs-Gitter enthalten sind, und die Anzahl der Ausführungs-Threads, die in der zweiten Vielzahl von Ausführungs-Threads enthalten sind, nicht gleich der Anzahl von Grafik-Stammfunktionen ist, die in der ersten Vielzahl von Grafik-Stammfunktionen enthalten sind.
  11. System, umfassend: einen Off-Chip-Speicher, der ein Task-Shading-Programm speichert; und einen Parallelprozessor, der: veranlasst, dass eine erste Vielzahl von Ausführungs-Threads das Task-Shading-Programm auf einem Eingangs-Gitter ausführen, um eine erste Task-Shader-Ausgabe zu erzeugen, die eine erste Gitter-Shader-Anzahl angibt; eine erste Vielzahl von Gitter-Shader-Identifikatoren erzeugt, wobei eine Gesamtzahl von Gitter-Shader-Identifikatoren, die in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten sind, gleich der ersten Gitter-Shader-Anzahl ist; für jeden Gitter-Shader-Identifikator, der in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten ist, einen Gitter-Shader basierend auf dem Gitter-Shader-Identifikator und der ersten Task-Shader-Ausgabe aufruft, um eine dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen, wobei die Geometrie in einem On-Chip-Speicher gespeichert wird; und eine oder mehrere Operationen an den Geometrien durchführt, die der ersten Vielzahl von Gitter-Shader-Identifikatoren zugeordnet sind, um ein erstes gerendertes Bild zu erzeugen.
  12. System nach Anspruch 11, wobei der Prozessor die erste Vielzahl von Ausführungs-Threads veranlasst, das Task-Shading-Programm auszuführen durch: Erzeugen eines Anwendungsdatenpuffers basierend auf dem Eingangs-Gitter; Speichern des Anwendungsdatenpuffers in dem Off-Chip-Speicher; und Speichern der ersten Gitter-Shader-Anzahl und einer dem Anwendungsdatenpuffer zugeordneten Adresse in dem On-Chip-Speicher als zumindest einen Teil der ersten Task-Shader-Ausgabe.
  13. System nach Anspruch 12, wobei der Prozessor eine Referenzanzahl, die in dem Anwendungsdatenpuffer enthalten ist, gleich der ersten Gitter-Shader-Anzahl festlegt.
  14. System nach Anspruch 13, wobei der Prozessor den Gitter-Shader basierend auf dem Gitter-Shader-Identifikator und dem ersten Task-Shader aufruft durch: Lesen der dem Anwendungsdatenpuffer zugeordneten Adresse aus dem On-Chip-Speicher; Zugreifen auf Daten, die in dem Anwendungsdatenpuffer enthalten sind, basierend auf der Adresse, die dem Anwendungsdatenpuffer und dem Gitter-Shader-Identifikator zugeordnet ist, um die dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen; und Verringern der Referenzanzahl, der in dem Anwendungsdatenpuffer gespeichert ist.
  15. System nach einem der Ansprüche 11 bis 14, wobei der Prozessor den Gitter-Shader basierend auf dem Gitter-Shader-Identifikator und der ersten Task-Shader-Ausgabe aufruft durch: Modifizieren der ersten Task-Shader-Ausgabe, um eine Gitter-Shader-Eingabe zu erzeugen, die den Gitter-Shader-Identifikator angibt; Speichern der Gitter-Shader-Eingabe in dem On-Chip-Speicher; und anschließend Veranlassen einer zweiten Vielzahl von Ausführungs-Threads, ein Gitter-Shading-Programm basierend auf der Gitter-Shader-Eingabe auszuführen, um die dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen.
  16. System nach Anspruch 15, wobei der Prozessor die zweite Vielzahl von Ausführungs-Threads veranlasst, das Gitter-Shading-Programm durch Bereitstellen der Gitter-Shader-Eingabe als eine Eingabe für das Gitter-Shading-Programm auszuführen.
  17. System nach einem der Ansprüche 11 bis 16, das ferner dazu konfiguriert ist, ein computerimplementiertes Verfahren gemäß einem der Ansprüche 1 bis 10 durchzuführen.
  18. Computerimplementiertes Verfahren zur Verarbeitung von Bilddaten, wobei das Verfahren umfasst: Veranlassen einer ersten Vielzahl von Ausführungs-Threads, ein Task-Shading-Programm auf einem Eingangs-Gitter auszuführen, um eine erste Task-Shader-Ausgabe zu erzeugen, die eine erste Gitter-Shader-Anzahl angibt, wobei die erste Task-Shader-Ausgabe einem ersten Task-Shader-Identifikator zugeordnet ist; Erzeugen einer ersten Vielzahl von Gitter-Shader-Identifikatoren, wobei eine Gesamtzahl von Gitter-Shader-Identifikatoren, die in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten sind, gleich der ersten Gitter-Shader-Anzahl ist; für jeden Gitter-Shader-Identifikator, der in der ersten Vielzahl von Gitter-Shader-Identifikatoren enthalten ist, Aufrufen eines Gitter-Shaders basierend auf dem Gitter-Shader-Identifikator und der ersten Task-Shader-Ausgabe, um eine dem Gitter-Shader-Identifikator zugeordnete Geometrie zu erzeugen; Bestimmen einer Verarbeitungsreihenfolge basierend auf der ersten Vielzahl von Gitter-Shader-Identifikatoren und dem ersten Task-Shader-Identifikator; und Durchführen einer oder mehrerer Rasterungsoperationen an den Geometrien, die der ersten Vielzahl von Gitter-Shader-Identifikatoren zugeordnet sind, basierend auf der Verarbeitungsreihenfolge, um ein erstes gerendertes Bild zu erzeugen.
DE102019101720.3A 2018-01-26 2019-01-24 Techniken zur Darstellung und Verarbeitung von Geometrie innerhalb einer erweiterten Grafikverarbeitungspipeline Pending DE102019101720A1 (de)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US15/881,566 2018-01-26
US15/881,564 2018-01-26
US15/881,572 2018-01-26
US15/881,564 US10600229B2 (en) 2018-01-26 2018-01-26 Techniques for representing and processing geometry within a graphics processing pipeline
US15/881,566 US10909739B2 (en) 2018-01-26 2018-01-26 Techniques for representing and processing geometry within an expanded graphics processing pipeline
US15/881,572 US10878611B2 (en) 2018-01-26 2018-01-26 Techniques for pre-processing index buffers for a graphics processing pipeline

Publications (1)

Publication Number Publication Date
DE102019101720A1 true DE102019101720A1 (de) 2019-08-01

Family

ID=67224386

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019101720.3A Pending DE102019101720A1 (de) 2018-01-26 2019-01-24 Techniken zur Darstellung und Verarbeitung von Geometrie innerhalb einer erweiterten Grafikverarbeitungspipeline

Country Status (2)

Country Link
CN (1) CN110084738B (de)
DE (1) DE102019101720A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11164372B2 (en) * 2019-12-10 2021-11-02 Nvidia Corporation Polar stroking for vector graphics
CN111476706A (zh) * 2020-06-02 2020-07-31 长沙景嘉微电子股份有限公司 顶点并行处理方法、装置及计算机存储介质、电子设备
US11379944B2 (en) * 2020-06-23 2022-07-05 Nvidia Corporation Techniques for performing accelerated point sampling in a texture processing pipeline
CN116188243B (zh) * 2023-03-02 2024-09-06 格兰菲智能科技股份有限公司 图形绘制流水线管理方法和图形处理器

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7385607B2 (en) * 2004-04-12 2008-06-10 Nvidia Corporation Scalable shader architecture
US7788468B1 (en) * 2005-12-15 2010-08-31 Nvidia Corporation Synchronization of threads in a cooperative thread array
US9251428B2 (en) * 2009-07-18 2016-02-02 Abbyy Development Llc Entering information through an OCR-enabled viewfinder
US8917271B2 (en) * 2009-10-05 2014-12-23 Nvidia Corporation Redistribution of generated geometric primitives
US9881391B2 (en) * 2013-10-02 2018-01-30 Microsoft Technology Licensing, Llc Procedurally defined texture maps
GB2540937B (en) * 2015-07-30 2019-04-03 Advanced Risc Mach Ltd Graphics processing systems

Also Published As

Publication number Publication date
CN110084738A (zh) 2019-08-02
CN110084738B (zh) 2023-11-07

Similar Documents

Publication Publication Date Title
DE102013017640B4 (de) Verteilte gekachelte Zwischenspeicherung
DE102013017639B4 (de) Zwischenspeicherung von adaptiv dimensionierten Cache-Kacheln in einem vereinheitlichten L2-Cache-Speicher mit Oberflächenkomprimierung
DE102013022257B4 (de) Programmierbares Mischen in mehrsträngigen Verarbeitungseinheiten
DE102019101720A1 (de) Techniken zur Darstellung und Verarbeitung von Geometrie innerhalb einer erweiterten Grafikverarbeitungspipeline
DE102016122297A1 (de) Mehrfach-Durchlauf-Rendering in einer Bildschirm-Raum-Pipeline
US10878611B2 (en) Techniques for pre-processing index buffers for a graphics processing pipeline
DE102019133028A1 (de) Für neuronale netzwerke geeignetes effizientes matrixformat
DE102018113845A1 (de) Systeme und Verfahren zum Trainieren von neuronalen Netzwerken mit dünnbesetzten Daten
DE102018114286A1 (de) Durchführen einer Traversierungs-Stack-Komprimierung
DE102015224026A1 (de) Indirektes Erfassen von Sampledaten zur Durchführung mehrfacher Faltungsoperationen in einem Parallelverarbeitungssystem
DE102013020614A1 (de) Mit Mehrfachauflösung konsistente Rastereinteilung
DE102013020613A1 (de) Umgehung der Pixel-Schattierung für die grafische Bilderzeugung mit geringer Leistung
US10600229B2 (en) Techniques for representing and processing geometry within a graphics processing pipeline
DE102013018445A1 (de) Festlegung eines nachgeordneten Bilderzeugungszustands in einer vorgeordneten Schattierungseinheit
DE102017104220A1 (de) Aufgabenanordnung zur SIMD-Verarbeitung
DE102013114373A1 (de) Konsistente Vertex-Einrastung für Rendering mit variabler Auflösung
DE102013020807A1 (de) Handhabung von nachgeordneten Z-Abdeckungsdaten in Rasteroperationen
DE102013020810A1 (de) Effiziente Super-Abtastung mit Schattierungs-Strängen pro Pixel
DE102019102009A1 (de) Reduzierung des rauschens während des renderings durch parallele path-space-filterung unter verwendung von hashing
DE102016109905A1 (de) Stückweise lineare unregelmäßige Rasterisierung
DE102013018139A1 (de) Technik zur Speicherung gemeinsamer Vertices
DE102013020968A1 (de) Technik zum Zugreifen auf einen inhaltsadressierbaren Speicher
DE102017109472A1 (de) Stereo-mehrfach-projektion implementiert unter verwendung einer graphikverarbeitungs-pipeline
DE102019101871A1 (de) Verfahren und Vorrichtung zum Gewinnen von Abtastpositionen von Textuieroperationen
DE102020112826A1 (de) Verfahren zur effizienten durchführung von datenreduktionen in parallelverarbeitungseinheiten

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication