DE102019119886A1

DE102019119886A1 - System-generated stable barycentric coordinates and direct plane equation access

Info

Publication number: DE102019119886A1
Application number: DE102019119886.0A
Authority: DE
Inventors: David Charles PATRICK; Dale L. Kirkland; Henry Packard Moreton; Ziyad Sami Hakura; Yury Uralsky
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2018-08-01
Filing date: 2019-07-23
Publication date: 2020-02-06

Abstract

Eine Grafikverarbeitungspipeline umfasst drei architektonische Merkmale, die es einem Fragmentshader ermöglichen, samplespezifische Attributwerte unter Verwendung baryzentrischer Koordinaten und punktspezifischer Attribute effizient zu berechnen. Das erste Merkmal ist eine baryzentrische Koordinateneinspeisung, um dem Fragmentshader baryzentrische Koordinaten bereitzustellen. Das zweite Merkmal ist ein Attributkennzeichner, der es ermöglicht, ein Attribut eines Grafikgrundelements ohne konventionelle Festfunktionsinterpolation zu verarbeiten. Das dritte Merkmal ist ein direkter Zugriffspfad vom Fragmentshader zu den Hardware-Ressourcen der Dreiecksdatenspeicherung, in denen Punktattributdaten und/oder Ebenengleichungskoeffizienten gespeichert sind. Es dem Fragmentshader zu ermöglichen, in dieser Weise samplespezifische Attributwerte zu berechnen, erhöht vorteilhaft eine Flexibilität des Systems und reduziert gleichzeitig eine Arbeitsbelastung, die mit einer Bildung der Dreiecksgleichungen verbunden ist.

Description

TECHNISCHER BEREICH
Die vorliegende Offenbarung bezieht sich auf Grafikwiedergabe, insbesondere auf systemerzeugte stabile baryzentrische Koordinaten und einen Direktzugriff auf eine Ebenengleichung.
HINTERGRUND
Eine Attributinterpolation in herkömmlichen Grafikwiedergabesystemen wird durchgeführt, indem für jedes verschiedene Attribut eine verschiedene Ebenengleichung gebildet und die verschiedenen Ebenengleichungen in Festfunktionsinterpolationsschaltungen ausgewertet werden, um einem Fragmentshader interpolierte samplespezifische Attributwerte bereitzustellen. Ein Bilden der verschiedenen Ebenengleichungen kann jedoch rechenintensiv sein und wird mit zunehmender Anzahl der verschiedenen Attribute noch teurer. Darüber hinaus kann eine Auswertung der Ebenengleichungen in Festfunktionsinterpolationsschaltungen eine Flexibilität des Gesamtsystems einschränken, indem sie Attributdatentypen auf spezifisch unterstützte Datentypen beschränkt. Daher besteht eine Notwendigkeit, diese Probleme und/oder andere sich im Zusammenhang mit dem Stand der Technik ergebende Probleme zu behandeln.
ZUSAMMENFASSUNG
Eine Grafikverarbeitungspipeline umfasst drei architektonische Merkmale, die es einem Fragmentshader ermöglichen, samplespezifische Attributwerte unter Verwendung baryzentrischer Koordinaten und punktspezifischer Attribute effizient zu berechnen. Das erste Merkmal ist eine baryzentrische Koordinateneinspeisung, um dem Fragmentshader baryzentrische Koordinaten bereitzustellen. Das zweite Merkmal ist ein Attributkennzeichner, der es ermöglicht, ein Attribut eines Grafikgrundelements ohne konventionelle Festfunktionsinterpolation zu verarbeiten. Das dritte Merkmal ist ein direkter Zugriffspfad vom Fragmentshader auf Hardware-Ressourcen der Dreiecksdatenspeicherung, in denen Punktattributdaten und/oder Ebenengleichungskoeffizienten gespeichert sind. Es dem Fragmentshader zu ermöglichen, in dieser Weise samplespezifische Attributwerte zu berechnen, erhöht vorteilhaft eine Flexibilität des Systems und reduziert gleichzeitig eine Arbeitsbelastung, die mit einer Bildung der Dreiecksgleichungen verbunden ist.
Es werden ein Verfahren, ein rechnerlesbares Medium und ein System zum Bilden von interpolierten samplespezifischen Attributwerten innerhalb eines Fragmentshaders offenbart, basierend auf punktspezifischen Attributen und baryzentrischen Koordinaten, die dem Fragmentshader bereitgestellt werden. Das Verfahren umfasst ein Empfangen von grundelementspezifischen Attributdaten durch den Fragmentshader und ein Bestimmen eines Attributdatenformats, das den grundelementspezifischen Attributdaten zugeordnet ist. Das Verfahren umfasst ferner ein durch den Fragmentshader erfolgendes Auswerten einer Ebenengleichung, welche ein Grundelement zum Berechnen samplespezifischer Attributwerte definiert, wenn das Attributdatenformat anzeigt, dass die samplespezifischen Attributdaten Ebenengleichungskoeffizienten umfassen, oder ein Auswerten einer baryzentrisch-basierten Gleichung, welche das Grundelement zum Berechnen der samplespezifischen Attributwerte definiert, wenn das Attributdatenformat anzeigt, dass die samplespezifischen Attributdaten punktspezifische Attribute und Ebenengleichungskoeffizienten für baryzentrische Gewichte umfassen.
Das rechnerlesbare Medium weist Anweisungen auf, die bei Ausführung durch ein Parallelprozessorsystem dazu führen, dass das Parallelprozessorsystem das Verfahren ausführt. Darüber hinaus umfasst das System einen Parallelprozessor, der zur Durchführung des Verfahrens eingerichtet ist.
Figurenliste

1A veranschaulicht ein Flussdiagramm eines Verfahrens zum Berechnen von samplespezifischen Attributen in Übereinstimmung mit einer Ausführungsform.
1B veranschaulicht eine baryzentrische Koordinate innerhalb der Ebene eines Dreiecks in Übereinstimmung mit einer Ausführungsform.
1C veranschaulicht eine Punktreihung in einem Dreiecksband in Übereinstimmung mit einer Ausführungsform.
1D veranschaulicht eine auf eine Bildschirmraumebene bezogene baryzentrische Ebene in Übereinstimmung mit einer Ausführungsform.
1E veranschaulicht eine Verfahrensweise zum Berechnen eines Abstands zwischen einem innerhalb eines Dreiecks liegenden Punkt und der nächsten Kante des Dreiecks in Übereinstimmung mit einer Ausführungsform. [0011] 2A veranschaulicht ein Blockdiagramm einer Grafikverarbeitungspipeline in Übereinstimmung mit einer Ausführungsform.
2B veranschaulicht ein Flussdiagramm eines Verfahrens zum Berechnen eines Abstands zwischen einem innerhalb eines Dreiecks liegenden Punkt und der nächsten Kante des Dreiecks in Übereinstimmung mit einer Ausführungsform.
3 veranschaulicht eine Parallelverarbeitungseinheit in Übereinstimmung mit einer Ausführungsform.
4A veranschaulicht einen allgemeinen Verarbeitungscluster innerhalb der Parallelverarbeitungseinheit der 3 in Übereinstimmung mit einer Ausführungsform.
4B veranschaulicht eine Speicherteileinheit der Parallelverarbeitungseinheit der 3 in Übereinstimmung mit einer Ausführungsform.
5A veranschaulicht den Streaming-Multiprozessor von 4A in Übereinstimmung mit einer Ausführungsform.
5B ist ein Konzeptdiagramm eines Verarbeitungssystems, das unter Verwendung der PPU der 3 in Übereinstimmung mit einer Ausführungsform verwirklicht wurde.
5C veranschaulicht ein exemplarisches System, in dem die vielfältige Architektur und/oder Funktionalität der vielfältigen vorherigen Ausführungsformen verwirklicht werden kann.
6 ist ein Konzeptdiagramm einer durch die PPU der 3 in Übereinstimmung mit einer Ausführungsform verwirklichten Grafikverarbeitungspipeline.

DETAILLIERTE BESCHREIBUNG
Ausführungsformen der vorliegenden Offenbarung ermöglichen es einem Fragmentshader innerhalb einer Grafikverarbeitungspipeline, interpolierte samplespezifische Attributwerte zu berechnen. In einer Ausführungsform kann der Fragmentshader in einem Ebenengleichungsmodus betrieben werden, um samplespezifische Attributwerte zu berechnen, indem eine Attributebenengleichung unter Verwendung von Ebenengleichungskoeffizienten, die hierin als A-, B- und C-Koeffizienten bezeichnet werden, ausgewertet wird. In einer Ausführungsform kann der Fragmentshader auch in einem baryzentrischen Modus betrieben werden, um samplespezifische Attributwerte basierend auf baryzentrischen Koordinaten (Gewichten) und punktspezifischen Attributen zu berechnen. Darüber hinaus kann der Fragmentshader die baryzentrischen Koordinaten berechnen, indem er eine baryzentrische Ebenengleichung auswertet. Ein Attributdatenformat kann vorteilhaft programmatisch innerhalb des Fragmentshaders und ist nicht auf vordefinierte Attributtypen beschränkt definiert werden, die explizit von Interpolationsschaltungen unterstützt werden. In einer Ausführungsform umfasst der Fragmentshader einen Pixel-Shader, und/oder umfasst die Grafikverarbeitungspipeline eine Grafikwiedergabepipeline.
In einer Ausführungsform werden zur Unterstützung des Ebenengleichungsmodus und des baryzentrischen Modus drei spezifische architektonische Merkmale durch die Grafikverarbeitungspipeline bereitgestellt. Das erste Merkmal ist eine baryzentrische Koordinateneinspeisung in die Grafikverarbeitungspipeline. In einer Ausführungsform wird die baryzentrische Ebenengleichung (z.B. in einer Dreiecksaufbauphase) gebildet und werden baryzentrische Ebenengleichungskoeffizienten an den Fragmentshader übertragen, der die baryzentrische Ebenengleichung auswertet, um samplespezifische baryzentrische Koordinaten zu berechnen. Das zweite Merkmal ist ein Attributkennzeichner, der es ermöglicht, ein Attribut eines Grafikgrundelements ohne eine Festfunktionsinterpolation zu verarbeiten, sodass der Fragmentshader Interpolationsoperationen für das Attribut durchführen kann. Darüber hinaus kann jedem verschiedenen Attribut eines Grafikgrundelements (z.B. einem Dreieck) unabhängig ein Verarbeitungsmodus zugewiesen werden, einschließlich des Ebenengleichungsmodus, des baryzentrischen Modus und verschiedener Modi, in denen Festfunktionshardware interpolierte samplespezifische Attributwerte liefert (z.B. konventionelle Modi). Das dritte Merkmal ist ein direkter Zugriffspfad vom Fragmentshader auf die Hardware-Ressourcen der Dreiecksdatenspeicherung (d.h. Dreiecks-Wahlzugriffsspeicher oder TRAM), in dem Punktattributdaten und/oder Ebenengleichungskoeffizienten gespeichert sind.
1A veranschaulicht ein Flussdiagramm eines Verfahrens 100 zum Berechnen von samplespezifischen Attributen in Übereinstimmung mit einer Ausführungsform. Obwohl das Verfahren 100 im Rahmen eines Multiprozessorsystems beschrieben wird, kann das Verfahren 100 auch von jedem technisch machbaren Verarbeitungssystem, jeder benutzerdefinierten Schaltung oder durch eine Kombination aus benutzerdefinierter Schaltung und Programmanweisungen durchgeführt werden. Das Verfahren 100 kann durch eine Schaltung innerhalb einer GPU, eines GPU-Clusters, einer Schaltung innerhalb eines CPU-Clusters oder eines anderen technisch realisierbaren Multiprozessorsystems, wie beispielsweise einer Parallelverarbeitungseinheit (PPU) 300 aus 3 und/oder einer Grafikverarbeitungspipeline 200 aus 2A ausgeführt werden. In einer Ausführungsform ist eine PPU 300 dazu eingerichtet, die Grafikverarbeitungspipeline 200 zu verwirklichen. Darüber hinaus werden durchschnittliche Fachpersonen verstehen, dass jedes System, das die Methode 100 ausführt, im Bereich und Sinn verschiedener Ausführungsformen liegt. In einer Ausführungsform wird das Verfahren 100 von einem Multiprozessorsystem durchgeführt, welches eine GPU-Vorrichtung umfasst.
In Schritt 101 empfängt ein Fragmentshader (z.B. einer der Fragmentshader 214) innerhalb der Grafikverarbeitungspipeline 200 grundelementspezifische Attributdaten. Die grundelementspezifischen Attributdaten können einen Attributkennzeichner aufweisen, der angibt, ob ein Attribut für ein Grundelement unter Verwendung des Attributebenengleichungsmodus oder des baryzentrischen Modus wiedergegeben werden soll. Es ist zu beachten, dass andere Interpolationsmodi (z.B. konventionelle Festfunktionsinterpolation) nach verschiedenen Verfahrensweisen verarbeitet werden können (nicht dargestellt).
In Schritt 102 bestimmt die Grafikverarbeitungspipeline 200 basierend auf dem Attributkennzeichner ein Attributdatenformat, das den grundelementspezifischen Attributdaten zugeordnet ist. Wenn in Schritt 103 das Attributdatenformat ein baryzentrisches Datenformat ist, dann werden im baryzentrischen Modus samplespezifische Attributwerte berechnet und das Verfahren fährt mit Schritt 107 fort. In Schritt 107 wertet der Fragmentshader eine baryzentrisch-basierte Gleichung aus, die das Grundelement definiert, um die samplespezifischen Attributwerte zu berechnen, wenn das Attributdatenformat anzeigt, dass die samplespezifischen Attributdaten punktspezifische Attribute und Ebenengleichungskoeffizienten für baryzentrische Gewichte umfassen. Jede technisch machbare baryzentrisch-basierte Gleichung kann verwendet werden, und jede technisch machbare Verfahrensweise kann durchgeführt werden, um die baryzentrisch-basierte Gleichung zu bewerten, ohne den Bereich und den Sinn verschiedener Ausführungsformen zu verlassen. So kann beispielsweise die baryzentrische Ebenengleichung verwendet werden, um baryzentrische Koordinaten zu berechnen, und ein samplespezifischer Attributwert, der berechnet wird, indem ein Skalarprodukt zwischen den baryzentrischen Koordinaten und einem Vektor, der aus punktspezifischen Attributen gebildet wird, durchgeführt wird. Die Methode wird dann beendet.
Zu Schritt 103 zurückkehrend sollten dann, wenn das Attributdatenformat kein baryzentrisches Datenformat ist, samplespezifische Attributwerte in dem Attributebenengleichungsmodus berechnet werden und das Verfahren fährt mit Schritt 105 fort. In Schritt 105 wertet die Grafikverarbeitungspipeline durch den Fragmentshader eine Ebenengleichung aus, die das Grundelement definiert, um samplespezifische Attributwerte zu berechnen, wenn das Attributdatenformat anzeigt, dass die grundelementspezifischen Attributdaten Ebenengleichungskoeffizienten umfassen. Die Methode wird dann beendet.
Es werden nun weitere veranschaulichende Informationen zu verschiedenen optionalen Architekturen und Funktionen angegeben, mit denen das vorstehend aufgeführte Rahmenkonzept nach den Wünschen des Benutzers verwirklicht werden kann. Es sollte ausdrücklich zur Kenntnis genommen werden, dass die folgenden Informationen zur Veranschaulichung aufgeführt sind und nicht einschränkend ausgelegt werden sollten. Eine jede der folgenden Eigenschaften kann wahlweise mit oder ohne Ausnahme anderer beschriebener Merkmale integriert werden.
1B veranschaulicht eine baryzentrische Koordinate 122 innerhalb der Ebene eines Dreiecks 120 in Übereinstimmung mit einer Ausführungsform. Die baryzentrische Koordinate 122 befindet sich innerhalb des Dreiecks 120 unter Verwendung von baryzentrischen Koordinaten Alpha (α), Beta (β) und optional Gamma (γ, nicht dargestellt). Eine bestimmende Beschränkung einer baryzentrischen Koordinate ist, dass die Summe von α+β+γ gleich eins (1) ist; somit kann eine baryzentrische Koordinate aus den beiden anderen berechnet werden. Das Dreieck 120 umfasst drei Punkte V(0), V(1) und V(2), die die Ebene des Dreiecks 120 definieren. Jeder Punkt V(0), V(1), V(2) kann einen oder mehrere punktspezifische Attributwerte (oder Werte) für ein gegebenes Attribut aufweisen. Ein Punktattribut kann ohne Einschränkung eine Texturkartenkoordinate, einen Farbwert, einen Intensitätswert, einen Normalvektor, einen Tiefenwert und so weiter aufweisen.
Eine Attributebenengleichung kann in einem gegebenen Raum, wie beispielsweise einem Bildschirmraum, unter Verwendung der drei Koeffizienten A, B und C beschrieben werden. Im Ebenengleichungsmodus kann der Fragmentshader einen samplespezifischen Attributwert an einer Bildschirmraumposition (x,y) berechnen, indem er die Attributebenengleichung als Ax+By+C auswertet. In dem baryzentrischen Modus kann der Fragmentshader eine baryzentrische Ebenengleichung auswerten, um die baryzentrische Koordinate 122 zu berechnen. Der Fragmentshader kann dann einen samplespezifischen Attributwert berechnen, indem er eine Skalarproduktoperation zwischen der baryzentrischen Koordinate 122 und einem Vektor mit entsprechenden punktspezifischen Attributen durchführt.
1C veranschaulicht die Punktreihung in einem Dreiecksband 130 in Übereinstimmung mit einer Ausführungsform. Wie dargestellt umfasst das Dreiecksband 130 Dreiecke 120 und Punkte V. Zum Beispiel umfasst das Dreieck 120(0) Punkte V(0), V(1), V(2) mit einem anregenden Punkt (z.B. erster Punkt) V(0). Dreieck 120(1) umfasst die Punkte V(1), V(3) und V(2) mit anregendem Punkt V(1).
In einer Ausführungsform kann das Dreiecksband 130 unter Verwendung konventioneller Punktreihung der Anwendungsprogrammierschnittstelle (API) spezifiziert werden, die als Punkte V(0), V(1), V(2), V(3), V(4) und so weiter dargestellt ist. Diese Punktreihungs- und Dreiecksbandkonstruktion bewirkt jedoch, dass ein Umlaufsinn 132 von aufeinanderfolgenden Dreiecken (z.B. Dreiecke 120(0), 120(1), 120(2) usw.) alterniert. Um einen gleichbleibenden Umlaufsinn 132 (z.B. im Uhrzeigersinn, wie dargestellt) für aufeinanderfolgende Dreiecke beizubehalten, kann die Punktfolge für jedes andere Dreieck im Dreiecksband 130 zur Unterbreitung an den Fragmentshader umgedreht werden. Generell können Dreiecke in geraden aufeinanderfolgenden Positionen innerhalb des Dreiecksbandes 130 dem Fragmentshader mit unveränderter Punktreihenfolge unterbreitet werden, während Dreiecke in ungeraden aufeinanderfolgenden Positionen innerhalb des Dreiecksbandes 130 dem Fragmentshader mit umgekehrter Punktreihenfolge unterbreitet werden können. Jede technisch realisierbare Verfahrensweise kann durchgeführt werden, um die Punktreihung für jedes zweite Dreieck umzukehren, um einen gleichbleibenden Umlaufsinn 132 beizubehalten. So wird beispielsweise in einer Ausführungsform eine zweite Instanz von punktspezifischen Daten erzeugt und an den Fragmentshader übertragen, wobei die punktspezifische Reihung geeignet umgedreht wird. Darüber hinaus können aufeinanderfolgende Punkte (z.B. Punkt V(0), V(1), V(2), etc.) in dem Dreiecksband 130 als anregender Punkt für entsprechende aufeinanderfolgende Dreiecke 120 bezeichnet werden.
In einer Ausführungsform können Punktdaten des Dreiecks 120(0) dem Fragmentshader unter Verwendung der Punktreihenfolge V(0), V(1), V(2) unterbreitet werden, wobei Punkt V(0) als der anregende Punkt bezeichnet wird. Zusätzlich können Punktdaten des Dreiecks 120(1) umgedreht und dem Fragmentshader unter Verwendung der Punktreihenfolge V(1), V(3), V(2) (zur Beibehaltung des Umlaufsinns 132 im Uhrzeigersinn) unterbreitet werden, wobei Punkt V(1) als der anregende Punkt für Dreieck 120(1) bezeichnet wird. Durch das Umkehren von Punkten jedes zweiten Dreiecks 120 in Bezug auf die API-Punktreihenfolge kann der Umlaufsinn 132 unter den aufeinanderfolgenden Dreiecken 120 des Dreiecksbandes 130 beibehalten werden.
In einer Ausführungsform werden Punktdaten für individuell spezifizierte Grundelemente (nicht innerhalb eines Streifens oder Netzes) dem Fragmentshader in der gleichen Reihenfolge unterbreitet, in der sie ursprünglich einem API-Stream für das Grundelement unterbreitet wurden. Wenn beispielsweise das Dreieck 120(0) der API unter Verwendung von Punkten mit Reihung V(0), V(1) und V(2) unterbreitet wird, dann werden dem Fragmentshader die Punkte in der gleichen Reihenfolge V(0) V(1) und V(2) unterbreitet. In der Grafikverarbeitungspipeline können verschiedene implementierungsabhängige und punktbezogene Umordnungsvorgänge auftreten. In bestimmten Ausführungsformen wird eine Kopie von Punktdaten und/oder anderen grundelementspezifischen Daten, wie sie der API unterbreitet werden, in Speicherschaltungen gespeichert (z.B. TRAM 216 in 2A) und dem Fragmentshader zur Verfügung gestellt, um eine gleichbleibende Punktreihung zu gewährleisten.
1D veranschaulicht eine auf eine Bildschirmraumebene 152 bezogene baryzentrische Ebene 150 in Übereinstimmung mit einer Ausführungsform. Wie dargestellt definieren x- und y-Achsen einen Koordinatenraum innerhalb der Bildschirmraumebene 152, und der Punkt P kann sich innerhalb des Koordinatenraums befinden. Darüber hinaus können verschiedene Punkte entlang der baryzentrischen Ebene 150 eine Höhe entlang einer orthogonalen Achse b relativ zu den x- und y-Achsen aufweisen. Insbesondere kann ein Punkt P auf der Bildschirmraumebene 152 angeordnet sein, und eine Ebenengleichung für die baryzentrische Ebene 150 kann bei Punkt P ausgewertet werden, um einen Punkt P' auf der baryzentrischen Ebene 150 zu lokalisieren.
1E veranschaulicht eine Verfahrensweise zum Berechnen eines Abstands zwischen einem Punkt 154 innerhalb eines Dreiecksgrundelements, und der nächsten Kante des Dreiecksgrundelements (bei O) in Übereinstimmung mit einer Ausführungsform. Wie dargestellt kann ein Abstand d zwischen dem Punkt 154 und O als Quadratwurzel aus einer Summe von Quadraten der baryzentrischen Ebenengleichungskoeffizienten A und B geteilt durch einen Wert b berechnet werden, der sich aus der Auswertung der baryzentrischen Ebenengleichung an dem Punkt 154 ergibt.
2A veranschaulicht ein Blockdiagramm einer Grafikverarbeitungspipeline 200 in Übereinstimmung mit einer Ausführungsform. Wie dargestellt umfasst die Grafikverarbeitungspipeline 200 Grafikpipelineverarbeitungseinheiten 210, einen Rasterer 212, Fragmentshader 214 und TRAM 216. In einer Ausführungsform werden die punktspezifischen Attributdaten von den Grafikpipelineverarbeitungseinheiten 210 berechnet. Darüber hinaus können durch die Grafikpipelineverarbeitungseinheiten 210 Ebenengleichungskoeffizienten berechnet werden. Die Ebenengleichungskoeffizienten und punktspezifischen Attributdaten werden in TRAM 216 gespeichert. In einer Ausführungsform sind Speicherzugriffsschaltungen dazu eingerichtet, den Fragmentshadern 214 einen Direktzugriff auf die in dem TRAM 216 gespeicherten Ebenengleichungskoeffizienten und punktspezifischen Attributdaten zu ermöglichen. In einer Ausführungsform ist die Grafikverarbeitungspipeline 200 innerhalb eines oder mehrerer allgemeiner Verarbeitungscluster (GPC) 350 aus 3 verwirklicht, und mindestens ein programmierbarer Streaming-Multiprozessor (SM) 440 aus 4A ist dazu eingerichtet, als ein oder mehrere Fragmentshader 214 zu agieren.
In dem Ebenengleichungsmodus können die Ebenengleichungskoeffizienten (A, B und C) für ein bestimmtes Attribut von einer Dreiecksbildungseinheit innerhalb der Grafikpipelineverarbeitungseinheiten 210 berechnet werden. Die Fragmentshader 214 berechnen dann samplespezifische Attributwerte, indem sie auf die Ebenengleichungskoeffizienten innerhalb des TRAM 216 zugreifen und die entsprechende Ebenengleichung eines bestimmten Attributtyps auswerten. Im baryzentrischen Modus werden Ebenengleichungskoeffizienten für eine baryzentrische Ebenengleichung durch die Dreiecksbildungseinheit berechnet und in dem TRAM 216 gespeichert. In dem TRAM 216 können auch verschiedene punktspezifische Attribute gespeichert werden. Die Fragmentshader 214 berechnen baryzentrische Koordinaten durch Auswertung einer baryzentrischen Ebenengleichung unter Verwendung der in dem TRAM 216 gespeicherten baryzentrischen Ebenengleichungskoeffizienten. Die Fragmentshader 214 berechnen dann einen samplespezifischen Attributwert basierend auf den baryzentrischen Koordinaten und den in dem TRAM 216 gespeicherten punktspezifischen Attributen.
Die punktspezifischen Attribute können in einem Festkomma- oder Gleitkommaformat dargestellt werden, das eine beliebige Anzahl von Gesamtbits aufweisen kann (z.B. 8, 16, 24, 32, etc.). Darüber hinaus können die punktspezifischen Attribute zur Speicherung in dem TRAM 216 in Wörter gepackt werden. So können beispielsweise zwei 16-Bit-Werte in ein 32-Bit-Wort gepackt werden.
In einer Ausführungsform rastert der Rasterer 212 ein bestimmtes Grafikgrundelement, um Fragmentdaten zu erzeugen, die den Fragmentshadern 214 als Eingabe zur Verfügung gestellt werden. Die Fragmentdaten können Bildschirmraumkoordinaten für einen vom Grafikgrundelement abgedeckten Bildschirmraumbereich aufweisen, der einem bestimmten Fragmentshader zur Verarbeitung und/oder Wiedergabe zugewiesen ist. In einer Ausführungsform können die Bildschirmraumkoordinaten als Eingabekoordinaten zur Auswertung einer gegebenen Ebenengleichung verwendet werden, wie etwa der baryzentrischen Ebenengleichung, einer Attributebenengleichung oder einer anderen technisch realisierbaren Ebenengleichung. Daten, die in dem TRAM 216 gespeichert sind und auf die die Fragmentshader 214 zugreifen, können vorteilhaft bestimmte Grafikpipelineeinheiten (z.B. Rasterer 212) umgehen, da die Fragmentshader 214 die grundelementspezifischen Attributdaten und punktspezifischen Attributdaten direkt aus dem TRAM 216 lesen können.
Es ist zu beachten, dass verschiedene Fragmentshader 214, die dasselbe Grafikgrundelement bearbeiten, dieselbe baryzentrische Ebenengleichung verwenden können, um verschiedene baryzentrische Koordinaten (z.B. basierend auf unterschiedlichen Bildschirmraumkoordinaten) und verschiedene samplespezifische Attributwerte für vielfältige Attribute zu berechnen. Die Fragmentshader 214 können auch baryzentrische Gewichte berechnen und/oder modifizieren, etwa mit einer Funktion höherer Ordnung. Zusätzlich können die Fragmentshader 214 auf die baryzentrischen Ebenengleichungskoeffizienten des TRAM 216 zugreifen, um zusätzliche Vorgänge durchzuführen, wie etwa eine Berechnung eines Abstands zu einer entsprechenden Kante des Grundelements.
In einer Ausführungsform wird ein Linien-Grafikgrundelement wiedergegeben, indem eines der baryzentrischen Gewichte auf Null gesetzt wird. Die beiden anderen baryzentrischen Gewichte können einen Punkt auf der Linie lokalisieren, und die Summe der baryzentrischen Gewichte (Koordinaten) kann gleich eins bleiben für alle auf der Linie wiedergegebenen Samples. In einem Beispiel können Fragmentshader 214 Pixel schattieren, die eine Linie aufweisen, bei der dasselbe baryzentrische Gewicht bei jedem Pixel auf Null gesetzt ist. Ein exemplarischer Anwendungsfall ist bei einer Wiedergabe von Wireframe-Modellen gegeben, bei denen Linien-Grundelemente entlang von Dreieckskanten wiedergegeben werden. In einer weiteren Ausführungsform wird ein Grafikgrundelement für einen Punkt ähnlich wiedergegeben, indem zwei baryzentrische Gewichte auf Null gesetzt werden.
2B veranschaulicht ein Flussdiagramm eines Verfahrens 230 zum Berechnen eines Abstands zwischen einem innerhalb eines Dreiecks liegenden Punkt und der nächsten Kante des Dreiecks in Übereinstimmung mit einer Ausführungsform. Obwohl Verfahren 230 im Sachzusammenhang eines Multiprozessorsystems beschrieben wird, kann das Verfahren 230 auch von jedem technisch machbaren Verarbeitungssystem, jeder benutzerdefinierten Schaltung oder durch eine Kombination aus benutzerdefinierter Schaltung und Programmanweisungen durchgeführt werden. Das Verfahren 230 kann durch eine Schaltung innerhalb einer GPU, eines GPU-Clusters, einer Schaltung innerhalb eines CPU-Clusters oder eines anderen technisch realisierbaren Multiprozessorsystems, wie etwa einer Parallelverarbeitungseinheit (PPU) 300 aus 3 und/oder einer Grafikverarbeitungspipeline 200 aus 2A ausgeführt werden. In einer Ausführungsform ist PPU 300 dazu eingerichtet, die Grafikverarbeitungspipeline 200 zu verwirklichen. Darüber hinaus werden durchschnittliche Fachpersonen verstehen, dass jedes System, das Verfahren 230 durchführt, in Bereich und Sinn verschiedener Ausführungsformen liegt. In verschiedenen Ausführungsformen wird das Verfahren 230 durch ein Multiprozessorsystem durchgeführt, das eine GPU-Vorrichtung umfasst. In einer Ausführungsform wird das Verfahren 230 durch einen Fragmentshader 214 durchgeführt.
In Schritt 232 empfängt der Fragmentshader baryzentrische Ebenengleichungskoeffizienten (z.B. A-, B- und C-Koeffizienten) für ein Dreiecksgrundelement. In einer Ausführungsform ist der Fragmentshader dazu eingerichtet, die baryzentrischen Ebenengleichungskoeffizienten direkt vom TRAM 216 zu lesen. In Schritt 234 wertet der Fragmentshader einen baryzentrischen Wert (z.B. Element b in 1E) basierend auf den baryzentrischen Ebenengleichungskoeffizienten aus. In einer Ausführungsform führt der Fragmentshader Programmanweisungen aus, um den baryzentrischen Wert auszuwerten. In Schritt 236 berechnet der Fragmentshader einen Abstand von einem Punkt innerhalb des Dreiecksgrundelements zu einer nächsten Kante des Dreiecksgrundelements basierend auf der Punktposition und den baryzentrischen Ebenengleichungskoeffizienten. In einer Ausführungsform ist der Abstand gleich einer Quadratwurzel aus einer Summe von baryzentrischen Ebenengleichungskoeffizienten dividiert durch den baryzentrischen Wert, wie in 1E dargestellt. Nach Berechnung der Entfernung endet das Verfahren 230.
Es werden ein Verfahren, ein rechnerlesbares Medium und ein System zum Berechnen interpolierter samplespezifischer Attributwerte offenbart. Wenn sie im offenbarten baryzentrischen Modus arbeiten können Fragmentshader 214 baryzentrische Koordinaten aus durch den TRAM 216 bereitgestellten baryzentrischen Ebenengleichungskoeffizienten berechnen und die baryzentrischen Koordinaten dazu verwenden, samplespezifische Attributwerte zu erzeugen. Wenn die Fragmentshader 214 im offenbarten Ebenengleichungsmodus arbeiten können sie samplespezifische Attributwerte erzeugen, indem sie eine Attributebenengleichung aus den durch das TRAM 216 bereitgestellten Ebenengleichungskoeffizienten auswerten. Die offenbarten Verfahrensweisen bieten vorteilhaft eine erhöhte Flexibilität innerhalb der Fragmentshader 214 bei gleichzeitiger Reduzierung der Gesamtarbeitslast, die mit einer Dreiecksbildung in einer Grafikpipeline, wie etwa der Grafikverarbeitungspipeline 200, verbunden ist.
Parallele Verarbeitungsarchitektur
3 veranschaulicht eine Parallelverarbeitungseinheit (PPU) 300 in Übereinstimmung mit einer Ausführungsform. In einer Ausführungsform ist die PPU 300 ein für Multithreading ausgelegter Prozessor, der auf einer oder mehreren integrierten Schaltungsvorrichtungen verwirklicht ist. Die PPU 300 ist eine latenzverbergende Architektur, die entwickelt wurde, um viele Threads parallel abzuarbeiten. Ein Thread (d.h. ein Thread der Ausführung) ist eine Instanziierung einer Reihe von Anweisungen, die für eine Ausführung durch die PPU 300 eingerichtet sind. In einer Ausführungsform ist die PPU 300 eine Grafikverarbeitungseinheit (GPU) die dazu eingerichtet ist, eine Grafikwiedergabepipeline zum Verarbeiten von dreidimensionalen (3D) Grafikdaten zu verwirklichen, um zweidimensionale (2D) Bilddaten zur Anzeige auf einer Anzeigevorrichtung wie beispielsweise einer Flüssigkristallanzeigevorrichtung (LCD) zu erzeugen. In anderen Ausführungsformen kann die PPU 300 zur Durchführung von Allgemeinberechnungszwecken verwendet werden. Obwohl hierin ein beispielhafter Parallelprozessor zu veranschaulichenden Zwecken vorgesehen ist, sei dennoch nachdrücklich darauf hingewiesen, dass dieser Prozessor nur zu veranschaulichenden Zwecken vorgesehen ist und dass jeder Prozessor als Ergänzung und/oder Ersatz für diesen einsetzbar ist.
Eine oder mehrere PPU 300 können dazu eingerichtet sein, Tausende von High Performance Computing (HPC)-, Rechenzentrums- und maschineller Lernanwendungen zu beschleunigen. Die PPU 300 kann dazu eingerichtet sein, zahlreiche Deep-Learning-Systeme und -Anwendungen zu beschleunigen, darunter autonome Fahrzeugplattformen, Deep Learning, hochpräzise Sprach-, Bild- und Texterkennungssysteme, intelligente Videoanalyse, molekulare Simulationen, Arzneimittelforschung, Krankheitsdiagnose, Wettervorhersage, Analysen großer Datenmengen, Astronomie, Simulation von Molekulardynamik, Finanzmodellierung, Robotik, Fabrikautomatisierung, Echtzeitsprachübersetzung, Optimierung von Onlinesuchen und personalisierte Benutzerempfehlungen und dergleichen.
Wie in 3 dargestellt, weist die PPU 300 eine Ein-/Ausgabe-(I/O)-Einheit 305, eine Frontend-Einheit 315, eine Ablaufplanungseinheit 320, eine Arbeitsverteilungseinheit 325, einen sternförmig angebundenen Knotenpunkt 330, ein Koppelfeld (Xbar) 370, einen oder mehrere allgemeine Verarbeitungscluster (GPC) 350 und eine oder mehrere Speicherteileinheiten 380. Die PPU 300 kann über eine oder mehrere Hochgeschwindigkeits-NVLink-Verbindungen 310 mit einem Host-Prozessor oder anderen PPU 300 verbunden sein. Die PPU 300 kann über eine Verbindung 302 mit einem Host-Prozessor oder anderen Peripheriegeräten verbunden sein. Die PPU 300 kann auch an einen lokalen Speicher angeschlossen werden, der eine Anzahl von Speichervorrichtungen 304 umfasst. In einer Ausführungsform kann der lokale Speicher eine Anzahl von Speichervorrichtungen mit wahlfreiem Zugriff (DRAM) umfassen. Die DRAM-Vorrichtungen können als Speicher mit hoher Bandbreite (HBM) eingerichtet werden, mit mehreren gestapelten DRAM-Plättchen in jeder Vorrichtung.
Die NVLink-Verbindung 310 ermöglicht es Systemen, eine oder mehrere PPU 300 in Kombination mit einer oder mehreren CPU zu skalieren und zu umfassen, und unterstützt eine Cache-Kohärenz zwischen den PPU 300 und CPU und das CPU-Mastering. Daten und/oder Befehle können durch den NVLink 310 über den sternförmig angebundenen Knotenpunkt 330 zu/von anderen Einheiten der PPU 300 übertragen werden, wie etwa eine oder mehrere Kopiereinheiten, einem Videoencoder, einem Videodecoder, einer Energieverwaltungseinheit usw. (nicht explizit dargestellt). Der NVLink 310 wird in Verbindung mit 5B näher beschrieben.
Die I/O-Einheit 305 ist dazu eingerichtet, Kommunikation (d.h. Befehle, Daten usw.) von einem Host-Prozessor (nicht dargestellt) über die Verbindung 302 zu senden und zu empfangen. Die 1/O-Einheit 305 kann mit dem Host-Prozessor direkt über die Verbindung 302 oder über eine oder mehrere Zwischenvorrichtungen, wie beispielsweise eine Speicherbrücke, kommunizieren. In einer Ausführungsform kann die I/O-Einheit 305 mit einem oder mehreren anderen Prozessoren, wie beispielsweise einer oder mehreren PPU 300, über die Verbindung 302 kommunizieren. In einer Ausführungsform verwirklicht die I/O-Einheit 305 eine Peripheral Component Interconnect Express (PCIe)-Schnittstelle für die Kommunikation über einen PCIe-Bus und die Verbindung 302 ist ein PCIe-Bus. In alternativen Ausführungsformen kann die I/O-Einheit 305 andere Arten von bekannten Schnittstellen zur Kommunikation mit externen Geräten verwirklichen.
Die I/O-Einheit 305 dekodiert Pakete, die über die Verbindung 302 empfangen werden. In einer Ausführungsform stellen die Pakete Befehle dar, die dazu eingerichtet sind, die PPU 300 zu veranlassen, verschiedene Vorgänge durchzuführen. Die I/O-Einheit 305 überträgt die dekodierten Befehle an verschiedene andere Einheiten der PPU 300, wie die Befehle angeben. So können beispielsweise einige Befehle an die Frontend-Einheit 315 übertragen werden. Andere Befehle können an den sternförmig angebundenen Knotenpunkt 330 oder andere Einheiten der PPU 300 übertragen werden, wie z.B. eine oder mehrere Kopiereinheiten, ein Videoencoder, ein Videodecoder, ein Energieverwaltungseinheit usw. (nicht explizit dargestellt). Mit anderen Worten ist die 1/O-Einheit 305 dazu eingerichtet, eine Kommunikation zwischen und unter den vielfältigen logischen Einheiten der PPU 300 zu leiten.
In einer Ausführungsform kodiert ein von dem Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, der der PPU 300 Arbeitslasten zur Verarbeitung bereitstellt. Eine Arbeitslast kann mehrere Anweisungen und Daten umfassen, die durch diese Anweisungen verarbeitet werden sollen. Der Puffer ist ein Bereich in einem Speicher, der sowohl dem Host-Prozessor als auch der PPU 300 zugänglich (d.h. lesen/schreiben) ist. So kann beispielsweise die I/O-Einheit 305 dazu eingerichtet sein, mittels Speicheranforderungen, die über die Verbindung 302 übertragen werden, auf den Puffer in einem mit der Verbindung 302 verbundenen Systemspeicher zuzugreifen. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und sendet dann einen Zeiger auf den Anfang des Befehlsstroms an die PPU 300. Die Frontend-Einheit 315 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Frontend-Einheit 315 verwaltet die einen oder mehreren Ströme, liest Befehle aus den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 300 weiter.
Die Frontend-Einheit 315 ist mit einer Ablaufplanungseinheit 320 gekoppelt, die die verschiedenen GPC 350 dazu einrichtet, durch die einen oder mehreren Ströme definierte Aufgaben zu verarbeiten. Die Ablaufplanungseinheit 320 ist dazu eingerichtet, auf die verschiedenen Aufgaben bezogene Zustandsinformationen zu überwachen, die von der Ablaufplanungseinheit 320 verwaltet werden. Der Zustand kann anzeigen, welchem GPC 350 eine Aufgabe zugeordnet ist, ob die Aufgabe aktiv oder inaktiv ist, eine der Aufgabe zugeordnete Vorrangstufe und so weiter. Die Ablaufplanungseinheit 320 verwaltet die Ausführung einer Vielzahl von Aufgaben auf einem oder mehreren GPC 350.
Die Ablaufplanungseinheit 320 ist mit einer Arbeitsverteilungseinheit 325 gekoppelt, die dazu eingerichtet ist, Aufgaben zur Ausführung auf den GPC 350 zu verteilen. Die Arbeitsverteilungseinheit 325 kann eine Anzahl von geplanten Aufgaben überwachen, die von der Ablaufplanungseinheit 320 empfangen wurden. In einer Ausführungsform verwaltet die Arbeitsverteilungseinheit 325 für jeden der GPC 350 einen Pool anstehender Aufgaben und einen Pool aktiver Aufgaben. Der Pool anstehender Aufgaben kann eine Anzahl von Slots (z.B. 32 Slots) umfassen, die Aufgaben enthalten, die von einem bestimmten GPC 350 bearbeitet werden sollen. Der Pool aktiver Aufgaben kann eine Anzahl von Slots (z.B. 4 Slots) für Aufgaben umfassen, die von den GPC 350 aktiv bearbeitet werden.
Wenn ein GPC 350 die Ausführung einerAufgabe beendet, wird diese Aufgabe aus dem Pool aktiver Aufgaben für den GPC 350 genommen und eine der anderen Aufgaben aus dem Pool anstehender Aufgaben ausgewählt und zur Ausführung auf dem GPC 350 angesetzt. Wenn eine aktive Aufgabe auf dem GPC 350 im Leerlauf war, z.B. während eines Wartens auf eine Auflösung einer Datenabhängigkeit, kann die aktive Aufgabe aus dem GPC 350 genommen und in den Pool anstehender Aufgaben zurückgeführt werden, während eine andere Aufgabe in dem Pool anstehender Aufgaben ausgewählt und für die Ausführung auf dem GPC 350 angesetzt wird.
Die Arbeitsverteilungseinheit 325 kommuniziert über das Koppelfeld 370 mit einem oder mehreren GPC 350. Das Koppelfeld 370 ist ein Verbindungsnetzwerk, das viele der Einheiten der PPU 300 mit anderen Einheiten der PPU 300 koppelt. So kann beispielsweise das Koppelfeld 370 dazu eingerichtet sein, die Arbeitsverteilungseinheit 325 mit einem bestimmten GPC 350 zu koppeln. Obwohl nicht ausdrücklich angegeben können eine oder mehrere andere Einheiten der PPU 300 auch über den sternförmig angebundenen Knotenpunkt 330 mit dem Koppelfeld 370 verbunden werden.
Die Aufgaben werden von der Ablaufplanungseinheit 320 verwaltet und von der Arbeitsverteilungseinheit 325 an einen GPC 350 verteilt. Der GPC 350 ist dazu eingerichtet, die Aufgabe abzuarbeiten und Ergebnisse zu erzeugen. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 350 übernommen, über das Koppelfeld 370 an einen anderen GPC 350 weitergeleitet oder im Speicher 304 gespeichert werden. Die Ergebnisse können über die Speicherteileinheiten 380, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/aus dem Speicher 304 verwirklichen, in den Speicher 304 geschrieben werden. Die Ergebnisse können über den NVLink 310 an eine andere PPU 304 oder CPU übertragen werden. In einer Ausführungsform umfasst die PPU 300 eine Anzahl U von Speicherteileinheiten 380, die gleich der Anzahl der getrennten und eigenständigen Speichervorrichtungen 304 ist, die mit der PPU 300 gekoppelt sind. Eine Speicherteileinheit 380 wird im Folgenden in Verbindung mit 4B näher beschrieben.
In einer Ausführungsform führt ein Host-Prozessor einen Treiberkern aus, der eine Anwendungsprogrammierschnittstelle (API) verwirklicht, die es einer oder mehreren auf dem Host-Prozessor ablaufenden Anwendungen ermöglicht, Vorgänge zur Ausführung auf der PPU 300 anzusetzen. In einer Ausführungsform werden mehrere Rechenanwendungen gleichzeitig von der PPU 300 ausgeführt, und die PPU 300 stellt Trennung, Dienstgüte (QoS) und unabhängige Addressräume für die mehreren Rechenanwendungen bereit. Eine Anwendung kann Anweisungen (z.B. API-Aufrufe) erzeugen, die den Treiberkern dazu veranlassen, einen oder mehrere Aufgaben zur Ausführung durch die PPU 300 zu erzeugen. Der Treiberkern gibt Aufgaben an einen oder mehrere Ströme aus, die von der PPU 300 verarbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen von verwandten Threads umfassen, die hierin als Warp bezeichnet werden. In einer Ausführungsform umfasst ein Warp 32 verwandte Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Vielzahl von Threads beziehen, einschließlich Anweisungen zur Ausführung der Aufgabe, und die Daten über einen gemeinsamen Speicher austauschen können. Threads und zusammenwirkende Threads werden in Verbindung mit 5A näher beschrieben.
4A veranschaulicht eine GPC 350 der PPU 300 aus 3 in Übereinstimmung mit einer Ausführungsform. Wie in 4A dargestellt umfasst jeder GPC 350 eine Reihe von Hardwareeinheiten für eine Verarbeitung von Aufgaben. In einer Ausführungsform umfasst jeder GPC 350 einen Pipelineverwalter 410, eine Pre-Raster-Betriebseinheit (PROP) 415, eine Rastereinheit 425, ein Arbeitsverteilungskoppelfeld (WDX) 480, eine Speicherverwaltungseinheit (MMU) 490 und einen oder mehrere Datenverarbeitungs-Cluster (DPC) 420. Es ist zu beachten, dass der GPC 350 von 4A anstelle oder zusätzlich zu den in 4A dargestellten Einheiten weitere Hardwareeinheiten aufweisen kann.
In einer Ausführungsform wird der Betrieb des GPC 350 durch den Pipelineverwalter 410 gesteuert. Der Pipelineverwalter 410 verwaltet die Konfiguration eines oder mehrerer DPC 420 für eine Abarbeitung von Aufgaben, die dem GPC 350 zugeordnet sind.
In einer Ausführungsform kann der Pipelineverwalter 410 mindestens einen der einen oder mehreren DPC 420 dazu einrichten, mindestens einen Teil einer Grafikwiedergabepipeline zu verwirklichen. So kann beispielsweise ein DPC 420 dazu eingerichtet sein, ein Punktshaderprogramm auf dem programmierbaren Streaming-Multiprozessor (SM) 440 auszuführen. Der Pipelineverwalter 410 kann auch dazu eingerichtet sein, von der Arbeitsverteilungseinheit 325 empfangene Pakete an die geeigneten logischen Einheiten innerhalb des GPC 350 weiterzuleiten. So können beispielsweise einige Pakete an Festfunktionshardwareeinheiten in dem PROP 415 und/oder in der Rastereinheit 425 weitergeleitet werden, während andere Pakete an die DPC 420 zur Verarbeitung durch die Grundelementeeinheit 435 oder den SM 440 weitergeleitet werden können. In einer Ausführungsform kann der Pipelineverwalter 410 mindestens einen der einen oder mehreren DPC 420 dazu einrichten, ein neuronales Netzwerkmodell und/oder eine Rechenpipeline zu verwirklichen.
Die PROP-Einheit 415 ist dazu eingerichtet, die von der Rastereinheit 425 und den DPC 420 erzeugten Daten an eine Rasterbetriebs-(ROP)-Einheit weiterzuleiten, die in Verbindung mit 4B näher beschrieben wird. Die PROP-Einheit 415 kann auch dazu eingerichtet sein, Optimierungen für einen Farbverschnitt durchzuführen, Pixeldaten zu organisieren, Adressenübersetzungen durchzuführen und dergleichen.
Die Rastereinheit 425 umfasst eine Reihe von zum Ausführen vielfältiger Rastervorgänge eingerichteter Festfunktionshardwareeinheiten. In einer Ausführungsform umfasst die Rastereinheit 425 eine Bildungseinheit, eine Grobrastereinheit, eine Kappungseinheit, eine Ausleseeinheit, eine Feinrastereinheit und eine Kachelvereinigungseinheit. Die Bildungseinheit empfängt transformierte Punkte und erzeugt Ebenengleichungen, die dem durch die Punkte definierten geometrischen Grundelement zugeordnet sind. Die Ebenengleichungen werden an die Grobrastereinheit übertragen, um Abdeckungsinformationen (z.B. eine x,y-Abdeckungsmaske für eine Kachel) für das Grundelement zu erzeugen. Die Ausgabe der Grobrastereinheit wird an den Ausleseeinheit übertragen, wo Fragmente, die dem Grundelement zugeordnet sind und einen z-Test nicht bestehen, verworfen werden, und an eine Kappungseinheit übertragen, wo Fragmente, die außerhalb eines Sichtfeldes liegen, gekappt werden. Die die Kappung und die Auslese überdauernden Fragmente können an die Feinrastereinheit übergeben werden, um basierend auf den von der Bildungseinheit erzeugten Ebenengleichungen Attribute für die Pixelfragmente zu erzeugen.
Die Ausgabe der Rastereinheit 425 umfasst Fragmente zur Verarbeitung durch beispielsweise einen in einem DPC 420 verwirklichten Fragmentshader.
Jeder im GPC 350 umfasste DPC 420 weist einen M-Pipe Controller (MPC) 430, einen Grundelementeeinheit 435 und einen oder mehrere SMen 440 auf. Der MPC 430 steuert den Betrieb des DPC 420, wobei die vom Pipelineverwalter 410 empfangenen Pakete an die geeigneten Einheiten des DPC 420 weitergeleitet werden. So können beispielsweise Pakete, die einem Punkt zugeordnet sind, an die Grundelementeeinheit 435 weitergeleitet werden, die dazu eingerichtet ist, dem Punkt zugeordnete Punktattribute aus dem Speicher 304 zu holen. Im Gegensatz dazu können Pakete, die einem Shaderprogramm zugeordnet sind, an den SM 440 übertragen werden.
Der SM 440 umfasst einen programmierbaren Streaming-Prozessor, der dazu eingerichtet ist, Aufgaben zu verarbeiten, die durch eine Reihe von Threads repräsentiert werden. Jeder SM 440 ist für Multithreading ausgelegt und dazu eingerichtet, eine Vielzahl von Threads (z.B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig auszuführen. In einer Ausführungsform verwirklicht der SM 440 eine SIMD-Architektur (Single-Instruction, Multiple-Data), bei der jeder Thread in einer Gruppe von Threads (d.h. ein Warp) dazu eingerichtet ist, einen anderen Datensatz basierend auf demselben Befehlssatz zu verarbeiten. Alle Threads in der Gruppe der Threads führen die gleichen Anweisungen aus. In einer weiteren Ausführungsform verwirklicht der SM 440 eine SIMT-Architektur (Single-Instruction, Multiple Thread), bei der jeder Thread in einer Gruppe von Threads dazu eingerichtet ist, einen anderen Datensatz basierend auf demselben Befehlssatz zu verarbeiten, wobei jedoch einzelne Threads in der Gruppe von Threads während der Ausführung davon abweichen dürfen. In einer Ausführungsform wird für jeden Warp ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand gepflegt, was eine Gleichzeitigkeit zwischen Warps und eine fortlaufende Ausführung innerhalb von Warps ermöglicht, wenn Threads innerhalb des Warps abweichen. In einer weiteren Ausführungsform wird für jeden einzelnen Thread ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand gepflegt, wodurch eine gleiche Gleichzeitigkeit zwischen allen Threads innerhalb und zwischen den Warps ermöglicht wird. Wenn der Ausführungszustand für jeden einzelnen Thread gepflegt wird, können Threads, die dieselben Anweisungen ausführen, für eine maximale Effizienz zusammengeführt und parallel ausgeführt werden. Der SM 440 wird im Folgenden in Verbindung mit 5A näher beschrieben.
Die MMU 490 stellt eine Schnittstelle zwischen dem GPC 350 und der Speicherteileinheit 380 bereit. Die MMU 490 kann eine Übersetzung virtueller Adressen in physikalische Adressen, einen Speicherschutz und eine Schlichtung von Speicheranforderungen bereitstellen. In einer Ausführungsform stellt die MMU 490 einen oder mehrere Übersetzungsnachschlagepuffer (TLBs) zur Verfügung, um die Übersetzung von virtuellen Adressen in physikalische Adressen im Speicher 304 durchzuführen.
4B veranschaulicht eine Speicherteileinheit 380 der PPU 300 von 3 in Übereinstimmung mit einer Ausführungsform. Wie in 4B dargestellt umfasst die Speicherteileinheit 380 eine Rasteroperations-(ROP)-Einheit 450, einen Stufe-2-(L2)-Cache 460 und eine Speicherschnittstelle 470. Die Speicherschnittstelle 470 ist mit dem Speicher 304 gekoppelt. Die Speicherschnittstelle 470 kann 32, 64, 128, 1024-Bit-Datenbusse oder dergleichen für die Hochgeschwindigkeitsdatenübertragung verwirklichen. In einer Ausführungsform umfasst die PPU 300 U Speicherschnittstellen 470, eine Speicherschnittstelle 470 je Paar von Speicherteileinheiten 380, wobei jedes Paar von Speicherteileinheiten 380 mit einer entsprechenden Speichervorrichtung 304 verbunden ist. So kann die PPU 300 beispielsweise an bis zu Y Speichervorrichtungen 304 angeschlossen werden, wie beispielsweise an Hochbandbreite-Speicherstapel oder Grafik-Doppeldatenrate-Version 5-Speicher mit synchronem, dynamischem und wahlfreiem Zugriff oder andere Arten von persistentem Speicher.
In einer Ausführungsform verwirklicht die Speicherschnittstelle 470 eine HBM2-Speicherschnittstelle und Y entspricht eine Hälfte von U. In einer Ausführungsform befinden sich die HBM2-Speicherstapel in dem gleichen physikalischen Gehäuse wie die PPU 300, was im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen zu erheblichen Leistungs- und Flächeneinsparungen führt. In einer Ausführungsform umfasst jeder HBM2-Stapel vier Speicherplättchen und Y entspricht 4, wobei der HBM2-Stapel zwei 128-Bit-Kanäle pro Plättchen für insgesamt 8 Kanäle und eine Datenbusbreite von 1024 Bit umfasst.
In einer Ausführungsform unterstützt der Speicher 304 einen Einzelfehlerkorrektur-Doppelfehlererkennungs-(SECDED)-Fehlerkorrekturcode (ECC) zum Schutz der Daten. ECC bietet eine höhere Zuverlässigkeit für Rechenanwendungen, die empfindlich auf Datenverfälschung reagieren. Zuverlässigkeit ist besonders wichtig in großen Cluster-Rechenumgebungen, in denen PPU 300 sehr große Datensätze verarbeiten und/oder Anwendungen über einen längeren Zeitraum ausführen.
In einer Ausführungsform verwirklicht die PPU 300 eine mehrstufige Speicherhierarchie. In einer Ausführungsform unterstützt die Speicherteileinheit 380 einen vereinheitlichten Speicher, um einen einzigen vereinheitlichten virtuellen Adressraum für CPU- und PPU 300-Speicher bereitzustellen, der einen Datenaustausch zwischen virtuellen Speichersystemen ermöglicht. In einer Ausführungsform wird die Häufigkeit der Zugriffe einer PPU 300 auf Speicher auf anderen Prozessoren verfolgt, um sicherzustellen, dass Speicherseiten in den physikalischen Speicher der PPU 300 verschoben werden, die häufiger auf die Seiten zugreift. In einer Ausführungsform unterstützt der NVLink 310 Adressübersetzungsdienste, die es der PPU 300 ermöglichen, direkt auf die Seitentabellen einer CPU zuzugreifen und einen vollen Zugriff auf einen CPU-Speicher durch die PPU 300 ermöglichen.
In einer Ausführungsform übertragen Kopiereinheiten Daten zwischen mehreren PPU 300 oder zwischen PPU 300 und CPU. Die Kopiereinheiten können Seitenfehler für Adressen erzeugen, die nicht in den Seitentabellen abgebildet sind. Die Speicherteileinheit 380 kann dann die Seitenfehler bedienen, die Adressen in die Seitentabelle zuordnen, woraufhin die Kopiereinheit den Transfer durchführen kann. In einem herkömmlichen System ist der Speicher für mehrfache Kopiereinheiten-Operationen zwischen mehreren Prozessoren fixiert (d.h. nicht auslagerbar), was den verfügbaren Speicher erheblich reduziert. Mit Hardware-Seitenfehlern können Adressen an die Kopiermaschinen weitergegeben werden, ohne sich Sorgen machen zu müssen, ob die Speicherseiten vorliegen, und der Kopiervorgang ist transparent.
Daten aus dem Speicher 304 oder einem anderen Systemspeicher können durch die Speicherteileinheit 380 abgerufen und im L2-Cache 460 gespeichert werden, der chipintern vorgesehen ist und zwischen den verschiedenen GPC 350 geteilt wird. Wie dargestellt umfasst jede Speicherteileinheit 380 einen Abschnitt des L2-Cache 460, der einer entsprechenden Speichervorrichtung 304 zugeordnet ist. Untergeordnete Caches können dann in verschiedenen Einheiten innerhalb der GPC 350 verwirklicht werden. So kann beispielsweise jeder der SM 440 einen Stufe-1-(L1)-Cache verwirklichen. Der L1-Cache ist ein privater Speicher, der einem bestimmten SM 440 zugeordnet ist. Daten aus dem L2-Cache 460 können abgerufen und in jedem der L1-Caches zur Verarbeitung in den Funktionseinheiten des SM 440 gespeichert werden. Der L2-Cache 460 ist mit der Speicherschnittstelle 470 und dem Koppelfeld 370 gekoppelt.
Die ROP-Einheit 450 führt grafische Rasteroperationen im Zusammenhang mit Pixelfarben durch, wie z.B. Farbkompression, Pixelverschnitt und dergleichen. Die ROP-Einheit 450 verwirklicht auch eine Tiefenprüfung in Verbindung mit der Rastereinheit 425, die eine Tiefe für eine Sampleposition empfängt, die einem Pixelfragment aus der Ausleseeinheit der Rastereinheit 425 zugeordnet ist. Die Tiefe wird gegen eine entsprechende Tiefe in einem Tiefenpuffer für eine dem Fragment zugeordnete Sampleposition geprüft. Wenn das Fragment die Tiefenprüfung für die Sampleposition besteht, aktualisiert die ROP-Einheit 450 den Tiefenpuffer und überträgt ein Ergebnis der Tiefenprüfung an die Rastereinheit 425. Es wird anerkannt werden, dass die Anzahl der Speicherteileinheiten 380 von der Anzahl der GPC 350 abweichen kann und daher jede ROP-Einheit 450 mit jedem der GPC 350 gekoppelt werden kann. Die ROP-Einheit 450 verfolgt die von den verschiedenen GPC 350 empfangenen Pakete und bestimmt, zu welchem GPC 350 ein von der ROP-Einheit 450 erzeugtes Ergebnis durch das Koppelfeld 370 geleitet wird. Obwohl die ROP-Einheit 450 in 4B in der Speicherteileinheit 380 inbegriffen ist, kann sich die ROP-Einheit 450 in anderer Ausführungsform außerhalb der Speicherteileinheit 380 befinden. Beispielsweise kann sich die ROP-Einheit 450 im GPC 350 oder in einer anderen Einheit befinden.
5A veranschaulicht den Streaming-Multiprozessor 440 von 4A in Übereinstimmung mit einer Ausführungsform. Wie in 5A dargestellt umfasst der SM 440 einen Befehlscache 505, eine oder mehrere Ablaufplanungseinheiten 510, eine Registerdatei 520, einen oder mehrere Rechenkerne 550, eine oder mehrere Spezialfunktionseinheiten (SFU) 552, eine oder mehrere Lade-/Speichereinheiten (LSU) 554, ein Verbindungsnetzwerk 580, einen gemeinsamen Speicher/L1-Cache 570.
Wie zuvor beschrieben fertigt die Arbeitsverteilungseinheit 325 Aufgaben zur Ausführung auf den GPC 350 der PPU 300 ab. Die Aufgaben sind einem bestimmten DPC 420 innerhalb eines GPC 350 zugeordnet und, wenn die Aufgabe mit einem Shaderprogramm in Zusammenhang steht ist, kann die Aufgabe einem SM 440 zugeordnet werden. Die Ablaufplanungseinheit 510 empfängt die Aufgaben von der Arbeitsverteilungseinheit 325 und verwaltet eine Befehlsablaufplanung für einen oder mehrere der der SM 440 zugeordneten Thread-Blöcke. Die Ablaufplanungseinheit 510 plant Thread-Blöcke zur Ausführung als Warps paralleler Threads, wobei jedem Thread-Block mindestens ein Warp zugeordnet ist. In einer Ausführungsform führt jeder Warp 32 Threads aus. Die Ablaufplanungseinheit 510 kann eine Vielzahl von verschiedenen Thread-Blöcken verwalten, indem sie die Warps den verschiedenen Thread-Blöcken zuordnet und dann während jedem Taktzyklus Anweisungen von der Vielzahl von verschiedenen kooperativen Gruppen an die verschiedenen Funktionseinheiten (d.h. Kerne 550, SFU 552 und LSU 554) abfertigt.
Cooperative Groups ist ein Programmiermodell zur Organisation von Gruppen kommunizierender Threads, das es Entwicklern ermöglicht, die Granularität auszudrücken, mit der Threads kommunizieren, was den Ausdruck reichhaltigerer, effizienterer paralleler Zerlegungen ermöglicht. Kooperative Start-APIs unterstützen eine Synchronisation zwischen Thread-Blöcken zur Ausführung paralleler Algorithmen. Herkömmliche Programmiermodelle bieten ein einziges, einfaches Konstrukt zur Synchronisation kooperierender Threads: eine Barriere über alle Threads eines Thread-Blöcken (d.h. die syncthreads() Funktion). Programmierer möchten jedoch oft Gruppen von Threads definieren, die kleiner sind als die Thread-Block-Granularität, und innerhalb der definierten Gruppen synchronisieren, um mehr Leistung, Designflexibilität und Softwarewiederverwendung in Form von gemeinsamen gruppenweiten Funktionsschnittstellen zu ermöglichen.
Cooperative Groups ermöglicht es Programmierern, Gruppen von Threads explizit in Subblock- (d.h. so klein wie ein einzelner Thread) und Multiblock-Granularitäten zu definieren und kollektive Operationen wie eine Synchronisation der Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt eine saubere Zusammensetzung über Softwaregrenzen hinweg, so dass Bibliotheken und Dienstprogramm-Funktionen sicher in ihrem lokalen Kontext synchronisieren können, ohne Konvergenzannahmen treffen zu müssen. Cooperative Groups Grundelemente ermöglichen neue Muster kooperativer Parallelität, einschließlich Produzenten-Verbraucher-Parallelität, opportunistischer Parallelität und globaler Synchronisation über ein ganzes Raster von Thread-Blöcken.
Eine Abfertigungseinheit 515 ist dazu eingerichtet, Anweisungen an eine oder mehrere der Funktionseinheiten zu senden. In der Ausführungsform umfasst die Ablaufplanungseinheit 510 zwei Abfertigungseinheiten 515, die es ermöglichen, während jedem Taktzyklus zwei verschiedene Anweisungen von demselben Warp abzufertigen. In alternativen Ausführungsformen kann jede Ablaufplanungseinheit 510 eine einzelne Abfertigungseinheit 515 oder zusätzliche Abfertigungseinheiten 515 aufweisen.
Jeder SM 440 weist eine Registerdatei 520 auf, die einen Satz von Registern für die Funktionseinheiten des SM 440 bereitstellt. In einer Ausführungsform ist die Registerdatei 520 so auf jede der Funktionseinheiten aufgeteilt, dass jeder Funktionseinheit ein eigener Abschnitt der Registerdatei 520 zugeordnet ist. In einer weiteren Ausführungsform wird die Registerdatei 520 auf die verschiedenen Warps aufgeteilt, die von dem SM 440 ausgeführt werden. Die Registerdatei 520 bietet Zwischenspeicher für Operanden, die mit den Datenpfaden der Funktionseinheiten verbunden sind.
Jeder SM 440 umfasst L Verarbeitungskerne 550. In einer Ausführungsform umfasst der SM 440 eine große Anzahl (z.B. 128, etc.) von eigenständigen Verarbeitungskernen 550. Jeder Kern 550 kann eine einfachpräzise, doppelpräzise und/oder gemischtpräzise Verarbeitungseinheit mit vollständigem Pipelining aufweisen, die eine Gleitkommaarithmetik-Logikeinheit und eine Ganzzahlarithmetik-Logikeinheit umfasst. In einer Ausführungsform verwirklichen die Gleitkommaarithmetik-Logikeinheiten den Standard IEEE 754-2008 für Gleitkommaarithmetik. In einer Ausführungsform weisen die Kerne 550 64 einfachpräzise (32-Bit) Gleitkommakerne, 64 Ganzzahlkerne, 32 doppelpräzise (64-Bit) Gleitkommakerne und 8 Tensorkerne auf.
Tensorkerne sind dazu eingerichtet, Matrixoperationen durchzuführen, und in einer Ausführungsform weisen die Kerne 550 ein oder mehrere Tensorkerne auf. Insbesondere sind die Tensorkerne dazu eingerichtet, Deep-Learning-Matrixarithmetik durchzuführen, wie z.B. Faltungsoperationen für ein Training und ein Folgern neuronaler Netze. In einer Ausführungsform arbeitet jeder Tensorkern auf einer 4×4-Matrix und führt eine Matrixmultiplikations- und -additionsoperation D=A×B+C durch, wobei A, B, C und D 4x4-Matrizen sind.
In einer Ausführungsform sind die Matrixmultiplikationseingaben A und B 16-Bit Fließkomma-Matrizen, wobei die Additionsmatrizen C und D 16-Bit-Fließkomma- oder 32-Bit-Fließkomma-Matrizen sein können. Tensorkerne arbeiten mit 16-Bit-Gleitkomma-Eingabedaten mit 32-Bit-Gleitkommaaddition. Die 16-Bit-Fließkomma-Multiplikation erfordert 64 Operationen und führt zu einem hochpräzisen Produkt, das dann unter Verwendung der 32-Bit-Fließkommaaddition mit den anderen Zwischenprodukten für eine 4x4x4-Matrix-Multiplikation akkumuliert wird. In der Praxis werden Tensorkerne verwendet, um viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchzuführen, die sich aus diesen kleineren Elementen zusammensetzen. Eine API wie die CUDA 9 C++ API stellt spezialisierte Matrixpopulations-, Matrixmultiplikations- und -akkumulationssowie Matrixspeicheroperationen bereit, um Tensor-Kerne aus einem CUDA-C++-Programm heraus effizient zu nutzen. Auf der CUDA-Ebene geht die Warp-Ebenen-Schnittstelle von Matrizen der Größe 16x 16 aus, die alle 32 Threads des Warps umfassen.
Jeder SM 440 umfasst auch M SFU 552, die spezielle Funktionen ausführen (z.B. Attributauswertung, reziproke Quadratwurzel und dergleichen). In einer Ausführungsform können die SFU 552 eine Baumdurchlaufeinheit aufweisen, die dazu eingerichtet ist, eine hierarchische Baumdatenstruktur zu durchlaufen. In einer Ausführungsform können die SFU 552 eine Textureinheit aufweisen, die dazu eingerichtet ist, Texturkartenfilteroperationen durchzuführen. In einer Ausführungsform sind die Textureinheiten dazu eingerichtet, Texturkarten (z.B. ein 2D-Feld von Elementarmustern / Texel) aus dem Speicher 304 zu laden und die Texturkarten abzutasten, um abgetastete Texturwerte für die Verwendung in vom SM 440 ausgeführten Shaderprogrammen zu erzeugen. In einer Ausführungsform werden die Texturkarten in dem gemeinsamen Speicher/L1-Cache 470 gespeichert. Die Textureinheiten verwirklichen Texturoperationen wie z.B. Filteroperationen mit Hilfe von Mip-Maps (d.h. Texturkarten mit unterschiedlichem Detaillierungsgrad). In einer Ausführungsform umfasst jeder SM 440 zwei Textureinheiten. In einer Ausführungsform ist mindestens eine der SFU 552 dazu eingerichtet, mindestens eine Instanz der Grafikverarbeitungspipeline 200 aus 2A zu umfassen.
Jeder SM 440 umfasst auch N LSU 554, die Lade- und Speicheroperationen zwischen dem gemeinsamen Speicher/L1-Cache 570 und der Registerdatei 520 verwirklichen. Jeder SM 440 umfasst ein Verbindungsnetzwerk 580, das jede der Funktionseinheiten mit der Registerdatei 520 und die LSU 554 mit der Registerdatei 520, gemeinsamen Speicher/L1 Cache 570 verbindet. In einer Ausführungsform ist das Verbindungsnetzwerk 580 ein Koppelnetz, das dazu eingerichtet sein kann, eine der Funktionseinheiten mit einem der Register in der Registerdatei 520 zu verbinden und die LSU 554 mit der Registerdatei und den Speicherplätzen im gemeinsamen Speicher/L1-Cache 570 zu verbinden.
Der gemeinsame Speicher/Ll Cache 570 ist ein Feld von chipinternem Speicher, das eine Datenspeicherung und Kommunikation zwischen dem SM 440 und der Grundelementeeinheit 435 sowie zwischen den Threads in dem SM 440 ermöglicht. In einer Ausführungsform umfasst der gemeinsame Speicher/L1-Cache 570 128KB Speicherkapazität und ist auf dem Pfad von dem SM 440 zur Speicherteileinheit 380 vorgesehen. Der gemeinsame Speicher/L1-Cache 570 kann zum zwischenspeichern von Lese- und Schreibzugriffen verwendet werden. Einer oder mehrere der gemeinsamen Speicher/L1-Cache 570, L2-Cache 460 und Speicher 304 sind Backup-Speicher.
Eine Kombination von Daten-Cache und gemeinsamer Speicherfunktionalität in einem einzigen Speicherblock bietet die beste Gesamtleistung für beide Arten von Speicherzugriffen. Die Kapazität ist als Cache für Programme nutzbar, die keinen gemeinsamen Speicher verwenden. Wenn beispielsweise der gemeinsame Speicher so eingerichtet ist, dass er die Hälfte der Kapazität nutzt, können Textur- und Lade-/Speicheroperationen die verbleibende Kapazität nutzen. Eine Integration in den gemeinsamen Speicher/L1-Cache 570 ermöglicht es dem gemeinsamen Speicher/L1-Cache 570, als Hochdurchsatzleitung für ein Streaming von Daten zu fungieren und gleichzeitig einen breitbandigen und latenzarmen Zugriff auf häufig wiederverwendete Daten zu ermöglichen.
Bei Konfiguration für Allzweck-Parallelberechnungen kann im Vergleich zur Grafikverarbeitung eine einfachere Konfiguration verwendet werden. Insbesondere werden die in 3 dargestellten Festfunktionsgrafikverarbeitungseinheiten umgangen, was ein wesentlich einfacheres Programmiermodell schafft. In der Allzweck-Parallelberechnungs-Konfiguration werden die Thread-Blöcke durch die Arbeitsverteilungseinheit 325 direkt den DPC 420 zugewiesen und an diese verteilt. Die Threads in einem Block führen das gleiche Programm aus, wobei eine eindeutige Thread-ID in der Berechnung verwendet wird, um sicherzustellen, dass jeder Thread einzigartige Ergebnisse erzeugt, wobei der SM 440 verwendet wird, um das Programm auszuführen und Berechnungen durchzuführen, gemeinsamer Speicher/L1-Cache 570, um zwischen Threads zu kommunizieren, und die LSU 554, um den globalen Speicher über den gemeinsamen Speicher/L1-Cache 570 und die Speicherteileinheit 380 auszulesen und zu beschreiben. Wenn der SM 440 für eine Allzweck-Parallelberechnung eingerichtet ist, kann er auch Befehle schreiben, mit denen die Ablaufplanungseinheit 320 neue Arbeiten auf den DPC 420 starten kann.
Die PPU 300 kann in einem Desktop-Rechner, einem Laptop-Rechner, einem Tablet-Rechner, Servern, Superrechnern, einem Smartphone (z.B. einer drahtlosen, tragbaren Vorrichtung), einem persönlichen digitalen Assistenten (PDA), einer Digitalkamera, einem Fahrzeug, einer am Kopf befestigten Anzeige, einer tragbaren elektronischen Vorrichtung und dergleichen integriert werden. In einer Ausführungsform ist die PPU 300 auf einem einzigen Halbleitersubstrat ausgeführt. In einer weiteren Ausführungsform ist die PPU 300 zusammen mit einer oder mehreren anderen Vorrichtungen, wie zusätzlichen PPU 300, dem Speicher 204, einer CPU mit reduziertem Befehlssatz (RISC), einer Speicherverwaltungseinheit (MMU), einem Digital-Analog-Wandler (DAC) und dergleichen, in einem System auf einem Chip (SoC) umfasst.
In einer Ausführungsform kann die PPU 300 in einer Grafikkarte umfasst sein, die eine oder mehrere Speichervorrichtungen 304 umfasst. Die Grafikkarte kann so eingerichtet sein, dass sie mit einem PCIe-Steckplatz auf einer Hauptkarte eines Desktop-Rechners verbunden ist. In noch einer weiteren Ausführungsform kann die PPU 300 eine integrierte Grafikverarbeitungseinheit (iGPU) oder ein paralleler Prozessor sein, der im Chipsatz der Hauptkarte enthalten ist.
Beispielhaftes Rechensystem
Systeme mit mehreren GPU und CPU werden in einer Vielzahl von Branchen eingesetzt, da Entwickler mehr Parallelität in Anwendungen wie künstlicher Intelligenz bereitstellen und nutzen. Leistungsstarke GPU-beschleunigte Systeme mit Zehntausenden von Rechenknoten werden in Rechenzentren, Forschungseinrichtungen und Superrechnern eingesetzt, um immer größere Probleme zu lösen. Mit zunehmender Anzahl von Verarbeitungsvorrichtungen innerhalb der Hochleistungssysteme müssen die Kommunikations- und Datenübertragungsmechanismen skalieren, um die erhöhte Bandbreite zu unterstützen.
5B ist ein Konzeptdiagramm eines unter Verwendung der PPU 300 von 3 und in Übereinstimmung mit einer Ausführungsform verwirklichten Verarbeitungssystems 500.
Das Verarbeitungssystem 500 kann eingerichtet sein, um das in 1A dargestellte Verfahren 100 zu verwirklichen. Das Verarbeitungssystem 500 umfasst eine CPU 530, ein Koppelfeld 510, und jeweils mehrere PPU 300 und entsprechende Speicher 304. Der NVLink 310 bietet Hochgeschwindigkeitskommunikationsverbindungen zwischen allen PPU 300. Obwohl eine bestimmte Anzahl von NVLink 310- und Interconnect 302-Verbindungen in 5B dargestellt ist, kann die Anzahl der Verbindungen zu jeder PPU 300 und der CPU 530 variieren. Das Koppelfeld 510 vermittelt zwischen der Verbindung 302 und der CPU 530. Die PPU 300, Speicher 304 und NVLinks 310 können auf einer einzigen Halbleiterplattform vorgesehen sein, um ein Parallelverarbeitungsmodul 525 zu bilden. In einer Ausführungsform unterstützt das Koppelfeld 510 zwei oder mehr Protokolle zum Vermitteln zwischen vielfältigen verschiedenen Verbindungen und/oder Verbindungen.
In einer weiteren (nicht dargestellten) Ausführungsform stellt der NVLink 310 eine oder mehrere Hochgeschwindigkeitskommunikationsverbindungen zwischen jeder der PPU 300 und der CPU 530 bereit sowie das Koppelfeld 510 vermittelt zwischen der Verbindung 302 und jeder der PPU 300. Die PPU 300, Speicher 304 und Verbindung 302 können auf einer einzigen Halbleiterplattform vorgesehen sein, um ein Parallelverarbeitungsmodul 525 zu bilden. In noch einer weiteren (nicht dargestellten) Ausführungsform stellt die Verbindung 302 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPU 300 und der CPU 530 bereit, und das Koppelfeld 510 vermittelt zwischen jeder der PPU 300, die den NVLink 310 verwendet, um eine oder mehrere Hochgeschwindigkeitskommunikationsverbindungen zwischen den PPU 300 bereitzustellen. In einer weiteren (nicht dargestellten) Ausführungsform stellt der NVLink 310 eine oder mehrere Hochgeschwindigkeitskommunikationsverbindungen zwischen den PPU 300 und der CPU 530 über das Koppelfeld 510 bereit. In noch einer weiteren (nicht dargestellten) Ausführungsform stellt die Verbindung 302 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPU 300 direkt zur Verfügung. Eine oder mehrere der NVLink 310 Hochgeschwindigkeitskommunikationsverbindungen können als physische NVLink-Verbindung oder als chipinterne oder plättcheninterne Verbindung unter Verwendung des gleichen Protokolls des NVLink 310 verwirklicht werden.
Im Sachzusammenhang der vorliegenden Beschreibung kann sich eine einzige Halbleiterplattform auf eine alleinige einheitliche halbleiterbasierte integrierte Schaltung beziehen, die auf einem Plättchen oder einem Chip hergestellt wird. Es ist zu beachten, dass sich der Begriff einzige Halbleiterplattform auch auf Mehrfachchipmodule mit erhöhter Konnektivität beziehen kann, die chipinternen Betrieb simulieren und wesentliche Verbesserungen gegenüber einer herkömmlichen Busimplementierung vornehmen. Natürlich können die verschiedenen Schaltungen oder Vorrichtungen auch einzeln oder in verschiedenen Kombinationen von Halbleiterplattformen nach den Wünschen des Benutzers angeordnet sein. Alternativ kann das Parallelverarbeitungsmodul 525 als ein Leiterplattensubstrat verwirklicht sein und jede der PPU 300 und/oder jeder Speicher 304 kann als eingehauste Vorrichtung ausgeführt sein. In einer Ausführungsform befinden sich die CPU 530, das Koppelfeld 510 und das Parallelverarbeitungsmodul 525 auf einer einzigen Halbleiterplattform.
In einer Ausführungsform beträgt die Signalübertragungsrate jeden NVLink 310 20 bis 25 Gigabit/Sekunde und jede PPU 300 umfasst sechs NVLink 310-Schnittstellen (wie in 5B dargestellt, sind fünf NVLink 310-Schnittstellen für jede PPU 300 enthalten). Jeder NVLink 310 bietet eine Datenübertragungsrate von 25 Gigabyte/Sekunde in jede Richtung, wobei sechs Links 300 Gigabyte/Sekunde liefern. Die NVLinks 310 sind ausschließlich für die PPU-zu-PPU-Kommunikation verwendbar, wie 5B zeigt, oder für eine Kombination aus PPU-zu-PPU und PPU-zu-CPU, wenn die CPU 530 auch eine oder mehrere NVLink 310-Schnittstellen umfasst.
In einer Ausführungsform ermöglicht der NVLink 310 einen direkten Lade-/Speicher-/Atomzugriffvon der CPU 530 auf den Speicher 304 jeder PPU 300. In einer Ausführungsform unterstützt der NVLink 310 Kohärenzoperationen, welche ermöglichen, dass aus den Speichern 304 ausgelesene Daten in der Cache-Hierarchie der CPU 530 gespeichert werden können, wodurch eine Cache-Zugriffslatenz für die CPU 530 reduziert wird. In einer Ausführungsform umfasst der NVLink 310 eine Unterstützung von Adressübersetzungsdiensten (ATS), so dass die PPU 300 direkt auf Seitentabellen innerhalb der CPU 530 zugreifen kann. Einer oder mehrere der NVLinks 310 können auch für den Betrieb in einem Energiesparmodus eingerichtet sein.
5C veranschaulicht ein exemplarisches System 565, in dem die vielfältige Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen verwirklicht sein kann. Das exemplarische System 565 kann dazu eingerichtet sein, das in 1A dargestellte Verfahren 100 zu verwirklichen.
Wie dargestellt wird ein System 565 bereitgestellt, das mindestens eine Zentralverarbeitungseinheit 530 umfasst, die mit einem Kommunikationsbus 575 verbunden ist. Der Kommunikationsbus 575 kann mit jedem geeigneten Protokoll verwirklicht werden, wie z.B. PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), HyperTransport oder jedem anderen Bus- oder Punkt-zu-Punkt- Kommunikationsprotokoll(en). Das System 565 umfasst auch einen Hauptspeicher 540. Eine Steuerlogik (Software) und Daten werden in dem Hauptspeicher 540 gespeichert, der als Speicher mit wahlfreiem Zugriff (RAM) ausgeführt sein kann.
Das System 565 umfasst ferner die Eingabevorrichtungen 560, das Parallelverarbeitungssystem 525 und die Anzeigevorrichtungen 545, d.h. eine herkömmliche CRT (Kathodenstrahlröhre), LCD (Flüssigkristallanzeige), LED (Leuchtdiode), Plasmaanzeige oder dergleichen. Benutzereingaben können von den Eingabegeräten 560 empfangen werden, z.B. Tastatur, Maus, Touchpad, Mikrofon und dergleichen. Jedes der vorgenannten Module und/oder Vorrichtungen kann sich sogar auf einer einzigen Halbleiterplattform befinden, um das System 565 zu bilden. Alternativ können die verschiedenen Module auch einzeln oder in verschiedenen Kombinationen von Halbleiterplattformen nach den Wünschen des Anwenders angeordnet sein.
Weiterhin kann das System 565 über eine Netzwerkschnittstelle 535 zu Kommunikationszwecken mit einem Netzwerk (z.B. Telekommunikationsnetzwerk, Lokalnetzwerk (LAN), Drahtlosnetzwerk, Weitverkehrsnetzwerk (WAN) wie das Internet, Peer-to-Peer-Netzwerk, Kabelnetzwerk oder dergleichen) gekoppelt sein.
Das System 565 kann ohne Einschränkung auch einen (nicht dargestellten) Sekundärspeicher aufweisen. Der Sekundärspeicher 610 umfasst beispielsweise ein Festplattenlaufwerk und/oder ein Wechseldatenträgerlaufwerk, der ein magnetisches oder optisches Plattenlaufwerk, ein Magnetbandlaufwerk, ein CD-Laufwerk, ein DVD-Laufwerk, ein Aufzeichnungsgerät, einen USB-Flashspeicher verkörpert. Das Wechseldatenträgerlaufwerk liest und/oder schreibt in bekannter Weise von einer / auf eine Wechseldatenträgereinheit.
Rechnerprogramme oder Rechnersteuerlogikalgorithmen können im Hauptspeicher 540 und/oder im Sekundärspeicher gespeichert werden. Bei Ausführung ermöglichen solche Rechnerprogramme dem System 565, verschiedene Funktionen wahrzunehmen. Der Hauptspeicher 540, der Massenspeicher und/oder jeder andere Speicher sind mögliche Beispiele für rechnerlesbare Medien.
Die Architektur und/oder Funktionalität der vielfältigen vorherigen Figuren kann im Sachzusammenhang eines allgemeinen Rechnersystems, eines Platinensystems, eines Spielkonsolensystems für Unterhaltungszwecke, eines anwendungsspezifischen Systems und/oder eines anderen gewünschten Systems verwirklicht werden. Das System 565 kann beispielsweise in Form eines Desktop-Rechners, eines Laptop-Rechners, eines Tablet-Rechners, Servern, Superrechnern, eines Smartphones (z.B. einer drahtlosen tragbaren Vorrichtung), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, einer am Kopf befestigten Anzeige, einer tragbaren elektronischen Vorrichtung, einer Mobiltelefonvorrichtung, eines Fernsehers, einer Arbeitsstation, Spielkonsolen, eines eingebetteten Systems und/oder einer anderen Art von Logik ausgeführt sein.
Grafikverarbeitungspipeline
In einer Ausführungsform umfasst die PPU 300 eine Grafikverarbeitungseinheit (GPU). Die PPU 300 ist dazu eingerichtet, Befehle zu empfangen, welche Shaderprogramme zur Verarbeitung von Bilddaten angeben. Grafikdaten können als ein Satz von Grundelementen wie etwa Punkte, Linien, Dreiecke, Quads, Dreiecksstreifen und dergleichen definiert werden. Typischerweise umfasst ein Grundelement Daten, die eine Anzahl von Punkten für das Grundelement angeben (z.B. in einem Modellraum-Koordinatensystem) sowie mit jedem Punkt des Grundelements im Zusammenhang stehende Attribute. Die PPU 300 kann dazu eingerichtet sein, die Grafikgrundelemente zu verarbeiten, um einen Framepuffer zu erzeugen (d.h. Pixeldaten für jedes der Pixel der Anzeige).
Eine Anwendung schreibt Modelldaten für eine Szene (d.h. eine Sammlung von Punkten und Attributen) in einen Speicher, wie beispielsweise einen Systemspeicher oder Speicher 304. Die Modelldaten definieren jedes der Objekte, die auf einer Anzeige sichtbar sein können. Die Anwendung führt dann einen API-Aufruf an den Treiberkern durch, der eine Darstellung und Anzeige der Modelldaten beantragt. Der Treiberkern liest die Modelldaten und schreibt Befehle in einen oder mehrere Ströme, um Operationen zur Verarbeitung der Modelldaten durchzuführen. Die Befehle können auf verschiedene Shaderprogramme Bezug nehmen, die auf den SM 440 der PPU 300 verwirklicht werden sollen, einschließlich eines oder mehrerer Punkt-Shader, Rumpf-Shader, Domain-Shader, Geometrie-Shader und Pixel-Shader. So kann beispielsweise einer oder mehrere der SM 440 dazu eingerichtet sein, ein Punkt-Shader-Programm auszuführen, das eine Anzahl von durch die Modelldaten definierten Punkten verarbeitet. In einer Ausführungsform können die verschiedenen SM 440 dazu eingerichtet sein, verschiedene Shaderprogramme gleichzeitig auszuführen. So kann beispielsweise eine erste Teilmenge von SM 440 eingerichtet werden, um ein Punkt-Shader-Programm auszuführen, während eine zweite Teilmenge von SM 440 eingerichtet werden kann, um ein Pixel-Shader-Programm auszuführen. Die erste Teilmenge des SM 440 verarbeitet Punktdaten, um verarbeitete Punktdaten zu erzeugen, und schreibt die verarbeiteten Punktdaten in den L2-Cache 460 und/oder den Speicher 304. Nachdem die verarbeiteten Punktdaten gerastert sind (d.h. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum umgewandelt wurden), um Fragmentdaten zu erzeugen, führt die zweite Teilmenge von SM 440 einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten verschnitten und in den Framepuffer im Speicher 304 geschrieben werden. Das Punktshader-Programm und das Pixelshader-Programm können gleichzeitig ablaufen und verschiedene Daten aus derselben Szene in einem Pipeline-Ansatz verarbeiten, bis alle Modelldaten für die Szene in den Framepuffer übertragen wurden. Anschließend wird der Inhalt des Framepuffers an eine Anzeigesteuerung zur Anzeige auf einer Anzeigevorrichtung übertragen.
6 ist ein Konzeptdiagramm einer durch die PPU 300 aus 3 und in Übereinstimmung mit einer Ausführungsform verwirklichte Grafikverarbeitungspipeline 600. Die Grafikverarbeitungspipeline 600 ist ein abstraktes Flussdiagramm der verwirklichten Verarbeitungsschritte zur Erzeugung von rechnererzeugten 2D-Bildern aus 3D-Geometriedaten. Bekanntermaßen können Pipeline-Architekturen Operationen mit langen Latenzzeiten effizienter durchführen, indem sie den die Operation in eine Vielzahl von Stufen aufteilen, wobei der Ausgang jeder Stufe mit dem Eingang der nächsten nachfolgenden Stufe gekoppelt ist. Somit empfängt die Grafikverarbeitungspipeline 600 Eingabedaten 601, die von einer Stufe zur nächsten Stufe der Grafikverarbeitungspipeline 600 übertragen werden, um Ausgabedaten 602 zu erzeugen. In einer Ausführungsform kann die Grafikverarbeitungspipeline 600 eine durch die OpenGL®-API definierte Grafikverarbeitungspipeline bilden. Optional kann die Grafikverarbeitungspipeline 600 im Sachzusammenhang der Funktionalität und Architektur der vorherigen Figuren und/oder jeder nachfolgenden Figur(en) verwirklicht werden.
Wie in 6 dargestellt umfasst die Grafikverarbeitungspipeline 600 eine Pipelinearchitektur, die mehrere Stufen umfasst. Die Stufen umfassen, ohne darauf beschränkt zu sein, eine Datenbildungsstufe 610, eine Punktshadingstufe 620, eine Grundelementbildungsstufe 630, eine Geometrieshadingstufe 640, eine Ansichtsfenster-Skalierungs-, Auslese- und Kappungs-(SCC)-Stufe 650, eine Rasterstufe 660, eine Fragmentshadingstufe 670 und eine Rasteroperationsstufe 680. In einer Ausführungsform umfassen die Eingabedaten 601 Befehle, die die Verarbeitungseinheiten so einrichten, dass sie die Stufen der Grafikverarbeitungspipeline 600 und geometrische Grundelemente (z.B. Punkte, Linien, Dreiecke, Vierecke, Quads, Dreiecksstreifen oder Fächer usw.) verwirklichen, die von den Stufen verarbeitet werden sollen. Die Ausgabedaten 602 können Pixeldaten (d.h. Farbdaten) umfassen, die in einen Framepuffer oder eine andere Art von Oberflächendatenstruktur in einem Speicher kopiert werden.
Die Datenbildungsstufe 610 empfängt die Eingabedaten 601, welche Punktdaten für Oberflächen hoher Ordnung, Grundelemente oder dergleichen spezifizieren. Die Datenbildungsstufe 610 sammelt die Punktdaten in einem Zwischenspeicher oder einer Warteschlange, beispielsweise durch Empfangen eines Befehls vom Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher aufweist, und Lesen der Punktdaten aus dem Puffer. Die Punktdaten werden dann zur Verarbeitung an die Punktshadingstufe 620 übertragen.
Die Punktshadingstufe 620 verarbeitet Punktdaten, indem sie eine Reihe von Operationen (z.B. einen Punktshader oder ein Programm) einmal für jeden der Punkte durchführt. Punkte können z.B. als 4-Koordinaten-Vektor (d.h. <x, y, z, w>) angegeben werden, der mit einem oder mehreren Punktattributen (z.B. Farbe, Texturkoordinaten, Oberflächennormale, etc.) im Zusammenhang steht. Die Punktshadingstufe 620 kann einzelne Punktattribute wie Position, Farbe, Texturkoordinaten und dergleichen manipulieren. Mit anderen Worten führt die Punktshadingstufe 620 Operationen an den Punktkoordinaten oder anderen Punktattributen durch, die mit einem Punkt im Zusammenhang stehen. Solche Operationen weisen üblicherweise Beleuchtungsoperationen auf (d.h. ein Ändern von Farbattributen für einen Punkt) und Transformationsoperationen (d.h. ein Ändern des Koordinatenraums für einen Punkt). So können beispielsweise Punkte durch Koordinaten in einem Objektkoordinatenraum spezifiziert werden, die durch Multiplikation der Koordinaten mit einer Matrix transformiert werden, die die Koordinaten aus dem Objektkoordinatenraum in einen Weltraum oder einen normierten Vorrichungskoordinatenraum (NCD) übersetzt. Die Punktshadingstufe 620 erzeugt transformierte Punktdaten, die an die Grundelementbildungsstufe 630 übertragen werden.
Die Grundelementbildungsstufe 630 sammelt von der Punktshadingstufe 620 ausgegebene Punkte und gruppiert die Punkte zu geometrischen geometrischen Grundelementen für eine Verarbeitung durch die Geometrieshadingstufe 640. So kann beispielsweise die Grundelementbildungsstufe 630 dazu eingerichtet sein, jeweils drei aufeinanderfolgende Punkte als geometrisches Grundelement (d.h. ein Dreieck) zur Übertragung an die Geometrieshadingstufe 640 zu gruppieren. In einigen Ausführungsformen können bestimmte Punkte für aufeinanderfolgende geometrische Grundelemente wiederverwendet werden (z.B. können zwei aufeinanderfolgende Dreiecke in einem Dreieckstreifen zwei Punkte teilen). Die Grundelementbildungsstufe 630 überträgt geometrische Grundelemente (d.h. eine Sammlung von zusammengehörigen Punkten) an die Geometrieshadingstufe 640.
Die Geometrieshadingstufe 640 verarbeitet geometrische Grundelemente, indem sie einen Satz von Operationen (d.h. einen Geometrieshader oder ein Programm) auf den geometrischen Grundelementen durchführt. Tessellierungsoperationen können aus jedem geometrischen Grundelement ein oder mehrere geometrische Grundelemente erzeugen. Mit anderen Worten kann die Geometrieshadingstufe 640 jedes geometrische Grundelement in ein feineres Netz von zwei oder mehr geometrischen Grundelementen unterteilen, die zur Verarbeitung durch den Rest der Grafikverarbeitungspipeline 600 vorgesehen sind. Die Geometrieshadingstufe 640 überträgt geometrische Grundelemente an die Ansichtsfenster-SCC-Stufe 650.
In einer Ausführungsform kann die Grafikverarbeitungspipeline 600 innerhalb eines Streaming-Multiprozessors betrieben werden und die Punktshadingstufe 620, die Grundelementbildungsstufe 630, die Geometrieshadingstufe 640, die Fragmentshadingstufe 670 und/oder die damit verbundene Hard- und Software können nacheinander Aufgaben durchführen. Sobald die aufeinanderfolgenden Aufgaben abgeschlossen sind, kann in einer Ausführungsform die Ansichtsfenster-SCC-Stufe 650 die Daten verwenden. In einer Ausführungsform können Grundelementdaten, die von einer oder mehreren Stufen der Grafikverarbeitungspipeline 600 verarbeitet werden, in einen Cache geschrieben werden (z.B. L1-Cache, Punktcache, etc.). In diesem Fall kann die Ansichtsfenster-SCC-Stufe 650 in einer Ausführungsform auf die Daten im Cache zugreifen. In einer Ausführungsform sind die Ansichtsfenster-SCC-Stufe 650 und die Rasterstufe 660 als Festfunktionsschaltung verwirklicht.
Die Ansichtsfenster-SCC-Stufe 650 führt eine Skalierung, eine Auslese und eine Kappung der geometrischen Grundelemente durch. Jede Oberfläche, auf die wiedergegeben wird, steht mit einer abstrakten Kameraposition im Zusammenhang. Die Kameraposition stellt eine Position eines Betrachters dar, der die Szene betrachtet, und definiert einen Sichtfeld, der die Objekte der Szene umschließt. Der Sichtfeld kann eine Betrachtungsebene, eine hintere Ebene und vier Kappungsebenen aufweisen. Jedes geometrische Grundelement, das sich vollständig außerhalb des Sichtfeldes befindet, kann aussortiert (d.h. verworfen) werden, da das geometrische Grundelement nicht zur endgültigen wiedergegebenen Szene beiträgt. Jedes geometrische Grundelement, das sich teilweise innerhalb des Sichtfeldes und teilweise außerhalb des Sichtfeldes befindet, kann gekappt werden (d.h. in ein neues geometrisches Grundelement umgewandelt werden, das sich innerhalb des Sichtfeldes befindet). Darüber hinaus können geometrische Grundelemente jeweils auf der Grundlage einer Tiefe des Sichtfeldes skaliert werden. Alle potenziell sichtbaren geometrischen Grundelemente werden dann an die Rasterstufe 660 übertragen.
Die Rasterstufe 660 wandelt die geometrischen 3D-Grundelemente in 2D-Fragmente um (z.B. für Darstellung nutzbar, usw.). Die Rasterstufe 660 kann dazu eingerichtet sein, die Punkte der geometrischen Grundelemente zu nutzen, um einen Satz von Ebenengleichungen zu bilden, aus welchen verschiedene Attribute interpolierbar sind
Die Rasterstufe 660 kann auch eine Abdeckungsmaske für eine Vielzahl von Pixeln berechnen, die angibt, ob eine oder mehrere Samplepositionen für das Pixel das geometrische Grundelement abfangen. In einer Ausführungsform kann auch ein Z-Test durchgeführt werden, um zu bestimmen, ob das geometrische Grundelement durch andere geometrische Grundelemente, die bereits gerastert wurden, verdeckt wird. Die Rasterstufe 660 erzeugt Fragmentdaten (d.h. interpolierte Punktattribute, die mit einer bestimmten Sampleposition für jedes abgedeckte Pixel in Zusammenhang stehen), die an die Fragmentshadingstufe 670 übertragen werden.
Fragmentshadingstufe 670 verarbeitet Fragmentdaten, indem sie eine Reihe von Operationen (z.B. einen Fragmentshader oder ein Programm) an jedem der Fragmente durchführt. Die Fragmentshadingstufe 670 kann Pixeldaten (d.h. Farbwerte) für das Fragment erzeugen, z.B. durch Beleuchtungsoperationen oder Abtasten von Texturkarten unter Verwendung interpolierter Texturkoordinaten für das Fragment. Die Fragmentshadingstufe 670 erzeugt Pixeldaten, die an die Rasteroperationsstufe 680 übertragen werden.
Die Rasteroperationsstufe 680 kann verschiedene Operationen an den Pixeldaten durchführen, wie z.B. Alpha-Tests, Schablonentests und ein Verschneiden der Pixeldaten mit anderen Pixeldaten, die anderen dem Pixel zuzuordnenden Fragmenten entspechen. Wenn die Rasteroperationsstufe 680 die Verarbeitung der Pixeldaten (d.h. der Ausgabedaten 602) abgeschlossen hat, können die Pixeldaten in ein Wiedergabeziel wie einen Framepuffer, einen Farbpuffer oder dergleichen geschrieben werden.
Es wird anerkannt werden, dass zusätzlich zu oder anstelle einer oder mehrerer der vorstehend beschriebenen Stufen eine oder mehrere zusätzliche Stufen in die Grafikverarbeitungspipeline 600 aufgenommen sein können. Verschiedene Implementierungen der abstrakten Grafikverarbeitungspipeline können verschiedene Stufen verwirklichen. Darüber hinaus kann in einigen Ausführungsformen eine oder mehrere der vorstehend beschriebenen Stufen (z.B. Geometrieshadingstufe 640) von der Grafikverarbeitungspipeline ausgeschlossen sein. Andere Arten von Grafikverarbeitungspipelines werden als im Bereich der vorliegenden Offenbarung liegend betrachtet. Darüber hinaus kann jede der Stufen der Grafikverarbeitungspipeline 600 durch eine oder mehrere dedizierte Hardwareeinheiten innerhalb eines Grafikprozessors wie der PPU 300 verwirklicht werden. Weitere Stufen der Grafikverarbeitungspipeline 600 können durch programmierbare Hardwareeinheiten wie den SM 440 der PPU 300 realisiert werden.
Die Grafikverarbeitungspipeline 600 kann über eine Anwendung verwirklicht werden, die von einem Host-Prozessor, wie beispielsweise einer CPU, ausgeführt wird. In einer Ausführungsform kann ein Gerätetreiber eine Anwendungsprogrammierschnittstelle (API) verwirklichen, die vielfältige Funktionen definiert, die von einer Anwendung verwendet werden können, um grafische Daten für eine Anzeige zu erzeugen. Der Gerätetreiber ist ein Softwareprogramm, das eine Vielzahl von Anweisungen aufweist, die den Betrieb der PPU 300 steuern. Die API bietet eine Abstraktion für einen Programmierer, welche es einem Programmierer ermöglicht, spezielle Grafikhardware wie die PPU 300 zu verwenden, um die grafischen Daten zu erzeugen, ohne dass der Programmierer den spezifischen Befehlssatz für die PPU 300 verwenden muss. Die Anwendung kann einen API-Aufruf aufweisen, der an den Gerätetreiber für die PPU 300 weitergeleitet wird. Der Gerätetreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu reagieren. In einigen Fällen kann der Gerätetreiber Operationen ausführen, indem er Anweisungen auf der CPU ausführt. In anderen Fällen kann der Gerätetreiber zumindest teilweise Operationen durchführen, indem er Operationen auf der PPU 300 über eine Ein-/Ausgabeschnittstelle zwischen der CPU und der PPU 300 startet. In einer Ausführungsform ist der Gerätetreiber dazu eingerichtet die Grafikverarbeitungspipeline 600 unter Verwendung der Hardware der PPU 300 zu verwirklichen.
Innerhalb der PPU 300 können verschiedene Programme ausgeführt werden, um die verschiedenen Stufen der Grafikverarbeitungspipeline 600 zu verwirklichen. So kann beispielsweise der Gerätetreiber einen Kernel auf der PPU 300 starten, um die Punktshadingstufe 620 auf einem SM 440 (oder mehreren SM 440) auszuführen. Der Gerätetreiber (oder der anfängliche Kernel, der von der PPU 400 ausgeführt wird) kann auch andere Kernel auf der PPU 400 starten, um andere Stufen der Grafikverarbeitungspipeline 600 auszuführen, wie z.B. die Geometrieshadingstufe 640 und die Fragmentshadingstufe 670. Darüber hinaus können einige der Stufen der Grafikverarbeitungspipeline 600 auf fester Einheitshardware wie einem Rasterer oder einem innerhalb der PPU 400 verwirklichten Datenbildner verwirklicht werden. Es wird anerkannt werden, dass die Ergebnisse eines Kernels von einer oder mehreren zwischenliegenden Festfunktionshardwareeinheiten verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 440 verarbeitet werden.
Obwohl verschiedene Ausführungsformen vorstehend beschrieben wurden, sollten verstanden werden, dass diese nur als Beispiel und nicht als Einschränkung dargestellt wurden. Daher sollten Breite und Umfang der vorliegenden Anmeldung nicht durch eine der oben beschriebenen exemplarischen Ausführungsformen eingeschränkt werden, sondern nur in Übereinstimmung mit den folgenden und später eingereichten Ansprüchen und deren Äquivalenten definiert werden.

Claims

Verfahren, umfassend: Empfangen von grundelementspezifischen Attributdaten durch einen Fragmentshader; Bestimmen eines Attributdatenformats, das mit den grundelementspezifischen Attributdaten im Zusammenhang steht; und Auswerten, durch den Fragmentshader, einer Ebenengleichung, die ein Grundelement definiert, um samplespezifische Attributwerte zu berechnen, wenn das Attributdatenformat anzeigt, dass die grundelementspezifischen Attributdaten Ebenengleichungskoeffizienten umfassen; oder Auswerten, durch den Fragmentshader, einer baryzentrisch-basierten Gleichung, die das Grundelement definiert, um die samplespezifischen Attributwerte zu berechnen, wenn das Attributdatenformat anzeigt, dass die grundelementspezifischen Attributdaten punktspezifische Attribute und Ebenengleichungskoeffizienten für baryzentrische Gewichte umfassen.
Verfahren nach Anspruch 1, wobei eine Anwendungsprogrammierschnittstelle (API) eine Reihenfolge für Punkte angibt, die das Grundelement definieren, und die grundelementspezifischen Attributdaten für jeden Punkt des Grundelements von dem Fragmentshader in der Reihenfolge empfangen werden.
Verfahren nach Anspruch 1 oder Anspruch 2, wobei eine Anwendungsprogrammierschnittstelle (API) eine Reihenfolge für Punkte angibt, die das Grundelement an einer geraden Position innerhalb eines Dreieckstreifens definieren, und die grundelementspezifischen Attributdaten für jeden Punkt des Grundelements von dem Fragmentshader in der Reihenfolge empfangen werden.
Verfahren nach einem der Ansprüche 1 bis 3, wobei eine Anwendungsprogrammierschnittstelle (API) eine Reihenfolge für Punkte angibt, die das Grundelement an einer ungeraden Position innerhalb eines Dreieckstreifens definieren, und die grundelementspezifischen Attributdaten für jeden Punkt des Grundelements von dem Fragmentshader in einer umgedrehten Reihenfolge empfangen werden, die einen Umlaufsinn innerhalb des Dreieckstreifens beibehält.
Verfahren nach einem der Ansprüche 1 bis 4, wobei das Attributdatenformat eine Anzahl von Bits anzeigt, die Elemente innerhalb der grundelementspezifischen Attributdaten darstellen.
Verfahren nach Anspruch 5, wobei das Datenformat ein Einfachpräzisions- oder Doppelpräzisionsgleitkommaformat ist.
Verfahren nach Anspruch 5, wobei das Datenformat ein Festkommaformat oder ein Ganzzahlformat ist.
Verfahren nach einem der Ansprüche 5 bis 7, wobei das Datenformat ein gepacktes Format anzeigt, das zwei oder mehr Werte angibt, die in einem Wort gespeichert sind.
Verfahren nach einem der Ansprüche 1 bis 8, wobei ein Bestimmen des Attributdatenformats auf einem Attributkennzeichner für das Grundelement basiert.
Verfahren nach einem der Ansprüche 1 bis 9, ferner umfassend: Auswerten, durch den Fragmentshader, eines baryzentrischen Wertes basierend auf den Ebenengleichungskoeffizienten für die baryzentrischen Gewichte; und Berechnen, durch den Fragmentshader, eines Abstands von einem Punkt innerhalb des Grundelements zu einer nächsten Kante des Grundelements basierend auf der Punktposition und den Ebenengleichungskoeffizienten für die baryzentrischen Gewichte, wobei der Abstand gleich einer Quadratwurzel aus einer Summe von Ebenengleichungskoeffizienten für die baryzentrischen Gewichte ist, dividiert durch den baryzentrischen Wert.
Verfahren nach einem der Ansprüche 1 bis 10, wobei das Grundelement eine Linie angibt und eines der baryzentrischen Gewichte auf Null gesetzt wird.
Parallelprozessor, umfassend: einen Fragmentshader, der eingerichtet ist zum: Empfangen von grundelementspezifischen Attributdaten; Bestimmen eines Attributdatenformats, das mit den grundelementspezifischen Attributdaten im Zusammenhang steht; und Auswerten einer Ebenengleichung, die ein Grundelement definiert, um samplespezifische Attributwerte zu berechnen, wenn das Attributdatenformat anzeigt, dass die grundelementspezifischen Attributdaten Ebenengleichungskoeffizienten umfassen; oder Auswerten einer baryzentrisch-basierten Gleichung, die das Grundelement definiert, um die samplespezifischen Attributwerte zu berechnen, wenn das Attributdatenformat anzeigt, dass die grundelementspezifischen Attributdaten punktspezifische Attribute und Ebenengleichungskoeffizienten für baryzentrische Gewichte umfassen.
Parallelprozessor nach Anspruch 12, wobei der Parallelprozessor ferner einen Dreiecks-Wahlzugriffsspeicher (TRAM) umfasst, der mit dem Fragmentshader gekoppelt ist und die grundelementspezifischen Attributdaten in dem TRAM gespeichert sind.
Parallelprozessor nach Anspruch 13, wobei die in dem TRAM gespeicherten grundelementspezifischen Attributdaten Ebenengleichungskoeffizienten und punktspezifische Attribute umfassen.
Parallelprozessor nach einem der Ansprüche 12 bis 14, der ferner dazu eingerichtet ist, das Verfahren nach einem der Ansprüche 2-11 durchzuführen.
Nichtflüchtiges, rechnerlesbares Speichermedium, das Anweisungen speichert, die, wenn sie von einem Multiprozessorsystem ausgeführt werden, einen innerhalb des Multiprozessorsystems ausführenden Fragmentshader veranlassen zum: Empfangen von grundelementspezifischen Attributdaten; Bestimmen eines Attributdatenformats, das mit den grundelementspezifischen Attributdaten im Zusammenhang steht; und Auswerten einer Ebenengleichung, die ein Grundelement definiert, um samplespezifische Attributwerte zu berechnen, wenn das Attributdatenformat anzeigt, dass die grundelementspezifischen Attributdaten Ebenengleichungskoeffizienten umfassen; oder Auswerten einer baryzentrisch-basierten Gleichung, die das Grundelement definiert, um die samplespezifischen Attributwerte zu berechnen, wenn das Attributdatenformat anzeigt, dass die grundelementspezifischen Attributdaten punktspezifische Attribute und Ebenengleichungskoeffizienten für baryzentrische Gewichte umfassen.
Verfahren, umfassend: Empfangen von baryzentrischen Ebenengleichungskoeffizienten für ein Dreiecksgrundelement durch einen Fragmentshader; Auswerten eines baryzentrischen Wertes basierend auf den baryzentrischen Ebenengleichungskoeffizienten durch den Fragmentshader; und Berechnen eines Abstands von einem Punkt innerhalb des Dreiecksgrundelements zu einer nächsten Kante des Dreiecksgrundelements basierend auf der Punktposition und den baryzentrischen Ebenengleichungskoeffizienten durch den Fragmentshader, wobei der Abstand gleich einer Quadratwurzel aus einer Summe von baryzentrischen Ebenengleichungskoeffizienten ist, dividiert durch den baryzentrischen Wert.