DE102021127982A1 - Streaming eines lichtfeldes mit verlustfreier oder verlustbehafteter kompression - Google Patents

Streaming eines lichtfeldes mit verlustfreier oder verlustbehafteter kompression Download PDF

Info

Publication number
DE102021127982A1
DE102021127982A1 DE102021127982.8A DE102021127982A DE102021127982A1 DE 102021127982 A1 DE102021127982 A1 DE 102021127982A1 DE 102021127982 A DE102021127982 A DE 102021127982A DE 102021127982 A1 DE102021127982 A1 DE 102021127982A1
Authority
DE
Germany
Prior art keywords
light field
scene
data
compressed
memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102021127982.8A
Other languages
English (en)
Inventor
Michael Stengel
Alexander Majercik
Ben Boudaoud
Morgan McGuire
Dawid STANISLAW PAJAK
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE102021127982A1 publication Critical patent/DE102021127982A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/3012—Organisation of register space, e.g. banked or distributed register file
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3802—Instruction prefetching
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/60—Memory management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/04—Texture mapping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/06—Ray-tracing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Graphics (AREA)
  • Biophysics (AREA)
  • Molecular Biology (AREA)
  • Artificial Intelligence (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • General Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Signal Processing (AREA)
  • Image Generation (AREA)

Abstract

Ein entferntes Gerät verwendet Raytracing, um ein Lichtfeld für eine zu rendernde Szene zu berechnen, wobei das Lichtfeld Informationen über das von den Oberflächen innerhalb der Szene reflektierte Licht umfasst. Dieses Lichtfeld wird dann unter Verwendung einer verlustfreien oder verlustbehafteten Komprimierung und einer oder mehrerer Videokomprimierungstechniken komprimiert, die eine zeitliche Wiederverwendung implementieren, so dass nur die Unterschiede zwischen dem Lichtfeld für die Szene und einem Lichtfeld für eine vorherige Szene komprimiert werden. Die komprimierten Lichtfelddaten werden dann an ein Client-Gerät gesendet, das die Lichtfelddaten dekomprimiert und unter Verwendung von solchen Daten das Lichtfeld für die Szene am Client-Gerät erhält. Dieses Lichtfeld wird dann unter Verwendung von dem Client-Gerät zur Berechnung einer globalen Beleuchtung für die Szene verwendet. Die globale Beleuchtung kann verwendet werden, um die Szene auf dem mobilen Gerät genau zu rendern, was zu einer realistischen Szene führt, die von dem mobilen Gerät dargestellt wird.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Erfindung bezieht sich auf das Rendering (dt. auch Bildsynthese) von Bildern und insbesondere auf die Durchführung einer globalen Beleuchtung (engl. Global Illumination) für eine Szene.
  • HINTERGRUND
  • Die heutigen Hochleistungs-Grafiksysteme für Spiele verfügen über mehrere Grafikprozessoren, hardwarebeschleunigtes Raytracing und effiziente Algorithmen und können mit globaler Raytracing-Beleuchtung eine Rendering-Qualität erreichen, die der eines Kinofilms nahe kommt, während die Interaktionslatenz in Millisekunden gemessen wird. Diese High-End-Systeme setzen Erwartungen voraus, die derzeit nur schwer von weniger leistungsfähigen Verbraucherplattformen erfüllt werden können, die durch thermische Beschränkungen, Akkuleistung und begrenzte GPU-Funktionen eingeschränkt sind.
  • Aktuelle cloud-basierte Grafiklösungen streamen (dt. gleichzeitige Übertragung und Wiedergabe von Video- und/oder Audiodaten) den gesamten Inhalt als vollständig gerenderte Bilder von einem entfernten Server zu einem Client. Auf dem Client wird der Videostream dekomprimiert und auf der Anzeige dargestellt. Netzwerklatenz, Bandbreitenbeschränkungen und steigende Bildschirmauflösungen und Bildwiederholraten gefährden jedoch die Zukunftsfähigkeit dieses Ansatzes. Es besteht daher die Notwendigkeit, ein verteiltes Rendering-System mit geringerer Bandbreite und Latenzzeit zu implementieren.
  • Figurenliste
    • 1 zeigt ein Flussdiagramm eines Verfahrens zum Streaming eines komprimierten Lichtfelds gemäß einem Ausführungsbeispiel.
    • 2 zeigt eine Parallelverarbeitungseinheit gemäß einem Ausführungsbeispiel.
    • 3A zeigt einen allgemeinen Verarbeitungscluster innerhalb der Parallelverarbeitungseinheit von 2 gemäß einem Ausführungsbeispiel.
    • 3B zeigt eine Speicherpartitionseinheit der Parallelverarbeitungseinheit von 2 gemäß einem Ausführungsbeispiel.
    • 4A zeigt den Streaming-Multiprozessor von 3A gemäß einem Ausführungsbeispiel.
    • 4B zeigt ein konzeptionelles Diagramm eines Verarbeitungssystems, das unter Verwendung der PPU von 2 gemäß einem Ausführungsbeispiel implementiert ist.
    • 4C zeigt ein exemplarisches System, in dem die verschiedenen Architekturen und/oder Funktionalitäten der verschiedenen vorherigen Ausführungsbeispiele implementiert werden können.
    • 5 zeigt ein konzeptionelles Diagramm einer Grafikverarbeitungspipeline, die gemäß einem Ausführungsbeispiel durch die PPU von 2 implementiert ist.
    • 6 zeigt ein Blockdiagramm eines beispielhaften Spiel-Streaming-Systems, das sich zur Verwendung bei der Implementierung einiger Ausführungsbeispiele der vorliegenden Offenbarung eignet.
    • 7 zeigt ein Blockdiagramm eines beispielhaften Rechengerätes, das zur Verwendung bei der Implementierung einiger Ausführungsbeispiele der vorliegenden Offenbarung eignet.
    • 8 zeigt ein Flussdiagramm eines Verfahrens zum Streaming eines Lichtfeldes, das gemäß einem Ausführungsbeispiel mit verlustfreier oder verlustbehafteter Kompression komprimiert wurde.
    • 9 zeigt ein Flussdiagramm eines Verfahrens zum Empfangen und Dekomprimieren eines komprimierten Lichtfelds, das gemäß einem Ausführungsbeispiel unter Verwendung einer Farbkonvertierung komprimiert wurde.
    • 10 zeigt ein exemplarisches verteiltes Rendering-System gemäß einem Ausführungsbeispiel.
    • 11 zeigt einen exemplarischen Datenfluss gemäß einem Ausführungsbeispiel.
  • DETAILLIERTE BESCHREIBUNG
  • Ein entferntes Gerät (z. B. ein Server oder ein oder mehrere verteilte Rechenknoten) nutzt Raytracing (dt. auch Strahlenverfolgung), um ein Lichtfeld für eine zu rendernde Szene zu berechnen, wobei das Lichtfeld Informationen über das von Oberflächen innerhalb der Szene reflektierte Licht enthält. Dieses Lichtfeld wird dann auf effiziente Weise komprimiert, indem eine oder mehrere Videokomprimierungstechniken verwendet werden, die eine zeitliche Wiederverwendung implementieren, so dass nur Unterschiede zwischen dem Lichtfeld für die Szene und einem Lichtfeld für eine vorherige Szene komprimiert werden. Dadurch wird die Menge der zu übertragenden Daten minimiert. Die komprimierten Lichtfelddaten werden dann an ein Client-Gerät (z. B. ein mobiles Rechengerät) gesendet, das die Lichtfelddaten dekomprimiert und unter Verwendung dieser Daten das Lichtfeld für die Szene am Client-Gerät erhält. Dieses Lichtfeld wird dann unter Verwendung von dem Client-Gerät zur Berechnung der globalen Beleuchtungsstärke für die Szene verwendet. Die globale Beleuchtung kann verwendet werden, um die Szene auf dem mobilen Gerät genau zu rendern (dt. auch eine Bildsynthese für die Szene durchzuführen), was zu einer realistischen Szene führt, die von dem mobilen Gerät einem oder mehreren Benutzern präsentiert wird.
  • 1 zeigt ein Flussdiagramm eines Verfahrens 100 zum Streamen eines komprimierten Lichtfeldes gemäß einem Ausführungsbeispiel. Obwohl das Verfahren 100 im Zusammenhang mit einer verarbeitenden Einheit beschrieben wird, kann das Verfahren 100 auch von einem Programm, einer benutzerdefinierten Schaltungsanordnung oder einer Kombination aus benutzerdefinierter Schaltungsanordnung und einem Programm ausgeführt werden. Beispielsweise kann das Verfahren 100 von einer GPU (Grafikverarbeitungseinheit), einer CPU (Zentraleinheit) oder einem beliebigen Prozessor ausgeführt werden, der in der Lage ist, paralleles Filtern von Pfadräumen durch Hashing (dt. auch Durchführen eines Hash-Verfahrens) durchzuführen. Darüber hinaus versteht der Fachmann, dass jedes System, das das Verfahren 100 ausführt, in den Umfang und den Geist der Ausführungsbeispiele der vorliegenden Erfindung fällt.
  • Es ist zu verstehen, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Weiter handelt es sich bei vielen der hier beschriebenen Elemente um funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionalitäten, die von Einheiten ausgeführt werden, können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
  • Wie in Operation 102 gezeigt, wird eine zu rendernde Szene an einem entfernten Gerät identifiziert. In einem Ausführungsbeispiel kann die Szene ein Standbild, ein Einzelbild innerhalb eines Videos, ein Einzelbild innerhalb eines Videospiels usw. enthalten. In einem anderen Ausführungsbeispiel kann das entfernte Gerät einen Rechenknoten in einem verteilten Rechensystem, einen oder mehrere Knoten in einer cloud-basierten Rechenumgebung, ein Server-Rechengerät usw. enthalten. In einem weiteren Ausführungsbeispiel kann das entfernte Gerät physisch von einem Client-Gerät getrennt sein.
  • Zum Beispiel kann das Client-Gerät gerenderte Szenen für einen oder mehrere Benutzer anzeigen (z. B. unter Verwendung von einer oder mehreren Anzeigen usw.). In einem anderen Beispiel können das entfernte Gerät und das Client-Gerät über ein oder mehrere drahtgebundene und/oder drahtlose Kommunikationsnetze (z. B. eine drahtlose Internetverbindung, ein Mobilfunknetz) kommunizieren.
  • Zusätzlich wird, wie in Operation 104 gezeigt, ein Lichtfeld für die Szene auf dem entfernten Gerät unter Verwendung von Raytracing berechnet. In einem Ausführungsbeispiel kann das entfernte Gerät eine Strahlenverfolgung innerhalb einer Szene durchführen, um das Lichtfeld für die Szene zu bestimmen. Die Strahlenverfolgung kann z. B. die Verfolgung eines Lichtweges als Pixel in einer Bildebene und die Simulation der Auswirkungen des Zusammentreffens mit Objekten innerhalb der Szene enthalten.
  • Weiter kann in einem Ausführungsbeispiel das Raytracing in Echtzeit durchgeführt werden. In einem Ausführungsbeispiel kann das Lichtfeld für eine Szene einen oder mehrere Vektoren enthalten, die eine Lichtmenge beschreiben, die in eine oder mehrere Richtungen durch einen oder mehrere Punkte im Raum innerhalb der Szene fließt. Beispielsweise kann das Lichtfeld einer Szene eine Vektorfunktion enthalten, die die Menge an Licht beschreibt, die in jede Richtung durch jeden Punkt im Raum innerhalb der Szene fließt. In einem anderen Ausführungsbeispiel kann das Lichtfeld eine Vielzahl von Lichtproben (engl. light probes, dt. auch Light-Probe) enthalten. In einem weiteren Ausführungsbeispiel kann jede Lichtprobe innerhalb des Lichtfeldes Informationen über das von den Oberflächen innerhalb der Szene reflektierte Licht speichern. In einem weiteren Ausführungsbeispiel kann das Lichtfeld ein Array von Blöcken (z. B. eine Vielzahl von Texelblöcken) enthalten, die die Lichtproben repräsentieren.
  • Weiter kann in einem Ausführungsbeispiel jeder Block innerhalb des Arrays Farbtexturinformationen und Sichtbarkeitstexturinformationen enthalten. Die Farbtexturinformationen können zum Beispiel Informationen über die Beleuchtungsfarbe innerhalb des Blocks enthalten. In einem anderen Beispiel können die Sichtbarkeitstexturinformationen Abstandsinformationen enthalten (z. B. einen Abstand zu einem nächstgelegenen Objekt/einer nächstgelegenen Oberfläche innerhalb des Blocks). In einem anderen Ausführungsbeispiel kann das Lichtfeld unter Verwendung eines Prozessors (z.B. einer Grafikverarbeitungseinheit (GPU), etc.) berechnet werden.
  • Wie in Operation 106 gezeigt, wird das Lichtfeld auf dem entfernten Gerät komprimiert, um komprimierte Lichtfelddaten für die Szene zu erzeugen. In einem Ausführungsbeispiel kann das entfernte Gerät das Lichtfeld unter Verwendung einer Videocodier- und/oder Videokomprimierungseinheit komprimieren. Die Einheit kann zum Beispiel in einer GPU bereitgestellt sein.
  • Darüber hinaus kann in einem Ausführungsbeispiel das Lichtfeld unter Verwendung von einem oder mehreren Videokompressionsalgorithmen/-techniken komprimiert werden. Beispielsweise kann das Lichtfeld unter Verwendung von GPU-beschleunigter HDR-Videokompression (High Dynamic Range) komprimiert werden, die über einen vorgegebenen Videocodierungs-/Komprimierungsstandard implementiert wird. In einem anderen Ausführungsbeispiel kann während der Komprimierung des Lichtfelds eine zeitliche Wiederverwendung implementiert werden. So können beispielsweise Informationen aus der Komprimierung zuvor gerenderter Szenen bei der Komprimierung einer aktuellen Szene verwendet werden. In einem anderen Beispiel können nur die Unterschiede zwischen dem Lichtfeld für die Szene und einem Lichtfeld für eine vorherige Szene als Lichtfelddaten komprimiert/gesendet werden.
  • Auf diese Weise können zeitliche Abhängigkeiten zwischen aufeinanderfolgenden Szenen genutzt werden, um die Menge der zu komprimierenden Daten zu reduzieren. Dies kann die Komprimierungsleistung erhöhen (z. B. durch Verringerung der für die Komprimierung des Lichtfelds benötigten Zeit) und kann die über ein Netzwerk an ein Gerät gesendete Datenmenge im Vergleich zu aktuellen Verfahren zur Implementierung der Komprimierung, die keine zeitlichen Abhängigkeiten nutzen, verringern.
  • Darüber hinaus kann in einem Ausführungsbeispiel die Kompression eine aktuelle Benutzeransicht innerhalb der Szene berücksichtigen. Zum Beispiel kann eine aktuelle Benutzeransicht von einem Client-Gerät empfangen werden. In einem anderen Beispiel kann nur der Teil des Lichtfeldes berechnet werden, der sich innerhalb der aktuellen Benutzersicht befindet. In einem weiteren Beispiel kann nur der Teil des berechneten Lichtfelds, der sich innerhalb der potenziell sichtbaren aktuellen Benutzeransicht befindet, komprimiert werden, um die komprimierten Lichtfelddaten zu erzeugen. Dadurch kann die Menge der komprimierten Daten reduziert werden, was die Leistung des Systems, das die Komprimierung durchführt, weiter verbessern und die Menge der komprimierten Daten, die über ein Netzwerk an ein Client-Gerät gesendet werden, weiter reduzieren kann.
  • Weiter, wie in Operation 108 gezeigt, werden die komprimierten Lichtfelddaten von dem entfernten Gerät an ein Client-Gerät gesendet. In einem Ausführungsbeispiel können die komprimierten Lichtfelddaten von dem entfernten Gerät über ein oder mehrere drahtgebundene und/oder drahtlose Kommunikationsnetze (z. B. eine drahtlose Internetverbindung, ein Mobilfunknetz usw.) an das Client-Gerät gesendet (z. B. gestreamt usw.) werden.
  • Auf diese Weise können die komprimierten Lichtfelddaten entfernt berechnet werden und dem Client-Gerät bereitgestellt werden, wo das Client-Gerät die komprimierten Lichtfelddaten dekomprimieren kann, um ein dekomprimiertes Lichtfeld für die Szene zu erhalten. Dieses dekomprimierte Lichtfeld kann von dem Client-Gerät verwendet werden, um eine globale Beleuchtung für die Szene auf dem Client-Gerät durchzuführen. Die Implementierung der zeitlichen Wiederverwendung während der Komprimierung des Lichtfeldes kann die Menge der übertragenen Daten/der genutzten Bandbreite über Kommunikationsnetze reduzieren, was die Leistung von Rechengeräten unter Verwendung von Kommunikation über solche Netze verbessern kann. Eine solche Wiederverwendung kann auch zu einer verringerten Latenzzeit sowohl bei der Erzeugung als auch bei der Übertragung der komprimierten Lichtfelddaten führen. Weiter können die Beleuchtungsberechnungen bei der Berechnung des Lichtfelds für die Szene dynamisch erfolgen und dürfen nicht auf statischen Szenen oder statischer Beleuchtung beruhen. Dies kann dynamische Änderungen der Szenengeometrie und der Beleuchtung effektiv berücksichtigen und die Qualität des gerenderten Ergebnisses verbessern.
  • Außerdem werden, wie in Operation 110 gezeigt, die komprimierten Lichtfelddaten für die Szene auf dem Client-Gerät empfangen. In einem Ausführungsbeispiel können die komprimierten Lichtfelddaten von dem entfernten Gerät an dem Client-Gerät über ein oder mehrere drahtgebundene und/oder drahtlose Kommunikationsnetze (z. B. eine drahtlose Internetverbindung, ein Mobilfunknetz usw.) empfangen werden.
  • Zusätzlich kann in mindestens einem Ausführungsbeispiel das Client-Gerät ein Gerät zum zumindest teilweisen Rendern einer Szene und zur Anzeige der gerenderten Szene enthalten. In einem anderen Ausführungsbeispiel kann das Client-Gerät ein mobiles Gerät (z. B. ein Smartphone, ein Tablet usw.), eine tragbare Spieleplattform, ein Virtual-Reality-Headset (VR) usw. enthalten.
  • Weiter, wie in Operation 112 gezeigt, werden die komprimierten Lichtfelddaten auf dem Client-Gerät dekomprimiert, um das Lichtfeld für die Szene zu erhalten. In einem Ausführungsbeispiel kann das Client-Gerät die komprimierten Lichtfelddaten unter Verwendung eines Videodecoders und/oder einer Videodekomprimierungseinheit dekomprimieren. In einem anderen Ausführungsbeispiel kann der Video-Decoder und/oder die Video-Dekompressionseinheit eine spezielle Hardware-Einheit innerhalb des Client-Geräts enthalten. In einem weiteren Ausführungsbeispiel kann die Videodecoder- und/oder Videodekompressionseinheit in einer GPU des Client-Geräts untergebracht sein. In einem weiteren Ausführungsbeispiel können Lichtfelddaten für frühere Szenen mit den dekomprimierten Lichtfelddaten kombiniert werden, um das Lichtfeld für die aktuelle Szene zu erhalten.
  • Weiter, wie in Operation 114 gezeigt, wird eine globale Beleuchtung für die Szene auf dem Client-Gerät unter Verwendung des Lichtfelds für die Szene berechnet. In einem Ausführungsbeispiel kann das Client-Gerät bei der Berechnung der globalen Beleuchtung Lookups innerhalb des Lichtfelds durchführen (z. B. anstelle der Durchführung von Raytracing oder anderen ressourcenintensiven Aktionen usw.). In einem anderen Ausführungsbeispiel kann die Durchführung der globalen Beleuchtung sowohl die Modellierung von indirektem Licht (z.B. wie Licht von Oberflächen auf andere Oberflächen innerhalb der Szene reflektiert wird) als auch von direktem Licht (z.B. Licht, das direkt von einer Lichtquelle auf eine Oberfläche trifft) enthalten.
  • In einem Ausführungsbeispiel kann die berechnete globale Beleuchtung auch dazu verwendet werden, die Szene auf dem Client-Gerät zu rendern. In einem anderen Ausführungsbeispiel kann die gerenderte Szene von dem Client-Gerät angezeigt werden (z. B. unter Verwendung einer Anzeige des Client-Geräts usw.).
  • Auf diese Weise kann die Leistung der globalen Beleuchtung für die Szene eine realistische Darstellung der Szene auf der Anzeige des Client-Geräts verbessern. Darüber hinaus kann die globale Beleuchtung auf eine effizientere Art und Weise unter Verwendung von Lichtfeld-Lookups durchgeführt werden, was den Umfang der auf dem Client-Gerät erforderlichen Verarbeitung reduzieren kann. Dies kann die Leistung des Client-Geräts beim Rendern der Szene verbessern und zu einem qualitativ hochwertigen, dynamisch gerenderten Bild mit geringer Bandbreitennutzung führen.
  • In einem weiteren Ausführungsbeispiel können ein oder mehrere Teile der Lichtfeldberechnung und -kompression unter Verwendung einer Parallelverarbeitungseinheit (PPU) wie der in 2 gezeigten PPU 200 durchgeführt werden.
  • Weitere beispielhafte Informationen werden nun in Bezug auf verschiedene optionale Architekturen und Merkmale dargelegt, mit denen das obige Framework je nach den Wünschen des Benutzers implementiert werden kann. Es sollte ausdrücklich darauf hingewiesen werden, dass die folgenden Informationen beispielhaft sind und in keiner Weise als einschränkend verstanden werden sollten. Jedes der folgenden Merkmale kann optional eingebaut werden, mit oder ohne Ausschluss anderer beschriebener Merkmale.
  • Parallelverarbeitungsarchitektur
  • 2 zeigt eine Parallelverarbeitungseinheit (PPU) 200 gemäß einem Ausführungsbeispiel. In einem Ausführungsbeispiel ist die PPU 200 ein Multithread-Prozessor, der auf einem oder mehreren Geräten mit integrierter Schaltung implementiert ist. Die PPU 200 ist eine latenzverbergende Architektur, die darauf ausgelegt ist, viele Threads parallel zu verarbeiten. Ein Thread (d. h. ein Ausführungsstrang) ist eine Instanziierung eines Satzes von Befehlen, die für die Ausführung durch die PPU 200 konfiguriert sind. In einem Ausführungsbeispiel ist die PPU 200 eine Grafikverarbeitungseinheit (GPU), die so konfiguriert ist, dass sie eine Grafik-Rendering-Pipeline für die Verarbeitung dreidimensionaler (3D) Grafikdaten implementiert, um zweidimensionale (2D) Bilddaten für die Anzeige auf einem Gerät wie einem Flüssigkristallanzeigegerät (LCD) zu generieren. In anderen Ausführungsbeispielen kann die PPU 200 für die Durchführung allgemeiner Berechnungen verwendet werden. Während ein exemplarischer Parallelprozessor hier zu beispielhaften Zwecken bereitgestellt wird, sollte ausdrücklich darauf hingewiesen werden, dass ein solcher Prozessor nur zu illustrativen Zwecken dargestellt wird und dass jeder beliebige Prozessor verwendet werden kann, um denselben zu ergänzen und/oder zu ersetzen.
  • Eine oder mehrere PPUs 200 können konfiguriert sein, um Tausende von High Performance Computing (HPC)-, Rechenzentrums- und maschinelle Lemanwendungen zu beschleunigen. Die PPU 200 kann so konfiguriert sein, dass sie zahlreiche Deep-Learning-Systeme und -Anwendungen beschleunigt, darunter autonome Fahrzeugplattformen, Deep Learning, hochpräzise Sprach-, Bild- und Texterkennungssysteme, intelligente Videoanalyse, Molekularsimulationen, Arzneimittelentdeckung, Krankheitsdiagnose, Wettervorhersage, Big-Data-Analytik, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotik, Fabrikautomatisierung, Echtzeit-Sprachübersetzung, Online-Suchoptimierung und personalisierte Benutzerempfehlungen und dergleichen.
  • Wie in 2 gezeigt, enthält die PPU 200 eine Eingabe/Ausgabe-Einheit (E/A) 205, eine Front-End-Einheit 215, eine Planer-Einheit 220, eine Arbeitsverteilungseinheit 225, einen Hub 230, eine Crossbar (Xbar) 270, einen oder mehrere allgemeine Verarbeitungscluster (GPCs) 250 und eine oder mehrere Partitionseinheiten 280. Die PPU 200 kann mit einem Host-Prozessor oder anderen PPUs 200 über eine oder mehrere Hochgeschwindigkeits-NVLink 210-Verbindungen verbunden sein. Die PPU 200 kann über eine Zwischenverbindung 202 mit einem Host-Prozessor oder anderen peripheren Geräten verbunden sein. Die PPU 200 kann auch mit einem lokalen Speicher verbunden sein, der eine Reihe von Speichergeräten 204 umfasst. In einem Ausführungsbeispiel kann der lokale Speicher eine Anzahl von Dynamic Random Access Memory (DRAM)-Geräten umfassen. Die DRAM-Geräte können als HBM-Subsystem (High-Bandwidth Memory) konfiguriert sein, wobei mehrere DRAM-Chips in jedem Gerät gestapelt sind.
  • Die NVLink 210-Verbindung ermöglicht die Skalierung von Systemen und enthält eine oder mehrere PPUs 200, die mit einer oder mehreren CPUs kombiniert sind, und unterstützt die Cache-Kohärenz zwischen den PPUs 200 und den CPUs sowie das CPU-Mastering. Daten und/oder Befehle können über den NVLink 210 durch den Hub 230 zu/von anderen Einheiten der PPU 200 übertragen werden, z. B. einer oder mehreren Copy-Engines, einem Video-Encoder, einem Video-Decoder, einer Energieverwaltungseinheit usw. (nicht explizit dargestellt). Der NVLink 210 wird in Verbindung mit 4B im Detail beschrieben.
  • Die E/A-Einheit 205 ist so konfiguriert, dass sie Kommunikationen (d.h. Befehle, Daten usw.) von einem Host-Prozessor (nicht gezeigt) über die Verbindung 202 sendet und empfängt. Die E/A-Einheit 205 kann mit dem Host-Prozessor direkt über die Verbindung 202 oder über ein oder mehrere zwischengeschaltete Geräte wie eine Speicherbrücke kommunizieren. In einem Ausführungsbeispiel kann die E/A-Einheit 205 mit einem oder mehreren anderen Prozessoren, wie einer oder mehreren PPUs 200, über die Verbindungseinheit 202 kommunizieren. In einem Ausführungsbeispiel implementiert die E/A-Einheit 205 eine Peripheral Component Interconnect Express (PCIe)-Schnittstelle für die Kommunikation über einen PCIe-Bus und die Verbindungseinheit 202 ist ein PCIe-Bus. In alternativen Ausführungsbeispielen kann die E/A-Einheit 205 andere Arten von bekannten Schnittstellen für die Kommunikation mit externen Geräten implementieren.
  • Die E/A-Einheit 205 dekodiert Pakete, die über die Verbindungseinheit 202 empfangen werden. In einem Ausführungsbeispiel repräsentieren die Pakete Befehle, die so konfiguriert sind, dass sie die PPU 200 veranlassen, verschiedene Operationen durchzuführen. Die E/A-Einheit 205 überträgt die dekodierten Befehle an verschiedene andere Einheiten der PPU 200, wie die Befehle spezifizieren können. Einige Befehle können zum Beispiel an die Front-End-Einheit 215 übertragen werden. Andere Befehle können an den Hub 230 oder andere Einheiten der PPU 200 wie eine oder mehrere Copy-Engines, einen Video-Encoder, einen Video-Decoder, eine Energieverwaltungseinheit usw. übertragen werden. (nicht explizit dargestellt). Mit anderen Worten: Die E/A-Einheit 205 ist so konfiguriert, dass sie die Kommunikation zwischen und unter den verschiedenen logischen Einheiten der PPU 200 weiterleitet.
  • In einem Ausführungsbeispiel kodiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, der der PPU 200 Arbeitslasten zur Verarbeitung bereitstellt. Eine Arbeitslast kann mehrere Befehle und Daten umfassen, die von diesen Befehlen verarbeitet werden sollen. Der Puffer ist ein Bereich in einem Speicher, auf den sowohl der Host-Prozessor als auch die PPU 200 zugreifen (d. h. lesen und schreiben) können. Beispielsweise kann die E/A-Einheit 205 so konfiguriert sein, dass sie über Speicheranforderungen, die über die Verbindungseinheit 202 übertragen werden, auf den Puffer in einem mit der Verbindungseinheit 202 verbundenen Systemspeicher zugreift. In einem Ausführungsbeispiel schreibt der Host-Prozessor den Befehlsstrom in den Puffer und überträgt dann einen Zeiger auf den Beginn des Befehlsstroms an die PPU 200. Die Front-End-Einheit 215 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Front-End-Einheit 215 verwaltet den einen oder die mehreren Ströme, liest Befehle aus den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 200 weiter.
  • Die Front-End-Einheit 215 ist mit einer Planer-Einheit 220 gekoppelt, die die verschiedenen GPCs 250 für die Verarbeitung von Aufgaben konfiguriert, die durch den einen oder die mehreren Streams definiert sind. Die Planer-Einheit 220 ist so konfiguriert, dass sie Zustandsinformationen in Bezug auf die verschiedenen Aufgaben, die von der Planer-Einheit 220 verwaltet werden, verfolgt. Der Zustand kann anzeigen, welchem GPC 250 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, welche Prioritätsstufe der Aufgabe assoziiert ist und so weiter. Die Planer-Einheit 220 verwaltet die Ausführung einer Vielzahl von Aufgaben auf dem einen oder mehreren GPCs 250.
  • Die Planer-Einheit 220 ist mit einer Arbeitsverteilungseinheit 225 gekoppelt, die konfiguriert ist, um Aufgaben zur Ausführung auf den GPCs 250 zu verteilen. Die Arbeitsverteilungseinheit 225 kann eine Anzahl von geplanten Aufgaben verfolgen, die von der Planer-Einheit 220 empfangen wurden. In einem Ausführungsbeispiel verwaltet die Arbeitsverteilungseinheit 225 einen Pool ausstehender Aufgaben und einen Pool aktiver Aufgaben für jeden der GPCs 250. Der Pool ausstehender Aufgaben kann eine Anzahl von Slots (z. B. 32 Slots) umfassen, die Aufgaben enthalten, die einem bestimmten GPC 250 zur Bearbeitung zugewiesen sind. Der Pool aktiver Aufgaben kann eine bestimmte Anzahl von Slots (z. B. 4 Slots) für Aufgaben umfassen, die von den GPCs 250 aktiv bearbeitet werden. Wenn ein GPC 250 die Ausführung einer Aufgabe beendet, wird diese Aufgabe aus dem Pool aktiver Aufgaben für den GPC 250 entfernt, und eine der anderen Aufgaben aus dem Pool ausstehender Aufgaben wird ausgewählt und für die Ausführung auf dem GPC 250 geplant. Wenn eine aktive Aufgabe auf dem GPC 250 inaktiv war, z. B. während des Wartens auf die Auflösung einer Datenabhängigkeit, kann die aktive Aufgabe aus dem GPC 250 entfernt und in den Pool aktiver Aufgaben zurückgeführt werden, während eine andere Aufgabe aus dem Pool ausstehender Aufgaben ausgewählt und für die Ausführung auf dem GPC 250 geplant wird.
  • Die Arbeitsverteilungseinheit 225 kommuniziert über die XBar 270 mit dem einen oder den mehreren GPCs 250. Die XBar 270 ist ein Verbindungsnetzwerk, das viele der Einheiten der PPU 200 mit anderen Einheiten der PPU 200 koppelt. Beispielsweise kann die XBar 270 so konfiguriert sein, dass sie die Arbeitsverteilungseinheit 225 mit einem bestimmten GPC 250 koppelt. Obwohl nicht explizit dargestellt, können auch eine oder mehrere andere Einheiten der PPU 200 über den Hub 230 mit der XBar 270 verbunden sein.
  • Die Aufgaben werden von der Planer-Einheit 220 verwaltet und von der Arbeitsverteilungseinheit 225 an einen GPC 250 weitergeleitet. Der GPC 250 ist konfiguriert, um die Aufgabe zu verarbeiten und Ergebnisse zu generieren. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 250 verwendet werden, über die XBar 270 an einen anderen GPC 250 weitergeleitet oder im Speicher 204 gespeichert werden. Die Ergebnisse können über die Partitionseinheiten 280 in den Speicher 204 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/aus dem Speicher 204 implementieren. Die Ergebnisse können über den NVLink 210 an eine andere PPU 200 oder CPU übertragen werden. In einem Ausführungsbeispiel enthält die PPU 200 eine Anzahl U von Partitionseinheiten 280, die der Anzahl von separaten und unterschiedlichen Speichergeräten 204 entspricht, die mit der PPU 200 verbunden sind. Eine Partitionseinheit 280 wird weiter unten in Verbindung mit 3B im Detail beschrieben.
  • In einem Ausführungsbeispiel führt ein Host-Prozessor einen Treiberkernel aus, der eine Anwendungsprogrammierschnittstelle (API) implementiert, die es einer oder mehreren auf dem Host-Prozessor ausgeführten Anwendungen ermöglicht, Operationen zur Ausführung auf der PPU 200 zu planen. In einem Ausführungsbeispiel werden mehrere Rechenanwendungen simultan von der PPU 200 ausgeführt, und die PPU 200 stellt Isolierung, Dienstgüte (QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen bereit. Eine Anwendung kann Anweisungen (d. h. API-Aufrufe) generieren, die den Treiberkernel veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die PPU 200 zu generieren. Der Treiberkernel gibt Aufgaben an einen oder mehrere Streams aus, die von der PPU 200 verarbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen von zusammenhängenden Threads umfassen, die hier als Warp bezeichnet werden. In einem Ausführungsbeispiel umfasst ein Warp 32 zusammengehörige Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Vielzahl von Threads beziehen, die Anweisungen zur Ausführung der Aufgabe enthalten und die Daten über gemeinsam genutzte Speicher austauschen können. Threads und kooperierende Threads werden in Verbindung mit 4A im Detail beschrieben.
  • 3A zeigt einen GPC 250 der PPU 200 aus 2 gemäß einem Ausführungsbeispiel. Wie in 3A dargestellt, enthält jeder GPC 250 eine Reihe von Hardware-Einheiten zur Verarbeitung von Aufgaben. In einem Ausführungsbeispiel enthält jeder GPC 250 einen Pipeline-Manager 310, eine Pre-Raster Operations Unit (PROP) 315, eine Raster-Engine 325, eine Work Distribution Crossbar (WDX) 380, eine Memory Management Unit (MMU) 390 und einen oder mehrere Verarbeitungscluster (DPCs) 320. Es ist zu beachten, dass der GPC 250 der 3A andere Hardware-Einheiten anstelle der in 3A gezeigten Einheiten oder zusätzlich zu diesen enthalten kann.
  • In einem Ausführungsbeispiel wird der Betrieb des GPC 250 durch den Pipeline-Manager 310 gesteuert. Der Pipeline-Manager 310 verwaltet die Konfiguration des einen oder der mehreren DPCs 320 für die Verarbeitung von Aufgaben, die dem GPC 250 zugewiesen sind. In einem Ausführungsbeispiel kann der Pipeline-Manager 310 mindestens einen der einen oder mehreren DPCs 320 konfigurieren, um mindestens einen Teil einer Grafik-Rendering-Pipeline zu implementieren. Beispielsweise kann ein DPC 320 so konfiguriert sein, dass er ein Vertex Schattierungsprogramm auf dem programmierbaren Streaming-Multiprozessor (SM) 340 ausführt. Der Pipeline-Manager 310 kann auch konfiguriert sein, um von der Arbeitsverteilungseinheit 225 empfangene Pakete an die entsprechenden logischen Einheiten innerhalb des GPC 250 weiterzuleiten. Beispielsweise können einige Pakete an Hardwareeinheiten mit fester Funktionalität im PROP 315 und/oder der Rasterengine 325 weitergeleitet werden, während andere Pakete an die DPCs 320 zur Verarbeitung durch die Primitive Engine 335 oder den SM 340 weitergeleitet werden können. In einem Ausführungsbeispiel kann der Pipeline-Manager 310 mindestens einen der einen oder mehreren DPCs 320 konfigurieren, um ein Modell eines neuronalen Netzwerks und/oder eine Rechenpipeline zu implementieren.
  • Die PROP-Einheit 315 ist so konfiguriert, dass sie die von der Rasterengine 325 und den DPCs 320 generierten Daten an eine Raster Operations (ROP)-Einheit weiterleitet, die in Verbindung mit 3B ausführlicher beschrieben wird. Die PROP-Einheit 315 kann auch konfiguriert sein, um Optimierungen für die Farbmischung durchzuführen, Pixeldaten zu organisieren, Adressübersetzungen vorzunehmen und ähnliches.
  • Die Rasterengine 325 enthält eine Reihe von Hardware-Einheiten mit festen Funktionen, die zur Durchführung verschiedener Rasteroperationen konfiguriert sind. In einem Ausführungsbeispiel enthält die Rasterengine 325 eine Setup-Engine, eine Grobraster-Engine, eine Abblend-Engine, eine Clipping-Engine, eine Feinraster-Engine und eine Kachel-Koaleszenz-Engine. Die Setup-Engine empfängt transformierte Vertices und generiert Ebenengleichungen, die mit dem durch die Vertices definierten geometrischen Primitiv assoziiert sind. Die Ebenengleichungen werden an die grobe Rasterengine weitergeleitet, um Abdeckungsinformationen (z. B. eine x,y-Abdeckungsmaske für eine Kachel) für das Primitiv zu generieren. Die Ausgabe der groben Rasterengine wird an die Culling Engine weitergeleitet, wo mit dem Primitiv assoziierte Fragmente, die einen z-Test nicht bestehen, ausgeblendet werden, und an eine Clipping Engine weitergeleitet, wo Fragmente, die außerhalb eines Sichtkegelstumpfes liegen, abgeschnitten werden. Diejenigen Fragmente, die das Abschneiden und Ausblenden überstehen, können an die Feinraster-Engine weitergeleitet werden, um Attribute für die Pixelfragmente basierend auf den von der Setup-Engine generierten Ebenengleichungen zu generieren. Die Ausgabe der Rasterengine 325 umfasst Fragmente, die z. B. von einem in einer DPC 320 implementierten Fragment-Shader verarbeitet werden.
  • Jeder DPC 320, der im GPC 250 enthalten ist, enthält ein M-Pipe Steuergerät (MPC) 330, eine primitive Engine 335 und ein oder mehrere SMs 340. Das MPC 330 steuert den Betrieb des DPC 320 und leitet die vom Pipeline-Manager 310 empfangenen Pakete an die entsprechenden Einheiten im DPC 320 weiter. Beispielsweise können Pakete, die mit einem Vertex assoziiert sind, an die primitive Engine 335 weitergeleitet werden, die konfiguriert ist, um mit dem Vertex assoziierte Vertex-Attribute aus dem Speicher 204 zu holen. Im Gegensatz dazu können Pakete, die mit einem Schattierungsprogramm assoziiert sind, an den SM 340 übertragen werden.
  • Der SM 340 umfasst einen programmierbaren Streaming-Prozessor, der für die Verarbeitung von Aufgaben konfiguriert ist, die durch eine Anzahl von Threads repräsentiert werden. Jeder SM 340 verfügt über mehrere Threads und ist so konfiguriert, dass er eine Vielzahl von Threads (z. B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig ausführen kann. In einem Ausführungsbeispiel implementiert der SM 340 eine SIMD-Architektur (Single-Instruction, Multiple-Data), bei der jeder Thread in einer Gruppe von Threads (d. h. ein Warp) so konfiguriert ist, dass er einen anderen Datensatz basierend auf demselben Befehlssatz verarbeitet. Alle Threads in der Gruppe von Threads führen die gleichen Anweisungen aus. In einem anderen Ausführungsbeispiel implementiert der SM 340 eine SIMT-Architektur (Single-Instruction, Multiple Thread), bei der jeder Thread in einer Gruppe von Threads so konfiguriert ist, dass er basierend auf demselben Befehlssatz einen anderen Datensatz verarbeitet, wobei jedoch einzelne Threads in der Gruppe von Threads während der Ausführung divergieren dürfen. In einem Ausführungsbeispiel werden ein Programmzähler, ein Aufrufstapel und ein Ausführungsstatus für jeden Warp beibehalten, was die Gleichzeitigkeit zwischen Warps und die serielle Ausführung innerhalb von Warps ermöglicht, wenn Threads innerhalb des Warps divergieren. In einem anderen Ausführungsbeispiel werden ein Programmzähler, ein Aufrufstapel und ein Ausführungsstatus für jeden einzelnen Thread beibehalten, was die Gleichzeitigkeit zwischen allen Threads innerhalb und zwischen Warps ermöglicht. Wenn der Ausführungsstatus für jeden einzelnen Thread beibehalten wird, können Threads, die dieselben Anweisungen ausführen, zusammengeführt und parallel ausgeführt werden, um maximale Effizienz zu erzielen. Der SM 340 wird weiter unten in Verbindung mit 4A im Detail beschrieben.
  • The MMU 390 provides an interface between the GPC 250 and the partition unit 280. The MMU 390 may provide translation of virtual addresses into physical addresses, memory protection, and arbitration of memory requests. In an embodiment, the MMU 390 provides one or more translation lookaside buffers (TLBs) for performing translation of virtual addresses into physical addresses in the memory 204.
  • 3B zeigt eine Speicherpartitionseinheit 280 der PPU 200 von 2 gemäß einem Ausführungsbeispiel. Wie in 3B gezeigt, enthält die Speicherpartitionseinheit 280 eine Rasteroperationseinheit (ROP) 350, einen Level-2-Cache (L2) 360 und eine Speicherschnittstelle 370. Die Speicherschnittstelle 370 ist mit dem Speicher 204 verbunden. Die Speicherschnittstelle 370 kann 32-, 64-, 128-, 1024-Bit-Datenbusse oder Ähnliches für die Hochgeschwindigkeitsdatenübertragung implementieren. In einem Ausführungsbeispiel enthält die PPU 200 U Speicherschnittstellen 370, eine Speicherschnittstelle 370 pro Paar von Partitionseinheiten 280, wobei jedes Paar von Partitionseinheiten 280 mit einem entsprechenden Speichergerät 204 verbunden ist. Beispielsweise kann die PPU 200 mit bis zu Y Speichergeräten 204 verbunden sein, wie z. B. Speicherstapeln mit hoher Bandbreite oder Grafikspeicher mit doppelter Datenrate, Version 5, synchronem Dynamic Random Access Memory oder anderen Arten von dauerhaftem Speicher.
  • In einem Ausführungsbeispiel implementiert die Speicherschnittstelle 370 eine HBM2-Speicherschnittstelle, und Y entspricht der Hälfte von U. In einem Ausführungsbeispiel befinden sich die HBM2-Speicherstapel in demselben physischen Gehäuse wie die PPU 200, was im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen erhebliche Energie- und Flächeneinsparungen bereitstellt. In einem Ausführungsbeispiel enthält jeder HBM2-Stapel vier Speicherchips und Y ist gleich 4, wobei der HBM2-Stapel zwei 128-Bit-Kanäle pro Chip enthält, was insgesamt 8 Kanäle und eine Datenbusbreite von 1024 Bit ergibt.
  • In einem Ausführungsbeispiel unterstützt der Speicher 204 den Single-Error Correcting Double-Error Detecting (SECDED) Error Correction Code (ECC) zum Schutz der Daten. ECC stellt eine höhere Zuverlässigkeit für Datenverarbeitungsanwendungen bereit, die empfindlich auf Datenbeschädigung reagieren. Zuverlässigkeit ist besonders wichtig in großen Cluster-Computing-Umgebungen, in denen PPUs 200 sehr große Datensätze verarbeiten und/oder Anwendungen über längere Zeiträume laufen lassen.
  • In einem Ausführungsbeispiel implementiert die PPU 200 eine mehrstufige Speicherhierarchie. In einem Ausführungsbeispiel unterstützt die Speicherpartitionseinheit 280 einen einheitlichen Speicher, um einen einzigen einheitlichen virtuellen Adressraum für den CPU- und PPU 200-Speicher bereitzustellen, was die gemeinsame Nutzung von Daten zwischen virtuellen Speichersystemen ermöglicht. In einem Ausführungsbeispiel wird die Häufigkeit der Zugriffe einer PPU 200 auf Speicher auf anderen Prozessoren verfolgt, um sicherzustellen, dass Speicherseiten in den physischen Speicher der PPU 200 verschoben werden, die häufiger auf die Seiten zugreift. In einem Ausführungsbeispiel unterstützt der NVLink 210 Adressübersetzungsdienste, die es der PPU 200 ermöglichen, direkt auf die Seitentabellen einer CPU zuzugreifen und einen vollständigen Zugriff auf den CPU-Speicher durch die PPU 200 bereitzustellen.
  • In einem Ausführungsbeispiel übertragen Copy-Engines Daten zwischen mehreren PPUs 200 oder zwischen PPUs 200 und CPUs. Die Copy-Engines können Seitenfehler für Adressen generieren, die nicht den Seitentabellen zugeordnet sind. Die Speicherpartitionseinheit 280 kann dann die Seitenfehler bearbeiten und die Adressen in die Seitentabelle zuordnen, woraufhin die Copy-Engine die Übertragung durchführen kann. In einem herkömmlichen System wird der Speicher für mehrere Copy-Engine-Operationen zwischen mehreren Prozessoren gepinnt (d. h. nicht auslagerbar), wodurch der verfügbare Speicher erheblich reduziert wird. Mit Hardware Page Faulting können Adressen an die Copy-Engines weitergegeben werden, ohne dass man sich Gedanken darüber machen muss, ob die Speicherseiten resident sind, und der Kopiervorgang ist transparent.
  • Daten aus dem Speicher 204 oder einem anderen Systemspeicher können von der Speicherpartitionseinheit 280 geholt und im L2-Cache 360 gespeichert werden, der sich auf dem Chip befindet und von den verschiedenen GPCs 250 gemeinsam genutzt wird. Wie dargestellt, enthält jede Speicherpartitionseinheit 280 einen Teil des L2-Cache 360, der einem entsprechenden Speichergerät 204 zugeordnet ist. Caches der unteren Ebene können dann in verschiedenen Einheiten innerhalb der GPCs 250 implementiert werden. Beispielsweise kann jeder der SMs 340 einen Level-1-Cache (L1-Cache) implementieren. Der L1-Cache ist ein privater Speicher, der einem bestimmten SM 340 zugeordnet ist. Daten aus dem L2-Cache 360 können geholt und in jedem der L1-Caches zur Verarbeitung in den funktionalen Einheiten der SMs 340 gespeichert werden. Der L2-Cache 360 ist mit der Speicherschnittstelle 370 und der XBar 270 verbunden.
  • Die ROP-Einheit 350 führt Grafikrasteroperationen in Bezug auf die Pixelfarbe durch, wie z. B. Farbkomprimierung, Pixelüberblendung und ähnliches. Die ROP-Einheit 350 führt in Verbindung mit der Rasterengine 325 auch eine Tiefenprüfung durch, wobei sie von der Sampling-Engine der Rasterengine 325 eine Tiefe für eine mit einem Pixelfragment assoziierte Abtaststelle empfängt. Die Tiefe wird mit einer entsprechenden Tiefe in einem Tiefenpuffer für eine mit dem Fragment assoziierte Abtaststelle verglichen. Wenn das Fragment den Tiefentest für den Abtastort besteht, aktualisiert die ROP-Einheit 350 den Tiefenpuffer und überträgt das Ergebnis des Tiefentests an die Rasterengine 325. Es ist zu beachten, dass die Anzahl der Partitionseinheiten 280 von der Anzahl der GPCs 250 abweichen kann und daher jede ROP-Einheit 350 mit jedem der GPCs 250 verbunden sein kann. Die ROP-Einheit 350 verfolgt die von den verschiedenen GPCs 250 empfangenen Pakete und bestimmt, an welchen GPC 250 ein von der ROP-Einheit 350 generiertes Ergebnis über die Xbar 270 weitergeleitet wird. Obwohl die ROP-Einheit 350 in 3B in der Speicherpartitionseinheit 280 enthalten ist, kann sie in anderen Ausführungsbeispielen auch außerhalb der Speicherpartitionseinheit 280 liegen. Zum Beispiel kann die ROP-Einheit 350 im GPC 250 oder einer anderen Einheit untergebracht sein.
  • 4A zeigt den Streaming-Multiprozessor 340 aus 3A gemäß einem Ausführungsbeispiel. Wie in 4A dargestellt, enthält der SM 340 einen Befehls-Cache 405, eine oder mehrere Planer-Einheiten 410(K), eine Registerdatei 420, einen oder mehrere Verarbeitungskerne 450, eine oder mehrere Sonderfunktionseinheiten (SFUs) 452, eine oder mehrere Lade-/Speichereinheiten (LSUs) 454, ein Verbindungsnetzwerk 480, einen gemeinsam genutzten Speicher/L1-Cache 470.
  • Wie oben beschrieben, weist die Arbeitsverteilungseinheit 225 Aufgaben zur Ausführung auf den GPCs 250 der PPU 200 zu. Die Aufgaben werden einem bestimmten DPC 320 innerhalb eines GPC 250 zugewiesen, und wenn die Aufgabe mit einem Schattierungsprogramm assoziiert ist, kann die Aufgabe einem SM 340 zugewiesen werden. Die Planer-Einheit 410(K) empfängt die Aufgaben von der Arbeitsverteilungseinheit 225 und plant die Anweisungen für einen oder mehrere Thread-Blöcke, die dem SM 340 zugeordnet sind. Die Planer-Einheit 410(K) plant Thread-Blöcke für die Ausführung als Warps paralleler Threads, wobei jedem Thread-Block mindestens ein Warp zugeordnet ist. In einem Ausführungsbeispiel führt jeder Warp 32 Threads aus. Die Planer-Einheit 410(K) kann eine Vielzahl verschiedener Thread-Blöcke verwalten, indem sie die Warps den verschiedenen Thread-Blöcken zuweist und dann während jedes Taktzyklus Anweisungen aus der Vielzahl verschiedener Cooperative Groups an die verschiedenen Funktionseinheiten (d. h. Kerne 450, SFUs 452 und LSUs 454) verteilt.
  • Cooperative Groups ist ein Programmiermodell für die Organisation von Gruppen kommunizierender Threads, das es Entwicklern ermöglicht, die Granularität auszudrücken, mit der Threads kommunizieren, und so reichhaltigere, effizientere parallele Dekompositionen zu ermöglichen. APIs für den kooperativen Start unterstützen die Synchronisierung zwischen Thread-Blöcken für die Ausführung paralleler Algorithmen. Konventionelle Programmiermodelle stellen ein einziges, einfaches Konstrukt für die Synchronisierung kooperierender Threads bereit: eine Barriere über alle Threads eines Thread-Blocks (d. h. die Funktion syncthreads()). Programmierer möchten jedoch oft Gruppen von Threads mit einer kleineren Granularität als der eines Thread-Blocks definieren und innerhalb der definierten Gruppen synchronisieren, um eine größere Leistung, Design-Flexibilität und Software-Wiederverwendung in Form von kollektiven gruppenweiten Funktionsschnittstellen zu ermöglichen.
  • Cooperative Groups ermöglicht es Programmierern, Gruppen von Threads explizit auf Sub-Block- (d.h. so klein wie ein einzelner Thread) und Multi-Block-Granularität zu definieren und kollektive Operationen wie Synchronisation auf den Threads in einer Cooperative Group durchzuführen. Das Programmiermodell unterstützt eine saubere Komposition über Software-Grenzen hinweg, so dass Bibliotheken und Utility-Funktionen innerhalb ihres lokalen Kontexts sicher synchronisieren können, ohne Annahmen über Konvergenz treffen zu müssen. Cooperative Groups-Primitive ermöglichen neue Muster kooperativer Parallelität, einschließlich Producer-Consumer-Parallelität, opportunistischer Parallelität und globaler Synchronisierung über ein ganzes Netz von Thread-Blöcken.
  • Eine Verteilungseinheit 415 ist konfiguriert, um Anweisungen an eine oder mehrere der Funktionalitäten zu übertragen. In dem Ausführungsbeispiel enthält die Planer-Einheit 410(K) zwei Verteilungseinheiten 415, die es ermöglichen, dass zwei verschiedene Anweisungen aus derselben Kette während jedes Taktzyklus versendet werden. In alternativen Ausführungsbeispielen kann jede Planer-Einheit 410(K) eine einzelne Verteilungseinheit 415 oder zusätzliche Verteilungseinheiten 415 enthalten.
  • Jeder SM 340 enthält eine Registerdatei 420, die einen Satz von Registern für die funktionalen Einheiten des SM 340 bereitstellt. In einem Ausführungsbeispiel ist die Registerdatei 420 zwischen den einzelnen funktionalen Einheiten aufgeteilt, so dass jeder funktionalen Einheit ein eigener Teil der Registerdatei 420 zugewiesen wird. In einem anderen Ausführungsbeispiel ist die Registerdatei 420 auf die verschiedenen Warps aufgeteilt, die vom SM 340 ausgeführt werden. Die Registerdatei 420 stellt einen temporären Speicher für Operanden bereit, die mit den Datenpfaden der funktionalen Einheiten verbunden sind.
  • Jeder SM 340 umfasst L Verarbeitungskerne 450. In einem Ausführungsbeispiel enthält der SM 340 eine große Anzahl (z.B. 128 usw.) von verschiedenen Verarbeitungskernen 450. Jeder Kern 450 kann eine voll ausgeführte, einfachgenaue, doppeltgenaue und/oder gemischtgenaue Verarbeitungseinheit enthalten, die eine arithmetische Gleitkomma-Logikeinheit und eine arithmetische Ganzzahl-Logikeinheit enthält. In einem Ausführungsbeispiel implementieren die arithmetischen Einheiten für Gleitkomma-Arithmetik den Standard IEEE 754-2008 für Gleitkomma-Arithmetik. In einem Ausführungsbeispiel enthalten die Kerne 450 64 Gleitkomma-Kerne mit einfacher Genauigkeit (32 Bit), 64 Ganzzahl-Kerne, 32 Gleitkomma-Kerne mit doppelter Genauigkeit (64 Bit) und 8 Tensor-Kerne.
  • Tensor-Kerne, die zur Durchführung von Matrixoperationen konfiguriert sind, und in einem Ausführungsbeispiel ein oder mehrere Tensor-Kerne sind in den Kernen 450 enthalten. Insbesondere sind die Tensorkerne so konfiguriert, dass sie Deep Learning-Matrixarithmetik durchführen, wie z. B. Faltungsoperationen zum Trainieren und Inferenzieren neuronaler Netzwerke. In einem Ausführungsbeispiel arbeitet jeder Tensorkern mit einer 4x4-Matrix und führt eine Matrixmultiplikations- und Akkumulationsoperation D=AB+C durch, wobei A, B, C und D 4x4-Matrizen sind.
  • In einem Ausführungsbeispiel sind die Eingaben für die Matrixmultiplikation A und B 16-Bit-Gleitkommamatrizen, während die Akkumulationsmatrizen C und D 16-Bit-Gleitkomma- oder 32-Bit-Gleitkommamatrizen sein können. Tensor-Kerne operieren mit 16-Bit-Gleitkomma-Eingangsdaten und 32-Bit-Gleitkomma-Akkumulation. Die 16-Bit-Gleitkommamultiplikation erfordert 64 Operationen und führt zu einem Produkt mit voller Genauigkeit, das dann unter Verwendung von 32-Bit-Gleitkommaaddition mit den anderen Zwischenprodukten zu einer 4x4x4-Matrixmultiplikation akkumuliert wird. In der Praxis werden Tensor-Kerne verwendet, um viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchzuführen, die aus diesen kleineren Elementen aufgebaut sind. Eine API, wie z.B. die CUDA 9 C++ API, stellt spezialisierte Matrixlade-, Matrixmultiplikations- und - akkumulations- und Matrixspeicheroperationen zur Verfügung, um Tensor Cores von einem CUDA-C++ Programm aus effizient zu verwenden. Auf der CUDA-Ebene geht die Schnittstelle auf Warp-Ebene von Matrizen der Größe 16x16 aus, die sich über alle 32 Threads des Warp erstrecken.
  • Jeder SM 340 umfasst auch M SFUs 452, die spezielle Funktionen ausführen (z. B. Attribut-Evaluierung, reziproke Quadratwurzel und Ähnliches). In einem Ausführungsbeispiel können die SFUs 452 eine Einheit zur Traversierung von Bäumen enthalten, die so konfiguriert ist, dass sie eine hierarchische Baumdatenstruktur traversiert. In einem Ausführungsbeispiel können die SFUs 452 eine Textureinheit enthalten, die so konfiguriert ist, dass sie Texturkarten-Filteroperationen durchführt. In einer Ausführungsform sind die Textureinheiten so konfiguriert, dass sie Texturkarten (z. B. ein 2D-Array von Texeln) aus dem Speicher 204 laden und die Texturkarten samplen, um gesampelte Texturwerte zur Verwendung in Schattierungsprogrammen zu erzeugen, die vom SM 340 ausgeführt werden. In einem Ausführungsbeispiel werden die Texturkarten in dem gemeinsam genutzten Speicher/L1-Cache 370 gespeichert. Die Textureinheiten implementieren Texturoperationen wie z. B. Filteroperationen unter Verwendung von Mip-Maps (d. h. Texturkarten mit variierenden Details). In einem Ausführungsbeispiel enthält jeder SM 240 zwei Textureinheiten.
  • Jeder SM 340 umfasst auch N LSUs 454, die Lade- und Speicheroperationen zwischen dem gemeinsam genutzten Speicher/L1-Cache 470 und der Registerdatei 420 durchführen. Jeder SM 340 enthält ein Verbindungsnetzwerk 480, das jede der funktionalen Einheiten mit der Registerdatei 420 und die LSU 454 mit der Registerdatei 420 und dem gemeinsam genutzten Speicher/L1-Cache 470 verbindet. In einem Ausführungsbeispiel ist das Verbindungsnetzwerk 480 eine Crossbar, die so konfiguriert werden kann, dass sie jede der funktionalen Einheiten mit jedem der Register in der Registerdatei 420 verbindet und die LSUs 454 mit der Registerdatei und Speicherplätzen im gemeinsam genutzten Speicher/L1-Cache 470 verbindet.
  • Der gemeinsam genutzte Speicher/L1-Cache 470 ist ein Array von On-Chip-Speicher, der die Datenspeicherung und Kommunikation zwischen dem SM 340 und der primitiven Engine 335 sowie zwischen Threads im SM 340 ermöglicht. In einem Ausführungsbeispiel umfasst der gemeinsam genutzte Speicher/L1-Cache 470 128 KB Speicherkapazität und befindet sich im Pfad vom SM 340 zur Partitionseinheit 280. Der gemeinsam genutzte Speicher/L1-Cache 470 kann zur Zwischenspeicherung von Lese- und Schreibvorgängen genutzt werden. Einer oder mehrere des gemeinsam genutzten Speichers/LI-Cache 470, des L2-Cache 360 und des Speichers 204 sind Backing-Stores.
  • Die Kombination der Funktionalität von Datencache und gemeinsam genutztem Speicher in einem einzigen Block stellt die beste Gesamtleistung für beide Arten von Speicherzugriffen bereit. Die Kapazität kann von Programmen, die keinen gemeinsam genutzten Speicher verwenden, als Cache genutzt werden. Wenn der gemeinsam genutzte Speicher beispielsweise so konfiguriert ist, dass die Hälfte der Kapazität genutzt wird, können Textur- und Lade-/Speicheroperationen die verbleibende Kapazität verwenden. Die Integration in den gemeinsam genutzten Speicher/L1-Cache 470 ermöglicht es dem gemeinsam genutzten Speicher/L1-Cache 470, als Leitung für Streaming-Daten mit hohem Durchsatz zu fungieren und gleichzeitig den Zugriff auf häufig wiederverwendete Daten mit hoher Bandbreite und niedriger Latenz bereitzustellen.
  • Wenn sie für allgemeine parallele Berechnungen konfiguriert sind, kann im Vergleich zur Grafikverarbeitung eine einfachere Konfiguration verwendet werden. Insbesondere werden die in 2 gezeigten Grafikverarbeitungseinheiten mit festen Funktionen umgangen, wodurch ein wesentlich einfacheres Programmiermodell entsteht. In der Konfiguration für allgemeine parallele Berechnungen weist die Arbeitsverteilungseinheit 225 Blöcke von Threads zu und verteilt sie direkt an die DPCs 320. Die Threads in einem Block führen dasselbe Programm aus, wobei eine eindeutige Thread-ID in der Berechnung verwendet wird, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse generiert, unter Verwendung des SM 340 zur Ausführung des Programms und zur Durchführung von Berechnungen, des gemeinsam genutzten Speichers/L1-Cache 470 zur Kommunikation zwischen den Threads und der LSU 454 zum Lesen und Schreiben des globalen Speichers über den gemeinsam genutzten Speicher/L1-Cache 470 und die Speicherpartitionseinheit 280. Wenn die SM 340 für allgemeine parallele Berechnungen konfiguriert ist, kann sie auch Befehle schreiben, die die Planer-Einheit 220 verwenden kann, um neue Arbeit auf den DPCs 320 zu starten.
  • Die PPU 200 kann in einem Desktop-Computer, einem Laptop-Computer, einem Tablet-Computer, Servern, Supercomputern, einem Smartphone (z. B. einem drahtlosen Handheld-Gerät), einem persönlichen digitalen Assistenten (PDA), einer Digitalkamera, einem Fahrzeug, einer am Kopf befestigten Anzeige, einem elektronischen Handheld-Gerät und dergleichen enthalten sein. In einem Ausführungsbeispiel ist die PPU 200 auf einem einzigen Halbleitersubstrat untergebracht. In einem anderen Ausführungsbeispiel ist die PPU 200 in einem System-on-a-Chip (SoC) zusammen mit einem oder mehreren anderen Geräten wie zusätzlichen PPUs 200, dem Speicher 204, einer CPU mit reduziertem Befehlssatz (RISC), einer Speicherverwaltungseinheit (MMU), einem Digital-Analog-Wandler (DAC) und dergleichen enthalten.
  • In einem Ausführungsbeispiel kann die PPU 200 auf einer Grafikkarte enthalten sein, die ein oder mehrere Speichergeräte 204 enthält. Die Grafikkarte kann so konfiguriert sein, dass sie mit einem PCIe-Steckplatz auf einem Motherboard eines Desktop-Computers verbunden werden kann. In einem weiteren Ausführungsbeispiel kann die PPU 200 eine integrierte Grafikverarbeitungseinheit (iGPU) oder ein Parallelprozessor sein, der im Chipsatz der Hauptplatine enthalten ist.
  • Exemplarisches Rechensystem
  • Systeme mit mehreren GPUs und CPUs werden in einer Vielzahl von Branchen verwendet, da die Entwickler mehr Parallelität in Anwendungen wie der künstlichen Intelligenz aufdecken und ausnutzen. Leistungsstarke GPU-beschleunigte Systeme mit zehn bis vielen tausend Rechenknoten werden in Rechenzentren, Forschungseinrichtungen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Da die Anzahl der verarbeitenden Geräte innerhalb der Hochleistungssysteme steigt, müssen die Kommunikations- und Datenübertragungsmechanismen skaliert werden, um die erhöhte Bandbreite zu unterstützen.
  • 4B zeigt ein konzeptionelles Diagramm eines Verarbeitungssystems 400, das unter Verwendung der PPU 200 aus 2 gemäß einem Ausführungsbeispiel implementiert wurde. Das exemplarische System 465 kann konfiguriert sein, um das in 1 gezeigte Verfahren 100 zu implementieren. Das Verarbeitungssystem 400 enthält eine CPU 430, einen Switch 410, mehrere PPUs 200 und entsprechende Speicher 204. Der NVLink 210 stellt Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 200 bereit. Obwohl in 4B eine bestimmte Anzahl von NVLink 210- und Interconnect 202-Verbindungen gezeigt wird, kann die Anzahl der Verbindungen zu jeder PPU 200 und der CPU 430 variieren. Der Switch 410 bildet die Schnittstelle zwischen der Verbindungsleitung 202 und der CPU 430. Die PPUs 200, die Speicher 204 und die NVLinks 210 können auf einer einzigen Halbleiterplattform untergebracht sein und ein Parallelverarbeitungsmodul 425 bilden. In einem Ausführungsbeispiel unterstützt der Switch 410 zwei oder mehr Protokolle, um eine Schnittstelle zwischen verschiedenen Verbindungen und/oder Verbindungen zu bilden.
  • In einem anderen Ausführungsbeispiel (nicht gezeigt) stellt der NVLink 210 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 200 und der CPU 430 bereit, und der Switch 410 bildet eine Schnittstelle zwischen der Verbindungsleitung 202 und jeder der PPUs 200. Die PPUs 200, die Speicher 204 und die Verbindung 202 können auf einer einzigen Halbleiterplattform untergebracht werden, um ein Parallelverarbeitungsmodul 425 zu bilden. In einem weiteren Ausführungsbeispiel (nicht gezeigt) stellt die Verbindung 202 eine oder mehrere Verbindungen zwischen jeder der PPUs 200 und der CPU 430 bereit, und der Switch 410 stellt unter Verwendung von NVLink 210 eine oder mehrere Hochgeschwindigkeitsverbindungen zwischen den PPUs 200 her. In einem anderen Ausführungsbeispiel (nicht gezeigt) stellt der NVLink 210 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 200 und der CPU 430 über den Switch 410 bereit. In einem weiteren Ausführungsbeispiel (nicht gezeigt) stellt die Verbindung 202 eine oder mehrere direkte Verbindungen zwischen den einzelnen PPUs 200 bereit. Eine oder mehrere der NVLink 210 Hochgeschwindigkeits-Kommunikationsverbindungen können als physische NVLink-Verbindung oder entweder als On-Chip- oder On-Die-Verbindung unter Verwendung desselben Protokolls wie NVLink 210 implementiert werden.
  • Im Zusammenhang mit der vorliegenden Beschreibung kann sich eine einzelne Halbleiterplattform auf eine einzige einheitliche, auf einem Chip basierende integrierte Schaltung beziehen, die auf einem Die oder Chip hergestellt wird. Es sei darauf hingewiesen, dass sich der Begriff Einzelhalbleiterplattform auch auf Multi-Chip-Module mit erhöhter Konnektivität beziehen kann, die einen On-Chip-Betrieb simulieren und wesentliche Verbesserungen gegenüber der Verwendung einer herkömmlichen Busimplementierung aufweisen. Natürlich können die verschiedenen Schaltungen oder Geräte auch separat oder in verschiedenen Kombinationen von Halbleiterplattformen untergebracht werden, je nach den Wünschen des Benutzers. Alternativ kann das Parallelverarbeitungsmodul 425 als ein Schaltungssubstrat implementiert werden, und jede der PPUs 200 und/oder Speicher 204 können gehäuste Geräte sein. In einem Ausführungsbeispiel befinden sich die CPU 430, der Switch 410 und das Parallelverarbeitungsmodul 425 auf einer einzigen Halbleiterplattform.
  • In einem Ausführungsbeispiel beträgt die Signalübertragungsrate jedes NVLink 210 20 bis 25 Gigabit/Sekunde, und jede PPU 200 enthält sechs NVLink 210-Schnittstellen (wie in 4B gezeigt, sind fünf NVLink 210-Schnittstellen für jede PPU 200 enthalten). Jeder NVLink 210 stellt eine Datenübertragungsrate von 25 Gigabyte/Sekunde in jeder Richtung bereit, wobei sechs Verbindungen 300 Gigabyte/Sekunde liefern. Die NVLinks 210 können ausschließlich für die PPU-zu-PPU-Kommunikation verwendet werden, wie in 4B gezeigt, oder für eine Kombination von PPU-zu-PPU und PPU-zu-CPU, wenn die CPU 430 auch eine oder mehrere NVLink 210-Schnittstellen enthält.
  • In einem Ausführungsbeispiel ermöglicht der NVLink 210 einen direkten Lade-/Speicher-/Atomzugriff von der CPU 430 auf den Speicher 204 jeder PPU 200. In einem Ausführungsbeispiel unterstützt der NVLink 210 Kohärenzoperationen, so dass aus den Speichern 204 gelesene Daten in der Cache-Hierarchie der CPU 430 gespeichert werden können, wodurch die Cache-Zugriffslatenz für die CPU 430 verringert wird. In einem Ausführungsbeispiel enthält der NVLink 210 Unterstützung für Adressübersetzungsdienste (ATS), wodurch die PPU 200 direkt auf Seitentabellen innerhalb der CPU 430 zugreifen kann. Einer oder mehrere der NVLinks 210 können auch so konfiguriert sein, dass sie in einem stromsparenden Modus arbeiten.
  • 4C zeigt ein exemplarisches System 465, in dem die verschiedenen Architekturen und/oder Funktionalitäten der verschiedenen vorherigen Ausführungsbeispiele implementiert werden können. Das exemplarische System 465 kann konfiguriert sein, um das in 1 gezeigte Verfahren 100 zu implementieren.
  • Wie gezeigt, ist ein System 465 enthalten, das mindestens eine zentrale Verarbeitungseinheit 430 enthält, die mit einem Kommunikationsbus 475 verbunden ist. Der Kommunikationsbus 475 kann unter Verwendung eines beliebigen geeigneten Protokolls implementiert werden, wie z. B. PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), HyperTransport oder ein anderes Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll bzw. andere Protokolle. Das System 465 enthält auch einen Hauptspeicher 440. Steuerlogik (Software) und Daten werden im Hauptspeicher 440 gespeichert, der die Form eines Direktzugriffsspeichers (RAM) annehmen kann.
  • Das System 465 enthält auch Eingabegeräte 460, das Parallelverarbeitungssystem 425 und Anzeigegeräte 445, d. h. eine herkömmliche CRT (Kathodenstrahlröhre), LCD (Flüssigkristallanzeige), LED (lichtemittierende Diode), Plasmaanzeige oder dergleichen. Benutzereingaben können über die Eingabegeräte 460, z. B. Tastatur, Maus, Touchpad, Mikrofon usw., erfolgen. Jedes der vorgenannten Module und/oder Geräte kann sogar auf einer einzigen Halbleiterplattform angeordnet sein, um das System 465 zu bilden. Alternativ können die verschiedenen Module auch separat oder in verschiedenen Kombinationen von Halbleiterplattformen angeordnet sein, je nach den Wünschen des Benutzers.
  • Weiter kann das System 465 über eine Netzwerkschnittstelle 435 zu Kommunikationszwecken mit einem Netzwerk (z. B. einem Telekommunikationsnetzwerk, einem Local Area Network (LAN), einem drahtlosen Netzwerk, einem Wide Area Network (WAN) wie dem Internet, einem Peer-to-Peer-Netzwerk, einem Kabelnetzwerk oder Ähnlichem) verbunden sein.
  • Das System 465 kann auch einen sekundären Speicher enthalten (nicht dargestellt). Der Sekundärspeicher enthält beispielsweise ein Festplattenlaufwerk und/oder ein Wechselspeicherlaufwerk, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein Compact-Disk-Laufwerk, ein DVD-Laufwerk, ein Aufzeichnungsgerät oder einen USB-Flash-Speicher repräsentiert. Das Wechselspeicherlaufwerk liest und/oder schreibt auf bekannte Weise von einer Wechselspeichereinheit.
  • Computerprogramme oder logische Algorithmen zur Computersteuerung können im Hauptspeicher 440 und/oder im sekundären Speicher gespeichert werden. Solche Computerprogramme ermöglichen es dem System 465, wenn sie ausgeführt werden, verschiedene Funktionen auszuführen. Der Speicher 440, der Speicher und/oder jeder andere Speicher sind mögliche Beispiele für computerlesbare Medien.
  • Die Architektur und/oder Funktionalität der verschiedenen vorhergehenden Figuren kann im Rahmen eines allgemeinen Computersystems, eines Schaltungssystems, eines Spielkonsolensystems für Unterhaltungszwecke, eines anwendungsspezifischen Systems und/oder eines beliebigen anderen gewünschten Systems implementiert werden. Zum Beispiel kann das System 465 die Form eines Desktop-Computers, eines Laptop-Computers, eines Tablet-Computers, eines Servers, eines Supercomputers, eines Smartphones (z.B. eines drahtlosen, handgehaltenen Geräts), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, einer am Kopf montierten Anzeige, eines handgehaltenen elektronischen Geräts, eines Mobiltelefongeräts, eines Fernsehers, einer Workstation, von Spielkonsolen, eines eingebetteten Systems und/oder jeder anderen Art von Logik annehmen.
  • Obwohl oben verschiedene Ausführungsbeispiele beschrieben wurden, ist es zu verstehen, dass sie nur als Beispiel und nicht als Einschränkung dargestellt wurden. Daher sollten die Breite und der Umfang einer bevorzugten Ausführungsform nicht durch eines der oben beschriebenen exemplarischen Ausführungsbeispiele begrenzt werden, sondern nur gemäß den folgenden Ansprüchen und deren Äquivalenten definiert werden.
  • Grafikverarbeitungs-Pipeline
  • In einem Ausführungsbeispiel umfasst die PPU 200 eine Grafikverarbeitungseinheit (GPU). Die PPU 200 ist so konfiguriert, dass sie Befehle empfängt, die Schattierungsprogramme für die Verarbeitung von Grafikdaten spezifizieren. Grafikdaten können als ein Satz von Primitiven wie Punkte, Linien, Dreiecke, Quads, Dreiecksstreifen und dergleichen definiert werden. Typischerweise enthält ein Primitiv Daten, die eine Anzahl von Vertices für das Primitiv spezifizieren (z. B. in einem Modell-Raum-Koordinatensystem), sowie Attribute, die jedem Vertex des Primitivs zugeordnet sind. Die PPU 200 kann so konfiguriert sein, dass sie die Grafikprimitive verarbeitet, um einen Einzelbildpuffer zu generieren (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 einen Systemspeicher oder Speicher 204. Die Modelldaten definieren jedes der Objekte, die auf einer Anzeige sichtbar sein können. Die Anwendung tätigt dann einen API-Aufruf an den Treiberkernel, der die zu rendernden und anzuzeigenden Modelldaten anfordert. Der Treiberkernel liest die Modelldaten und schreibt Befehle in einen oder mehrere Streams, um Operationen zur Verarbeitung der Modelldaten durchzuführen. Die Befehle können auf verschiedene Schattierungsprogramme verweisen, die auf den SMs 340 der PPU 200 zu implementieren sind, einschließlich eines oder mehrerer Vertex-Schattierer, Hull-Schattierer, Domain-Schattierer, Geometrie-Schattierer und Pixel-Schattierer. Beispielsweise kann einer oder mehrere der SMs 340 konfiguriert sein, um ein Schattierungsprogramm für Vertices auszuführen, das eine Anzahl von Vertices verarbeitet, die durch die Modelldaten definiert sind. In einem Ausführungsbeispiel können die verschiedenen SMs 340 konfiguriert sein, um verschiedene Schattierungsprogramme gleichzeitig auszuführen. So kann beispielsweise eine erste Teilmenge von SMs 340 so konfiguriert sein, dass sie ein Vertex-Shader-Programm ausführt, während eine zweite Teilmenge von SMs 340 so konfiguriert sein kann, dass sie ein Pixel-Schattierungsprogramm ausführt. Die erste Untergruppe von SMs 340 verarbeitet Vertex-Daten, um verarbeitete Vertex-Daten zu erzeugen, und schreibt die verarbeiteten Vertex-Daten in den L2-Cache 360 und/oder den Speicher 204. Nachdem die verarbeiteten Vertex-Daten gerastert (d. h. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum umgewandelt) wurden, um Fragmentdaten zu erzeugen, führt die zweite Untergruppe von SMs 340 einen Pixel-Schattierer aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten gemischt und in den Einzelbildpuffer im Speicher 204 geschrieben werden. Das Vertex-Schattierungsprogramm und das Pixel-Schattierer-Programm können gleichzeitig ausgeführt werden und verschiedene Daten derselben Szene in einer Pipeline verarbeiten, bis alle Modelldaten für die Szene in den Einzelbildpuffer gerendert worden sind. Dann wird der Inhalt des Einzelbildpuffers an ein Anzeigensteuergerät zur Anzeige auf einem Anzeigegerät übertragen.
  • 5 zeigt ein konzeptionelles Diagramm einer Grafikverarbeitungspipeline 500, die gemäß einem Ausführungsbeispiel von der PPU 200 aus 2 implementiert wird. Die Grafikverarbeitungspipeline 500 ist ein abstraktes Flussdiagramm der Verarbeitungsschritte, die zur Generierung von computergenerierten 2D-Bildern aus 3D-Geometriedaten implementiert werden. Wie bekannt, können Pipeline-Architekturen Vorgänge mit langer Latenzzeit effizienter durchführen, indem sie den Vorgang in eine Vielzahl von Stufen aufteilen, wobei die Ausgabe jeder Stufe mit der Eingabe der nächstfolgenden Stufe gekoppelt ist. So erhält die Grafikverarbeitungs-Pipeline 500 Eingabedaten 501, die von einer Stufe zur nächsten Stufe der Grafikverarbeitungs-Pipeline 500 übertragen werden, um Ausgabedaten 502 zu generieren. In einem Ausführungsbeispiel kann die Grafikverarbeitungspipeline 500 eine durch die OpenGL®-API definierte Grafikverarbeitungspipeline repräsentieren. Optional kann die Grafikverarbeitungspipeline 500 im Zusammenhang mit der Funktionalität und Architektur der vorangegangenen Figuren und/oder jeder aufeinanderfolgenden Figur(en) implementiert werden.
  • Wie in 5 dargestellt, umfasst die Grafikverarbeitungspipeline 500 eine Pipeline-Architektur, die eine Reihe von Stufen enthält. Die Stufen enthalten unter anderem eine Datenassemblierungsstufe 510, eine Vertex-Schattierungsstufe 520, eine Primitiv-Assemblierungsstufe 530, eine Geometrie-Schattierungsstufe 540, eine Ansichtsfenster-Skalierungs-, Ausblend- und Abschneidestufe (VSCC) 550, eine Rasterisierungsstufe 560, eine Fragment-Schattierungsstufe 570 und eine Rasteroperationsstufe 580. In einem Ausführungsbeispiel umfassen die Eingabedaten 501 Befehle, mit denen die verarbeitenden Einheiten so konfiguriert werden, dass sie die Stufen der Grafikverarbeitungspipeline 500 und die von den Stufen zu verarbeitenden geometrischen Primitive (z. B. Punkte, Linien, Dreiecke, Quads, Dreiecksstreifen oder Fächer usw.) implementieren. Die Ausgabedaten 502 können Pixeldaten (d. h. Farbdaten) umfassen, die in einen Einzelbildpuffer oder eine andere Art von Oberflächendatenstruktur in einem Speicher kopiert werden.
  • Die Datenzusammenstellungsstufe 510 empfängt die Eingabedaten 501, die Vertex-Daten für Oberflächen höherer Ordnung, Primitive oder Ähnliches spezifizieren. Die Datenassemblierungsstufe 510 sammelt die Vertex-Daten in einem temporären Speicher oder in einer Warteschlange, z. B. durch Empfang eines Befehls vom Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher enthält, und Lesen der Vertex-Daten aus dem Puffer. Die Vertex-Daten werden dann an die Vertex-Schattierungsstufe 520 zur Verarbeitung weitergeleitet.
  • Die Vertex-Schattierungsstufe 520 verarbeitet Vertex-Daten, indem sie einen Satz von Operationen (d. h. eine Schattierung oder ein Programm) einmal für jeden der Vertices ausführt. Vertices können z.B. als 4-Koordinaten-Vektor (d.h. <x, y, z, w>) spezifiziert werden, der mit einem oder mehreren Vertex-Attributen assoziiert ist (z.B. Farbe, Texturkoordinaten, Oberflächennormale, etc.). Die Vertex-Schattierungsstufe 520 kann einzelne Vertex-Attribute wie Position, Farbe, Texturkoordinaten und dergleichen manipulieren. Mit anderen Worten, die Vertex-Schattierungsstufe 520 führt Operationen an den Vertex-Koordinaten oder anderen Vertex-Attributen durch, die mit einem Vertex assoziiert sind. Solche Operationen enthalten üblicherweise Beleuchtungsoperationen (d.h. die Änderung von Farbattributen für einen Vertex) und Transformationsoperationen (d.h. die Änderung des Koordinatenraums für einen Vertex). Beispielsweise können Vertices unter Verwendung von Koordinaten in einem Objektkoordinatenraum spezifiziert werden, die durch Multiplikation der Koordinaten mit einer Matrix transformiert werden, die die Koordinaten aus dem Objektkoordinatenraum in einen Weltbereich oder einen normalisierten Gerätekoordinatenraum (NCD) übersetzt. Die Vertex-Schattierungsstufe 520 generiert transformierte Vertex-Daten, die an die Primitiv-Assemblierungsstufe 530 weitergeleitet werden.
  • Die Primitive Assembly-Stufe 530 sammelt die von der Vertex-Schattierungsstufe 520 ausgegebenen Vertices und gruppiert die Vertices in geometrische Primitives zur Verarbeitung durch die Geometrie-Schattierungsstufe 540. Beispielsweise kann die Primitive Assembly Stage 530 so konfiguriert sein, dass sie alle drei aufeinanderfolgenden Vertices als geometrische Primitive (d.h. ein Dreieck) zur Übertragung an die Geometrie-Schattierungsstufe 540 gruppiert. In einigen Ausführungsbeispielen können bestimmte Vertices für aufeinanderfolgende geometrische Primitive wiederverwendet werden (z. B. können zwei aufeinanderfolgende Dreiecke in einem Dreiecksstreifen zwei Vertices gemeinsam nutzen). Die Primitiv-Assemblierungsstufe 530 überträgt geometrische Primitive (d. h. eine Sammlung assoziierter Vertices) an die Geometrie-Schattierungsstufe 540.
  • Die Geometrie-Schattierungsstufe 540 verarbeitet geometrische Primitive, indem sie eine Reihe von Operationen (d.h. einen Geometrie-Schattierer oder ein Programm) an den geometrischen Primitiven durchführt. Tesselierungsoperationen können ein oder mehrere geometrische Primitive aus jedem geometrischen Primitiv generieren. Mit anderen Worten kann die Geometrieschattierungsstufe 540 jedes geometrische Element in ein feineres Netz aus zwei oder mehr geometrischen Grundelementen unterteilen, das vom Rest der Grafikverarbeitungspipeline 500 verarbeitet wird. Die Geometrieschattierungsstufe 540 überträgt geometrische Grundelemente an die Ansichtsfenster-SCC-Stufe 550.
  • In einem Ausführungsbeispiel kann die Grafikverarbeitungspipeline 500 in einem Streaming-Multiprozessor arbeiten, und die Vertex-Schattierungsstufe 520, die Primitiv-Assemblierungsstufe 530, die Geometrie-Schattierungsstufe 540, die Fragment-Schattierungsstufe 570 und/oder damit assoziierte Hardware/Software können sequentiell Verarbeitungsvorgänge durchführen. Sobald die sequentiellen Verarbeitungsvorgänge abgeschlossen sind, kann in einem Ausführungsbeispiel die Ansichtsfenster-SCC-Stufe 550 die Daten verwenden. In einem Ausführungsbeispiel können primitive Daten, die von einer oder mehreren der Stufen in der Grafikverarbeitungspipeline 500 verarbeitet wurden, in einen Cache (z. B. LI-Cache, einen Vertex-Cache usw.) geschrieben werden. In diesem Fall kann in einem Ausführungsbeispiel die Ansichtsfenster-SCC-Stufe 550 auf die Daten im Cache zugreifen. In einem Ausführungsbeispiel sind die SCC-Stufe 550 des Ansichtsfensters und die Rasterisierungsstufe 560 als Schaltungsanordnung mit festen Funktionen implementiert.
  • Die Ansichtsfenster-SCC-Stufe 550 skaliert das Ansichtsfenster, blendet es aus und schneidet die geometrischen Primitive ab. Jede Oberfläche, auf die gerendert wird, ist mit einer abstrakten Kameraposition assoziiert. Die Kameraposition repräsentiert den Standort eines Betrachters, der auf die Szene blickt, und definiert einen Sichtkegelstumpf, der die Objekte der Szene einschließt. Der Sichtkegelstumpf kann eine Betrachtungsebene, eine Rückwandebene und vier Abschneideebenen enthalten. Alle geometrischen Primitive, die sich vollständig außerhalb des Sichtkegels befinden, können ausgeblendet (d. h. verworfen) werden, da sie keinen Beitrag zur final gerenderten Szene leisten. Jedes geometrische Element, das sich teilweise innerhalb und teilweise außerhalb des Sichtkegelstumpfes befindet, kann abgeschnitten (d. h. in ein neues geometrisches Element umgewandelt) werden, das innerhalb des Sichtkegelstumpfes liegt. Darüber hinaus können geometrische Primitive basierend auf der Tiefe des Sichtkegelstumpfes skaliert werden. Alle potenziell sichtbaren geometrischen Primitive werden dann an die Rasterisierungsstufe 560 weitergeleitet.
  • Die Rasterisierungsstufe 560 wandelt die geometrischen 3D-Primitive in 2D-Fragmente um (die z. B. für die Anzeige usw. verwendet werden können). Die Rasterisierungsstufe 560 kann so konfiguriert sein, dass sie die Vertices der geometrischen Primitive verwendet, um einen Satz von Ebenengleichungen aufzubauen, aus denen verschiedene Attribute interpoliert werden können. Die Rasterisierungsstufe 560 kann auch eine Abdeckungsmaske für eine Vielzahl von Pixeln berechnen, die anzeigt, ob ein oder mehrere Sampling-Positionen für das Pixel das geometrische Primitiv durchschneiden. In einem Ausführungsbeispiel kann auch ein Z-Test durchgeführt werden, um zu bestimmen, ob die geometrische Grundform von anderen geometrischen Grundformen, die bereits gerastert wurden, verdeckt wird. Die Rasterisierungsstufe 560 generiert Fragment-Daten (d.h. interpolierte Vertex-Attribute, die mit einer bestimmten Sampling-Position für jedes abgedeckte Pixel assoziiert sind), die an die Fragment-Schattierungsstufe 570 übermittelt werden.
  • Die Fragment-Schattierungsstufe 570 verarbeitet Fragmentdaten, indem sie eine Reihe von Operationen (d.h. eine Fragment-Schattierung oder ein Programm) an jedem der Fragmente durchführt. Die Fragmentschattierungsstufe 570 kann Pixeldaten (d.h. Farbwerte) für das Fragment generieren, z.B. durch Ausführen von Beleuchtungsoperationen oder Sampling von Texturkarten unter Verwendung interpolierter Texturkoordinaten für das Fragment. Die Fragmentschattierungsstufe 570 generiert Pixeldaten, die an die Rasteroperationsstufe 580 übertragen werden.
  • Die Rasteroperationsstufe 580 kann verschiedene Operationen an den Pixeldaten durchführen, wie z. B. Alphatests, Schablonentests und das Mischen der Pixeldaten mit anderen Pixeldaten, die anderen, dem Pixel assoziierten Fragmenten entsprechen. Wenn die Rasteroperationsstufe 580 die Verarbeitung der Pixeldaten (d.h. der Ausgabedaten 502) abgeschlossen hat, können die Pixeldaten in ein Rendering-Ziel wie einen Einzelbildpuffer, einen Farbpuffer oder ähnliches geschrieben werden.
  • Es ist zu beachten, dass eine oder mehrere zusätzliche Stufen in der Grafikverarbeitungspipeline 500 enthalten sein können, zusätzlich zu oder anstelle von einer oder mehreren der oben beschriebenen Stufen. Verschiedene Implementierungen der abstrakten Grafikverarbeitungspipeline können unterschiedliche Stufen implementieren. Darüber hinaus können eine oder mehrere der oben beschriebenen Stufen in einigen Ausführungsbeispielen von der Grafikverarbeitungspipeline ausgeschlossen werden (z. B. die Geometrieschattierungsstufe 540). Andere Arten von Grafikverarbeitungspipelines sind im Rahmen der vorliegenden Offenbarung denkbar. Darüber hinaus kann jede der Stufen der Grafikverarbeitungspipeline 500 durch eine oder mehrere dedizierte Hardware-Einheiten innerhalb eines Grafikprozessors wie der PPU 200 implementiert werden. Andere Stufen der Grafikverarbeitungspipeline 500 können durch programmierbare Hardwareeinheiten wie die SM 340 der PPU 200 implementiert werden.
  • Die Grafikverarbeitungspipeline 500 kann über eine Anwendung implementiert werden, die von einem Host-Prozessor, wie z. B. einer CPU, ausgeführt wird. In einem Ausführungsbeispiel kann ein Gerätetreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, die verschiedene Funktionen definiert, die von einer Anwendung verwendet werden können, um grafische Daten für die Anzeige zu generieren. Der Gerätetreiber ist ein Softwareprogramm, das eine Vielzahl von Anweisungen enthält, die den Betrieb der PPU 200 steuern. Die API stellt eine Abstraktion für einen Programmierer bereit, die es ihm ermöglicht, spezialisierte Grafikhardware wie die PPU 200 zu nutzen, um die grafischen Daten zu generieren, ohne dass der Programmierer den spezifischen Befehlssatz für die PPU 200 verwenden muss. Die Anwendung kann einen API-Aufruf enthalten, der an den Gerätetreiber für die PPU 200 weitergeleitet wird. Der Gerätetreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu reagieren. In einigen Fällen kann der Gerätetreiber Operationen durchführen, indem er Anweisungen auf der CPU ausführt. In anderen Fällen kann der Gerätetreiber Operationen durchführen, zumindest teilweise, indem er Operationen auf der PPU 200 unter Verwendung einer Eingabe/Ausgabe-Schnittstelle zwischen der CPU und der PPU 200 startet. In einem Ausführungsbeispiel ist der Gerätetreiber konfiguriert, um die Grafikverarbeitungspipeline 500 unter Verwendung der Hardware der PPU 200 zu implementieren.
  • Innerhalb der PPU 200 können verschiedene Programme ausgeführt werden, um die verschiedenen Stufen der Grafikverarbeitungspipeline 500 zu implementieren. Zum Beispiel kann der Gerätetreiber einen Kernel auf der PPU 200 starten, um die Vertex-Schattierungsstufe 520 auf einem SM 340 (oder mehreren SMs 340) auszuführen. Der Gerätetreiber (oder der initiale Kernel, der von der PPU 300 ausgeführt wird) kann auch andere Kernel auf der PPU 300 starten, um andere Stufen der Grafikverarbeitungspipeline 500 auszuführen, z. B. die Geometrie-Schattierungsstufe 540 und die Fragment-Schattierungsstufe 570. Darüber hinaus können einige der Stufen der Grafikverarbeitungspipeline 500 auf Hardware mit fester Einheit implementiert werden, wie z. B. ein Rasterisierer oder ein Datenassembler, die in der PPU 300 implementiert sind. Es ist zu beachten, dass die Ergebnisse eines Kerns von einer oder mehreren zwischengeschalteten Hardware-Einheiten mit fester Funktion verarbeitet werden können, bevor sie von einem nachfolgenden Kern auf einem SM 340 verarbeitet werden.
  • Beispielhaftes Spiel-Streaming-System
  • Bezug nehmend auf Figur, 6 zeigt ein beispielhaftes Systemdiagramm für ein Spiel-Streaming-System 600, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. 6 enthält Spieleserver 602 (die ähnliche Komponenten, Merkmale und/oder Funktionalität wie das beispielhafte Rechengerät 700 aus 7 enthalten können), Client-Geräte) 604 (die ähnliche Komponenten, Merkmale und/oder Funktionalität wie das beispielhafte Rechengerät 700 aus 7 enthalten können) und Netzwerk(e) 606 (die ähnlich wie die hier beschriebenen Netzwerke sein können). In einigen Ausführungsbeispielen der vorliegenden Offenbarung kann das System 600 implementiert werden.
  • In dem System 600 kann/können das/die Client-Gerät(e) 604 für eine Spielsitzung nur Eingabedaten als Reaktion auf Eingaben an das/die Eingabegerät(e) empfangen, die Eingabedaten an den/die Spielserver 602 übertragen, kodierte Anzeigedaten von dem/den Spielserver(n) 602 empfangen und die Anzeigedaten auf der Anzeige 624 anzeigen. So werden die rechenintensiveren Berechnungen und Verarbeitungen auf den/die Spieleserver 602 verlagert (z. B. wird das Rendern - insbesondere Raytracing oder Path Tracing - für die grafische Ausgabe der Spielesitzung von der/den GPU(s) des/der Spieleserver(s) 602 ausgeführt). Mit anderen Worten, die Spielesitzung wird von dem/den Spieleserver(n) 602 zu dem/den Client-Gerät(en) 604 gestreamt, wodurch die Anforderungen des/der Client-Gerät(e) 604 für die Grafikverarbeitung und das Rendern reduziert werden.
  • Zum Beispiel kann ein Client-Gerät 604 in Bezug auf eine Instanziierung einer Spielesitzung ein Einzelbild der Spielesitzung auf der Anzeige 624 basierend auf dem Empfang der Anzeigedaten von dem/den Spieleserver(n) 602 anzeigen. Das Client-Gerät 604 kann eine Eingabe an einem der Eingabegeräte empfangen und daraufhin Eingabedaten generieren. Das Client-Gerät 604 kann die Eingabedaten über die Kommunikationsschnittstelle 620 und über das/die Netzwerk(e) 606 (z. B. das Internet) an den/die Spielserver 602 übertragen, und der/die Spielserver 602 kann die Eingabedaten über die Kommunikationsschnittstelle 618 empfangen. Die CPU(s) können die Eingabedaten empfangen, die Eingabedaten verarbeiten und Daten an die GPU(s) übertragen, die bewirken, dass die GPU(s) eine Generierung der Spielsitzung generieren. Die Eingabedaten können beispielsweise eine Bewegung einer Spielfigur des Benutzers repräsentieren, das Abfeuern einer Waffe, das Nachladen, das Abgeben eines Balls, das Wenden eines Fahrzeugs, usw. Die Rendering-Komponente 612 kann die Spielsitzung rendern (z. B. repräsentativ für das Ergebnis der Eingabedaten), und die Rendering-Erfassungskomponente 614 kann das Rendering der Spielsitzung als Anzeigedaten erfassen (z. B. als Bilddaten, die das gerenderte Einzelbild der Spielsitzung erfassen). Das Rendern der Spielsitzung kann Raytracing- oder Pfadverfolgungsbeleuchtungs- und/oder Schatteneffekte enthalten, die unter Verwendung einer oder mehrerer Parallelverarbeitungseinheiten - wie GPUs, die weiter die Verwendung eines oder mehrerer dedizierter Hardwarebeschleuniger oder Verarbeitungskerne zur Durchführung von Raytracing- oder Pfadverfolgungstechniken nutzen können - des/der Spieleserver(s) 602 berechnet werden. Der Kodierer 616 kann dann die Anzeigedaten kodieren, um kodierte Anzeigedaten zu generieren, und die kodierten Anzeigedaten können über das/die Netzwerk(e) 606 über die Kommunikationsschnittstelle 618 an das Client-Gerät 604 übertragen werden. Das Client-Gerät 604 kann die kodierten Anzeigedaten über die Kommunikationsschnittstelle 620 empfangen und der Decoder 622 kann die kodierten Anzeigedaten dekodieren, um die Anzeigedaten zu generieren. Das Client-Gerät 604 kann dann die Anzeigedaten über die Anzeige 624 anzeigen.
  • Beispielhaftes Rechengerät
  • 7 zeigt ein Blockdiagramm eines beispielhaften Rechengeräts 700, das zur Verwendung bei der Implementierung einiger Ausführungsbeispiele der vorliegenden Offenbarung geeignet ist. Das Rechengerät 700 kann ein Verbindungssystem (Interconnect-System) 702 enthalten, das direkt oder indirekt die folgenden Geräte koppelt: Speicher 704, eine oder mehrere Zentraleinheiten (CPUs) 706, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 708, eine Kommunikationsschnittstelle 710, Ein-/Ausgabeanschlüsse (E/A) 712, Eingabe-/Ausgabekomponenten 714, eine Stromversorgung 716, eine oder mehrere Präsentationskomponenten 718 (z.B. Anzeige(n)) und eine oder mehrere Logikeinheiten 720.
  • Obwohl die verschiedenen Blöcke in 7 als über das Verbindungssystem 702 mit Leitungen verbunden dargestellt sind, ist dies nicht als Einschränkung zu verstehen und dient nur der Klarheit. Zum Beispiel kann in einigen Ausführungsbeispielen eine Präsentationskomponente 718, wie ein Anzeigegerät, als E/A-Komponente 714 betrachtet werden (z. B. wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 706 und/oder GPUs 708 einen Speicher enthalten (z. B. kann der Speicher 704 zusätzlich zum Speicher der GPUs 708, der CPUs 706 und/oder anderer Komponenten ein Speichergerät repräsentieren). Mit anderen Worten: Das Rechengerät in 7 ist lediglich beispielhaft. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „mobiles Gerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, da alle im Umfang des Rechengeräts der 7 in Betracht kommen.
  • Das Verbindungssystem 702 kann eine oder mehrere Verbindungen oder Busse repräsentieren, wie z.B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verbindungssystem 702 kann einen oder mehrere Bus- oder Verbindungstypen enthalten, wie z. B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect Express) und/oder eine andere Art von Bus oder Verbindung. In einigen Ausführungsbeispielen gibt es direkte Verbindungen zwischen den Komponenten. So kann beispielsweise die CPU 706 direkt mit dem Speicher 704 verbunden sein. Weiter kann die CPU 706 direkt mit der GPU 708 verbunden sein. Bei direkten oder Punktzu-Punkt-Verbindungen zwischen Komponenten kann das Verbindungssystem 702 eine PCIe-Verbindung enthalten, um die Verbindung herzustellen. In diesen Beispielen muss ein PCI-Bus nicht im Rechengerät 700 enthalten sein.
  • Der Speicher 704 kann eine Vielzahl von computerlesbaren Medien enthalten. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die das Rechengerät 700 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nicht-flüchtige Medien sowie entfernbare und nicht-entfernbare Medien enthalten. Als Beispiel und ohne Einschränkung können die computerlesbaren Medien Computer-SpeicherMedien und Kommunikationsmedien umfassen.
  • Die Computer-Speichermedien können sowohl flüchtige als auch nicht-flüchtige Medien und/oder entfernbare und nicht-entfernbare Medien enthalten, die in einem beliebigen Verfahren oder einer Technologie zur Speicherung von Informationen wie computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder anderen Datentypen implementiert sind. Beispielsweise kann der Speicher 704 computerlesbare Anweisungen speichern (z. B. solche, die ein oder mehrere Programme und/oder ein oder mehrere Programmelemente repräsentieren, wie z. B. ein Betriebssystem). Computerspeichermedien können unter anderem RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichergeräte oder jedes andere Medium enthalten, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das das Rechengerät 700 zugreifen kann. Wie hierin verwendet, umfassen Computer-SpeicherMedien nicht per se Signale.
  • Die Computer-Speichermedien können computerlesbare Anweisungen, Datenstrukturen, Programm-Module und/oder andere Datentypen in einem modulierten Datensignal, wie z.B. einer Trägerwelle oder einem anderen Transportmechanismus, verkörpern und enthalten beliebige Informationsübertragungsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder verändert wurden, dass Informationen in dem Signal kodiert werden. Der Speicher kann beispielsweise verdrahtete Medien, wie ein verdrahtetes Netzwerk oder eine Direktverbindung, und drahtlose Medien, wie akustische, RF-, Infrarot- und andere drahtlose Medien, enthalten, ohne darauf beschränkt zu sein. Kombinationen der oben genannten Medien sollten ebenfalls im Umfang der computerlesbaren Medien enthalten sein.
  • Die CPU(s) 706 kann/können so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt/ausführen, um eine oder mehrere Komponenten des Rechengeräts 700 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 706 kann/können jeweils einen oder mehrere Kerne enthalten (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.), die in der Lage sind, eine Vielzahl von Software-Threads simultan zu verarbeiten. Die CPU(s) 706 kann/können jeden Prozessortyp enthalten und je nach Art des implementierten Rechengeräts 700 unterschiedliche Prozessortypen enthalten (z. B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Je nach Art des Rechengeräts 700 kann der Prozessor beispielsweise ein Advanced RISC Machines (ARM)-Prozessor unter Verwendung von Reduced Instruction Set Computing (RISC) oder ein x86-Prozessor unter Verwendung von Complex Instruction Set Computing (CISC) sein. Das Rechengerät 700 kann eine oder mehrere CPUs 706 enthalten, zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Co-Prozessoren, wie z. B. mathematischen Co-Prozessoren.
  • Zusätzlich zu oder alternativ zu der/den CPU(s) 706 kann die GPU(s) 708 so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt, um eine oder mehrere Komponenten des Rechengeräts 700 zu steuern, um eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehrere der GPU(s) 708 können eine integrierte GPU sein (z.B. mit einer oder mehreren der CPU(s) 706) und/oder eine oder mehrere der GPU(s) 708 können eine diskrete GPU sein. In Ausführungsbeispielen kann eine oder mehrere der GPU(s) 708 ein Coprozessor einer oder mehrerer der CPU(s) 706 sein. Die GPU(s) 708 kann/können von dem Rechengerät 700 verwendet werden, um Grafiken zu rendern (z. B. 3D-Grafiken) oder allgemeine Berechnungen durchzuführen. Die GPU(s) 708 kann/können zum Beispiel für allgemeine Berechnungen auf GPUs (GPGPU) verwendet werden. Die GPU(s) 708 kann(en) Hunderte oder Tausende von Kernen enthalten, die in der Lage sind, Hunderte oder Tausende von Software-Threads simultan zu verarbeiten. Die GPU(s) 708 kann/können Pixeldaten für die Ausgabe von Bildern als Reaktion auf Rendering-Befehle generieren (z. B. Rendering-Befehle von der/den CPU(s) 706, die über eine Host-Schnittstelle empfangen werden). Die GPU(s) 708 kann/können einen Grafikspeicher, z. B. einen Anzeigespeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, wie z. B. GPGPU-Daten, enthalten. Der Anzeigespeicher kann als Teil des Speichers 704 enthalten sein. Die GPU(s) 708 kann/können zwei oder mehr GPUs enthalten, die parallel arbeiten (z. B. über eine Verbindung). Die Verbindung kann die GPUs direkt verbinden (z. B. unter Verwendung von NVLINK) oder die GPUs über einen Switch verbinden (z. B. unter Verwendung von NVSwitch). In Kombination kann jede GPU 708 Pixeldaten oder GPGPU-Daten für verschiedene Teile einer Ausgabe oder für verschiedene Ausgaben generieren (z. B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher enthalten oder den Speicher gemeinsam mit anderen GPUs nutzen.
  • Zusätzlich zu oder alternativ zu der (den) CPU(s) 706 und/oder der (den) GPU(s) 708 kann (können) die Logikeinheit(en) 720 konfiguriert sein, um zumindest einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten des Rechengeräts 700 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. In Ausführungsbeispielen können die CPU(s) 706, die GPU(s) 708 und/oder die Logikeinheit(en) 720 diskret oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der logischen Einheiten 720 können Teil einer oder mehrerer der CPU(s) 706 und/oder der GPU(s) 708 sein und/oder eine oder mehrere der logischen Einheiten 720 können diskrete Komponenten sein oder anderweitig außerhalb der CPU(s) 706 und/oder der GPU(s) 708 liegen. In Ausführungsbeispielen kann eine oder mehrere der logischen Einheiten 720 ein Coprozessor einer oder mehrerer der CPU(s) 706 und/oder einer oder mehrerer der GPU(s) 708 sein.
  • Beispiele für die Logikeinheit(en) 720 enthalten einen oder mehrere Verarbeitungskerne und/oder Komponenten davon, wie Tensor-Kerne (TCs), Tensor-Verarbeitungseinheiten (TPUs), Pixel-Visual-Cores (PVCs), Vision-Verarbeitungseinheiten (VPUs), Grafikverarbeitungscluster (GPCs), Texturverarbeitungscluster (TPCs), Streaming-Multiprozessoren (SMs), Baum-Traversierungseinheiten (TTUs), Artificial Intelligence Accelerators (AIAs), Deep Learning Accelerators (DLAs), Arithmetik-Logik-Einheiten (ALUs), anwendungsspezifische integrierte Schaltungen (ASICs), Fließkommaeinheiten (FPUs), Eingabe/Ausgabe-Elemente (I/Os), Peripheral Component Interconnect (PCI)- oder Peripheral Component Interconnect Express (PCIe)-Elemente und/oder Ähnliches.
  • Die Kommunikationsschnittstelle 710 kann einen oder mehrere Empfänger, Sender und/oder Transceiver enthalten, die es dem Rechengerät 700 ermöglichen, mit anderen Rechengeräten über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikation. Die Kommunikationsschnittstelle 710 kann Komponenten und Funktionalitäten enthalten, um die Kommunikation über eine beliebige Anzahl verschiedener Netzwerke zu ermöglichen, wie z.B. drahtlose Netzwerke (z.B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), verdrahtete Netzwerke (z.B. Kommunikation über Ethernet oder InfiniBand), Wide Area Networks mit niedriger Leistung (z.B. LoRaWAN, SigFox, etc.) und/oder das Internet.
  • Über die E/A-Anschlüsse 712 kann das Rechengerät 700 logisch mit anderen Geräten gekoppelt werden, darunter die E/A-Komponenten 714, die Präsentationskomponente(n) 718 und/oder andere Komponenten, von denen einige in das Rechengerät 700 eingebaut (z. B. integriert) sein können. Beispielhafte E/A-Komponenten 714 enthalten ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, ein Steuergerät für Spiele, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. Die E/A-Komponenten 714 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die von einem Benutzer generierte Luftgesten, Sprache oder andere physiologische Eingaben verarbeitet. In einigen Fällen können die Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie unten im Detail beschrieben) in Verbindung mit einer Anzeige des Rechengeräts 700 implementieren. Das Rechengerät 700 kann Tiefenkameras, wie z. B. stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -erfassung enthalten. Zusätzlich kann das Rechengerät 700 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (IMU)) enthalten, die das Erkennen von Bewegungen ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von dem Rechengerät 700 verwendet werden, um immersive Augmented Reality oder virtuelle Realität zu rendern.
  • Die Stromversorgung 716 kann eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon enthalten. Die Stromversorgung 716 kann dem Rechengerät 700 Energie bereitstellen, um den Betrieb der Komponenten des Rechengeräts 700 zu ermöglichen.
  • Die Präsentationskomponente(n) 718 kann/können eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-Up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten enthalten. Die Präsentationskomponente(n) 718 kann/können Daten von anderen Komponenten (z. B. der/den GPU(s) 708, der/den CPU(s) 706 usw.) empfangen und die Daten ausgeben (z. B. als Bild, Video, Ton usw.).
  • Beispielhafte Netzwerkumgebungen
  • Netzwerkumgebungen, die sich zur Verwendung bei der Implementierung von Ausführungsbeispielen der Offenbarung eignen, können ein oder mehrere Client-Geräte, Server, netzwerkgebundene Speicher (NAS), andere Backend-Geräte und/oder andere Gerätetypen enthalten. Die Client-Geräte, Server und/oder anderen Gerätetypen (z. B. jedes Gerät) können auf einer oder mehreren Instanzen des/der Rechengerät(e) 700 der 7 implementiert werden - z. B. kann jedes Gerät ähnliche Komponenten, Merkmale und/oder Funktionalität des/der Rechengerät(e) 700 enthalten.
  • Komponenten einer Netzwerkumgebung können über ein oder mehrere Netzwerke miteinander kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netzwerk kann mehrere Netzwerke oder ein Netzwerk von Netzwerken enthalten. Beispielsweise kann das Netzwerk ein oder mehrere Wide Area Networks (WANs), ein oder mehrere Local Area Networks (LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein öffentliches Telefonnetz (PSTN) und/oder ein oder mehrere private Netzwerke enthalten. Wenn das Netz ein drahtloses Telekommunikationsnetz enthält, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) eine drahtlose Verbindung bereitstellen.
  • Kompatible Netzwerkumgebungen können eine oder mehrere Peer-to-Peer-Netzwerkumgebungen - in diesem Fall kann ein Server nicht in einer Netzwerkumgebung enthalten sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall können ein oder mehrere Server in einer Netzwerkumgebung enthalten sein - umfassen. In Peer-to-Peer-Netzwerkumgebungen kann die hier beschriebene Funktionalität in Bezug auf einen oder mehrere Server auf einer beliebigen Anzahl von Client-Geräten implementiert werden.
  • In mindestens einem Ausführungsbeispiel kann eine Netzwerkumgebung eine oder mehrere Cloud-basierte Netzwerkumgebungen, eine verteilte Datenverarbeitungsumgebung, eine Kombination davon, usw. enthalten. Eine Cloud-basierte Netzwerkumgebung kann eine Framework-Schicht, einen Aufgabenplaner, einen Ressourcenmanager und ein verteiltes Dateisystem enthalten, die auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kern-Netzwerkserver und/oder Edge-Server enthalten können. Eine Framework-Schicht kann ein Framework zur Unterstützung von Software einer Software-Schicht und/oder einer oder mehrerer Anwendungen einer Anwendungsschicht enthalten. Die Software oder Anwendung(en) können jeweils webbasierte Dienstsoftware oder Anwendungen enthalten. In Ausführungsbeispielen kann eines oder mehrere der Client-Geräte die webbasierte Dienstsoftware oder Anwendungen verwenden (z. B. durch Zugriff auf die Dienstsoftware und/oder Anwendungen über eine oder mehrere Anwendungsprogrammierschnittstellen (APIs)). Die Framework-Schicht kann eine Art von freiem und quelloffenem Software-Webanwendungs-Framework sein, das z. B. ein verteiltes Dateisystem für die Verarbeitung großer Datenmengen (z. B. „Big Data“) verwenden kann, ist aber nicht darauf beschränkt.
  • Eine Cloud-basierte Netzwerkumgebung kann Cloud-Computing und/oder Cloud-Speicher bereitstellen, die eine beliebige Kombination der hierin beschriebenen Rechen- und/oder Datenspeicherfunktionen (oder einen oder mehrere Teile davon) ausführen. Jede dieser verschiedenen Funktionen kann über mehrere Standorte von zentralen oder Kern-Servern (z. B. von einem oder mehreren Rechenzentren, die über einen Staat, einen Bereich, ein Land, den Globus usw. verteilt sein können) verteilt sein. Befindet sich eine Verbindung zu einem Nutzer (z. B. einem Client-Gerät) relativ nahe an einem oder mehreren Edge-Servem, kann ein Kern-Server zumindest einen Teil der Funktionalität dem oder den Edge-Servern zuweisen. Eine Cloud-basierte Netzwerkumgebung kann privat (z. B. auf eine einzelne Organisation beschränkt), öffentlich (z. B. für viele Organisationen verfügbar) und/oder eine Kombination davon (z. B. eine hybride Cloud-Umgebung) sein.
  • Das (die) Client-Gerät(e) kann (können) zumindest einige der Komponenten, Merkmale und Funktionalitäten des (der) hierin in Bezug auf 7 beschriebenen Beispiel-Rechengeräts (-geräte) 700 enthalten. Als Ausführungsbeispiel und nicht einschränkend kann ein Rechengerät einen Personal Computer (PC), einen Laptop, ein mobiles Gerät, ein Smartphone, einen Tablet-Computer, eine Smartwatch, einen tragbaren Computer, einen Personal Digital Assistant (PDA), einen MP3-Player, ein Virtual-Reality-Headset, ein Global Positioning System (GPS) oder ein Gerät, einen Videoplayer, eine Videokamera, ein Überwachungsgerät oder - system, ein Fahrzeug, ein Boot, ein fliegendes Schiff, eine virtuelle Maschine, eine Drohne, ein Roboter, ein tragbares Kommunikationsgerät, ein Krankenhausgerät, ein Spielgerät oder -system, ein Unterhaltungssystem, ein Fahrzeugcomputersystem, ein eingebettetes Systemsteuergerät, eine Fernbedienung, ein Gerät, ein Unterhaltungselektronikgerät, eine Workstation, ein Edge-Gerät, eine beliebige Kombination dieser beschriebenen Geräte oder jedes andere geeignete Gerät.
  • Exemplarische Implementierung mit verlustbehafteter Komprimierung
  • 8 zeigt ein Flussdiagramm eines Verfahrens 800 zum Streaming eines komprimierten Lichtfelds, das gemäß einem Ausführungsbeispiel unter Verwendung einer verlustbehafteten Kompression komprimiert wird. Obwohl das Verfahren 800 im Zusammenhang mit einer verarbeitenden Einheit beschrieben wird, kann das Verfahren 800 auch durch ein Programm, eine benutzerdefinierte Schaltungsanordnung oder durch eine Kombination aus benutzerdefinierter Schaltungsanordnung und einem Programm ausgeführt werden. Beispielsweise kann das Verfahren 800 von einer GPU (Grafikverarbeitungseinheit), einer CPU (Zentraleinheit) oder einem beliebigen Prozessor ausgeführt werden, der in der Lage ist, paralleles Filtern von Pfadräumen durch Hashing durchzuführen. Darüber hinaus werden Personen mit gewöhnlichem Fachwissen verstehen, dass jedes System, das das Verfahren 800 ausführt, innerhalb des Umfangs und des Geistes der Ausführungsbeispiele der vorliegenden Erfindung liegt.
  • Es ist zu verstehen, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Weiter sind viele der hier beschriebenen Elemente funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionalitäten, die von Einheiten ausgeführt werden, können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
  • Wie in Operation 802 gezeigt, wird eine zu rendernde Szene identifiziert. In einem Ausführungsbeispiel kann die Szene ein Standbild, ein Einzelbild innerhalb eines Videos, ein Einzelbild innerhalb eines Videospiels usw. enthalten. In einem anderen Ausführungsbeispiel kann das entfernte Gerät einen Rechenknoten in einem verteilten Rechensystem, einen oder mehrere Knoten in einer Cloud-basierten Rechenumgebung, ein Server-Rechengerät usw. enthalten. In einem weiteren Ausführungsbeispiel kann das entfernte Gerät physisch von einem Client-Gerät getrennt sein.
  • Zusätzlich wird, wie in Operation 804 gezeigt, ein Lichtfeld für die Szene unter Verwendung von Raytracing berechnet. In einem Ausführungsbeispiel kann das entfernte Gerät Raytracing innerhalb einer Szene durchführen, um das Lichtfeld für die Szene zu bestimmen. Das Raytracing kann z. B. die Verfolgung eines Lichtweges als Pixel in einer Bildebene und die Simulation der Auswirkungen seiner Begegnungen mit Objekten innerhalb der Szene enthalten. In einem anderen Ausführungsbeispiel kann das Raytracing in Echtzeit durchgeführt werden.
  • Weiter kann in einem Ausführungsbeispiel das Lichtfeld eine Vielzahl von Lichtproben enthalten. In einem anderen Ausführungsbeispiel kann jede Lichtprobe Informationen über Licht speichern, das durch leeren Raum innerhalb der Szene hindurchgeht.
  • Weiter, wie in Operation 806 gezeigt, wird das Lichtfeld unter Verwendung verlustbehafteter Kompression komprimiert, um komprimierte Lichtfelddaten für die Szene zu erzeugen. In einem Ausführungsbeispiel kann das entfernte Gerät das Lichtfeld unter Verwendung einer Videocodier- und/oder Videokompressionseinheit komprimieren. Die Einheit kann zum Beispiel in einer GPU angeordnet sein.
  • In einem Ausführungsbeispiel kann das Lichtfeld auch unter Verwendung von einem oder mehreren Videokompressionsalgorithmen/-techniken komprimiert werden. In einem anderen Ausführungsbeispiel kann die Kompression eine aktuelle Benutzeransicht innerhalb der Szene berücksichtigen.
  • Zusätzlich kann in einem Ausführungsbeispiel die Komprimierung des Lichtfeldes unter Verwendung einer verlustbehafteten Komprimierung die Durchführung einer Farbkonvertierung des Lichtfeldes enthalten. Zum Beispiel kann das Lichtfeld Farbdaten enthalten (z.B. rote, grüne und blaue (RGB) Pixel, usw.). In einem anderen Beispiel kann das Lichtfeld von RGB-Pixeln in YUV-Pixel umgewandelt werden, wobei Y einen Luma-Wert und U, V einen Chrominanz-Wert repräsentiert. So können z. B. Pixelblöcke einer bestimmten Größe (z. B. vier RGB-Pixel usw.) in YUV-Pixel der gleichen Größe (z. B. vier Pixel) umcodiert werden. In einem anderen Ausführungsbeispiel können die neu kodierten YUV- oder RGB-Pixel dann komprimiert werden.
  • Darüber hinaus kann in einem Ausführungsbeispiel die Komprimierung des Lichtfelds unter Verwendung verlustfreier oder verlustbehafteter Komprimierung die Durchführung eines Downsamplings (dt. auch Unterabtastung, Verringerung der Bildpunkte engl. samples) der Chrominanz-Ebene innerhalb des Lichtfelds enthalten. Zum Beispiel kann das Lichtfeld Farbwerte enthalten, die normalisiert und in einer vorbestimmten Textur gespeichert werden (z.B. eine A2RGB 10-Farbtextur usw.). In einem anderen Beispiel können diese normalisierten Werte quantisiert und in vorzeichenlose ganzzahlige YUV-Werte (z. B. YUV-Tupel usw.) bitverschoben werden. In einem weiteren Beispiel können diese YUV-Tupel in YUV-Ebenen neu geordnet werden. In einem weiteren Beispiel kann eine Reduktion (z. B. Downsampling) an den YUV-Ebenen vorgenommen werden, um reduzierte YUV-Ebenen zu erzeugen. Auf die reduzierten YUV-Ebenen kann dann auch kodiert werden.
  • Auf diese Weise kann die Komprimierung des Lichtfeldes unter Verwendung einer verlustfreien oder verlustbehafteten Komprimierung ein höheres Maß an Komprimierung ermöglichen, was die Größe der komprimierten Daten und die zur Übertragung der komprimierten Daten an ein Client-Gerät erforderliche Bandbreite verringern kann. Dadurch kann die Leistung der an der Übertragung und dem Empfang der komprimierten Daten beteiligten Computerhardware verbessert werden. Obwohl bei der verlustbehafteten Komprimierung einige Farbinformationen verloren gehen können, ist ein solcher Verlust akzeptabel, da die menschliche visuelle Erfassung im Vergleich zur Luminanz/Helligkeit weniger empfindlich auf Farbe reagiert. Infolgedessen kann der Farbverlust für das menschliche Auge nicht wahrnehmbar sein.
  • Weiter, wie in Operation 808 gezeigt, werden die komprimierten Lichtfelddaten an ein Gerät gesendet. In einem Ausführungsbeispiel kann das komprimierte Lichtfeld von dem entfernten Gerät über ein oder mehrere drahtgebundene und/oder drahtlose Kommunikationsnetze (z. B. eine drahtlose Internetverbindung, ein Mobilfunknetz usw.) an das Client-Gerät gesendet werden.
  • Auf diese Weise kann das komprimierte Lichtfeld aus der Ferne berechnet, unter Verwendung verlustfreier oder verlustbehafteter Kompression komprimiert und dem Gerät des Kunden bereitgestellt werden, wo das Gerät des Kunden das komprimierte Lichtfeld dekomprimieren und das dekomprimierte Lichtfeld verwenden kann, um eine globale Beleuchtung für die Szene am Gerät des Kunden durchzuführen. Die Implementierung der zeitlichen Wiederverwendung während der Komprimierung des Lichtfelds kann zu einer geringeren Latenzzeit sowohl bei der Erstellung als auch bei der Übertragung der komprimierten Lichtfelddaten führen. Weiter können bei der Berechnung des Lichtfelds für die Szene die Beleuchtungsberechnungen dynamisch berechnet werden und können nicht auf statischen Szenen oder statischer Beleuchtung beruhen. Dies kann dynamische Änderungen der Szenen/Beleuchtung effektiv berücksichtigen und die Qualität des gerenderten Ergebnisses verbessern.
  • 9 zeigt ein Flussdiagramm eines Verfahrens 900 zum Empfangen und Dekomprimieren eines unter Verwendung einer Farbkonvertierung komprimierten Lichtfeldes gemäß einem Ausführungsbeispiel. Obwohl das Verfahren 900 im Zusammenhang mit einer verarbeitenden Einheit beschrieben wird, kann das Verfahren 900 auch durch ein Programm, eine benutzerdefinierte Schaltungsanordnung oder durch eine Kombination aus benutzerdefinierter Schaltungsanordnung und einem Programm durchgeführt werden. Beispielsweise kann das Verfahren 900 von einer GPU (Grafikverarbeitungseinheit), einer CPU (Zentraleinheit) oder einem beliebigen Prozessor ausgeführt werden, der in der Lage ist, paralleles Filtern von Pfadräumen durch Hashing durchzuführen. Darüber hinaus werden Personen mit gewöhnlichem Fachwissen verstehen, dass jedes System, das das Verfahren 900 ausführt, innerhalb des Umfangs und des Geistes der Ausführungsbeispiele der vorliegenden Erfindung liegt.
  • Es ist zu verstehen, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Weiter sind viele der hier beschriebenen Elemente funktionelle Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionalitäten, die von Einheiten ausgeführt werden, können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
  • Wie in Operation 902 gezeigt, werden komprimierte Lichtfelddaten für eine Szene empfangen. In einem Ausführungsbeispiel kann das komprimierte Lichtfeld von einem entfernten Gerät an einem Client-Gerät über ein oder mehrere drahtgebundene und/oder drahtlose Kommunikationsnetze (z. B. eine drahtlose Internetverbindung, ein Mobilfunknetz usw.) empfangen werden. In einem weiteren Ausführungsbeispiel kann das Client-Gerät ein Gerät enthalten, das eine Szene zumindest teilweise rendert und die gerenderte Szene anzeigt. In einem weiteren Ausführungsbeispiel kann das Client-Gerät ein mobiles Gerät (z. B. ein Smartphone, ein Tablet usw.), eine tragbare Spieleplattform, ein VR-Headset usw. enthalten.
  • Zusätzlich werden, wie in Operation 904 gezeigt, die komprimierten Lichtfelddaten dekomprimiert, und eine Farbkonvertierung der dekomprimierten Lichtfelddaten wird durchgeführt, um das Lichtfeld für die Szene zu erhalten. In einem Ausführungsbeispiel kann das Client-Gerät das komprimierte Lichtfeld unter Verwendung eines Videodecoders und/oder einer Videodekomprimierungseinheit dekomprimieren. In einem anderen Ausführungsbeispiel kann der Video-Decoder und/oder die Video-Dekompressionseinheit eine spezielle Hardware-Einheit innerhalb des Client-Geräts enthalten. In einem weiteren Ausführungsbeispiel kann die Videodecoder- und/oder Videodekompressionseinheit in einer GPU des Client-Geräts angeordnet sein.
  • Weiter kann in einem Ausführungsbeispiel das Lichtfeld zuvor von RGB-Pixeln in YUV-Pixel umgewandelt worden sein. In einem anderen Ausführungsbeispiel kann das dekomprimierte Lichtfeld daher in einem YUV-Format vorliegen. In einem weiteren Ausführungsbeispiel kann das dekomprimierte Lichtfeld von den YUV-Pixeln wieder in RGB-Pixel umgewandelt werden.
  • Weiter kann, wie in Operation 906 gezeigt, eine globale Beleuchtung für die Szene unter Verwendung des Lichtfeldes für die Szene durchgeführt werden. In einem Ausführungsbeispiel kann das Client-Gerät bei der Berechnung der globalen Beleuchtung Nachschlageoperationen innerhalb des Lichtfelds durchführen (z. B. anstelle der Durchführung von Raytracing oder anderen ressourcenintensiven Aktionen usw.). In einem anderen Ausführungsbeispiel kann die Berechnung der globalen Beleuchtung sowohl die Modellierung von indirektem Licht (z. B. wie Licht von Oberflächen auf andere Oberflächen innerhalb der Szene reflektiert wird) als auch von direktem Licht (z. B. Licht, das direkt von einer Lichtquelle auf eine Oberfläche trifft) enthalten. In einem weiteren Ausführungsbeispiel kann die berechnete globale Beleuchtung verwendet werden, um die Szene auf dem Client-Gerät zu rendern. In einem weiteren Ausführungsbeispiel kann die gerenderte Szene auf dem Gerät des Kunden angezeigt werden.
  • Auf diese Weise kann die Leistung der globalen Beleuchtung für die Szene eine realistische Darstellung der Szene bei der Anzeige durch das Client-Gerät verbessern. Darüber hinaus kann die globale Beleuchtung unter Verwendung von Lichtfeld-Lookups effizienter durchgeführt werden, was den Umfang der auf dem Client-Gerät erforderlichen Verarbeitung verringern kann. Dies kann die Leistung des Client-Geräts beim Rendern der Szene verbessern und zu einem qualitativ hochwertigen, dynamisch gerenderten Bild mit geringer Bandbreitennutzung führen.
  • Beispielhafte verteilte Rechenumgebung
  • 10 zeigt ein beispielhaftes verteiltes Rendering-System 1000 gemäß einem exemplarischen Ausführungsbeispiel. Wie dargestellt, steht ein Client-Gerät 1002 über ein Kommunikationsnetzwerk 1006 mit einem entfernten Gerät 1004 in Verbindung. In einem Ausführungsbeispiel kann das Kommunikationsnetzwerk 1006 ein oder mehrere drahtgebundene und/oder drahtlose Kommunikationsnetzwerke enthalten.
  • Zusätzlich kann in einem Ausführungsbeispiel eine zu rendernde Szene von dem entfernten Gerät 1004 empfangen werden. Zum Beispiel kann die Szene eine Szene innerhalb eines Videospiels enthalten, das von einem Benutzer auf dem Client-Gerät gespielt wird. In einem anderen Beispiel können Spielinformationen (z. B. ein Benutzerstandort innerhalb des Spiels, eine Ansicht des Benutzers innerhalb des Spiels usw.) von dem Client-Gerät 1002 über das Kommunikationsnetz 1006 an das entfernte Gerät 1004 übertragen werden.
  • Weiter kann in einem Ausführungsbeispiel das entfernte Gerät 1004 ein Lichtfeld für die Szene unter Verwendung von Raytracing berechnen. Zusätzlich kann das entfernte Gerät 1004 das Lichtfeld für die Szene unter Verwendung von verlustfreier oder verlustbehafteter Kompression komprimieren, um komprimierte Lichtfelddaten für die Szene zu erzeugen. Zum Beispiel kann das entfernte Gerät 1004 eine Farbkonvertierung des Lichtfeldes durchführen. In einem anderen Beispiel kann das entfernte Gerät 1004 ein Downsampling der Chrominanz-Ebene innerhalb des Lichtfeldes durchführen.
  • In einem Ausführungsbeispiel kann das Lichtfeld durch das entfernte Gerät 1004 unter Verwendung von einem oder mehreren Videokompressionsalgorithmen/-techniken komprimiert werden, die eine zeitliche Wiederverwendung implementieren. In einem anderen Beispiel kann die Berechnung und Komprimierung des Lichtfeldes eine aktuelle, potenziell sichtbare Benutzeransicht innerhalb der Szene berücksichtigen, die dem entfernten Gerät 1004 von dem Client-Gerät 1002 bereitgestellt wird.
  • In einem weiteren Ausführungsbeispiel kann das entfernte Gerät 1004 die komprimierten Lichtfelddaten über das Kommunikationsnetzwerk 1006 an das Client-Gerät 1002 senden. Das Client-Gerät 1002 kann dann die komprimierten Lichtfelddaten dekomprimieren und kann unter Verwendung der dekomprimierten Daten das Lichtfeld für die Szene erhalten. Das Client-Gerät 1002 kann dann globale Beleuchtungswerte für die Szene unter Verwendung eines oder mehrerer Lookups innerhalb des Lichtfelds berechnen. Das Client-Gerät 1002 kann auch eine Farbkonvertierung der dekomprimierten Lichtfelddaten durchführen, wenn es bestimmt, dass die Farbkonvertierung vor der Komprimierung von dem entfernten Gerät 1004 an den Lichtfelddaten durchgeführt wurde. Das Client-Gerät kann dann die Szene unter Verwendung der berechneten globalen Beleuchtungswerte für die Szene rendern.
  • Auf diese Weise können Rendering-Aufgaben zwischen dem Client-Gerät 1002 und dem entfernten Gerät 1004 aufgeteilt werden, so dass das entfernte Gerät 1004 rechenintensivere Rendering- oder Raytracing-Hardware-abhängige Aufgaben ausführt (z. B. Raytracing, Lichtfeldberechnung), um die Rendering-Aufgaben zu vereinfachen/zu reduzieren, die am Client-Gerät ausgeführt werden (z. B. globale Beleuchtung unter Verwendung von Lichtfeld-Lookups), oder um Raytracing-Hardware-Abhängigkeiten am Client-Gerät zu vereinfachen/reduzieren. Durch die Verwendung eines oder mehrerer Videokomprimierungsalgorithmen/-techniken und die Berücksichtigung einer aktuellen Benutzeransicht innerhalb der Szene während der Komprimierung können die resultierenden komprimierten Daten minimiert werden, wodurch die über das Kommunikationsnetzwerk 1006 übertragene Datenmenge und die Gesamtlatenz des Systems 1000 verringert werden können.
  • Verteiltes, entkoppeltes System für das Streaming dynamischer Lichtproben an Thin Clients
  • Heutige Hochleistungsgrafiksysteme für Spiele mit mehreren Grafikprozessoren, hardwarebeschleunigtem Raytracing und effizienten Algorithmen können unter Verwendung von Raytracing globaler Beleuchtung eine kinoreife Rendering-Qualität in Echtzeit erreichen und eine in Millisekunden gemessene Interaktionslatenz bereitstellen. Diese High-End-Systeme setzen Erwartungen, die auf niedrigeren Endverbraucherplattformen nicht erfüllt werden können, da diese durch thermische Grenzen, Batteriestrom und begrenzte GPU-Funktionen eingeschränkt sind.
  • Bildschirmauflösungen, Bildwiederholraten und HDR-Farbtiefe (High Dynamic Range) nehmen zu, und XR-Anwendungen erfordern das Rendern mehrerer Ansichten. Die fortschreitenden Anforderungen können aktuelle mobile Prozessoren, die in ungebundenen Geräten verwendet werden, überfordern.
  • In einem Ausführungsbeispiel können Global Illumination (GI)-Daten von einem Cloud-Rendering-Server zu Thin Clients gestreamt werden. Die gestreamten Daten ermöglichen dynamisches, qualitativ hochwertiges, diffuses GI mit Raytracing auf Thin-Clients ohne Raytracing-Fähigkeiten zu geringen Rechenkosten. Unter Verwendung von effizienter Kodier- und Dekodierhardware können hohe Komprimierungsraten bei geringer Latenz erreicht werden. Weiter können heuristische Aktualisierungsschemata für Lichtproben verwendet werden, die die Menge der im Rahmen einer GI-Aktualisierung übertragenen Daten reduzieren können. Als Ergebnis kann in einem Ausführungsbeispiel ein einzelner Server (zehntausende) Lichtproben pro Sekunde über mehrere angeschlossene Thin Clients hinweg aktualisieren, wodurch sich die Rendering-Kosten amortisieren.
  • Eine exemplarische Pipeline für das Streaming von Lichtproben kann die folgenden 4 Schritte enthalten:
    1. 1. Serverseitiges Raytracing des Lichtfeldes (Lichtprobenvolumen)
    2. 2. Kodieren der für jeden Client optimierten Lichtprobendaten
    3. 3. Netzwerkübertragung der kodierten Daten an den Client
    4. 4. Dekodierung der Lichtprobendaten und Rendering auf dem Client
  • 11 zeigt einen exemplarischen Datenfluss 1100 gemäß einem Ausführungsbeispiel. Bei einer Client-Server-Architektur kann eine Grafikpipeline auf einen oder mehrere Server und einen oder mehrere Clients verteilt werden, anstatt volle Einzelbilder zu streamen. Der Server, der sich in einem Ausführungsbeispiel in einem Rechenzentrum befinden soll, besteht konzeptionell aus zwei Knoten, die über eine Verbindung mit hoher Bandbreite miteinander verbunden sind. Der erste Knoten fungiert als Spielserver 1102, der die Eingaben der Clients 1106 zuverlässig entgegennimmt und den Spielstatus 1108 entsprechend aktualisiert. Dies ist analog zu einem Standard-Multiplayer-Spielserver. Der zweite Knoten fungiert als GI-Server 1104, der Raytracing von Lichtprobendaten durchführt und sie für den Client-Transport kodiert.
  • Es wird davon ausgegangen, dass jede Szenenänderung vom Spielserver 1102 mit vernachlässigbarer Latenz an den GI-Server 1104 gemeldet wird. Unter Verwendung des aktuellen Szenenzustands berechnet der GI-Server 1104 diffuse Lichtprobendaten, die unabhängig von der Ansicht sind. Folglich können diese GI-Daten für mehrere Clients in Multiplayer-Spielszenarien verwendet werden, wodurch sich die Kosten für das Rendem amortisieren. Unter Verwendung von hardwarebeschleunigter Videokodierung werden die Lichtprobendaten auf dem Server komprimiert. Die kodierten Daten werden unter Verwendung eines zuverlässigen Netzwerkprotokolls mit geringer Latenz über eine Kombination aus WiFi-, 5G- und/oder kabelgebundenen Verbindungen an den Client 1106 übertragen.
  • Auf der Seite des Clients 1106 wird Hardware-Videodekodierung verwendet (sofern verfügbar), um die Lichtprobendaten mit geringer Latenz zu dekomprimieren. Die Client-Rendering-Schleife 1110 verwendet dann die unkomprimierten Lichtproben-Texturen, um dynamische und hochwertige diffuse GI mit geringen Rechenkosten hinzuzufügen. Der GI-Textur-Dekodierungsprozess ist von der Rendering-Schleife entkoppelt und kann mit einer völlig anderen Geschwindigkeit erfolgen. Dadurch kann der Client 1106 mit voller Einzelbildrate laufen, was zu einer minimalen wahrgenommenen Latenz bei Benutzereingaben oder Bewegungen führt. Eingabe-Latenz, wie sie bei traditionellen Cloud-Rendering-Lösungen auftritt, wird somit vermieden.
  • In einem Ausführungsbeispiel bieten GI-Daten spezifische Vorteile, wenn sie in der Cloud gerendert werden: (1) diffuses GI ist ansichtsunabhängig und wird über mehrere Benutzer und potenziell mehrere Einzelbilder hinweg verwendet; (2) das Rendern von GI-Daten ist rechenaufwändig, wofür Thin-Client-Hardware nicht ausreicht; und (3) die Benutzer reagieren weniger empfindlich auf verzögerte diffuse Beleuchtung als auf ansichtsabhängige Effekte.
  • Unkomprimiertes Streaming von Lichtproben
  • Streaming von Probenfarben
  • Unter Verwendung von Ausführungsbeispielen kann eine Dynamic Diffuse Global Illumination (DDGI) Bestrahlungsvolumenbeschreibung verwendet werden. Jede Probe kann ein 10x10 Texel-Array mit 32 Bit Farbe pro Texel verwenden, um Farbdaten für jede Richtung in Form einer oktaedrischen Abbildung zu kodieren. Somit kann der erforderliche Netzdurchsatz T Farbe für die Aktualisierung von N beliebigen Farbproben mit einer Rate R Farbe (in Hz) wie folgt dargestellt werden:
  • T F a r b e = R F a r b e × N P r o b e n × 3,125 k b
    Figure DE102021127982A1_0001
  • In einem Beispiel hat ein 16x8x16 (2048) Probenvolumen eine unkomprimierte DDGI-Farbtexturgröße von 6,25 Mb (0,78 MB). Die Aktualisierung von 2048 unkomprimierten Farbproben mit 10 Hz erfordert eine Bandbreite von 62,5 Mbps.
  • Sichtbarkeit von Streaming-Proben
  • In einem Ausführungsbeispiel speichert DDGI den mittleren Abstand und den mittleren quadratischen Abstand für jede Probe. Während der Schattierung werden diese Werte verwendet, um die Gewichtung der Sichtbarkeit zwischen den Proben und den schattierten Punkten unter Verwendung eines statistischen Tschebyscheff-Tests zu bestimmen. Die Daten zum mittleren Abstand/Quadratabstand werden als „Sichtbarkeitsdaten“ und die Textur selbst als „Sichtbarkeitstextur“ bezeichnet. Die Sichtbarkeitstextur enthält 18x18 Texel pro Probe, kodiert als ein Paar halbpräziser (16-Bit) Gleitkommawerte (32 Bit/Texel). Der erforderliche Durchsatz (Tvisibility) für eine Aktualisierungsrate der Sichtbarkeit von Rvisibility kann daher wie folgt dargestellt werden:
  • T S i c h t b a r k e i t = R S i c h t b a r k e i t × N P r o b e n × 10,125 k b
    Figure DE102021127982A1_0002
  • Bei demselben Probenvolumen, das oben für die Farbe analysiert wurde (2048 Proben), ist die Größe der Sichtbarkeitstextur 3,24 Mal höher als die der Farbtextur, d. h. 20,3 MB (2,5 MB). Das Streaming der unbearbeiteten Sichtbarkeitstextur mit 10 Hz erfordert einen Durchsatz von 202,5 Mbps. Die Mindestanforderung an den Durchsatz für unkomprimierte Farb- und Sichtbarkeitstexturen, die mit 10 Hz für 2048 Proben aktualisiert werden, beträgt 265 Mbps. Dies sind exemplarische Bandbreitenbeschränkungen, die unter Verwendung mehrerer Thin-Client-Geräte in gängigen drahtlosen Netzwerken gelten. Obwohl dieser naive, unkomprimierte Ansatz verlustfrei ist und eine perfekte „Kohärenz“ der Proben aufrechterhält, erfordert er einen unverhältnismäßig hohen Netzwerkdurchsatz, da er alle Probendaten unabhängig davon sendet, ob die Daten unverändert sind oder wahrscheinlich auf dem Client verwendet werden. Dieser Durchsatz kann jedoch verringert werden.
  • Lichtprobe-Kompression mit niedriger Latenz
  • In einem Ausführungsbeispiel wird eine GPU-beschleunigte HDR-Videokompression unter Verwendung eines vorgegebenen Videocodierungs-/Komprimierungsstandards implementiert. In einem anderen Ausführungsbeispiel kann eine hardwarebeschleunigte HDR10-Kodierung und -Dekodierung implementiert werden.
  • Kodierung von Farbe
  • In einem Ausführungsbeispiel komprimiert ein Verfahren Farbdaten wie folgt. Normalisierte Farbwerte werden in A2RGB10F-Textur gespeichert (10 Bits vorzeichenlose kleine Fließkommazahlen für jede Farbe, 2 unbenutzte Bits für Alpha). Da die vorzeichenlosen Small Floats normalisiert sind, können diese Werte verlustfrei in vorzeichenlose 10-Bit-Ganzzahlwerte im Bereich [0,1023] quantisiert werden. Ein exemplarisches Eingabeformat für den Hardware-Encoder sind 16-Bit-Ganzzahlen ohne Vorzeichen, die in 3 Y,U,V-Ebenen organisiert sind (lineares Y-Luma, U, V-Chrominanz). Das YUV420-Oberflächenformat kann für verlustbehaftete Kompression verwendet werden, und das YUV444-Oberflächenformat kann für verlustfreie Kompression unter Vermeidung von Chroma-Subsampling verwendet werden. In einem Ausführungsbeispiel verwendet ein Hardware-Encoder nur 10 von 16 Bits für die Farbkodierung. Die restlichen Bits sind für zukünftige Versionen des Codecs reserviert, die 12- und 16-Bit-Farbkodierung unterstützen. Daher können diese Bits auf Null gesetzt werden. Die YUV-Tupel werden dann in Y,U,V-Ebenen umgeordnet, auf die die Hardwarekodierung angewendet wird. Bei der Dekodierung wird der Prozess in umgekehrter Reihenfolge durchgeführt.
  • Kodieren von Sichtbarkeit
  • Eine Lösung für die Sichtbarkeit beruht auf verlustfreier Videokodierung mit geringer Bittiefe. Die Idee ist, einen einzelnen Sechzehn-Bit-Gleitkommawert auf zwei benachbarte 8-Bit-Ganzzahlwerte zu verteilen. Da die Sichtbarkeitstextur für eine Lichtprobe zwei Kanäle enthält (RG16F), werden die Bits auf vier 8-Bit-Ganzzahlwerte verteilt. Wenn der verwendete Hardware-Encoder keine vierkanaligen Bilder unterstützt, kann eine Sequenz von drei RG16F-Werten in eine Sequenz von vier YUV-Werten gepackt werden, wodurch die Bits in YUVY-, UVYU- und VYUV-Sequenzen aufgeteilt werden. Die YUV-Textur kann verbreitert werden, um genügend Speicher für die Sichtbarkeitstextur zu allokieren. Bei einer ursprünglichen Sichtbarkeitstextur der Lichtprobe mit der Breite x kann die YUV-Texturbreite auf x' = [4/3 · x'] erhöht werden.
  • Client-seitige Dekodierung mit Threads
  • Um den Durchsatz zu maximieren und ein CPU-Blockierverhalten zwischen Rendering-Updates und Dekodierung eingehender Textur-Updates zu vermeiden, kann die Texturdekodierung in einem separaten Thread auf dem Client erfolgen. Dadurch wird eine Spielschleife während der CPU-basierten Texturdekodierung oder der Verteilung für die GPU-Dekodierung nicht blockiert.
  • Selektive Aktualisierungen von Lichtproben
  • Als nächster Schritt zur Optimierung des Netzwerkdurchsatzes pro GI-Aktualisierung kann das Senden von Proben, die keine für die client-seitige Schattierung relevanten Informationen enthalten, vermieden werden. Eine relevante Probe erfüllt die folgenden drei Bedingungen:
    1. 1. Sie wird für die Schattierung in der Szene aktualisiert und verwendet
    2. 2. Die zugehörigen Texel haben sich seit der letzten an einen Client übermittelten Aktualisierung signifikant verändert
    3. 3. Es schattiert Punkte, die potentiell für einen Benutzer sichtbar sind
  • Auf dem Server werden alle Proben, für die die vorhergehenden drei Bedingungen gelten, gesammelt und an den Client übertragen. Bei jeder Übertragung werden die übertragenen Probendaten auf dem Server aufgezeichnet und mit den gerenderten Probendaten verglichen, um zu bestimmen, welche Probendaten bei der nächsten Übertragung gesendet werden sollen.
  • Lichtproben-Neupacken
  • Inaktive Proben können aus der ursprünglichen Textur entfernt werden, indem man zu einem indexbasierten System zur Aktualisierung der Proben (selektiv, iterativ) übergeht, im Gegensatz zu einer vollständigen Übertragung der Textur (globale Aktualisierung des Probenvolumens). Eine zusätzliche Reduzierung ist für jedes Kem-Texel-Array sowohl in der Farb- als auch in der Sichtbarkeitstextur möglich. Die ursprünglichen DDGI-Texturen enthalten Ein-Pixel-Guard-Bands (pro Probe) zum Filtern der Textur, die redundante Informationen aus dem Kern-Texel-Array enthalten. Diese Daten können beim Packen auf dem Server entfernt und beim Entpacken auf dem Client verlustfrei rekonstruiert werden. Durch diese Strategie wird die Größe der übertragenen Texturen reduziert, was unabhängig vom Komprimierungsschema (oder der unkomprimierten Übertragung) einen Vorteil darstellt. Für die zeitliche Wiederverwendung können die Probenpositionen in den Texturen jedoch nach Möglichkeit über mehrere Einzelbilder hinweg beibehalten werden.
  • Das auf einem Index basierende Aktualisierungsschema ermöglicht eine flexible Anpassung der Gesamtpaketgröße, da die Anzahl der iterativ aktualisierten Proben spezifiziert werden kann. Auf diese Weise lässt sich der Durchsatz für jeden einzelnen Client mit einem Regler anpassen.
  • Lichtproben-Aktualisierungstexturen
  • Im Folgenden werden selektive Aktualisierungen von Proben auf dem Server und dem/den Client(s) beschrieben.
  • Der Server speichert permanente Client-Probentexturen sowie temporäre selektive Probenaktualisierungstexturen für jeden Client. Die permanenten Probentexturen repräsentieren den Zustand der Proben, wie sie auf jedem Client vorhanden sind. Die temporären Probenaktualisierungstexturen werden pro Aktualisierungsschritt erstellt und speichern die Probeninformationen, die gerade erneuert werden. Zusammen mit dieser Textur kann der Client darüber informiert werden, welche Proben in dem Volumen gerade aktualisiert werden. Diese Information wird vom Probenaktualisierungstextur-Puffer bereitgestellt, der die Koordinaten der Probenaktualisierungstexturen den Probentexturen des Clients zuordnet. Im Vergleich zu den Probenaktualisierungstexturen ist die Größe des Probenindexpuffers (kodiert als eine einzelne vorzeichenlose Zwei-Byte-Ganzzahl pro Probe) sehr klein und wird durch Delta-Kodierung weiter reduziert.
  • Für den Client läuft dieser Prozess in umgekehrter Reihenfolge ab. Nur die an den Client gesendeten Lichtproben werden in der permanenten Probentextur aktualisiert. Die Zuordnung von der Aktualisierungstextur zur permanenten Lichtprobentextur erfolgt unter Verwendung des empfangenen und dekomprimierten Probenindexpuffers. Die übrigen Texel werden als gültig aus dem vorherigen Zustand übernommen. Da die Texturdekomprimierung und -aktualisierung asynchron in einem parallelen Thread erfolgen, wird die Renderschleife nicht blockiert und kann kontinuierlich mit voller Einzelbildrate laufen.
  • Schwellenwert für die Änderung von Lichtproben
  • Um alle Proben, die die primäre Client-Ansicht beeinflussen könnten, konservativ abzuschätzen, können alle Proben, deren Wert sich seit der letzten Übertragung geändert hat, berücksichtigt werden. Auf dem Server können zwei zusätzliche Texturen pro verbundenem Client verwaltet werden, eine für Farbe und eine für Sichtbarkeit, die den Zustand jeder Probe zum Zeitpunkt der letzten Übertragung speichern. Zum Zeitpunkt der Übertragung kann jede Probe mit ihrem zuletzt übertragenen Zustand verglichen werden und kann nur dann zur Übertragung in Betracht gezogen werden, wenn sich ihre Werte über einen spezifizierten Schwellenwert hinaus verändert haben. Auch wenn höhere Schwellenwerte aus Sicht der Wahrnehmung tolerierbar sind, kann eine Probe als verändert markiert werden, wenn sie nicht Texel für Texel mit ihrem zuletzt übertragenen Zustand identisch ist. Es kann davon ausgegangen werden, dass die vollständig konvertierte Farbe auf dem Server, der die Szene ändert, die einzige Quelle für Abweichungen im Ergebnis der Probe ist. Vor der Übertragung jeder Probe können ihre Daten in die jeweils zuletzt übertragene Textur geschrieben werden.
  • Serverseitiges Ausblenden von Proben in der Client-Ansicht
  • Ausgehend von einem Blickwinkel innerhalb einer Szene kann die Teilmenge der Proben-Texel, die zu einem gerenderten Einzelbild beitragen können, nur diejenigen sein, die sich in der Nähe von Punkten mit primärer Sichtbarkeit befinden. Dies kann eine erhebliche Verringerung der Gesamtzahl aktiver/aktualisierender Proben aus dem vollen Volumen repräsentieren.
  • Durch Beschränkung der aktualisierten Proben auf diejenigen, die zur Schattierung des primären Sichtbarkeitskegels beitragen, kann die Anzahl der zu aktualisierenden Proben reduziert werden. Eine spielabhängige Client-Ansichtsvorhersage kann die Anzahl der aktualisierten Proben anpassen. Eine solche Vorhersage kann an die Netzwerklatenz und den Spielinhalt gekoppelt sein. Eine anwendungsunabhängige Strategie kann implementiert werden, indem der Server die potenziell sichtbare Menge (PVS) von Proben abschätzt, die zur Schattierung des Clients beitragen, indem er eine sphärische Ansicht von der Position des Clients aus rendert. Das Sammeln von Proben aus dieser PVS-Abschätzung gewährleistet die Korrektheit der Client-Ansicht bei Kameradrehung.
  • Obwohl oben verschiedene Ausführungsbeispiele beschrieben wurden, ist zu verstehen, dass sie nur als Beispiel und nicht als Einschränkung dargestellt wurden. Daher dürfen die Breite und der Umfang einer bevorzugten Ausführungsform nicht durch eines der oben beschriebenen exemplarischen Ausführungsbeispiele eingeschränkt werden, sondern sind nur gemäß den folgenden Ansprüchen und deren Entsprechungen zu definieren.
  • Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinell verwendbaren Befehlen, einschließlich computerausführbarer Befehle, wie z. B. Programmmodule, beschrieben werden, die von einem Computer oder einer anderen Maschine, wie z. B. einem Personal Data Assistant oder einem anderen tragbaren Gerät, ausgeführt werden. Im Allgemeinen beziehen sich Programmmodule, die Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw. enthalten, auf Code, der bestimmte Aufgaben erfüllt oder bestimmte abstrakte Datentypen implementiert. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen praktiziert werden, einschließlich Handheld-Geräten, Unterhaltungselektronik, allgemeinen Computern, spezielleren Rechengeräten, usw. Die Offenbarung kann auch in verteilten Rechenumgebungen praktiziert werden, in denen Aufgaben von entfernt arbeitenden Geräten ausgeführt werden, die über ein Kommunikationsnetz verbunden sind.
  • Unter Verwendung von „und/oder“ in Bezug auf zwei oder mehr Elemente sollte nur ein Element oder eine Kombination von Elementen verstanden werden. Zum Beispiel kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C enthalten. Darüber hinaus kann „mindestens eines der Elemente A oder B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B enthalten. Weiter kann „mindestens eines der Elemente A und B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B enthalten.
  • Der Gegenstand der vorliegenden Offenbarung wird hier mit einer gewissen Genauigkeit beschrieben, um den gesetzlichen Anforderungen zu genügen. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verwirklicht werden kann, um verschiedene Schritte oder Kombinationen von Schritten, die den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien zu enthalten. Obwohl die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden können, um verschiedene Elemente der verwendeten Verfahren zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbart dargestellten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte ist ausdrücklich beschrieben.

Claims (16)

  1. Verfahren, das an einem Gerät umfasst: Identifizieren einer zu rendemden Szene; Berechnen eines Lichtfeldes für die Szene unter Verwendung von Raytracing; Komprimieren des Lichtfeldes unter Verwenden einer verlustfreien oder verlustbehafteten Kompression, um komprimierte Lichtfelddaten für die Szene zu erzeugen; und Senden der komprimierten Lichtfelddaten an ein Client-Gerät.
  2. Verfahren nach Anspruch 1, wobei das Komprimieren des Lichtfeldes unter Verwenden einer verlustfreien oder verlustbehafteten Komprimierung ein Durchführen einer Farbkonvertierung des Lichtfeldes umfasst.
  3. Verfahren nach Anspruch 1 oder 2, wobei das Lichtfeld von roten, grünen und blauen (RGB) Pixeln in YUV-Pixel umgewandelt wird, wobei Y einen Luma-Wert repräsentiert und U, V einen Chrominanz-Wert repräsentiert.
  4. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Komprimieren des Lichtfeldes unter Verwenden einer verlustfreien oder verlustbehafteten Kompression ein Downsampling einer Chrominanz-Ebene innerhalb des Lichtfeldes umfasst.
  5. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Lichtfeld Farbwerte umfasst, die normalisiert und in einer vorgegebenen Textur gespeichert werden.
  6. Verfahren nach Anspruch 5, wobei die normalisierten Werte quantisiert und in vorzeichenlose ganzzahlige YUV-Tupel bitverschoben werden.
  7. Verfahren nach Anspruch 6, das weiter ein Umordnen der YUV-Tupel in YUV-Ebenen und das Durchführen einer Reduktion an den YUV-Ebenen umfasst, um reduzierte YUV-Ebenen zu erzeugen.
  8. Verfahren nach Anspruch 7, weiter umfassend die Anwendung einer Kodierung auf die reduzierten YUV-Ebenen.
  9. Verfahren nach einem der vorhergehenden Ansprüche, wobei: das Lichtfeld ein Array von Blöcken umfasst, jeder Block Farbtexturinformationen und Sichtbarkeitstexturinformationen umfasst, die Farbtexturinformationen Beleuchtungsfarbinformationen innerhalb des Blocks umfassen, und die Sichtbarkeitstexturinformationen einen Abstand zu einer nächstgelegenen Oberfläche innerhalb des Blocks umfassen.
  10. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Lichtfeld unter Verwenden von einem oder mehreren Videokompressionsverfahren komprimiert wird, die eine zeitliche Wiederverwendung während der Kompression implementieren.
  11. Verfahren nach Anspruch 10, wobei nur Unterschiede zwischen dem Lichtfeld für die Szene und einem Lichtfeld für eine vorherige Szene komprimiert werden.
  12. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Komprimierung eine aktuelle Benutzeransicht innerhalb der Szene berücksichtigt, so dass nur ein Teil des berechneten Lichtfeldes, der sich innerhalb der aktuellen Benutzeransicht befindet, komprimiert wird.
  13. Nichtflüchtiges computerlesbares Speichermedium, das Befehle speichert, die, wenn sie von einem Prozessor eines Geräts ausgeführt werden, den Prozessor veranlassen, das Gerät zu veranlassen, zum: Identifizieren einer zu rendernden Szene; Berechnen eines Lichtfeldes für die Szene unter Verwenden von Raytracing; Komprimieren des Lichtfeldes unter Verwenden einer verlustfreien oder verlustbehafteten Kompression, um komprimierte Lichtfelddaten für die Szene zu erzeugen; und Senden der komprimierten Lichtfelddaten an ein Client-Gerät.
  14. Computerlesbares Speichermedium nach Anspruch 13, das, wenn es von dem Prozessor ausgeführt wird, den Prozessor veranlasst, das Gerät zu veranlassen, ein Verfahren nach einem der Ansprüche 2 bis 12 auszuführen.
  15. Verfahren, das an einem Gerät umfasst: Empfangen von komprimierten Lichtfelddaten für eine Szene; Dekomprimieren der komprimierten Lichtfelddaten und Durchführen einer Farbkonvertierung der dekomprimierten Lichtfelddaten, um das Lichtfeld für die Szene zu erhalten; und Berechnen der globalen Beleuchtung für die Szene unter Verwendung des Lichtfeldes für die Szene.
  16. Verfahren nach Anspruch 15, wobei die dekomprimierten Lichtfelddaten von YUV-Pixeln in RGB-Pixel umgewandelt werden.
DE102021127982.8A 2020-11-03 2021-10-27 Streaming eines lichtfeldes mit verlustfreier oder verlustbehafteter kompression Pending DE102021127982A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202063109204P 2020-11-03 2020-11-03
US63/109,204 2020-11-03
US17/308,893 2021-05-05
US17/308,893 US11501467B2 (en) 2020-11-03 2021-05-05 Streaming a light field compressed utilizing lossless or lossy compression

Publications (1)

Publication Number Publication Date
DE102021127982A1 true DE102021127982A1 (de) 2022-05-05

Family

ID=81184259

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021127982.8A Pending DE102021127982A1 (de) 2020-11-03 2021-10-27 Streaming eines lichtfeldes mit verlustfreier oder verlustbehafteter kompression

Country Status (3)

Country Link
US (1) US11501467B2 (de)
CN (1) CN114445257A (de)
DE (1) DE102021127982A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11941752B2 (en) 2020-07-21 2024-03-26 Nvidia Corporation Streaming a compressed light field
US11722393B2 (en) * 2020-12-15 2023-08-08 Caterpillar Inc. Systems and methods for managing on-site communications for latency-dependent applications
CN116797710A (zh) * 2022-03-15 2023-09-22 华为技术有限公司 编码方法及电子设备

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6567083B1 (en) 1997-09-25 2003-05-20 Microsoft Corporation Method, system, and computer program product for providing illumination in computer graphics shading and animation
US6687753B2 (en) 1998-06-25 2004-02-03 International Business Machines Corporation Method and system for providing three-dimensional graphics over computer networks
US7952583B2 (en) 2000-06-19 2011-05-31 Mental Images Gmbh Quasi-monte carlo light transport simulation by efficient ray tracing
US7212207B2 (en) 2003-08-20 2007-05-01 Sony Computer Entertainment Inc. Method and apparatus for real-time global illumination incorporating stream processor based hybrid ray tracing
US7561620B2 (en) * 2004-08-03 2009-07-14 Microsoft Corporation System and process for compressing and decompressing multiple, layered, video streams employing spatial and temporal encoding
US7990380B2 (en) 2004-09-30 2011-08-02 Intel Corporation Diffuse photon map decomposition for parallelization of global illumination algorithm
WO2006100664A2 (en) 2005-03-21 2006-09-28 Yosef Mizrahi Method, system and computer-readable code for providing a computer gaming service
US7755627B2 (en) 2005-11-23 2010-07-13 Pixar Global illumination filtering methods and apparatus
US7609264B2 (en) 2006-03-29 2009-10-27 Microsoft Corporation Shell radiance texture function
US7995059B1 (en) 2006-06-09 2011-08-09 Pixar Mid-field and far-field irradiance approximation
US7408550B2 (en) 2006-07-24 2008-08-05 Bunnell Michael T System and methods for real-time rendering of deformable geometry with global illumination
US20080143720A1 (en) 2006-12-13 2008-06-19 Autodesk, Inc. Method for rendering global illumination on a graphics processing unit
US8147339B1 (en) 2007-12-15 2012-04-03 Gaikai Inc. Systems and methods of serving game video
KR100980449B1 (ko) 2007-12-17 2010-09-07 한국전자통신연구원 병렬 전역조명 렌더링 방법 및 시스템
US7937245B2 (en) 2008-04-02 2011-05-03 Dreamworks Animation Llc Rendering of subsurface scattering effects in translucent objects
US8525826B2 (en) 2008-08-08 2013-09-03 International Business Machines Corporation System for iterative interactive ray tracing in a multiprocessor environment
KR20100132605A (ko) 2009-06-10 2010-12-20 삼성전자주식회사 하이브리드 렌더링 장치 및 방법
US8542231B2 (en) 2009-06-29 2013-09-24 Crytek Gmbh Method, computer graphics image rendering system and computer-readable data storage medium for computing of indirect illumination in a computer graphics image of a scene
US8587588B2 (en) 2009-08-18 2013-11-19 Dreamworks Animation Llc Ray-aggregation for ray-tracing during rendering of imagery
KR101266360B1 (ko) 2009-08-24 2013-05-22 한국전자통신연구원 전역조명을 지원하는 그래픽 처리 장치 및 이를 이용한 그래픽 처리 방법
US20130120385A1 (en) 2009-09-15 2013-05-16 Aravind Krishnaswamy Methods and Apparatus for Diffuse Indirect Illumination Computation using Progressive Interleaved Irradiance Sampling
US8558837B2 (en) 2010-01-18 2013-10-15 Disney Enterprises, Inc. Modular radiance transfer
US9171396B2 (en) 2010-06-30 2015-10-27 Primal Space Systems Inc. System and method of procedural visibility for interactive and broadcast streaming of entertainment, advertising, and tactical 3D graphical information using a visibility event codec
EP2461587A1 (de) 2010-12-01 2012-06-06 Alcatel Lucent Verfahren und Vorrichtungen zur Übertragung von 3D-Videoinformationen von einem Server an einen Client
US20120212491A1 (en) 2011-02-22 2012-08-23 Sony Computer Entertainment Inc. Indirect lighting process for virtual environments
US8780112B2 (en) 2011-06-08 2014-07-15 Pacific Data Images Llc Coherent out-of-core point-based global illumination
CN103765481B (zh) 2011-08-05 2016-06-29 想象技术有限公司 用于3-d场景加速结构创建和更新的系统和方法
US9250966B2 (en) 2011-08-11 2016-02-02 Otoy, Inc. Crowd-sourced video rendering system
JP5977023B2 (ja) 2011-11-07 2016-08-24 株式会社スクウェア・エニックス・ホールディングス 描画システム、プログラム、及び記録媒体
KR20130062462A (ko) 2011-11-25 2013-06-13 한국전자통신연구원 스트리밍 게임 서비스를 위한 분산 서버 시스템 및 방법
US9013496B2 (en) 2012-06-19 2015-04-21 Microsoft Technology Licensing, Llc Rendering global light transport in real-time using machine learning
US9378582B2 (en) 2012-07-31 2016-06-28 Siemens Product Lifecycle Management Software Inc. Rendering of design data
US10699361B2 (en) 2012-11-21 2020-06-30 Ati Technologies Ulc Method and apparatus for enhanced processing of three dimensional (3D) graphics data
US9264749B2 (en) 2012-12-13 2016-02-16 Microsoft Technology Licensing, Llc Server GPU assistance for mobile GPU applications
SG11201605971WA (en) 2013-01-31 2016-09-29 Dirtt Environmental Solutions Method and system for efficient modeling of specular reflection
US9330485B2 (en) 2013-02-20 2016-05-03 Kabushiki Kaisha Toshiba Volume rendering of medical images
US9478065B2 (en) 2013-03-14 2016-10-25 Robert Bosch Gmbh System and method for remote generation of indirect illumination sources in three-dimensional graphics
US10713838B2 (en) 2013-05-03 2020-07-14 Nvidia Corporation Image illumination rendering system and method
US10008034B2 (en) 2013-05-03 2018-06-26 Nvidia Corporation System, method, and computer program product for computing indirect lighting in a cloud network
US10911735B2 (en) * 2019-02-22 2021-02-02 Avalon Holographics Inc. Layered scene decomposition CODEC with asymptotic resolution
US11941752B2 (en) 2020-07-21 2024-03-26 Nvidia Corporation Streaming a compressed light field

Also Published As

Publication number Publication date
CN114445257A (zh) 2022-05-06
US20220138988A1 (en) 2022-05-05
US11501467B2 (en) 2022-11-15

Similar Documents

Publication Publication Date Title
DE102018130037B4 (de) DYNAMISCHES JITTER- und LATENZ-TOLERANTES RENDERING
DE102021118444A1 (de) Einrichtung und Verfahren zum Komprimieren von Strahlverfolgungsbeschleunigungsstrukturaufbaudaten
DE102019117592A1 (de) Videoverarbeitungsmechanismus
DE102021207678A1 (de) Streamen eines komprimierten lichtfelds
DE112017004246T5 (de) Cache- und komprimierungsinteroperabilität in einer grafikprozessorpipeline
US10636336B2 (en) Mixed primary display with spatially modulated backlight
DE102019102279A1 (de) Erzeugung von synthetischen Bildern zum Trainieren eines Neuronal-Netzwerkmodells
DE102019117485A1 (de) Adaptive Auflösung einer Punktwolke und Blickpunktvorhersage für Videostreaming in Rechenumgebungen
US11496773B2 (en) Using residual video data resulting from a compression of original video data to improve a decompression of the original video data
DE102020124932A1 (de) Vorrichtung und Verfahren zur Echtzeit-Grafikverarbeitung mittels lokaler und cloudbasierter Grafikverarbeitungsbetriebsmittel
DE102019120661A1 (de) Videoverfeinerungsmechanismus
DE102019119102A1 (de) Spärliche repräsentation für voxel
DE102021127982A1 (de) Streaming eines lichtfeldes mit verlustfreier oder verlustbehafteter kompression
DE102019119085A1 (de) Punktbasiertes rendern und entfernung von projektionsrauschen
DE102019117218A1 (de) Reduziertes Rendern eines Videos mit sechs Freiheitsgraden
DE102019117495A1 (de) System und verfahren zur 3d-blob-klassifizierung und -übertragung
DE112017000864T5 (de) Strahlenkomprimierung für effizientes Verarbeiten von Grafikdaten bei Rechenvorrichtungen
DE102020132377A1 (de) Vorrichtung und Verfahren zur Drosselung einer Raytracing-Pipeline
DE102021121109A1 (de) Wiederherstellung dreidimensionaler modelle aus zweidimensionalen bildern
DE102019101871A1 (de) Verfahren und Vorrichtung zum Gewinnen von Abtastpositionen von Textuieroperationen
DE102021104310A1 (de) Reservoir-basiertes räumlich-zeitliches resampling nach wichtigkeit unter verwendung einer globalen beleuchtungsdatenstruktur
DE102020108526A1 (de) Adaptive pixelabtastreihenfolge für zeitlich dichtes rendern
DE102021132992A1 (de) Messen und Detektieren von Leerlaufzeiten und Erkennen der Ursachen dafür in Cloud-basierten Streaming-Anwendungen
DE102019121200A1 (de) Bewegungsadaptives rendern mittels shading mit variabler rate
DE112019001978T5 (de) Verbesserung des realismus von szenen mit wasseroberflächen beim rendern

Legal Events

Date Code Title Description
R012 Request for examination validly filed