DE102017109472A1

DE102017109472A1 - Stereo-mehrfach-projektion implementiert unter verwendung einer graphikverarbeitungs-pipeline

Info

Publication number: DE102017109472A1
Application number: DE102017109472.5A
Authority: DE
Inventors: Ziyad Sami Hakura; Eric B. Lum; Henry Packard Moreton
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2016-05-05
Filing date: 2017-05-03
Publication date: 2017-11-09
Also published as: CN107392836B; CN107392836A; US20170323469A1; US10068366B2

Abstract

Ein Verfahren, ein computerlesbares Medium und ein System werden zum Erzeugen von Mehrfach-Ansicht-Bilddaten offenbart. Das Verfahren umfasst die Schritte einer Verarbeitung von Primitivendaten eines Modells, um verarbeitete Primitivendaten zu erzeugen, die mehrere Positionsvektoren für jeden Vertex in den Primitivendaten umfassen, wobei die Anzahl von Positionsvektoren, die jedem Vertex zugeordnet sind, gleich der Anzahl von Ansichten in mindestens zwei Ansichten ist, die erzeugt werden. Das Verfahren umfasst ferner Speichern der verarbeiteten Primitivendaten in einem Puffer. Schließlich können die verarbeiteten Primitivendaten aus dem Puffer für jede Ansicht in den mindestens zwei Ansichten gelesen und an eine Raster-Pipeline übertragen werden, um Bilddaten zu erzeugen, die einer bestimmten Ansicht entsprechen.

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft Graphikverarbeitung und insbesondere das Erzeugen von Bilddaten für Mehrfach-Ansichts-Anwendungen.
HINTERGRUND
Anwendungen der virtuellen Realität (VR) etablieren sich stärker, wobei sie sich von spezialisierten Hardwarearchitekturen zu herkömmlichen Tischgeräten mittels Vorrichtungen, wie die Oculus-VR-Headsets, bewegen. VR-Headsets benutzen unterschiedliche Ansichten, die auf unterschiedliche Augen des Benutzers projiziert werden, um die Illusion von Tiefe zu erzeugen. Wie herkömmliche Computeranwendungen können Bilddaten zur Anzeige auf diesen Vorrichtungen in Echtzeit durch verschiedene Anwendungen erzeugt werden. Eine Graphikverarbeitungseinheit (GPU) oder andere spezialisierte Graphikhardware kann von der Anwendung benutzt werden, um komplexere Geometrie zu verarbeiten, um realistischere Bilder zu erzeugen.
Eine GPU kann mindestens einen Teil einer Graphikverarbeitungs-Pipeline implementieren, um dreidimensionale Graphikdaten effizient zu verarbeiten, um Pixeldaten zu erzeugen, die auf der Anzeigevorrichtung anzuzeigen sind. Herkömmlicherweise werden Primitivendaten (d. h. Daten für ein zu renderndes Modell) in die Spitze der Graphikverarbeitungs-Pipeline eingegeben. Die Primitivendaten werden sequentiell von einer Anzahl von Stufen der Graphikverarbeitungs-Pipeline verarbeitet, welche schließlich die Primitivendaten in Pixeldaten umwandelt, die ein spezifisches Bild des Modells aus einer bestimmten virtuellen Kameraposition definieren. Weil stereoskopische Bilder, wie diejenigen, die in VR-Headsets angezeigt werden, zwei unterschiedliche Ansichten erfordern, die von zwei unterschiedlichen Kamerapositionen erzeugt werden, müssen zwei unterschiedliche Bilder von der Graphikverarbeitungs-Pipeline erzeugt werden.
Herkömmlicherweise würde das Erzeugen von zwei Ansichten aus unterschiedlichen virtuellen Kamerapositionen von der Anwendung verlangen, die Primitivendaten für das Modell in die Graphikverarbeitungs-Pipeline zweimal – einmal für jede Ansicht – einzugeben. Das zweimalige Eingeben der Primitivendaten in die Graphikverarbeitungs-Pipeline erfordert jedoch ungefähr die zweifache Zeit, um die Daten zu verarbeiten und zwei Ansichten zu erzeugen. Das Erzeugen von Mehrfach-Ansicht-Bilddaten auf diese Art und Weise ist ineffizient, weil es sein kann, dass viele Stufen der Graphikverarbeitungs-Pipeline die gleichen Berechnungen zweimal durchführen. Somit gibt es einen Bedarf, sich diesen Problemen und/oder anderen Problemen zu widmen, die dem Stand der Technik zugeordnet sind.
ZUSAMMENFASSUNG
Ein Verfahren, ein computerlesbares Medium und ein System werden zum Erzeugen von Mehrfach-Ansicht-Bilddaten offenbart. Das Verfahren umfasst die Schritte einer Verarbeitung von Primitivendaten eines Modells, um verarbeitete Primitivendaten zu erzeugen, die mehrere Positionsvektoren für jeden Vertex in den Primitivendaten umfassen, wobei die Anzahl von Positionsvektoren, die jedem Vertex zugeordnet sind, gleich der Anzahl von Ansichten in mindestens zwei Ansichten ist, die erzeugt werden. Das Verfahren umfasst ferner Speichern der verarbeiteten Primitivendaten in einem Puffer. Schließlich können die verarbeiteten Primitivendaten aus dem Puffer für jede Ansicht in den mindestens zwei Ansichten gelesen und an eine Raster-Pipeline übertragen werden, um Bilddaten zu erzeugen, die einer bestimmten Ansicht entsprechen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1A veranschaulicht ein Ablaufdiagramm eines Verfahrens zum Erzeugen von Mehrfach-Projektions-Stereobilddaten gemäß einer Ausführungsform;
1B veranschaulicht ein Ablaufdiagramm eines Verfahrens zum Erzeugen von Bilddaten für eine ausgewählte Ansicht gemäß einer Ausführungsform;
2 veranschaulicht eine Parallelverarbeitungseinheit (PPU) gemäß einer Ausführungsform;
3A veranschaulicht einen allgemeinen Verarbeitungscluster der PPU von 2 gemäß einer Ausführungsform;
3B veranschaulicht eine Partitions-Einheit der PPU von 2 gemäß einer Ausführungsform;
4 veranschaulicht den Streaming-Multiprozessor von 3A gemäß einer Ausführungsform;
5 veranschaulicht ein System-on-Chip, das die PPU von 2 umfasst, gemäß einer Ausführungsform;
6 ist ein Konzeptdiagramm einer Graphikverarbeitungs-Pipeline, die von der PPU von 2 implementiert wird, gemäß einer Ausführungsform;
7 ist ein Konzeptdiagramm einer Graphikverarbeitungs-Pipeline, die von der PPU von 2 implementiert wird, gemäß einer anderen Ausführungsform;
8 ist ein Konzeptdiagramm einer modifizierten Graphikverarbeitungs-Pipeline gemäß einer Ausführungsform;
9 ist ein Konzeptdiagramm einer Datenstruktur zum Speichern von Vertexdaten im Puffer gemäß einer Ausführungsform;
10 veranschaulicht eine Abbildung von Ansichten auf Render-Ziele gemäß einer Ausführungsform; und
11 veranschaulicht ein beispielhaftes System, in dem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann.
AUSFÜHRLICHE BESCHREIBUNG
1A veranschaulicht ein Ablaufdiagramm eines Verfahrens 100 zum Erzeugen von Mehrfach-Projektions-Stereobilddaten gemäß einer Ausführungsform. Es wird anerkannt, dass das Verfahren 100 innerhalb des Schutzumfangs von Software beschrieben wird, die von einem Prozessor ausgeführt wird; in einigen Ausführungsformen kann das Verfahren 100 jedoch in Hardware oder einer Kombination aus Hardware und Software implementiert sein. Das Verfahren 100 beginnt bei Schritt 102, wo eine Graphikverarbeitungs-Pipeline konfiguriert wird, um Primitivendaten für ein Modell gemäß mindestens zwei Ansichten zu rendern. Jede Ansicht kann einem oder mehreren Darstellungsfeldern zugeordnet sein. Jede Ansicht kann einer unterschiedlichen virtuellen Kameraposition entsprechen, die benutzt wird, um ein Modell zu rendern, das durch die Primitivendaten definiert wird. Die Primitivendaten können eine Anzahl von Datenstrukturen für geometrische Primitive (z. B., Linien, Dreiecke, Vierecke, Dreieckfächer, Dreieckstreifen, Patches, usw.) umfassen. Jede geometrische Primitive kann eine Anzahl von Vertices umfassen, wobei jeder Vertex eine Mehrzahl von Vertexattributen zugeordnet ist. In einer Ausführungsform ist die Graphikverarbeitungs-Pipeline konfiguriert, um Primitivendaten für zwei Ansichten zu rendern, wobei jede Ansicht sechs Darstellungsfeldern zugeordnet wird, wobei jedes Darstellungsfeld einer Fläche einer Würfelabbildung entspricht.
Bei Schritt 104 empfängt die Graphikverarbeitungs-Pipeline die Primitivendaten für das Modell. In einer Ausführungsform benutzt eine von einem Host-Prozessor ausgeführte Anwendung eine API, die durch einen Vorrichtungstreiber für eine Parallelverarbeitungseinheit implementiert wird. Der Vorrichtungstreiber übersetzt die API-Aufrufe, um einen Datenstrom zu erzeugen, der an die Parallelverarbeitungseinheit übertragen wird. Der Datenstrom kann Befehle zum Konfigurieren verschiedener Hardwareeinheiten der parallelen Verarbeitungseinheit umfassen, um verschiedene Teile der Graphikverarbeitungs-Pipeline sowie auch Primitivendaten zu implementieren, die von der Graphikverarbeitungs-Pipeline zu verarbeiten sind.
Bei Schritt 106 verarbeitet die Graphikverarbeitungs-Pipeline die Primitivendaten. Mindestens zwei Positionsvektoren werden für jeden Vertex der Primitivendaten erzeugt, wobei jeder Positionsvektor in den mindestens zwei Positionsvektoren einer bestimmten Ansicht in den mindestens zwei Ansichten entspricht. Die Primitivendaten können verarbeitet und mehrere Positionsvektoren durch eine beliebige Stufe in einer beliebigen Kombination des Vertex-Shading, des Tessellations-Shading, und der Geometrie-Shading-Stufen, die durch die Graphikverarbeitungs-Pipeline implementiert werden, erzeugt werden.
In einer Ausführungsform wird die Geometrie-Shading-Stufe von einem Streaming-Multiprozessor implementiert, der einen Geometrie-Shader ausführt (d. h. ein Programm, das konfiguriert ist, um durch eine programmierbare Einheit der parallelen Verarbeitungseinheit ausgeführt zu werden), der Anweisungen umfasst, die Positionsvektoren für jede Ansicht der mindestens zwei Ansichten für jeden Vertex erzeugen. Beispielsweise kann der Geometrie-Shader einen Positionsvektor erzeugen, der eine x-Koordinate, eine y-Koordinate, eine z-Koordinate und eine w-Koordinate (z. B. <x, y, z, w>) für einen Vertex für jede Ansicht der mindestens zwei Ansichten umfasst. Die unterschiedlichen Positionsvektoren können basierend auf unterschiedlichen virtuellen Kamerapositionen erzeugt werden, wie durch die Anwendung definiert. In einem stereoskopischen System sind die unterschiedlichen virtuellen Kamerapositionen typischerweise konfiguriert, um näherungsweise mit dem Abstand zwischen den Augenpositionen eines Betrachters übereinzustimmen, wie horizontal symmetrisch zu einer zentralen vertikalen Ebene eines Kopfes eines Betrachters verschoben.
In einer anderen Ausführungsform kann Tessellation von einer Hull-Shading-Stufe, einer Tessellationsstufe und einer Domain-Shading-Stufe durchgeführt werden. In derartigen Ausführungsformen wird die Domain-Shading-Stufe durch einen Streaming-Multiprozessor implementiert, der einen Domain-Shader ausführt, der Anweisungen umfasst, die mehrere Positionsvektoren für jeden Vertex entsprechend jeder Ansicht der mindestens zwei Ansichten erzeugen. In noch einer anderen Ausführungsform wird eine Vertex-Shading-Stufe von einem Streaming-Multiprozessor implementiert, der einen Vertex-Shader ausführt, der Anweisungen umfasst, die mehrere Positionsvektoren für jeden Vertex entsprechend jeder Ansicht der mindestens zwei Ansichten erzeugen.
Bei Schritt 108 werden die verarbeiteten Primitivendaten in einem Puffer in einem Speicher gespeichert. Die verarbeiteten Primitivendaten können eine Datenstruktur für jeden Vertex umfassen, die mehrere Positionsvektoren umfasst, die jeder Ansicht der mindestens zwei Ansichten entsprechen. Die Graphikverarbeitungs-Pipeline weist eine Darstellungsfeld-Skalierungs(scale)-, Aussonderungs(cull)- und Abschneide(clipping)-Stufe (Darstellungsfeld-SCC-Stufe) auf, die konfiguriert sein kann, um die verarbeiteten Primitivendaten in einem Puffer unter Verwendung einer Datenausgabefunktion der Darstellungsfeld-SCC-Stufe zu speichern, so dass die geometrischen Primitivendaten an die Raster-Pipeline (d. h. den Stufen der Graphikverarbeitungs-Pipeline, die Rasterung und Pixel- oder Fragment-Shading umfassen) mehrere Male übertragen werden können, wobei die Graphikprimitiven an die Raster-Pipeline einmal für jede Ansicht übertragen werden.
Bei Schritt 110 wird eine bestimmte Ansicht der mindestens zwei Ansichten ausgewählt. In einer Ausführungsform werden stereoskopische Bilddaten erzeugt, was bedeutet, dass es zwei Ansichten gibt. In einer derartigen Ausführungsform kann eine Darstellungsfeld-SCC-Stufe entweder die erste Ansicht oder die zweite Ansicht auswählen, um die Bilddaten für ein Bild des linken Auges oder die Bilddaten für ein Bild des rechten Auges zu erzeugen. Bei Schritt 112 werden Bilddaten für die ausgewählte Ansicht unter Benutzung eine Raster-Pipeline erzeugt. Die Primitivendaten, die der ausgewählten Ansicht entsprechen, können aus dem Puffer durch die Darstellungsfeld-SCC-Stufe der Graphikverarbeitungs-Pipeline gelesen und an eine Raster-Pipeline übertragen werden, um die Bilddaten zu erzeugen. Die Raster-Pipeline kann eine Anzahl von Stufen in der Graphikverarbeitungs-Pipeline umfassen, die konfiguriert ist, um die verarbeiteten Primitivendaten in 2D-Bilddaten umzuwandeln. Die Stufen, die in der Raster-Pipeline umfasst sind, können eine Rasterungsstufe, eine Fragment-Shading-Stufe und eine Raster-Operationen-Stufe umfassen. Schritte 110 und 112 können für jede Ansicht der mindestens zwei Ansichten wiederholt werden.
1B veranschaulicht ein Ablaufdiagramm eines Verfahrens 120 zum Erzeugen von Bilddaten für eine ausgewählte Ansicht gemäß einer Ausführungsform. Schritte 110 und 112 des Verfahrens 100 können durch die Darstellungsfeld-SCC-Stufe der Graphikverarbeitungs-Pipeline verwaltet und mindestens teilweise durch die verschiedenen Stufen der Raster-Pipeline implementiert werden. Schritt 112 kann durch die diskreten Schritte implementiert werden, die im Verfahren 120 von 1B veranschaulicht sind.
Bei Schritt 122 werden Primitivendaten aus dem Puffer basierend auf der ausgewählten Ansicht ausgelesen. In einer Ausführungsform liest die Darstellungsfeld-SCC-Stufe die Primitivendaten aus dem Puffer, wobei die Positionsvektoren für die Vertices ausgewählt werden, die der ausgewählten Ansicht entsprechen. Mit anderen Worten wird, obwohl die in dem Puffer gespeicherten Primitivendaten mehrere Positionsvektoren für jeden Vertex der Primitive umfassen, die Darstellungsfeld-SCC-Stufe die Primitivendaten lesen, als ob die Primitivendaten lediglich einen Positionsvektor für jeden Vertex der Primitive umfassen, wobei die Positionsvektoren, die gelesen werden, der ausgewählten Ansicht entsprechen, die verarbeitet wird. Die unterschiedlichen Positionsvektoren können als Vertexattribute in der Datenstruktur für den Vertex zusammen mit anderen Ansichts-abhängigen und Ansichts-unabhängigen Attributen gespeichert werden. Wenn Primitivendaten aus dem Puffer für eine bestimmte Ansicht gelesen werden, werden die Primitivendaten alle Ansichts-unabhängigen Attribute sowie auch Ansichts-abhängigen Attribute umfassen, die der bestimmten Ansicht entsprechen, und alle Ansichts-abhängigen Attribute weglassen, die den anderen Ansichten entsprechen.
Bei Schritt 124 werden die Primitivendaten an eine Raster-Pipeline übertragen, um Bilddaten zu erzeugen, die der ausgewählten Ansicht entsprechen. In einer Ausführungsform überträgt die Darstellungsfeld-SCC-Stufe die Primitivendaten an eine Rasterungsstufe der Graphikverarbeitungs-Pipeline, die eine erste Stufe der Raster-Pipeline ist. Bei Schritt 126 werden die Primitivendaten verarbeitet, um Fragmente für jede Primitive zu erzeugen. Die Rasterungsstufe der Graphikverarbeitungs-Pipeline kann die Primitivendaten in eine Mehrzahl von Fragmenten umwandeln, die an eine Fragment-Shading-Stufe der Graphikverarbeitungs-Pipeline übertragen werden. Bei Schritt 128 werden die Fragmente verarbeitet, um Bilddaten für die ausgewählte Ansicht zu erzeugen. Die Fragment-Shading-Stufe und/oder Raster-Operationen-Stufe der Raster-Pipeline können endgültige Pixelwerte für Bilddaten erzeugen, die der ausgewählten Ansicht entsprechen. Bei Schritt 130 werden die Bilddaten in einem Render-Ziel für die ausgewählte Ansicht gespeichert. Ein Render-Ziel kann ein Frame-Puffer (d. h. ein 2D-Array von Bilddaten) sein, der in einem Speicher zugeteilt ist. In einer Ausführungsform ist jede Ansicht einem bestimmten Render-Ziel zugeordnet, wobei mehrere Render-Ziele mehreren Ansichten entsprechen. In einer anderen Ausführungsform können Bilddaten für zwei oder mehr Ansichten in einem einzigen Render-Ziel in einer Seite-an-Seite Konfiguration gespeichert werden, wobei ein einziges Render-Ziel mehrere Ansichten entspricht.
Es wird anerkannt, dass die oben beschriebene Graphikverarbeitungs-Pipeline die Primitivendaten einmal für alle Ansichten der mindestens zwei Ansichten durch einen ersten Abschnitt der Pipeline verarbeitet und dann die Primitivendaten einmal für jede Ansicht der mindestens zwei Ansichten durch einen zweiten Abschnitt der Pipeline verarbeitet, um Bilddaten für jede Ansicht der mindestens zwei Ansichten zu erzeugen. Eine derartige Konfiguration ermöglicht einer Anwendung ohne Weiteres die Graphikverarbeitungs-Pipeline zu konfigurieren, um Mehrfach-Projektions-Ansichten, wie beispielsweise stereoskopische Bilder, unter Verwendung einfacher Konfigurationsbefehle zu erzeugen und dann die Primitivendaten, die für alle Ansichten verwendet werden, nur einmal an die Graphikverarbeitungs-Pipeline zu übertragen. Da eine Ansichts-unabhängige Verarbeitung nur einmal im ersten Teil der Graphikverarbeitungs-Pipeline durchgeführt wird, ist die oben beschriebene Technik außerdem effizienter als einfaches Zuführen der Primitivendaten in die Spitze der Graphikverarbeitungs-Pipeline mehrere Male, um Bilddaten für die unterschiedlichen Ansichten zu erzeugen.
Es wird ebenfalls anerkannt, dass in einigen Ausführungsformen die Arbeit von unterschiedlichen Ansichten verschachtelt sein kann. Mit anderen Worten kann die Graphikverarbeitungs-Pipeline die Arbeit von jeder Ansicht nicht streng serialisieren, um eine bestimmte Ansicht vollständig zu rendern, bevor ein Rendern für eine andere Ansicht begonnen wird. Beispielsweise können in Systemen, die Kacheln implementieren, Bilddaten für eine bestimmte Kachel für jede der mehrere Ansichten gerendert werden, bevor eine andere Kachel verarbeitet wird, wobei Bilddaten für die neue Kachel für jede der mehrere Ansichten gerendert werden.
Veranschaulichendere Information wird nun hinsichtlich verschiedener optionaler Architekturen und Merkmale dargelegt, mit denen das vorangehende Rahmenwerk gemäß den Wünschen des Benutzers implementiert werden kann oder nicht. Es sei nachdrücklich bemerkt, dass die folgende Information für veranschaulichende Zwecke dargelegt und nicht auf irgendeine Art und Weise als beschränkend ausgelegt wird. Beliebige der folgenden Merkmale können optional mit oder ohne Ausschluss anderer beschriebener Merkmale aufgenommen sein.
Parallelverarbeitungsarchitektur
2 veranschaulicht eine Parallelverarbeitungseinheit (PPU) 200 gemäß einer Ausführungsform. In einer Ausführungsform ist die PPU 200 ein Multi-Threaded-Prozessor bzw. mehrsträngiger Prozessor, der auf einer oder mehreren integrierten Schaltung Vorrichtungen implementiert ist. Die PPU 200 ist eine Latenzverbergende Architektur, die ausgestaltet ist, um eine große Anzahl von Threads bzw. Strängen parallel zu verarbeiten. Ein Thread bzw. Strang (d. h. ein Ausführungsthread) ist eine Instanziierung eines Satzes von Anweisungen, die konfiguriert sind, um von der PPU 200 ausgeführt zu werden. In einer Ausführungsform ist die PPU 200 eine Graphikverarbeitungseinheit (GPU), die konfiguriert ist, um eine Graphik-Rendering-Pipeline zur Verarbeitung von dreidimensionalen (3D) Graphikdaten zu implementieren, um zweidimensionale (2D) Bilddaten zur Anzeige auf einer Anzeigevorrichtung, wie beispielsweise einer Flüssigkristallanzeige(LCD)-Vorrichtung, zu erzeugen. In anderen Ausführungsformen kann die PPU 200 zum Durchführen von Allzweckberechnungen benutzt werden. Während ein beispielhafter paralleler Prozessor hier für veranschaulichende Zwecke bereitgestellt wird, sei nachdrücklich bemerkt, dass ein derartiger Prozessor lediglich für veranschaulichende Zwecke dargelegt wird, und dass ein beliebiger Prozessor benutzt werden kann, um dasselbe zu ergänzen und/oder zu ersetzen.
Wie in 2 gezeigt, umfasst die PPU 200 eine Eingabe/Ausgabe(E/A)-Einheit 205, eine Host-Schnittstelleneinheit 210, eine Frontend-Einheit 215, eine Planer-Einheit 220, eine Arbeitsverteilungs-Einheit 225, einen Hub 230, eine Kreuzschiene (Xbar) 270, einen oder mehrere allgemeine Verarbeitungscluster (GPCs) 250 und eine oder mehrere Partitions-Einheiten 280. Die PPU 200 kann mit einem Host-Prozessor oder anderen peripheren Vorrichtungen über einen Systembus 202 verbunden werden. Die PPU 200 kann ebenfalls mit einem lokalen Speicher verbunden werden, der eine Anzahl von Speichervorrichtungen 204 umfasst. In einer Ausführungsform kann der lokale Speicher eine Anzahl von Direktzugriffsspeicher(DRAM)-Vorrichtungen umfassen.
Die E/A-Einheit 205 ist konfiguriert, um Kommunikationen (d. h. Befehle, Daten, usw.) von einem Host-Prozessor (nicht gezeigt) über den Systembus 202 zu übertragen und zu empfangen. Die E/A-Einheit 205 kann mit dem Host-Prozessor direkt über den Systembus 202 oder durch eine oder mehrere Zwischenvorrichtungen, wie beispielsweise einer Speicherbrücke, kommunizieren. In einer Ausführungsform implementiert die E/A-Einheit 205 eine Umfangskomponenten-Zwischenverbindungsexpress(PCIe)-Schnittstelle für Kommunikationen über einen PCIe-Bus. In alternativen Ausführungsformen kann die E/A-Einheit 205 andere Arten von bekannten Schnittstellen zum Kommunizieren mit externen Vorrichtungen implementieren.
Die E/A-Einheit 205 ist mit einer Host-Schnittstelleneinheit 210 gekoppelt, die Pakete decodiert, die über den Systembus 202 empfangen wurden. In einer Ausführungsform stellen die Pakete Befehle dar, die konfiguriert sind, um die PPU 200 zu veranlassen, verschiedene Operationen durchzuführen. Die Host-Schnittstelleneinheit 210 überträgt die decodierten Befehle an verschiedene andere Einheiten der PPU 200, wie es die Befehle spezifizieren können. Beispielsweise können einige Befehle an die Frontend-Einheit 215 übertragen werden. Andere Befehle können an den Hub 230 oder andere Einheiten der PPU 200, wie beispielsweise eine oder mehrere Kopiermaschinen, einen Video-Codierer, einen Video-Decodierer, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt) übertragen werden. Mit anderen Worten ist die Host-Schnittstelleneinheit 210 konfiguriert, um Kommunikationen zwischen und unter den verschiedenen logischen Einheiten der PPU 200 weiterzuleiten.
In einer Ausführungsform codiert ein Programm, das von dem Host-Prozessor ausgeführt wird, einen Befehlsstrom in einem Puffer, welcher der PPU 200 Arbeitslasten zur Verarbeitung bereitstellt. Eine Arbeitslast kann eine Anzahl von Anweisungen und Daten umfassen, die von diesen Anweisungen zu verarbeiten sind. Der Puffer ist eine Region in einem Speicher, der von sowohl dem Host-Prozessor als auch der PPU 200 zugänglich ist (d. h. Lesen/Schreiben). Beispielsweise kann die Host-Schnittstelleneinheit 210 konfiguriert sein, um auf den Puffer in einem Systemspeicher, der mit dem Systembus 202 verbunden ist, über Speicheranfragen, die über den Systembus 202 übertragen werden, durch die E/A-Einheit 205 zuzugreifen. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und überträgt dann einen Zeiger an den Start des Befehlsstroms zu der PPU 200. Die Host-Schnittstelleneinheit 210 stellt der Frontend-Einheit 215 Zeiger auf einen oder mehrere Befehlsströme bereit. Die Frontend-Einheit 215 verwaltet den einen oder mehrere Ströme, wobei Befehle aus den Strömen gelesen und Befehle an die verschiedenen Einheiten der PPU 200 weitergeleitet werden. Die Frontend-Einheit 215 ist mit eine Planer-Einheit 220 gekoppelt, welche die verschiedenen GPCs 250 konfiguriert, um Aufgaben zu verarbeiten, die durch den einen oder mehrere Ströme definiert sind. Die Planer-Einheit 220 ist konfiguriert, um Zustandsinformation zu verfolgen, die verschiedene Aufgaben betrifft, die von der Planer-Einheit 220 verwaltet werden. Der Zustand kann angeben, welchem GPC 250 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, ob eine Prioritätsebene der Aufgabe zugeordnet ist und so weiter. Die Planer-Einheit 220 verwaltet die Ausführung einer Mehrzahl von Aufgaben auf dem einen oder mehreren GPCs 250.
Die Planer-Einheit 220 ist mit einer Arbeitsverteilungs-Einheit 225 gekoppelt, die konfiguriert ist, um Aufgaben zur Ausführung auf den GPCs 250 zu versenden. Die Arbeitsverteilungs-Einheit 225 kann eine Anzahl von eingeplanten Aufgaben verfolgen, die von der Planer-Einheit 220 empfangen werden. In einer Ausführungsform verwaltet die Arbeitsverteilungs-Einheit 225 einen Pool für anhängige Aufgaben und einen Pool für aktive Aufgaben für jeden der GPCs 250. Der Pool für anhängige Aufgaben kann eine Anzahl von Schlitzen (z. B. 32 Schlitze) umfassen, die Aufgaben enthalten, die zugewiesen sind, von einem bestimmten GPC 250 verarbeitet zu werden. Der Pool für aktive Aufgaben kann eine Anzahl von Schlitzen (z. B. 4 Schlitze) für Aufgaben umfassen, die von den GPCs 250 aktiv verarbeitet werden. Wenn ein GPC 250 die Ausführung einer Aufgabe abschließt, wird diese Aufgabe aus dem Pool für aktive Aufgaben für den GPC 250 geräumt und eine der anderen Aufgaben wird aus dem Pool für anhängige Aufgaben ausgewählt und zur Ausführung auf dem GPC 250 eingeplant. Wenn eine aktive Aufgabe auf dem GPC 250 inaktiv war, wie beispielsweise während darauf gewartet wird, dass eine Datenabhängigkeit behoben wird, dann kann die aktive Aufgabe aus dem GPC 250 geräumt und zu dem Pool für anhängige Aufgaben zurückgeführt werden, während eine andere Aufgabe in dem Pool für anhängige Aufgaben ausgewählt und zur Ausführung auf dem GPC 250 eingeplant wird.
Die Arbeitsverteilungs-Einheit 225 kommuniziert mit dem einen oder mehreren GPCs 250 über eine Kreuzschiene bzw. XBar 270. Die XBar 270 ist ein Zwischenverbindungs-Netzwerk, das viele der Einheiten der PPU 200 mit anderen Einheiten der PPU 200 koppelt. Beispielsweise kann die XBar 270 konfiguriert sein, um die Arbeitsverteilungs-Einheit 225 mit einem bestimmten GPC 250 zu koppeln. Obwohl nicht explizit gezeigt, sind eine oder mehrere andere Einheiten der PPU 200 mit der Host-Einheit 210 gekoppelt. Die anderen Einheiten können ebenfalls mit der XBar 270 über einen Hub 230 verbunden sein.
Die Aufgaben werden von der Planer-Einheit 220 verwaltet und an einen GPC 250 durch die Arbeitsverteilungs-Einheit 225 versendet. Der GPC 250 ist konfiguriert, um die Aufgabe zu verarbeiten und Ergebnisse zu erzeugen. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 250 verbraucht werden, an einen unterschiedlichen GPC 250 über die XBar 270 weitergeleitet oder im Speicher 204 gespeichert werden. Die Ergebnisse können in den Speicher 204 über die Partitions-Einheiten 280 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/aus dem Speicher 204 implementieren. In einer Ausführungsform umfasst die PPU 200 eine Anzahl U von Partitions-Einheiten 280, die gleich der Anzahl von separaten und unterschiedlichen Speichervorrichtungen 204 ist, die mit der PPU 200 gekoppelt sind. Eine Partitions-Einheit 280 wird nachstehend ausführlicher in Verbindung mit 3B beschrieben.
In einer Ausführungsform führt ein Host-Prozessor einen Treiber-Kernel aus, der eine Anwendungsprogrammier-Schnittstelle (API) implementiert, die ermöglicht einer oder mehreren Anwendungen ermöglicht, die auf dem Host-Prozessor ausgeführt werden, Operationen zur Ausführung auf der PPU 200 einzuplanen. Eine Anwendung kann Anweisungen (d. h. API-Aufrufe) erzeugen, welche den Treiber-Kernel veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die PPU 200 zu erzeugen. Der Treiber-Kernel gibt Aufgaben an einen oder mehrere Ströme aus, die von der PPU 200 verarbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen von in Beziehung stehenden Threads umfassen, die hier als ein Warp bezeichnet werden. Ein Thread-Block kann sich auf eine Mehrzahl von Gruppen von Threads beziehen, die Anweisungen umfassen, um die Aufgabe durchzuführen. Threads in der gleichen Gruppe von Threads können Daten durch einen gemeinsam benutzten Speicher austauschen. In einer Ausführungsform umfasst eine Gruppe von Threads 32 in Beziehung stehende Threads.
3A veranschaulicht einen GPC 250 der PPU 200 von 2 gemäß einer Ausführungsform. Wie in 3A gezeigt, umfasst jeder GPC 250 eine Anzahl von Hardwareeinheiten zur Verarbeitung von Aufgaben. In einer Ausführungsform umfasst jeder GPC 250 einen Pipeline-Manager 310, eine Vor-Raster-Operationen-Einheit (PROP) 315, eine Raster-Engine 325, eine Arbeitsverteilungs-Kreuzschiene (WDX) 380, eine Speicherverwaltungseinheit (MMU) 390 und einen oder mehrere Texturverarbeitungscluster (TPCs) 320. Es wird anerkannt, dass der GPC 250 von 3A andere Hardwareeinheiten anstatt von oder zusätzlich zu in 3A gezeigten Einheiten umfassen kann.
In einer Ausführungsform wird der Betrieb des GPC 250 durch den Pipeline-Manager 310 gesteuert. Der Pipeline-Manager 310 verwaltet die Konfiguration des einen oder mehrerer TPCs 320 zur Verarbeitung von Aufgaben, die dem GPC 250 zugeteilt sind. In einer Ausführungsform kann der Pipeline-Manager 310 mindestens einen des einen oder mehrerer TPCs 320 konfigurieren, um mindestens einen Abschnitt einer Graphik-Rendering-Pipeline zu implementieren. Beispielsweise kann ein TPC 320 konfiguriert sein, um ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 340 auszuführen. Der Pipeline-Manager 310 kann ebenfalls konfiguriert sein, um Pakete, die von der Arbeitsverteilungs-Einheit 225 empfangen werden, an die geeigneten logischen Einheiten innerhalb des GPC 250 weiterzuleiten. Beispielsweise können einige Pakete an Festfunktions-Hardwareeinheiten in der PROP 315 und/oder der Raster-Engine 325 weitergeleitet werden, während andere Pakete an die TPCs 320 zur Verarbeitung durch die Primitiven-Engine 335 oder den SM 340 weitergeleitet werden können.
Die PROP-Einheit 315 ist konfiguriert, um Daten, die von der Raster-Engine 325 und den TPCs 320 erzeugt werden, an eine Raster-Operationen-Einheit (ROP-Einheit) in der Partitions-Einheit 280 weiterzuleiten, die nachstehend ausführlicher beschrieben wird. Die PROP-Einheit 315 kann ebenfalls konfiguriert sein, um Optimierungen zur Farbenmischung durchzuführen, Pixeldaten zu organisieren, Adressenübersetzungen und dergleichen durchzuführen.
Die Raster-Engine 325 umfasst eine Anzahl von Festfunktions-Hardwareeinheiten, die konfiguriert sind, um verschiedene Raster-Operationen durchzuführen. In einer Ausführungsform umfasst die Raster-Engine 325 eine Setup-Engine, eine Grobraster-Engine, eine Aussonderungs-Engine, eine Abschneide-Engine, eine Feinraster-Engine und eine Kachel-verschmelzende-Engine. Die Setup-Engine empfängt transformierte Vertices und erzeugt Ebenengleichungen, die den geometrischen Primitiven zugeordnet sind, die durch die Vertices definiert werden. Die Ebenengleichungen werden an die Grobraster-Engine übertragen, um Abdeckungsinformation(z. B. eine (x, y)-Abdeckungsmaske für eine Kachel) für die Primitive zu erzeugen. Die Ausgabe der Grobraster-Engine kann an die Aussonderungs-Engine übertragen werden, wo Fragmente, die Primitiven zugeordnet sind, die einen z-Test nicht bestehen, ausgesondert und an eine Abschneide-Engine übertragen werden, wo Fragmente, die außerhalb eines Betrachtungsstumpfes liegen, abgeschnitten werden. Diejenigen Fragmente, die Abschneidung und Aussonderung überleben, können an eine Feinraster-Engine weitergeben werden, um Attribute für die Pixelfragmente basierend auf den Ebenengleichungen zu erzeugen, die durch die Setup-Engine erzeugt werden. Die Ausgabe der Raster-Engine 325 umfasst Fragmente, die beispielsweise von einem Fragment-Shader zu verarbeiten sind, der innerhalb eines TPC 320 implementiert ist.
Jeder TPC 320, der in dem GPC 250 umfasst ist, umfasst einen M-Pipe-Controller (MPC) 330, eine Primitiven-Engine 335, einen oder mehrere SMs 340 und eine oder mehrere Textureinheiten 345. Der MPC 330 steuert den Betrieb des TPC 320, der von dem Pipeline-Manager 310 empfangene Pakete an die geeigneten Einheiten im TPC 320 weiterleitet. Beispielsweise können einem Vertex zugeordnete Pakete an die Primitiven-Engine 335 weitergeleitet werden, die konfiguriert ist, um der Vertex zugeordnete Vertexattribute aus dem Speicher 204 zu holen. Im Gegensatz dazu können einem Shader-Programm zugeordnete Pakete an den SM 340 übertragen werden.
In einer Ausführungsform sind die Textureinheiten 345 konfiguriert, um Texturabbildungen (z. B., ein 2D-Array von Texeln) aus dem Speicher 204 zu laden und die Texturabbildungen abzutasten, um abgetastete Texturwerte zur Verwendung in Shader-Programme zu erzeugen, die von dem SM 340 ausgeführt werden. Die Textureinheiten 345 implementieren Textur-Operationen, wie beispielsweise Filter-Operationen unter Verwendung von Mip-Abbildungen (d. h. Texturabbildungen mit einem unterschiedlichen Grad an Detail). Die Textureinheit 345 wird ebenfalls als der Lade/Speicher-Weg für den SM 340 zu der MMU 390 verwendet. In einer Ausführungsform umfasst jeder TPC 320 zwei (2) Textureinheiten 345.
Der SM 340 umfasst einen programmierbaren Streaming-Prozessor, der konfiguriert ist, um Aufgaben zu verarbeiten, die durch eine Anzahl von Threads dargestellt werden. Jeder SM 340 umfasst mehrere Threads (ist multi-threaded) und ist konfiguriert, um eine Mehrzahl von Threads (z. B., 32 Threads) von einer bestimmten Gruppe von Threads nebenläufig auszuführen. In einer Ausführungsform implementiert der SM 340 eine SIMD(Einzelne-Anweisung, Mehrere-Daten)-Architektur, wobei jeder Thread in einer Gruppe von Threads (d. h. einem Warp) konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten. Alle Threads in der Gruppe von Threads führen die gleichen Anweisungen aus. In einer anderen Ausführungsform implementiert der SM 340 eine SIMT(Einzelne Anweisung, Mehrere Threads)-Architektur, wobei jeder Thread in einer Gruppe von Threads konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten, wobei jedoch einzelnen Threads in der Gruppe von Threads ermöglicht wird, während der Ausführung zu divergieren. Mit anderen Worten können, wenn eine Anweisung für die Gruppe von Threads zur Ausführung versandt wird, einige Threads in der Gruppe von Threads aktiv sein, wodurch die Anweisung ausgeführt wird, während andere Threads in der Gruppe von Threads inaktiv sein können, wodurch keine Operation (NOP) durchgeführt wird, anstatt die Anweisung auszuführen. Der SM 340 kann ausführlicher nachstehend in Verbindung mit 4 beschrieben werden.
Die MMU 390 stellt eine Schnittstelle zwischen dem GPC 250 und der Partitions-Einheit 280 bereit. Die MMU 390 kann Übersetzung von virtuellen Adressen in physikalische Adressen, Speicherschutz und Arbitrierung von Speicheranfragen bereitstellen. In einer Ausführungsform stellt die MMU 390 einen oder mehrere Adressenübersetzungspuffer (TLBs = translation lookaside buffers) zum Verbessern der Übersetzung von virtuellen Adressen in physikalische Adressen in dem Speicher 204 bereit.
3B veranschaulicht eine Partitions-Einheit 280 der PPU 200 von 2 gemäß einer Ausführungsform. Wie in 3B gezeigt, umfasst die Partitions-Einheit 280 eine Raster-Operationen(ROP)-Einheit 350, einen L2-Cache-Speicher 360, eine Speicherschnittstelle 370 und eine L2-Kreuzschiene (XBar) 365. Die Speicherschnittstelle 370 ist mit dem Speicher 204 gekoppelt. Die Speicherschnittstelle 370 kann 16-, 32-, 64-, 128-Bit-Datenbusse oder dergleichen für Hochgeschwindigkeits-Datentransfer implementieren. In einer Ausführungsform umfasst die PPU 200U Speicherschnittstellen 370, eine Speicherschnittstelle 370 pro Partitions-Einheit 280, wobei jede Partitions-Einheit 280 mit einer entsprechenden Speichervorrichtung 204 verbunden ist. Beispielsweise kann die PPU 200 mit bis zu U Speichervorrichtungen 204, wie beispielsweise einem synchronen dynamischen Speicher mit wahlweisem Zugriff mit Graphikdoppeldatenrate der Version 5 (GDDR5 SDRAM) verbunden sein. In einer Ausführungsform implementiert die Speicherschnittstelle 370 eine DRAM-Schnittstelle und U ist gleich 8.
In einer Ausführungsform implementiert die PPU 200 eine Mehrebenen-Speicherhierarchie. Der Speicher 204 ist außerhalb des Chips im SDRAM lokalisiert, der mit der PPU 200 verbunden ist. Daten aus dem Speicher 204 können geholt und in dem L2-Cache-Speicher 360 gespeichert werden, der innerhalb des Chips lokalisiert ist und zwischen den verschiedenen GPCs 250 gemeinsam benutzt wird. Wie gezeigt, umfasst jede Partitions-Einheit 280 einen Abschnitt des L2-Cache-Speichers 360, der einer entsprechenden Speichervorrichtung 204 zugeordnet ist. Cache-Speicher niedrigerer Ebene können dann in verschiedenen Einheiten innerhalb der GPCs 250 implementiert werden. Beispielsweise kann jeder der SMs 340 einen L1-Cache-Speicher implementieren. Der L1-Cache-Speicher ist ein privater Speicher, der für einen bestimmten SM 340 dediziert ist. Daten von dem L2-Cache-Speicher 360 können geholt und in jedem der L1-Cache-Speicher zur Verarbeitung in den Funktionseinheiten der SMs 340 gespeichert werden. Der L2-Cache-Speicher 360 ist mit der Speicherschnittstelle 370 und der XBar 270 gekoppelt.
Die ROP-Einheit 350 umfasst einen ROP-Manager 355, eine Farbeneinheit ROP (CROP-Einheit) 352 und eine Z ROP (ZROP) Einheit 354. Die CROP-Einheit 352 führt Raster-Operationen durch, welche die Pixelfarbe betreffen, wie beispielsweise Farbenkomprimierung, Pixelmischung und dergleichen. Die ZROP-Einheit 354 implementiert Tiefentesten in Verbindung mit der Raster-Engine 325. Die ZROP-Einheit 354 empfängt eine Tiefe für einen Abtastort, der einem Pixelfragment zugeordnet ist, von der Aussonderungs-Engine der Raster-Engine 325. Die ZROP-Einheit 354 prüft die Tiefe gegen eine entsprechende Tiefe in einem Tiefenpuffer für einen Abtastort, der dem Fragment zugeordnet ist. Wenn das Fragment den Tiefentest für den Abtastort besteht, dann aktualisiert die ZROP-Einheit 354 den Tiefenpuffer und überträgt ein Ergebnis des Tiefentests an die Raster-Engine 325. Der ROP-Manager 355 steuert den Betrieb der ROP-Einheit 350. Es wird anerkannt, dass sich die Anzahl von Partitions-Einheiten 280 von der Anzahl von GPCs 250 unterscheiden kann, und daher jede ROP-Einheit 350 mit jedem der GPCs 250 gekoppelt werden kann. Daher verfolgt der ROP-Manager 355 Pakete, die von den unterschiedlichen GPCs 250 empfangen werden, und bestimmt, zu welchem GPC 250 ein Ergebnis weitergeleitet wird, das durch die ROP-Einheit 350 erzeugt wurde. Die CROP-Einheit 352 und die ZROP-Einheit 354 sind mit dem L2-Cache-Speicher 360 über eine L2-XBar 365 gekoppelt.
4 veranschaulicht den Streaming-Multiprozessor 340 von 3A gemäß einer Ausführungsform. Wie in 4 gezeigt, umfasst der SM 340 einen Anweisungs-Cache-Speicher 405, eine oder mehrere Planer-Einheiten 410, eine Registerdatei 420, einen oder mehrere Verarbeitungskerne 450, eine oder mehrere Spezialfunktionseinheiten (SFUs) 452, eine oder mehrere Lade/Speicher-Einheiten (LSUs) 454, ein Zwischenverbindungs-Netzwerk 480, einen gemeinsam benutzten Speicher 470 und einen L1-Cache-Speicher 490.
Wie oben beschrieben, versendet die Arbeitsverteilungs-Einheit 225 Aufgaben zur Ausführung auf den GPCs 250 der PPU 200. Die Aufgaben werden einem bestimmten TPC 320 innerhalb eines GPC 250 zugeteilt, und, wenn die Aufgabe einem Shader-Programm zugeordnet ist, kann die Aufgabe einem SM 340 zugeteilt werden. Die Planer-Einheit 410 empfängt die Aufgaben von der Arbeitsverteilungs-Einheit 225 und verwaltet die Anweisungs-Planung (instruction scheduling) für eine oder mehrere Gruppen von Threads (d. h. Warps), die dem SM 340 zugewiesen sind. Die Planer-Einheit 410 plant Threads zur Ausführung in Gruppen von parallel Threads, wobei jede Gruppe ein Warp genannt wird. In einer Ausführungsform umfasst jeder Warp 32 Threads. Die Planer-Einheit 410 kann eine Mehrzahl von unterschiedlichen Warps verwalten, wobei die Warps zur Ausführung geplant und dann Anweisungen von der Mehrzahl von unterschiedlichen Warps an die verschiedenen Funktionseinheiten (d. h. Kerne 350, SFUs 352 und LSUs 354) während jeden Taktzyklus versandt werden.
In einer Ausführungsform umfasst jede Planer-Einheit 410 eine oder mehrere Anweisungs-Versandeinheiten 415. Jede Versandeinheit 415 ist konfiguriert, um Anweisungen an eine oder mehrere der Funktionseinheiten zu übertragen. In der in 4 gezeigten Ausführungsform umfasst die Planer-Einheit 410 zwei Versandeinheiten 415, die ermöglichen, dass zwei unterschiedliche Anweisungen von dem gleichen Warp während jedes Taktzyklus versandt werden. In alternativen Ausführungsformen kann jede Planer-Einheit 410 eine einzige Versandeinheit 415 oder zusätzliche Versandeinheiten 415 umfassen.
Jeder SM 340 umfasst eine Registerdatei 420, die einen Satz von Registern für die Funktionseinheiten des SM 340 bereitstellt.
In einer Ausführungsform ist die Registerdatei 420 zwischen jeder der Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein zugehöriger Abschnitt der Registerdatei 420 zugeteilt ist. In einer anderen Ausführungsform ist die Registerdatei 420 zwischen den unterschiedlichen Warps aufgeteilt, die von dem SM 340 ausgeführt werden. Die Registerdatei 420 stellt temporären Speicher für Operanden bereit, die mit den Datenwegen der Funktionseinheiten verbunden sind.
Jeder SM 340 umfasst L Verarbeitungskerne 450. In einer Ausführungsform umfasst der SM 340 eine große Anzahl (z. B., 128, usw.) von unterschiedlichen Verarbeitungskernen 450. Jeder Kern 450 kann eine vollständig in einer Pipeline angeordnete (fully-pipelined) Einfach-Präzisions-Verarbeitungseinheit umfassen, die eine Gleitkommaarithmetik-Logikeinheit und eine Ganzzahlarithmetik-Logikeinheit umfasst. Der Kern 450 kann ebenfalls eine Doppel-Präzisions-Verarbeitungseinheit umfassen, die eine Gleitkommaarithmetik-Logikeinheit umfasst. In einer Ausführungsform implementieren die Gleitkommaarithmetik-Logikeinheiten den IEEE 754-2008 Standard für Gleitkommaarithmetik. Jeder SM 340 umfasst ebenfalls M SFUs 452, die Spezialfunktionen durchführen (z. B., Attributauswertung, reziproke Quadratwurzel und dergleichen), und N LSUs 454, die Lade- und Speicher-Operationen zwischen dem gemeinsam benutzten Speicher 470 oder dem L1-Cache-Speicher 490 und der Registerdatei 420 implementieren. In einer Ausführungsform umfasst der SM 340 128 Kerne 450, 32 SFUs 452 und 32 LSUs 454.
Jeder SM 340 umfasst ein Zwischenverbindungs-Netzwerk 480, das jede der Funktionseinheiten mit der Registerdatei 420 verbindet und die LSU 454 mit der Registerdatei 420, dem gemeinsam benutzten Speicher 470 und dem L1-Cache-Speicher 490 verbindet. In einer Ausführungsform ist das Zwischenverbindungs-Netzwerk 480 eine Kreuzschiene, die konfiguriert sein kann, um beliebige der Funktionseinheiten mit einem beliebigen der Register in der Registerdatei 420 zu verbinden und die LSUs 454 mit der Registerdatei und Speicherorten in dem gemeinsam benutzten Speicher 470 und L1-Cache-Speicher 490 zu verbinden.
Der gemeinsam benutzte Speicher 470 ist ein Array von auf dem Chip befindlicher Speicher, der Datenspeicherung und Kommunikation zwischen dem SM 340 und der Primitiven-Engine 335 und zwischen Threads in dem SM 340 ermöglicht. In einer Ausführungsform umfasst der gemeinsam benutzte Speicher 470 64 KB von Speicherkapazität. Ein L1-Cache-Speicher 490 ist im Weg von dem SM 340 zu der Partitions-Einheit 280. Der L1-Cache-Speicher 490 kann verwendet werden, um Lese- und Schreibvorgänge zwischen zu speichern. In einer Ausführungsform umfasst der L1-Cache-Speicher 490 24 KB von Speicherkapazität.
Die oben beschriebene PPU 200 kann konfiguriert sein, um hochparallele Berechnungen viel schneller als herkömmliche CPUs durchzuführen. Parallele Berechnen weist Vorteile bei der Graphikverarbeitung, der Datenkomprimierung, der Biometrik, den Stromverarbeitungsalgorithmen und dergleichen auf.
Wenn für Allzweck-Parallelberechnung konfiguriert, kann eine einfachere Konfiguration verwendet werden. In diesem Modell werden, wie in 2 gezeigt, Festfunktions-Graphikverarbeitungseinheiten umgangen, wobei ein viel einfacheres Programmiermodell erzeugt wird. In dieser Konfiguration werden von der Arbeitsverteilungs-Einheit 225 Blöcke von Threads zugewiesen und direkt an die TPCs 320 verteilt. Die Threads in einem Block führen das gleiche Programm unter Verwendung einer eindeutigen Thread-ID in der Berechnung aus, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, wobei der SM 340 verwendet wird, um das Programm auszuführen und Berechnungen durchzuführen, damit der gemeinsam benutzte Speicher 470 zwischen Threads kommuniziert, und die LSU 454 verwendet wird, um den globalen Speicher durch Partitionierung des L1-Cache-Speichers 490 und der Partitions-Einheit 280 zu lesen und zu beschreiben.
Wenn für Allzweck-Parallelberechnung konfiguriert, kann der SM 340 ebenfalls Befehle schreiben, welche die Planer-Einheit 220 verwenden kann, um neue Arbeit auf den TPCs 320 zu starten.
In einer Ausführungsform umfasst die PPU 200 eine Graphikverarbeitungseinheit (GPU). Die PPU 200 ist konfiguriert, um Befehle zu empfangen, die Shader-Programme zur Verarbeitung von Graphikdaten spezifizieren. Graphikdaten können als ein Satz von Primitiven, wie beispielsweise Punkte, Linien, Dreiecke, Vierecke, Dreieckstreifen und dergleichen definiert sein. Typischerweise umfasst eine Primitive Daten, die eine Anzahl von Vertices für die Primitive (z. B., in einem Modellraum-Koordinatensystem) sowie auch Attribute spezifizieren, die jedem Vertex der Primitiven zugeordnet sind. Die PPU 200 kann konfiguriert sein, um die Graphikprimitive zu verarbeiten, um ein Frame-Puffer 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 Vertices und Attributen) in einen Speicher, wie beispielsweise einen Systemspeicher oder Speicher 204. Die Modelldaten definieren jedes der Objekte, die auf einer Anzeige sichtbar sein können. Die Anwendung führt dann einen API-Aufruf an dem Treiber-Kernel aus, der die Modelldaten anfragt, die zu rendern und anzuzeigen sind. Der Treiber-Kernel liest die Modelldaten und schreibt Befehle an den einen oder mehrere Ströme, um Operationen durchzuführen, um die Modelldaten zu verarbeiten. Die Befehle können unterschiedliche Shader-Programme referenzieren, die auf den SMs 340 der PPU 200 zu implementieren sind, die einen oder mehrere eines Vertex-Shader, Hull-Shader, Domain-Shader, Geometrie-Shader und eines Pixel-Shader umfassen können. Beispielsweise können eine oder mehrere der SMs 340 konfiguriert sein, um ein Vertex-Shader-Programm auszuführen, das eine Anzahl von Vertices verarbeitet, die durch die Modelldaten definiert sind. In einer Ausführungsform können die unterschiedlichen SMs 340 konfiguriert sein, um unterschiedliche Shader-Programme nebenläufig auszuführen. Beispielsweise kann eine erste Untermenge von SMs 340 konfiguriert sein, ein Vertex-Shader-Programm auszuführen, während eine zweite Untermenge von SMs 340 konfiguriert sein kann, ein Pixel-Shader-Programm auszuführen. Die erste Untermenge von SMs 340 verarbeitet Vertexdaten, um verarbeitete Vertexdaten zu erzeugen, und schreibt die verarbeiteten Vertexdaten in den L2-Cache-Speicher 360 und/oder den Speicher 204. Nachdem die verarbeiteten Vertexdaten gerastert sind (d. h. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum transformiert sind), um Fragmentdaten zu erzeugen, führt die zweite Untermenge von SMs 340 einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten gemischt werden und in den Frame-Puffer im Speicher 204 geschrieben werden. Das Vertex-Shader-Programm und das Pixel-Shader-Programm können nebenläufig ausgeführt werden, wobei unterschiedliche Daten von der gleichen Szene in einem Pipeline-Verfahren verarbeitet werden, bis alle der Modelldaten für die Szene gerenderten zu dem Frame-Puffer gerendert wurden. Dann wird der Inhalt des Frame-Puffers an einen Anzeigencontroller zur Anzeige auf einer Anzeigevorrichtung übertragen.
Die PPU 200 kann in einem Tischcomputer, einem Laptop-Computer, einem Tablet-Computer, einem Smartphone (z. B. einer drahtlosen handgehaltenen Vorrichtung), einem persönlichen digitalen Assistenten (PDA), einer Digitalkamera, einer handgehaltenen elektronischen Vorrichtung und dergleichen umfasst sein. In einer Ausführungsform ist die PPU 200 auf einem einzelnen Halbleitersubstrat verkörpert. In einer anderen Ausführungsform ist die PPU 200 in einem System-on-Chip (SoC) zusammen mit einer oder mehreren anderen Logikeinheiten, wie beispielsweise einer Rechner-mit-reduziertem-Befehlssatz(RISC)-CPU, einer Speicherverwaltungseinheit (MMU), einem Digital/Analog-Wandler (DAC) und dergleichen umfasst.
In einer Ausführungsform kann die PPU 200 auf einer Graphikkarte umfasst sein, die eine oder mehrere Speichervorrichtungen 204, wie beispielsweise GDDR5 SDRAM, umfasst. Die Graphikkarte kann konfiguriert sein, um sich mit einem PCIe-Schlitz auf einer Hauptplatine eines Tischcomputers schnittstellenmäßig zu verbinden, der beispielsweise einen Northbridge-Chipsatz und einen Southbridge-Chipsatz umfasst. In noch einer anderen Ausführungsform kann die PPU 200 eine integrierte Graphikverarbeitungseinheit (iGPU) sein, die in dem Chipsatz (d. h. Northbridge) der Hauptplatine umfasst ist.
5 veranschaulicht ein System-on-Chip (SoC) 500, das die PPU 200 von 2 umfasst, gemäß einer Ausführungsform. Wie in 5 gezeigt, umfasst das SoC 500 eine CPU 550 und eine PPU 200, wie oben beschrieben. Das SoC 500 kann ebenfalls einen Systembus 202 umfassen, um Kommunikation zwischen den verschiedenen Komponenten des SoC 500 zu ermöglichen. Speicheranfragen, die von der CPU 550 und der PPU 200 erzeugt werden, können durch eine System-MMU 590 weitergeleitet werden, die von mehreren Komponenten des SoC 500 gemeinsam benutzt werden. Das SoC 500 kann ebenfalls eine Speicherschnittstelle 595 umfassen, die mit einer oder mehreren Speichervorrichtungen 204 gekoppelt ist. Die Speicherschnittstelle 595 kann beispielsweise eine DRAM-Schnittstelle implementieren.
Obwohl nicht explizit gezeigt, kann das SoC 500 andere Komponenten zusätzlich zu den in 5 gezeigten Komponenten umfassen. Beispielsweise kann das SoC 500 mehrere PPUs 200 (z. B., vier PPUs 200), einen Video-Codierer/Decodierer und einen drahtlosen Breitband-Sendeempfänger sowie auch andere Komponenten umfassen. In einer Ausführungsform kann das SoC 500 mit dem Speicher 204 in einer Package-on-Package(PoP)-Konfiguration umfasst sein.
6 ist ein Konzeptdiagramm einer von der PPU 200 implementierten Graphikverarbeitungs-Pipeline 600 gemäß einer Ausführungsform. Die Graphikverarbeitungs-Pipeline 600 ist ein abstraktes Ablaufdiagramm der Verarbeitungsschritte, die implementiert werden, um 2D-Computer-erzeugte Bilder aus 3D-Geometriedaten zu erzeugen. Wie bekannt ist, können Pipeline-Architekturen Operationen mit langer Latenz effizienter durch Aufteilen der Operation in eine Mehrzahl von Stufen durchführen, wobei die Ausgabe jeder Stufe mit dem Eingang der nächsten aufeinanderfolgenden Stufe gekoppelt ist. Somit empfängt die Graphikverarbeitungs-Pipeline 600 Eingabedaten 601, die von einer Stufe zu der nächsten Stufe der Graphikverarbeitungs-Pipeline 600 übertragen werden, um Ausgabedaten 602 zu erzeugen. In einer Ausführungsform kann die Graphikverarbeitungs-Pipeline 600 eine Graphikverarbeitungs-Pipeline darstellen, die durch die OpenGL^® API definiert ist. Als eine Option kann die Graphikverarbeitungs-Pipeline 600 im Kontext der Funktionalität und Architektur der vorherigen Figuren und/oder etwaiger nachfolgenden Figur(en) implementiert werden.
Wie in 6 gezeigt, umfasst die Graphikverarbeitungs-Pipeline 600 eine Pipeline-Architektur, die eine Anzahl von Stufen umfasst. Die Stufen umfassen, sind jedoch nicht beschränkt auf, eine Daten-Zusammenstellungsstufe 610, eine Vertex-Shading-Stufe 620, eine Primitiven-Zusammenstellungsstufe 630, eine Geometrie-Shading-Stufe 640, eine Darstellungsfeld-Skalierungs-, Aussonderungs- und Abschneide-(VSCC)-Stufe 650, eine Rasterungsstufe 660, eine Fragment-Shading-Stufe 670 und eine Raster-Operationen-Stufe 680. In einer Ausführungsform umfassen die Eingabedaten 601 Befehle, welche die Verarbeitungseinheiten konfigurieren, um die Stufen der Graphikverarbeitungs-Pipeline 600 und geometrische Primitive (z. B., Punkte, Linien, Dreiecke, Vierecke, Dreieckstreifen oder Fächer, usw.) zu implementieren, die mittels der Stufen zu verarbeiten sind. Die Ausgabedaten 602 können Pixeldaten (d. h. Farbdaten) umfassen, die in einen Frame-Puffer oder einen anderen Typ von Oberflächen-Datenstruktur in einem Speicher kopiert werden.
Die Daten-Zusammenstellungsstufe 610 empfängt die Eingabedaten 601, die Vertexdaten für Oberflächen höherer Ordnung, Primitive oder dergleichen spezifizieren. Die Daten-Zusammenstellungsstufe 610 sammelt die Vertexdaten in einem temporären Speicher oder Queue, wie beispielsweise durch Empfangen eines Befehls von dem Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher umfasst und die Vertexdaten aus dem Puffer liest. Die Vertexdaten werden dann an die Vertex-Shading-Stufe 620 zur Verarbeitung übertragen.
Die Vertex-Shading-Stufe 620 verarbeitet Vertexdaten durch Durchführen eines Satzes von Operationen (d. h. eines Vertex-Shader oder eines Programms) einmal für jede der Vertices. Vertices können beispielsweise als ein 4-Koordinaten-Vektor (d. h. (x, y, z, w>) spezifiziert sein, der einem oder mehreren Vertexattributen (z. B., Farbe, Texturkoordinaten, Oberflächennormalen, usw.) zugeordnet ist. Die Vertex-Shading-Stufe 620 kann einzelne Vertexattribute, wie beispielsweise Position, Farbe, Texturkoordinaten und dergleichen, manipulieren. Mit anderen Worten führt die Vertex-Shading-Stufe 620 Operationen an den Vertex-Koordinaten oder anderen Vertexattributen durch, welche einer Vertex zugeordnet sind. Derartige Operationen umfassen gewöhnlicherweise Beleuchtungs-Operationen (d. h. Modifizieren von Farbattributen für einen Vertex) und Transformations-Operationen (d. h. Modifizieren des Koordinatenraums für einen Vertex). Beispielsweise können Vertices unter Verwendung von Koordinaten in einem Objekt-Koordinatenraum spezifiziert sein, die durch Multiplizieren der Koordinaten mittels einer Matrix transformiert werden, welche die Koordinaten aus dem Objekt-Koordinatenraum in einen Welt-Raum oder einen normierten Vorrichtungskoordinaten(NCD = Normalized Device Coordinates)-Raum übersetzt. Die Vertex-Shading-Stufe 620 erzeugt transformierte Vertexdaten, die an die Primitiven-Zusammenstellungsstufe 630 übertragen werden.
Die Primitiven-Zusammenstellungsstufe 630 sammelt Vertices, die mittels der Vertex-Shading-Stufe 620 ausgegeben werden, und gruppiert die Vertices in geometrischen Primitiven zur Verarbeitung durch die Geometrie-Shading-Stufe 640. Beispielsweise kann die Primitiven-Zusammenstellungsstufe 630 konfiguriert sein, um alle drei aufeinanderfolgenden Vertices als eine geometrische Primitive (d. h. ein Dreieck) zur Übertragung an die Geometrie-Shading-Stufe 640 zu gruppieren. In einigen Ausführungsformen können spezifische Vertices für aufeinanderfolgende geometrische Primitiven erneut verwendet werden (z. B. können zwei aufeinanderfolgende Dreiecke in einem Dreieckstreifen zwei Vertices gemeinsam benutzen). Die Primitiven-Zusammenstellungsstufe 630 überträgt geometrische Primitive (d. h. eine Sammlung von zugeordneten Vertices) an die Geometrie-Shading-Stufe 640.
Die Geometrie-Shading-Stufe 640 verarbeitet geometrische Primitiven durch Durchführen eines Satzes von Operationen (d. h. eines Geometrie-Shader oder Programms) an den geometrischen Primitiven. Tessellations-Operationen können eine oder mehrere geometrische Primitiven aus jeder geometrischen Primitive erzeugen. Mit anderen Worten kann die Geometrie-Shading-Stufe 640 jede geometrische Primitive in ein feineres Netz von zwei oder mehr geometrischen Primitiven zur Verarbeitung durch den Rest der Graphikverarbeitungs-Pipeline 600 unterteilen. Die Geometrie-Shading-Stufe 640 überträgt geometrische Primitive an die Darstellungsfeld-SCC-Stufe 650.
In einer Ausführungsform kann die Graphikverarbeitungs-Pipeline 600 innerhalb eines Streaming-Multiprozessors arbeiten und die Vertex-Shading-Stufe 620, die Primitiven-Zusammenstellungsstufe 630, die Geometrie-Shading-Stufe 640, die Fragment-Shading-Stufe 670 und/oder die damit zugeordnete Hardware/Software kann sequentiell Verarbeitungsoperationen durchführen. Sobald die sequentiellen Verarbeitungsoperationen in einer Ausführungsform abgeschlossen sind, kann die Darstellungsfeld-SCC-Stufe 650 die Daten benutzen. In einer Ausführungsform können Primitivendaten, die durch eine oder mehrere der Stufen in der Graphikverarbeitungs-Pipeline 600 verarbeitet wurden, in einen Cache-Speicher (z. B. einen L1-Cache-Speicher, einen Vertex-Cache-Speicher usw.) geschrieben werden. In diesem Fall kann in einer Ausführungsform die Darstellungsfeld-SCC-Stufe 650 auf die Daten in dem Cache-Speicher zugreifen. In einer Ausführungsform sind die Darstellungsfeld-SCC-Stufe 650 und die Rasterungsstufe 660 als Festfunktions-Schaltungen implementiert.
Die Darstellungsfeld-SCC-Stufe 650 führt Darstellungsfeld-Skalierung, Aussonderung und Abschneidung der geometrischen Primitiven durch. Jede Oberfläche, die gerendert wird, wird einer abstrakten Kameraposition zugeordnet. Die Kameraposition stellt einen Ort eines Betrachters dar, der die Szene betrachtet, und definiert einen Betrachtungsstumpf, der die Objekte der Szene einschließt. Der Betrachtungsstumpf kann eine Betrachtungs-Ebene, eine hintere Ebene und vier Abschneide-Ebenen umfassen. Jede geometrische Primitive, die vollständig außerhalb des Betrachtungsstumpfes ist, kann ausgesondert (d. h. verworfen) werden, weil die geometrische Primitive nicht zu der endgültigen gerenderten Szene beitragen wird. Jede geometrische Primitive, die innerhalb des Betrachtungsstumpfs und teilweise außerhalb des Betrachtungsstumpf ist, kann abgeschnitten werden (d. h. in ein neue geometrische Primitive transformiert werden, die innerhalb des Betrachtungsstumpf eingeschlossen ist). Des Weiteren können geometrische Primitiven jeweils basierend auf einer Tiefe des Betrachtungsstumpfes skaliert werden. Alle potentiell sichtbaren geometrischen Primitiven werden dann an die Rasterungsstufe 660 übertragen.
Die Rasterungsstufe 660 wandelt die 3D-geometrischen Primitiven in 2D-Fragmente um (die z. B. in der Lage sind, zur Anzeige benutzt zu werden, usw.). Die Rasterungsstufe 660 kann konfiguriert sein, um die Vertices der geometrischen Primitive zu benutzen, um einen Satz von Ebenengleichungen aufzustellen, von denen verschiedene Attribute interpoliert werden können. Die Rasterungsstufe 660 kann ebenfalls eine Abdeckungsmaske für eine Mehrzahl von Pixeln berechnen, die angibt, ob eine oder mehrere Abtastorte für das Pixel die geometrische Primitive schneiden. In einer Ausführungsform kann auch z-Testen durchgeführt werden, um zu bestimmen, ob die geometrische Primitive von anderen geometrischen Primitiven verdeckt wird, die bereits gerastert wurden. Die Rasterungsstufe 660 erzeugt Fragmentdaten (d. h. interpolierte Vertexattribute, die einem bestimmten Abtastort für jedes abgedeckte Pixel zugeordnet sind), die an die Fragment-Shading-Stufe 670 übertragen werden.
Die Fragment-Shading-Stufe 670 verarbeitet Fragmentdaten durch Durchführen eines Satzes von Operationen (d. h. eines Fragment-Shader oder eines Programms) an jedem der Fragmente. Die Fragment-Shading-Stufe 670 kann Pixeldaten (d. h. Farbenwerte) für das Fragment erzeugen, wie beispielsweise durch Durchführen von Beleuchtungs-Operationen oder Abtasten von Texturabbildungen unter Verwendung von interpolierten Texturkoordinaten für das Fragment. Die Fragment-Shading-Stufe 670 erzeugt Pixeldaten, die an die Raster-Operationen-Stufe 680 übertragen werden.
Die Raster-Operationen-Stufe 680 kann verschiedene Operationen an den Pixeldaten durchführen, wie beispielsweise Alpha-Tests, Stencil-Tests und Mischung der Pixeldaten mit anderen Pixeldaten, die anderen Fragmente entsprechen, die dem Pixel zugeordnet sind. Wenn die Raster-Operationen-Stufe 680 die Verarbeitung der Pixeldaten (d. h. der Ausgabedaten 602) beendet hat, können die Pixeldaten in ein Render-Ziel, wie beispielsweise einen Frame-Puffer, einen Farbenpuffer oder dergleichen, geschrieben werden.
Es wird anerkannt, dass eine oder mehrere zusätzliche Stufen in der Graphikverarbeitungs-Pipeline 600 zusätzlich zu oder anstatt einer oder mehrerer der oben beschriebenen Stufen umfasst sein können. Verschiedene Implementierungen der abstrakten Graphikverarbeitungs-Pipeline können unterschiedliche Stufen implementieren. Des Weiteren können eine oder mehrere der oben beschriebenen Stufen der Graphikverarbeitungs-Pipeline in einigen Ausführungsformen (wie beispielsweise der Geometrie-Shading-Stufe 640) ausgeschlossen sein. Andere Arten von Graphikverarbeitungs-Pipelines werden betrachtet, als innerhalb des Schutzumfangs der vorliegenden Offenbarung zu liegen. Des Weiteren können beliebige der Stufen der Graphikverarbeitungs-Pipeline 600 von einer oder mehreren dedizierten Hardwareeinheiten innerhalb eines Graphikprozessors, wie beispielsweise der PPU 200, implementiert werden. Andere Stufen der Graphikverarbeitungs-Pipeline 600 können durch programmierbare Hardwareeinheiten, wie beispielsweise dem SM 340 der PPU 200, implementiert werden.
Die Graphikverarbeitungs-Pipeline 600 kann über eine Anwendung implementiert werden, die von einem Host-Prozessor, wie beispielsweise einer CPU 550, ausgeführt wird. In einer Ausführungsform kann ein Vorrichtungstreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, die verschiedene Funktionen definiert, die von einer Anwendung benutzt werden können, um graphische Daten zur Anzeige zu erzeugen. Der Vorrichtungstreiber ist ein Softwareprogramm, das eine Mehrzahl von Anweisungen umfasst, die den Betrieb der PPU 200 steuern. Die API stellt eine Abstraktion für einen Programmierer bereit, die einem Programmierer erlaubt, spezialisierte Graphikhardware zu benutzen, wie beispielsweise die PPU 200, um die graphischen Daten zu erzeugen, ohne zu verlangen, dass der Programmierer den spezifischen Anweisungssatz für die PPU 200 benutzen muss. Die Anwendung kann einen API-Aufruf umfassen, der an den Vorrichtungstreiber für die PPU 200 weitergeleitet wird. Der Vorrichtungstreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu antworten. In einigen Fällen kann der Vorrichtungstreiber Operationen durch Ausführen von Anweisungen auf der CPU 550 durchführen. In anderen Fällen kann der Vorrichtungstreiber Operationen, zumindest teilweise, durch Starten von Operationen auf der PPU 200 durchführen, wobei eine Eingabe/Ausgabe-Schnittstelle zwischen der CPU 550 und der PPU 200 benutzt wird. In einer Ausführungsform ist der Vorrichtungstreiber konfiguriert, um die Graphikverarbeitungs-Pipeline 600 unter Benutzung der Hardware der PPU 200 zu implementieren.
Verschiedene Programme können innerhalb der PPU 200 ausgeführt werden, um die verschiedenen Stufen der Graphikverarbeitungs-Pipeline 600 zu implementieren. Beispielsweise kann der Vorrichtungstreiber ein Kernel auf der PPU 200 starten, um die Vertex-Shading-Stufe 620 auf einem SM 340 (oder mehreren SMs 340) durchzuführen. Der Vorrichtungstreiber (oder den von der PPU 200 ausgeführten Anfangskernel) kann ebenfalls andere Kernels auf der PPU 200 starten, um andere Stufen der Graphikverarbeitungs-Pipeline 600 durchzuführen, wie beispielsweise die Geometrie-Shading-Stufe 640 und die Fragment-Shading-Stufe 670. Außerdem können einige der Stufen der Graphikverarbeitungs-Pipeline 600 auf einer festen Hardwareeinheit implementiert werden, wie beispielsweise einem Rasterer oder einem Daten-Assembler, der innerhalb der PPU 200 implementiert ist. Es wird anerkannt, dass Ergebnisse von einem Kernel durch eine oder mehrere intervenierende Festfunktions-Hardwareeinheiten verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 340 verarbeitet werden.
7 ist ein Konzeptdiagramm einer Graphikverarbeitungs-Pipeline 700, die von der PPU 200 von 2 implementiert wird, gemäß einer anderen Ausführungsform. Die Graphikverarbeitungs-Pipeline 700 ist ein abstraktes Ablaufdiagramm der Verarbeitungsschritte, die implementiert werden, um 2D-computererzeugte Bilder aus 3D-Geometriedaten zu erzeugen. Wie in 7 gezeigt, umfasst die Graphikverarbeitungs-Pipeline 700 eine Pipeline-Architektur, die eine Anzahl von Stufen umfasst, wobei viele Stufen davon der Graphik-Pipeline 600 von 6 ähnlich sind. Es wird anerkannt, dass die Graphikverarbeitungs-Pipeline 700 eine Hull-Shading-Stufe 710, eine Tessellationsstufe 720 und eine Domain-Shading-Stufe 730 zwischen der Primitiven-Zusammenstellungsstufe 630 und der Geometrie-Shading-Stufe 640 umfasst. In der Graphik-Pipeline 600 kann Tessellation von Primitiven in der Geometrie-Shading-Stufe 640 durchgeführt worden sein. Durch Hinzufügen getrennter Stufen für Hull-Shading, Tessellation und Domain-Shading kann Tessellation effizienter durchgeführt werden.
Die Hull-Shading-Stufe 710 empfängt Primitiven von der Primitiven-Zusammenstellungsstufe 630 und führt einen Hull-Shader aus. Der Hull-Shader ist ein Programm, das einen Patch von Primitiven als Eingabe nimmt und einen Patch von Primitiven als Ausgabe zusammen mit Patch-Konstanten erzeugt, die von der Tessellationsstufe 720 und/oder der Domain-Shading-Stufe 730 benutzt werden. Ein Patch kann eine oder mehrere Primitive niedriger Auflösung umfassen, die von der Primitiven-Zusammenstellungsstufe 630 ausgegeben werden. In einer Ausführungsform umfasst ein Patch eine einzige Dreieck-Primitive, die drei Vertices aufweist.
Die Tessellationsstufe 720 der Graphikverarbeitungs-Pipeline empfängt Patches von der Hull-Shading-Stufe 710 und tesseliert jeden Patch. Die Tessellationsstufe 720 kann durch eine Hardwareeinheit implementiert werden, die einen neuen Patch mit einer großen Anzahl von Steuerpunkten erzeugt. Beispielsweise wird die Tessellationsstufe 720 einen Patch mit drei Vertices empfangen und jede Seite des durch den Patch definierten Dreiecks in eine Anzahl von Segmenten unter Verwendung von beispielsweise baryzentrischen Koordinaten aufteilen. Die Tessellationsstufe 720 ist eine Festfunktions-Einheit, obwohl die Anzahl von Aufteilungen von jeder Seite einer Primitiven konfigurierbar sein kann. Beispielsweise kann die Hull-Shading-Stufe 710 einen Tessellations-Faktor an die Tessellationsstufe 720 ausgeben, der bestimmt, wie viele Aufteilungen auf jeder Seite einer Primitiven ausgeführt werden sollten. Die Tessellationsstufe 720 kann Primitiven an die Domain-Shading-Stufe 730 ausgeben.
In einer anderen Ausführungsform kann die Tessellationsstufe 720 durch eine programmierbare Einheit implementiert werden, die einen Tessellations-Shader ausführt. Der Tessellations-Shader ist ein Programm, das einen Patch als Eingabe nimmt und einen neuen Patch erzeugt, der mehrere Vertices als Ausgabe aufweist. Der Tessellations-Shader ist der oben beschriebenen Festfunktions-Hardware mit der Ausnahme ähnlich, dass der Tessellations-Shader eine programmierbare Steuerung der Tessellation ermöglicht. Beispielsweise kann der die Tessellations-Shader eine Anzahl von Aufteilungen für jeden Rand einer Primitive basierend auf einem Algorithmus erzeugen. Die Anzahl von Aufteilungen kann beispielsweise durch die Größe der Primitiven bestimmt oder basierend auf der Anzahl von Pixeln berechnet werden, die geschätzt werden,
In noch einer anderen Ausführungsform kann die Tessellationsstufe 720 durch sowohl eine Hardwareeinheit als auch eine programmierbare Einheit implementiert werden, wobei die Hardwareeinheit einen ersten Durchlauf mit grober Tessellation durchführt und die programmierbare Einheit ein bedingende feine Tessellation an den Patches durchführt, die von der Hardwareeinheit ausgegeben werden. Somit kann eine feine Tessellation durchgeführt werden, wenn die ursprüngliche grobe Tessellation nicht zu einem ausreichend feinen Netz führt.
Die Domain-Shading-Stufe 730 empfängt Patches von der Tessellationsstufe 720 und führt einen Domain-Shader aus. Der Domain-Shader ist ein Programm, das eine tesselierte Primitive als Eingabe nimmt und an jedem Vertex in der tesselierten Primitive arbeitet. Die Patches, an denen von der Domain-Shading-Stufe 730 gearbeitet werden, können in baryzentrischen Koordinaten spezifiziert sein, und der Domain-Shader kann Konstanten verwenden, die einem zugeordneten Patch zugeordnet sind, um die baryzentrischen Koordinaten in tatsächliche Koordinaten für eine bestimmte Ansicht (d. h. <x, y, z, w>) zu übersetzen. Die ausgegebenen Vertices können Positionsvektoren für jede Ansicht der zwei oder mehr Ansichten umfassen.
Die Geometrie-Shading-Stufe 640 ist ähnlich zu der Geometrie-Shading-Stufe 640 von 6. Während die Geometrie-Shading-Stufe 640 von 6 Tessellation sowie auch jede andere Verarbeitung durchführt, die innerhalb des Geometrie-Shader umfasst ist, wird die Geometrie-Shading-Stufe 640 von 7 keine Tessellation durchführen und nur zusätzliche Geometrie-Shading-Operationen durchführen, weil Tessellation bereits von der Hull-Shading-Stufe 710, der Tessellationsstufe 720 und der Domain-Shading-Stufe 730 durchgeführt worden ist. Es wird anerkannt, dass die anderen Stufen der Graphikverarbeitungs-Pipeline 700 arbeiten, wie oben in der Graphikverarbeitungs-Pipeline 600 von 6 beschrieben. Die Graphikverarbeitungs-Pipeline 700 ermöglicht einfach mehr Steuerung der Tessellation. In einigen Ausführungsformen kann die Geometrie-Shading-Stufe 640 vollständig weggelassen werden, weil die Hull-Shading-Stufe 710, die Tessellationsstufe 720 und die Domain-Shading-Stufe 740 Tessellation durchführen und keine weiteren Geometrie-Shading-Operationen erforderlich sind.
8 ist ein Konzeptdiagramm einer modifizierten Graphikverarbeitungs-Pipeline 800 gemäß einer Ausführungsform. Wie gezeigt, umfasst die Graphikverarbeitungs-Pipeline 800 eine VTG-Pipeline 810, die Darstellungsfeld-SCC-Stufe 650 und eine Raster-Pipeline 820. Die VTG-Pipeline 810 umfasst die Stufen der Graphikverarbeitungs-Pipelines 600 oder 700, die Vertex-Shading, Tessellation und Geometrie-Shading zugeordnet sind. Beispielsweise kann die VTG-Pipeline 810 die Daten-Zusammenstellungsstufe 610, die Vertex-Shading-Stufe 620, die Primitiven-Zusammenstellungsstufe 630 und die Geometrie-Shading-Stufe 640 der Graphikverarbeitungs-Pipeline 600 umfassen. Abwechselnd kann die VTG-Pipeline 810 die Daten-Zusammenstellungsstufe 610, die Vertex-Shading-Stufe 620, die Primitiven-Zusammenstellungsstufe 630, die Hull-Shading-Stufe 710, die Tessellationsstufe 720, die Domain-Shading-Stufe 730 und/oder die Geometrie-Shading-Stufe 640 der Graphikverarbeitungs-Pipeline 700 umfassen. Natürlich kann die VTG-Pipeline 810 eine oder mehrere der oben aufgelisteten Stufen weglassen oder andere Stufen umfassen, die hier nicht ausgelistet sind.
Die Graphikverarbeitungs-Pipeline 800 empfängt die Eingabedaten 601 zur Verarbeitung. Die Eingabedaten 601 umfassen Graphikprimitiven. Die Graphikprimitiven werden von der VTG-Pipeline 810 verarbeitet. Beispielsweise können die Graphikprimitiven von einem Vertex-Shader verarbeitet und von einem ein Hull-Shader und Domain-Shader tesseliert werden. Die letzte Stufe der VTG-Pipeline 810 kann konfiguriert sein, um mehrere Positionsvektoren für jeden Vertex zu erzeugen, die jeder Ansicht von zwei oder mehr Ansichten entsprechen.
Beispielsweise kann in einem stereoskopischen Bildverarbeitungssystem mit zwei Ansichten eine Vertex-Ausgabe von der VTG-Pipeline 810 zwei Positionsvektoren umfassen: einen ersten Positionsvektor, der eine erste Position (z. B., (x₀, y₀, z₀, w₀>) der Vertex für eine Ansicht des linken Auges spezifiziert; und einen zweiten Positionsvektor, der eine zweite Position (z. B., <x₁, y₁, z₁, w₁>) der Vertex für eine Ansicht des rechten Auges spezifiziert. Die unterschiedlichen Positionsvektoren für jede Ansicht können als Ansichts-abhängige Attribute für den Vertex spezifiziert werden. In einer Ausführungsform kann jede Komponente des Positionsvektors als ein separates Attribut gespeichert werden. Beispielsweise kann die x-Koordinate für einen Positionsvektor als ein erstes Attribut gespeichert werden, die y-Koordinate für einen Positionsvektor als ein zweites Attribut gespeichert werden und so weiter. In derartigen Ausführungsformen können unterschiedliche Positionsvektoren innerhalb der Datenstruktur für einen Vertex durch Spezifizieren einer Kombination von Ansichts-abhängigen Koordinatenattributen und Ansichts-unabhängigen Koordinatenattributen codiert werden. Beispielsweise können zwei unterschiedliche x-Koordinaten für zwei unterschiedliche Ansichten (d. h. Ansichts-abhängige Koordinatenattribute) spezifiziert werden, wohingegen eine einzige y-Koordinate, z-Koordinate und w-Koordinate von den Positionsvektoren für die beiden unterschiedlichen Ansichten gemeinsam genutzt werden können (d. h. Ansichts-unabhängige Koordinatenattribute). Somit können fünf Attribut zwei 4-Koordinaten-Positionsvektoren codieren und nicht acht Attribut (oder zwei 4-KoordinatenvektorAttribut) spezifizieren.
Die Darstellungsfeld-SCC-Stufe 650 kann eine Datenausgabefunktion implementieren, die den Vertexdaten ermöglicht, zu einem Puffer 830 in einem Speicher, wie beispielsweise dem Speicher 204, geströmt zu werden. Der Puffer 830 kann Vertexdaten für eine Mehrzahl von Primitiven halten. Der Puffer 830 wird gefüllt und dann wird der Puffer 830 ein oder mehrere Male ausgelesen, um die Primitiven in dem Puffer 830 über die Raster-Pipeline 820 zu rendern.
Die Raster-Pipeline 820 umfasst die Stufen der Graphikverarbeitungs-Pipelines 600 oder 700, die dem Umwandeln von 3D-Primitiven in 2D-Pixeldaten zugeordnet sind. Beispielsweise kann die Raster-Pipeline 820 die Rasterungsstufe 660, die Fragment-Shading-Stufe 670 und die Raster-Operationen-Stufe 680 der Graphikverarbeitungs-Pipelines 600 und 700 umfassen. Die Darstellungsfeld-SCC-Stufe 650 ist konfiguriert, um Vertexdaten aus dem Puffer 830 zu lesen und die Vertexdaten an die Raster-Pipeline 820 zu übertragen, um Pixeldaten für eine bestimmte Ansicht der zwei oder mehr Ansichten zu erzeugen.
Beispielsweise kann in einem stereoskopischen System mit zwei Ansichten (d. h. eine Ansicht für das linke Auge und eine Ansicht für das rechte Auge) die Darstellungsfeld-SCC-Stufe 650 der Raster-Pipeline 820 konfigurieren, um Bilddaten für ein erstes Render-Ziel zu erzeugen. Das erste Render-Ziel kann ein Frame-Puffer sein (d. h. ein Speicher zum Speichern eines 2D-Arrays von Pixelwerte), der erzeugt wird, Bilddaten für eine Ansicht des linken Auges zu speichern. Die Bilddaten können aus Pixelwerten (z. B., RGB, RGBA, CMYK, YUV usw.) für jedes Pixel einer Anzeigevorrichtung bestehen. Sobald die Raster-Pipeline 820 konfiguriert ist, kann die Darstellungsfeld-SCC-Stufe 650 die Vertexdaten aus dem Puffer 830 für die Ansicht des linken Auges lesen und die Vertexdaten an die Raster-Pipeline 820 zur Verarbeitung übertragen, um Bilddaten zu erzeugen, die in dem ersten Render-Ziel gespeichert werden. Die Darstellungsfeld-SCC-Stufe 650 kann dann die Raster-Pipeline 820 konfigurieren, um Bilddaten für ein zweites Render-Ziel zu erzeugen. Das zweite Render-Ziel kann ein Frame-Puffer sein, der erzeugt wird, um Bilddaten für eine Ansicht des rechten Auges zu speichern. Sobald die Raster-Pipeline 820 konfiguriert ist, kann die Darstellungsfeld-SCC-Stufe 650 die Vertexdaten aus dem Puffer 830 für die Ansicht des rechten Auges lesen und die Vertexdaten an die Raster-Pipeline 820 zur Verarbeitung übertragen, um Bilddaten zu erzeugen, die in dem zweiten Render-Ziel gespeichert werden.
Es wird anerkannt, dass die Größe des Puffer 830 beschränkt sein kann. Mit anderen Worten ist in einer Ausführungsform der Puffer 830 zu klein, um die Vertexdaten zu halten, die für das gesamte Modell erzeugt werden, das gerendert wird. Des Weiteren würde es ineffizient sein, Vertexdaten für das gesamte Modell zu einem Speicher zu Puffern, bevor die Vertexdaten zum Rendern eingelesen werden. Somit kann der Puffer 830 dimensioniert sein, um lediglich einen Abschnitt der Vertexdaten zu halten, die zu einem beliebigen Zeitpunkt gerendert werden. Mehrere Puffer 830 können verwendet werden, so dass die Darstellungsfeld-SCC-Stufe 650 Primitiven, die von der VTG-Pipeline 810 empfangen werden, in einen Puffer 830 ausströmen kann, während die Darstellungsfeld-SCC-Stufe 650 Primitivendaten von einem anderen Puffer 830 einliest, um sie an die Raster-Pipeline 820 zu übertragen.
In einer Ausführungsform kann der Puffer 830 dimensioniert sein, um Vertexdaten für eine einzige Primitive zu halten. Beispielsweise kann der Puffer 830 dimensioniert sein, um Vertexdaten für drei Vertices einer Dreieckprimitive zu halten. Jede Primitive, die von der VTG-Pipeline 810 mittels der Darstellungsfeld-SCC-Stufe 650 empfangen wird, wird in einem unterschiedlichen Puffer 830 gespeichert, und dann wird jede Primitive durch die Raster-Pipeline 820 eine Anzahl von Malen entsprechend der Anzahl von Ansichten gerendert. In einer anderen Ausführungsform kann der Puffer 830 dimensioniert sein, um Vertexdaten für eine Mehrzahl von Primitiven zu halten. Beispielsweise kann der Puffer 830 in der Lage sein, Vertexdaten für einige zehn oder hundert Primitiven zu speichern. Somit können viele Primitiven in dem Puffer gespeichert werden, bevor die Primitiven durch die Raster-Pipeline 820 gerendert werden. In noch einer anderen Ausführungsform wird die Größe des Puffers 830 durch einen Treiber dynamisch zugeteilt und die Darstellungsfeld-SCC-Stufe 650 konfiguriert, um Vertexdaten im Puffer 830 zu speichern, bis der Puffer voll ist. Sobald der Puffer voll ist, kann die Darstellungsfeld-SCC-Stufe 650 dann die Vertexdaten einlesen, die an die Raster-Pipeline 820 zum Rendern zu übertragen sind.
9 ist ein Konzeptdiagramm einer Datenstruktur zum Speichern von Vertexdaten im Puffer 830 gemäß einer Ausführungsform. Die Vertexdaten umfassen einen Satz von Vertexattributen. Die Attribute können eine Position, eine Farbe, einen Normalenvektor, Texturkoordinaten oder sogar benutzerdefinierte Attribut umfassen. Jedes Attribut kann einen Vektor von zwischen einer und vier Komponenten umfassen. Jede Komponente kann beispielweise ein 32-Bit-Gleitkommawert, eine 32-Bit-Ganzzahl, ein 64-Bit-Gleitkommawert und dergleichen sein. Vertexdaten werden in dem Puffer 830 gespeichert und umfassen Attribute für alle Ansichten, die gerendert werden. In einer Ausführungsform können bis zu 32 generische 128-Bit-Vertexattribut-Vektoren für jeden Vertex spezifiziert werden.
Wie in 9 gezeigt, kann eine Datenstruktur zum Speichern von Vertexdaten eine Anzahl von Feldern umfassen. Jedes Feld kann ein Ansichts-unabhängiges (gemeinsames) Attribut oder ein Ansichts-abhängiges Attribut umfassen. Ansichts-unabhängige Attribute sind für alle Ansichten aktiviert. Im Gegensatz dazu sind Ansichts-abhängige Attribut lediglich für eine Ansicht aktiviert. Wie in 9 gezeigt, sind Attribute 0 und 7 allen Ansichten gemeinsam, Attribute 1–3 sind lediglich für Ansicht 0 aktiviert und Attribute 4–6 sind lediglich für Ansicht 1 aktiviert. Die Darstellungsfeld-SCC-Stufe 650 ist konfiguriert, um sämtliche der Attribute in den Puffer 830 während der Datenausgabeoperation zu schreiben. Es wird anerkannt, dass der Positionsvektor für jede Ansicht in einem Ansichts-abhängigen Attribut spezifiziert werden kann, das für diese bestimmte Ansicht aktiviert ist. Beispielsweise kann ein Positionsvektor für Ansicht 0 im Attributindex 3 und ein Positionsvektor für Ansicht 1 im Attributindex 6 gespeichert werden. Wenn die Darstellungsfeld-SCC-Stufe 650 Vertexdaten aus dem Puffer 830 für eine bestimmte Ansicht liest, liest die Darstellungsfeld-SCC-Stufe 650 lediglich die Attribute, die für die bestimmte Ansicht aktiviert sind. Wenn die Darstellungsfeld-SCC-Stufe 650 beispielsweise die Vertexdaten für Ansicht 0 liest, kann die Darstellungsfeld-SCC-Stufe 650 Attribute 0–3 und 7 lesen. Im Gegensatz dazu kann, wenn die Darstellungsfeld-SCC-Stufe 650 die Vertexdaten für Ansicht 1 liest, die Darstellungsfeld-SCC-Stufe 650 Attribute 0 und 4–7 lesen.
Jedem Attribut ist eine Eingabeabbildung (IMAP) zugeordnet, die definiert, welche Komponenten des Vektors von der Fragment-Shading-Stufe 670 benutzt werden. Ein Compiler erzeugt die IMAP-Daten für eine einzelne Ansicht. Wie gezeigt, sind die IMAP-Daten eine Bitmap, die vier Bits für jeden Attributindex umfasst, der angibt, welche Komponenten des entsprechenden Attributvektors von der Fragment-Shading-Stufe 670 der Graphikverarbeitungs-Pipeline benutzt werden. In einer Ausführungsform werden die IMAP-Daten für eine erste Ansicht (z. B. Ansicht 0) durch den Compiler erzeugt, und eine letzte Stufe der VTG-Pipeline 810 erzeugt eine entsprechende IMAP für jede zusätzliche Ansicht der zwei oder mehreren Ansichten. Beispielsweise kann die Domain-Shading-Stufe 730 konfiguriert sein, um die IMAP 1 Daten aus den IMAP 0 Daten zu erzeugen, die von dem Compiler empfangen werden.
Es wird anerkannt, dass das Ansichts-abhängige Attribut sequentiell für jede Ansicht der zwei oder mehr Ansichten spezifiziert werden muss. Diese Anforderung ermöglicht der Darstellungsfeld-SCC-Stufe 650, das Attribut aus dem Puffer 830 für jede Ansicht zu lesen und alle Attribut in der gleichen Reihenfolge zu halten. Beispielsweise entsprechen Attribut 1, 2 und 3 für Ansicht 0 jeweils den Attributen 4, 5, und 6 für Ansicht 1. Mit anderen Worten definieren Attribute 1 und 4 unterschiedliche Werte für das gleiche Attribut der unterschiedlichen Ansichten, Attribute 2 und 5 unterschiedliche Werte für das gleiche Attribut der unterschiedlichen Ansichten, und Attribute 3 und 6 unterschiedliche Werte für das gleiche Attribut der unterschiedlichen Ansichten. Wenn die Attribute aus dem Puffer 830 gelesen werden, wird das erste Attribut Attribut 0 sein, das zweite Attribut wird Attribut 1 oder 4 (abhängig von der Ansicht) sein, das dritte Attribut wird Attribut 2 oder 5 sein, das vierte Attribut wird Attribut 3 oder 6 sein und das fünfte Attribut wird Attribut 7 sein. Somit wird ungeachtet dessen, welche Ansicht gerendert wird, die Reihenfolge der Attribute immer die gleiche sein. Dies ermöglicht der Fragment-Shading-Stufe 670, die von der Rasterungsstufe 660 empfangenen Vertexdaten auf die gleiche Weise für alle Ansichten zu verarbeiten.
10 veranschaulicht eine Abbildung von Ansichten auf Render-Ziele gemäß einer Ausführungsform. Die Graphikverarbeitungs-Pipeline kann unterschiedlichen Render-Ziele (z. B., Frame-Puffer) ermöglichen, spezifiziert zu werden, wenn Bilddaten erzeugt werden. Ein Render-Ziel ist ein Speicher, der zugeteilt ist, um ein 2D-Array von Bilddaten zu speichern. Jedes Render-Ziel kann einem Bild eines Modells entsprechen, das von einem bestimmten Betrachtungspunkt gerendert wird, der gemäß einem bestimmten Darstellungsfeld orientiert ist. In einer Ausführungsform können bis zu 4096 unterschiedliche Render-Ziele spezifiziert werden.
In einer Ausführungsform kann die Graphikverarbeitungs-Pipeline konfiguriert sein, um eine Würfelabbildung der Modellumgebung von einem bestimmten Betrachtungspunkt (d. h. einer Ansicht) zu erzeugen. Eine Würfelabbildung ist im Wesentlichen sechs Bilder, die um den Betrachtungspunkt in der Form eines Würfels gewickelt sind, und stellt das gerenderte Bild eines Modells dar, das einem bestimmten Betrachtungspunkt zugeordnet ist, der sechs unterschiedliche Betrachtungsstumpf-Orientierungen aufweist. Jeder Abschnitt der Würfelabbildung, der einer Seite des Würfels entspricht, kann in ein unterschiedliches Darstellungsfeld abgebildet werden. Die Attribute jedes Darstellungsfelds können im Spezialregister der PPU 200 gespeichert werden und sind durch die Darstellungsfeld-SCC-Stufe 650 zugänglich. Eine Darstellungsfeld-Arraymaske spezifiziert, welche Darstellungsfelder aktiviert sind. Das Darstellungsfeld-Attribut kann die Größe und Orientierung des Betrachtungsstumpfes definieren, das verwendet wird, um Primitiven in der Darstellungsfeld-SCC-Stufe 650 auszusondern und abzuschneiden. Der Betrachtungspunkt (d. h. die Kameraposition) kann für jede Ansicht unterschiedlich sein, um den Ort der virtuellen Kameraposition zu ändern. Beispielsweise kann der Betrachtungspunkt für eine erste Ansicht horizontal von einem Betrachtungspunkt einer zweiten Ansicht versetzt sein. Das Rendern von Bildern von diesen versetzten Betrachtungspunkten kann den Bilder ermöglichen, auf einer stereoskopischen Anzeige angezeigt zu werden, so dass ein Betrachter eine Tiefe der gerenderten Objekte wahrnehmen kann.
Wenn Würfelabbildungen für stereoskopische Ansichten gerendert werden, kann die Graphikverarbeitungs-Pipeline konfiguriert sein, um sechs unterschiedliche Bilder für jede der beiden Ansichten zu rendern. Die Ausgabe der Graphikverarbeitungs-Pipeline wird in einem unterschiedlichen Render-Ziel für jede Ansicht/Darstellungsfeld-Kombination gespeichert. In einer Ausführungsform ist die Darstellungsfeld-SCC-Stufe 650 konfiguriert, um die Vertexdaten in dem Puffer 830 für jedes aktive Darstellungsfeld für jede der beiden Ansichten zu wiederholen. Mit anderen Worten kann die Darstellungsfeld-SCC-Stufe 650 konfiguriert sein, um durch zwei Schleifen zu laufen, einer inneren Schleife, die einmal pro Darstellungsfeld durchlaufen wird, das über die Darstellungsfeld-Arraymaske aktiviert ist, und einer äußeren Schleife, die einmal pro aktivierter Ansicht durchlaufen wird. Während jeder Iteration der inneren Schleife liest die Darstellungsfeld-SCC-Stufe 650 die Darstellungsfelddaten für das aktive Darstellungsfeld aus dem Register und liest die Vertexdaten aus dem Puffer 830 für die aktive Ansicht. Verschiedene Operationen können an den Vertexdaten von der Darstellungsfeld-SCC-Stufe 650 durchgeführt werden (wie beispielsweise Abschneiden und Aussondern von Primitiven), und dann werden die Vertexdaten an die Raster-Pipeline 820 zum Rendern zu einem entsprechenden Render-Ziel übertragen. Während jeder Iteration der äußeren Schleife ändert die Darstellungsfeld-SCC-Stufe 650 den Ansichtsindex in die nächste Ansicht und die innere Schleife wird für jedes der aktivierten Darstellungsfelder wiederholt.
Wie in 10 gezeigt, kann jede Ansicht/Darstellungsfeld-Kombination einem bestimmten Render-Ziel zugeordnet sein, das im Speicher gespeichert ist. Eine erste Ansicht (d. h. Ansicht 0) kann einer Anzahl von unterschiedlichen Render-Zielen zugeordnet sein, die der Anzahl von aktivierten Darstellungsfeldern entspricht. Auf ähnliche Weise kann eine zweite Ansicht (d. h. Ansicht 1) ebenfalls der Anzahl von unterschiedlichen Render-Zielen zugeordnet sein, die der Anzahl von aktivierten Darstellungsfeldern entspricht. Wenn eine Würfelabbildung für jede Ansicht in diesem Fall gerendert wird, entsprechen Render-Ziele 0–5 den unterschiedlichen Abschnitten der Würfelabbildung für die erste Ansicht, und Render-Ziele 6–11 entsprechen den unterschiedlichen Abschnitten der Würfelabbildung für die zweite Ansicht.
In einer Ausführungsform kann die PPU 200 eine Hardwareeinheit umfassen, die ein Render-Ziel-Arrayindexwert basierend auf einem Ansichtsindex versetzt, der einer bestimmten Ansicht zugeordnet ist. Ein Treiber kann eine API implementieren, die einem Programmierer ermöglicht, eine Konstante zu setzen, die eine Anzahl von Render-Ziel-Arrayschichten angibt, die für jede Ansicht konfiguriert ist. Die Hardwareeinheit kann diese Konstante zusammen mit dem Ansichtsindex benutzen, welcher der aktuellen Ansicht entspricht, um einen Versatz für den Render-Ziel-Arrayindexwert zu berechnen, der durch einen Shader spezifiziert wird. Beispielsweise kann die Hardwareeinheit die Funktion berechnen: RT_array_index = RT_array_index + (konstante·ansicht_index) (Gl. 1)
Mit dem Würfelabbildungsbeispiel kann die Konstante auf 6 gesetzt werden, so dass der Render-Ziel-Arrayindexwert um sechs während des Renderns von Ansicht 1 im Vergleich mit dem entsprechenden Render-Ziel-Arrayindexwert für Ansicht 0 erhöht wird. Die Darstellungsfeld-SCC-Stufe 650 kann mindestens teilweise unter Verwendung dieser Hardwareeinheit implementiert werden, um den Render-Ziel-Arrayindex einzustellen, der während des Rendern durch den berechneten Versatz verwendet wird. In einer Ausführungsform ist die Hardwareeinheit die Raster-Engine 325.
In einer anderen Ausführungsform kann die Graphikverarbeitungs-Pipeline konfiguriert sein, um Bilder Seite-an-Seite zu erzeugen. Beispielsweise kann eine Ansicht des linken Auges und eine Ansicht des rechten Auges zu dem gleichen Render-Ziel gerendert werden. Eine Technik, um Bilder Seite-an-Seite zu erzeugen, besteht darin, zwei Ansichten eines Modells unter Verwendung zweier unterschiedlichen Darstellungsfelder, einem Darstellungsfeld für jede Ansicht, zu rendern. Jede Ansicht kann einer unterschiedlichen Darstellungsfeld-Arraymaske zugeordnet werden, welche die Darstellungsfelder spezifiziert, die für diese bestimmte Ansicht spezifiziert sind. Die erste Ansicht kann einem ersten Darstellungsfeld zugeordnet sein und die zweite Ansicht kann einem zweiten Darstellungsfeld zugeordnet sein, das von dem ersten Darstellungsfeld versetzt ist. Mit anderen Worten ist die Konfiguration des zweiten Darstellungsfelds dem ersten Darstellungsfeld mit der Ausnahme ähnlich, dass das zweite Darstellungsfeld von dem ersten Darstellungsfeld um eine Bildbreite versetzt ist, so dass die Bilddaten, die in einem einzigen Render-Ziel gespeichert sind, Seite-an-Seite gespeichert sind.
Es wird anerkannt, dass die PPU 200 eine oder mehrere Hardwareeinheiten umfassen kann, die pro Ansicht Darstellungsfeldarraymasken unterstützen. Mit anderen Worten kann die Hardwareeinheit mehrere Register benutzen, um unterschiedliche Darstellungsfeld-Arraymasken zu speichern, die den mehreren Ansichten entsprechen. Eine bestimmte Darstellungsfeld-Arraymaske kann dann aus den unterschiedlichen Registern unter Verwendung des Ansichtsindex der aktuellen Ansicht während Operationen zum Rendern jeder Ansicht ausgewählt werden. Somit kann ein unterschiedlicher Satz von Darstellungsfeldern für jede unterschiedliche Ansicht der mehreren Ansichten aktiviert werden. Ein Treiber kann die unterschiedlichen Darstellungsfeld-Arraymasken für jede Ansicht erzeugen und die Darstellungsfeld-Arraymasken in dem Register der PPU 200 speichern. In einer Ausführungsform kann die Darstellungsfeld-SCC-Stufe 650 mindestens teilweise unter Verwendung dieser Hardwareeinheit implementiert werden, um die bestimmten Darstellungsfelder, die für jede Ansicht zu rendern sind, basierend auf dem Ansichtsindex für die Ansicht automatisch auszuwählen.
Die Darstellungsfeld-SCC-Stufe 650 kann konfiguriert sein, um den Puffer für jede der Ansicht/Darstellungsfeld-Kombinationen erneut zu wiederholen. Somit kann im Fall der Würfelabbildung und zwei Ansichten der Puffer 830 zwölf Mal gelesen werden, um zwölf unterschiedliche Bilder in den zwölf unterschiedlichen Render-Zielen zu rendern. Es wird anerkannt, dass das Wiederholen des Puffers 830 zwölf Mal und Rendern der zwölf unterschiedlichen Bilder unter Verwendung der Raster-Pipeline 820 effizienter als die Verarbeitung des gesamten Modells durch die gesamte Graphikverarbeitungs-Pipeline zwölf Mal ist, da die Modelldaten lediglich durch die VTG-Pipeline 810 einmal verarbeitet werden.
Des Weiteren können Vorteile des Parallelismus benutzt werden, so dass mehrere Raster-Pipelines 820 parallel betrieben werden können, um Bilddaten für unterschiedliche Darstellungsfelder gleichzeitig zu erzeugen, um die Anzahl von Malen zu verringern, die Vertexdaten aus dem Puffer eingelesen werden müssen. Beispielsweise können mehrere TPCs 320 konfiguriert werden, um die Raster-Pipelines 820 zu implementieren, um Bilddaten für jede der sechs aktivierten Darstellungsfelder jeder Ansicht zu rendern. Da Attributdaten die gleichen für eine bestimmte Ansicht sind, kann auf Daten, die aus dem Speicher in einen gemeinsam benutzten Cache-Speicher, wie beispielsweise ein L2-Cache-Speicher 360, gelesen werden, von jeder der unterschiedlichen Raster-Pipelines 820 schnell zugegriffen werden, um unterschiedliche Bilddaten basierend auf den unterschiedlichen Darstellungsfeldern zu erzeugen. Die Parallelarchitektur kann die VTG-Pipeline 810 daran hindern, zum Stillstand zu kommen, weil alle Puffer 830, die verfügbar sind, um neue Vertexdaten auszuströmen, benutzt werden.
Wie hier verwendet, können die unterschiedlichen Stufen der Graphikverarbeitungs-Pipelines innerhalb der Architektur der PPU 200 implementiert werden. Einige Stufen der Graphikverarbeitungs-Pipelines können auf programmierbaren Einheiten implementiert werden, die konfiguriert sind, um Anweisungen eines Programms auszuführen. Beispielsweise können die Vertex-Shading-Stufe 620, die Hull-Shading-Stufe 710, die Domain-Shading-Stufe 730, die Geometrie-Shading-Stufe 640 und die Fragment-Shading-Stufe 670 von einem SM 340 implementiert werden, der konfiguriert ist, um Anweisungen von verschiedenen Shader-Programmen auszuführen. Die SMs 340 können die Shader-Programme unter Verwendung von mehreren Threads in der Parallelverarbeitung unterschiedlicher Daten ausführen. Andere Stufen der Graphikverarbeitungs-Pipeline können auf Festfunktions-Hardwareeinheiten implementiert sein, die zu einem gewissen Ausmaß konfigurierbar sind. Beispielsweise können die Darstellungsfeld-SCC-Stufe 650 und die Rasterungsstufe durch die Raster-Engine 325 implementiert werden.
11 veranschaulicht ein beispielhaftes System 1100, in welchem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorangehenden Ausführungsformen implementiert werden können. Wie gezeigt, wird ein System 1100 bereitgestellt, das mindestens einen zentralen Prozessor 1101 aufweist, der mit einem Kommunikationsbus 1102 verbunden ist. Der Kommunikationsbus 1102 kann unter Anwendung eines beliebigen geeigneten Protokolls, wie beispielsweise durch PCI (periphere Komponenten-Zwischenverbindung), PCI-Express, AGP (beschleunigter Graphikport), HyperTransport oder durch ein oder mehrere andere Bus-Protokolle oder Punkt-Zu-Punkt-Kommunikationsprotokolle implementiert werden. Das System 1100 kann ferner einen Hauptspeicher 1104 aufweisen. Steuerlogik (Software) und Daten sind in dem Hauptspeicher 1104 gespeichert, der die Form eines Speichers mit wahlfreiem Zugriff (RAM) aufweisen kann.
Das System 1100 umfasst ferner Eingabevorrichtungen 1112, einen Graphikprozessor 1106 und eine Anzeige 1108, d. h. eine herkömmliche CRT (Kathodenstrahlröhre), eine LCD (Flüssigkristallanzeige), eine LED (lichtemittierende Diode), eine Plasmaanzeige oder dergleichen. Eine Anwendereingabe kann über die Eingabevorrichtungen 1112, beispielsweise Tastatur, Maus, berührungsempfindliche Auflage, Mikrophon und dergleichen, empfangen werden. In einer Ausführungsform kann der Graphikprozessor 1106 eine Mehrzahl von Shading-Modulen, ein Rastermodul, usw. aufweisen. Jedes der vorangehenden Module kann in einer einzelnen Halbleiterplattform angeordnet sein, so dass eine graphische Verarbeitungseinheit (GPU) gebildet ist.
In der vorliegenden Beschreibung kann eine einzelne Halbleiterplattform eine einzelne alleinstehende halbleiterbasierte integrierte Schaltung oder einen Chip bezeichnen. Es sollte beachtet werden, dass der Begriff einzelne Halbleiterplattform auch Multi-Chip-Module mit vergrößerter Verbindungsstruktur bezeichnen kann, die einen chipinternen Betrieb simulieren, und die eine wesentliche Verbesserung gegenüber der Verwendung einer Realisierung mit herkömmlicher zentraler Recheneinheit (CPU) und einem Bus darstellen. Selbstverständlich können die verschiedenen Module auch separat oder in verschiedenen Kombinationen von Halbleiterplattformen entsprechend den Bedürfnissen des Anwenders angeordnet sein. Der nicht-wiederherstellende statische Signalspeicher 300 und/oder die nicht-wiederherstellende Haupt-Signalspeicher-mit-Abtastung-Schaltung 420 können in einer oder mehreren der folgenden Komponenten integriert sein: dem zentralen Prozessor 1101, dem Hauptspeicher 1104, einem sekundären Speicher 1110, den Eingabevorrichtungen 1112, dem Graphikprozessor 1106, der Anzeige 1108 und dem Bus 1102.
Das System 1100 kann ebenfalls einen sekundären Speicher 1110 umfassen. Der sekundäre Speicher 1110 umfasst beispielsweise eine Festplatte und/oder eine entfernbare Speicherplatte, die ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein Kompaktdisketten-Laufwerk, ein Laufwerk für eine digitale Vielseitigkeitsdiskette (DVD), ein Aufzeichnungsgerät, einen Flash-Speicher mit universellem seriellen Bus (USB) repräsentieren kann. Die entfernbare Speichervorrichtung liest in eine und/oder schreibt aus einer entfernbaren Speichereinheit auf eine bekannte Art und Weise.
Computerprogramme oder Computer-Steuerlogikalgorithmen können in dem Hauptspeicher 1104 und/oder in dem sekundären Speicher 1110 gespeichert sein. Derartige Computerprogramme versetzen, wenn sie ausgeführt werden, das System 1100 in die Lage, verschiedene Funktionen auszuführen. Der Hauptspeicher 1104, der Speicher 1110 und/oder ein beliebiger anderer Speicher sind mögliche Beispiele für computerlesbare Medien.
In einer Ausführungsform können die Architektur und/oder Funktionalität der verschiedenen vorherigen Figuren im Zusammenhang mit dem zentralen Prozessor 1101, dem Graphikprozessor 1106, einer integrierten Schaltung (nicht gezeigt), die zumindest einen Teil der Fähigkeiten sowohl des zentralen Prozessors 1101 als auch des Graphikprozessors 1106 aufweist, mit einem Chipsatz (das heißt, einer Gruppe aus integrierten Schaltungen, die so gestaltet ist, dass sie als Einheit zur Ausführung zugehöriger Funktionen arbeiten und als solche verkauft wird, usw.) und/oder mit einer anderen integrierten Schaltung für diesen Zweck implementiert werden.
Ferner können die Architektur und/oder Funktionalität der verschiedenen vorangehenden Figuren auch im Rahmen eines allgemeinen Computersystems, eines Systems aus Leiterplatten, eines Systems mit Spielekonsole, die für Unterhaltungszwecke gedacht ist, im Rahmen eines anwendungsspezifischen Systems und/oder im Rahmen eines anderen gewünschten Systems implementiert werden. Beispielsweise kann das System 1100 die Form eines Tischrechners, eines Laptops, eines Dienstleister-Rechners, eines Arbeitsplatzrechners, von Spielekonsolen, eines eingebetteten Systems und/oder einer beliebigen anderen Art von Logik annehmen. Des Weiteren kann das System 1100 die Form verschiedener anderer Vorrichtungen annehmen, wozu gehören, ohne Einschränkung, eine Vorrichtung als persönlicher digitaler Assistent (PDA), eine Vorrichtung als Mobiltelefon, eine Vorrichtung als Fernsehgerät, usw.
Obwohl dies nicht gezeigt ist, kann das System 1100 mit einem Netzwerk (beispielsweise einem Telekommunikationsnetzwerk, einem Nahbereichsnetzwerk (LAN), einem drahtlosen Netzwerk, einem Weitbereichsnetzwerk (WAN), wie etwa das Internet, einem Gerät-zu-Gerät-Netzwerk, einem Kabelnetzwerk oder dergleichen) für Kommunikationszwecke verbunden sein.
Obwohl verschiedene Ausführungsformen zuvor beschrieben wurden, sollte beachtet werden, dass diese nur als Beispiel und nicht als Einschränkung vorgestellt werden. Daher sollte die Breite und der Schutzumfang einer bevorzugten Ausführungsform nicht durch eine der zuvor beschriebenen anschaulichen Ausführungsformen eingeschränkt werden, sondern sollten nur entsprechend den folgenden Patentansprüchen und ihren Äquivalenten definiert sein.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

IEEE 754-2008 Standard [0057]

Claims

Verfahren, umfassend: Konfigurieren einer Graphikverarbeitungs-Pipeline, um Primitivendaten für ein Modell gemäß mindestens zwei Ansichten zu rendern; Empfangen der Primitivendaten für das Modell an einem ersten Abschnitt der Graphikverarbeitungs-Pipeline; Verarbeiten, innerhalb des ersten Abschnitts der Graphikverarbeitungs-Pipeline, der Primitivendaten, um verarbeitete Primitivendaten zu erzeugen, wobei die verarbeiteten Primitivendaten Vertexdaten für mindestens eine Primitive umfassen, und wobei jede Primitive eine Mehrzahl von Vertices umfasst, wobei jeder Vertex in der Mehrzahl von Vertices eine Datenstruktur umfasst, die mindestens zwei Vertexattribute umfasst, wobei die mindestens zwei Vertexattribute eine Anzahl von Positionsvektoren umfassen, die einer Anzahl von Ansichten in den mindestens zwei Ansichten entspricht; Speichern der verarbeiteten Primitivendaten in einem Puffer in einem Speicher; und für jede Ansicht der mindestens zwei Ansichten: Auswählen einer bestimmten Ansicht der mindestens zwei Ansichten, Lesen der verarbeiteten Primitivendaten aus dem Puffer basierend auf der ausgewählten Ansicht, und Erzeugen von Bilddaten für die ausgewählte Ansicht innerhalb eines zweiten Abschnitts der Graphikverarbeitungs-Pipeline.
Verfahren gemäß Anspruch 1, wobei der erste Abschnitt der Graphikverarbeitungs-Pipeline eine Geometrie-Shading-Stufe umfasst, und wobei die Geometrie-Shading-Stufe durch Konfigurieren eines Streaming-Multiprozessors einer Parallelverarbeitungseinheit implementiert wird, um, über einen oder mehrere Threads, einen Geometrie-Shader auszuführen, der einen oder mehrere Threads konfiguriert, um die Anzahl von Positionsvektoren für jeden Vertex zu erzeugen.
Verfahren gemäß Anspruch 1 oder 2, wobei der erste Abschnitt der Graphikverarbeitungs-Pipeline eine Domain-Shading-Stufe umfasst, und wobei die Domain-Shading-Stufe durch Konfigurieren eines Streaming-Multiprozessors einer Parallelverarbeitungseinheit implementiert wird, um über einen oder mehrere Threads einen Domain-Shader auszuführen, der einen oder mehrere Threads konfiguriert, um die Anzahl von Positionsvektoren für jeden Vertex zu erzeugen.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der erste Abschnitt der Graphikverarbeitungs-Pipeline eine Vertex-Shading-Stufe umfasst, und wobei die Vertex-Shading-Stufe durch Konfigurieren eines Streaming-Multiprozessors einer Parallelverarbeitungseinheit implementiert wird, um, über einen oder mehrere Threads, einen Vertex-Shader auszuführen, der einen oder mehrere Threads konfiguriert, um die Anzahl von Positionsvektoren für jeden Vertex zu erzeugen.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der zweite Abschnitt der Graphikverarbeitungs-Pipeline mindestens eine einer Rasterungsstufe, einer Fragment-Shading-Stufe und einer Raster-Operationen-Stufe umfasst.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Graphikverarbeitungs-Pipeline eine Darstellungsfeld-SCC-Stufe umfasst, die konfiguriert ist, um die verarbeiteten Primitivendaten im Puffer zu speichern und die verarbeiteten Primitivendaten aus dem Puffer basierend auf der ausgewählten Ansicht zu lesen.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei eine Parallelverarbeitungseinheit eine Raster-Engine umfasst, die konfiguriert ist, um die verarbeiteten Primitivendaten in dem Puffer zu speichern, die verarbeiteten Primitivendaten aus dem Puffer eine Anzahl von Malen zu lesen, die der Anzahl von Ansichten in den mindestens zwei Ansichten entspricht, und die verarbeiteten Primitivendaten an den zweiten Abschnitt der Graphikverarbeitungs-Pipeline zu übertragen, um die verarbeiteten Primitivendaten zu rendern und Bilddaten für jede Ansicht in den mindestens zwei Ansichten zu erzeugen.
Verfahren gemäß Anspruch 7, wobei sechs Darstellungsfelder für jede Ansicht aktiviert sind, und wobei die sechs Darstellungsfelder konfiguriert sind, um eine Würfelabbildung des Modells entsprechend jeder Ansicht zu erzeugen.
Verfahren gemäß Anspruch 7 oder 8, wobei die Raster-Engine konfiguriert ist, ein unterschiedliches Render-Ziel zum Speichern von Bilddaten auszuwählen, das jeder bestimmten Ansicht der mindestens zwei Ansichten entspricht, durch Berechnen eines Versatzes für einen Render-Ziel-Arrayindex basierend auf einem Ansichtsindex für die bestimmte Ansicht multipliziert mit einer Konstanten.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Graphikverarbeitungs-Pipeline konfiguriert ist, Primitivendaten für zwei Ansichten zu rendern, um stereoskopische Bilddaten zu erzeugen.
Verfahren gemäß Anspruch 10, wobei Bilddaten für eine erste Ansicht der stereoskopische Bilddaten in einem erstem Abschnitt eines Render-Ziels gespeichert werden und Bilddaten für eine zweite Ansicht der stereoskopische Bilddaten in einem zweiten Abschnitt des Render-Ziels gespeichert werden, wobei die Bilddaten für die erste Ansicht gemäß einer erste Darstellungsfeld-Arraymaske gerendert werden, die spezifiziert, dass ein erstes Darstellungsfeld aktiviert ist, und die Bilddaten für die zweiten Ansicht gemäß einer zweiten Darstellungsfeld-Arraymaske gerendert werden, die spezifiziert, dass ein zweites Darstellungsfeld aktiviert ist.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei das Erzeugen von Bilddaten für die ausgewählte Ansicht innerhalb des zweiten Abschnitts der Graphikverarbeitungs-Pipeline das Erzeugen von Bilddaten umfasst, die jedem aktivierten Darstellungsfeld entsprechen, das durch eine Darstellungsfeld-Arraymaske spezifiziert ist, wobei jede Ansicht der mindestens zwei Ansichten einer unterschiedlichen Darstellungsfeld-Arraymaske entspricht.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Positionsvektoren innerhalb der mindestens zwei Attribute als eine Kombination von Ansichts-abhängigen Koordinatenattributen und Ansichts-unabhängigen Koordinatenattributen codiert sind.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Datenstruktur für jeden Vertex eine Anzahl von Attributen umfasst, und wobei jedes Attribut für einen bestimmten Vertex als ein Ansichts-abhängiges Attribut oder ein Ansichts-unabhängiges Attribut spezifiziert ist.
Nicht-transitorisches computerlesbares Speichermedium, das Anweisungen speichert, die, wenn durch einen Prozessor ausgeführt, den Prozessor veranlassen, Schritte durchzuführen, umfassend: Konfigurieren einer Graphikverarbeitungs-Pipeline, um Primitivendaten für ein Modell gemäß mindestens zwei Ansichten zu rendern; Empfangen der Primitivendaten für das Modell an einem ersten Abschnitt der Graphikverarbeitungs-Pipeline; Verarbeiten, innerhalb des ersten Abschnitts der Graphikverarbeitungs-Pipeline, der Primitivendaten, um verarbeitete Primitivendaten zu erzeugen, wobei die verarbeiteten Primitivendaten Vertexdaten für mindestens eine Primitive umfassen, und wobei jede Primitive eine Mehrzahl von Vertices umfasst, wobei jeder Vertex in der Mehrzahl von Vertices eine Datenstruktur umfasst, die mindestens zwei Vertexattribute umfasst, wobei die mindestens zwei Vertexattribute eine Anzahl von Positionsvektoren umfasst, die einer Anzahl von Ansichten in den mindestens zwei Ansichten entspricht; Speichern der verarbeiteten Primitivendaten in einem Puffer in einem Speicher; und für jede Ansicht der mindestens zwei Ansichten: Auswählen einer bestimmten Ansicht der mindestens zwei Ansichten, Lesen der verarbeiteten Primitivendaten aus dem Puffer basierend auf der ausgewählten Ansicht, und Erzeugen von Bilddaten für die ausgewählte Ansicht innerhalb eines zweiten Abschnitts der Graphikverarbeitungs-Pipeline.
Nicht-transitorisches computerlesbares Speichermedium gemäß Anspruch 15, das Anweisungen speichert, die, wenn durch den Prozessor ausgeführt, den Prozessor veranlassen, ein Verfahren durchzuführen, wie in einem der Ansprüche 2 bis 14 erwähnt.
System, umfassend: eine Parallelverarbeitungseinheit, die konfiguriert ist, um eine oder mehrere Stufen einer Graphikverarbeitungs-Pipeline zu implementieren, wobei die Parallelverarbeitungseinheit konfiguriert ist, um: Primitivendaten für ein Modell gemäß mindestens zwei Ansichten zu rendern, die Primitivendaten für das Modell an einem ersten Abschnitt in der Graphikverarbeitungs-Pipeline zu empfangen, innerhalb des ersten Abschnitts der Graphikverarbeitungs-Pipeline die Primitivendaten zu verarbeiten, um verarbeitete Primitivendaten zu erzeugen, wobei die verarbeiteten Primitivendaten Vertexdaten für mindestens eine Primitive umfassen, und wobei jede Primitive eine Mehrzahl von Vertices umfasst, wobei jeder Vertex in der Mehrzahl von Vertices eine Datenstruktur umfasst, die mindestens zwei Vertexattribute umfasst, wobei die mindestens zwei Vertexattribute eine Anzahl von Positionsvektoren umfassen, die einer Anzahl von Ansichten in den mindestens zwei Ansichten entspricht, die verarbeiteten Primitivendaten in einem Puffer in einem Speicher zu speichern, und für jede Ansicht der mindestens zwei Ansichten: eine bestimmte Ansicht der mindestens zwei Ansichten auszuwählen, die verarbeiteten Primitivendaten aus dem Puffer basierend auf der ausgewählten Ansicht zu lesen, und Bilddaten für die ausgewählte Ansicht innerhalb eines zweiten Abschnitts der Graphikverarbeitungs-Pipeline zu erzeugen.
System gemäß Anspruch 17, wobei der erste Abschnitt der Graphikverarbeitungs-Pipeline mindestens eine einer Vertex-Shading-Stufe, einer Domain-Shading-Stufe und einer Geometrie-Shading-Stufe umfasst; wobei der zweite Abschnitt der Graphikverarbeitungs-Pipeline mindestens eine einer Rasterungsstufe, einer Fragment-Shading-Stufe und einer Raster-Operationen-Stufe umfasst; und wobei die Graphikverarbeitungs-Pipeline ferner eine Darstellungsfeld-SCC-Stufe zwischen dem ersten Abschnitt der Graphikverarbeitungs-Pipeline und dem zweiten Abschnitt der Graphikverarbeitungs-Pipeline umfasst.
System gemäß Ansprüchen 17 oder 18, wobei die Parallelverarbeitungseinheit eine Raster-Engine umfasst, die konfiguriert ist, um die verarbeiteten Primitivendaten in dem Puffer zu speichern, die verarbeiteten Primitivendaten aus dem Puffer eine Anzahl von Malen zu lesen, die der Anzahl von Ansichten in den mindestens zwei Ansichten entspricht, und die verarbeiteten Primitivendaten an den zweiten Abschnitt der Graphikverarbeitungs-Pipeline zu übertragen, um die verarbeiteten Primitivendaten zu rendern und Bilddaten für jede Ansicht in den mindestens zwei Ansichten zu erzeugen.
System gemäß Anspruch 19, wobei sechs Darstellungsfelder für jede Ansicht aktiviert sind und wobei die sechs Darstellungsfeld konfiguriert sind, um eine Würfelabbildung des Modells entsprechend jeder Ansicht zu erzeugen.
System gemäß einem der Ansprüche 17 bis 20, wobei die Graphikverarbeitungs-Pipeline konfiguriert ist, um Primitivendaten für zwei Ansichten zu rendern, um stereoskopische Bilddaten zu erzeugen.