DE102008026431B4 - Extrapolation von nicht residenten Mipmap-Daten unter Verwendung residenter Mipmap-Daten - Google Patents

Extrapolation von nicht residenten Mipmap-Daten unter Verwendung residenter Mipmap-Daten Download PDF

Info

Publication number
DE102008026431B4
DE102008026431B4 DE102008026431.8A DE102008026431A DE102008026431B4 DE 102008026431 B4 DE102008026431 B4 DE 102008026431B4 DE 102008026431 A DE102008026431 A DE 102008026431A DE 102008026431 B4 DE102008026431 B4 DE 102008026431B4
Authority
DE
Germany
Prior art keywords
texture
resident
mipmap
extrapolation
level
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.)
Active
Application number
DE102008026431.8A
Other languages
English (en)
Other versions
DE102008026431A1 (de
Inventor
William P. Newhall Jr.
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 DE102008026431A1 publication Critical patent/DE102008026431A1/de
Application granted granted Critical
Publication of DE102008026431B4 publication Critical patent/DE102008026431B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/40—Analysis of texture
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/005—General purpose rendering architectures
    • 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
    • G06T7/00—Image analysis
    • G06T7/60—Analysis of geometric attributes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2210/00—Indexing scheme for image generation or computer graphics
    • G06T2210/36—Level of detail

Abstract

Verfahren zur Extrapolation von nicht residenten Mipmap-Levels einer Texture-Map unter Verwendung residenter Mipmap-Levels der Texture-Map, welches aufweist: Empfangen einer Aufforderung zum Konvertieren eines nicht residenten Mipmap-Levels in ein residentes Mipmap-Level zur Verwendung beim Rendering eines Bildes zur Anzeige; Einleiten einer Kopie des nicht residenten Mipmap-Levels von einem nicht residenten Speicher in einen residenten Speicher; Verwenden eines Werts eines Detaillevel-Extrapolationsschwellenwertes zum Erzeugen von gefilterten Texture-Elementwerten des Bildes; und Updaten eines Werts des Detaillevel-Extrapolationsschwellenwertes, wenn die Kopie der nicht residenten Mipmap-Levels abgeschlossen ist, wobei der Schritt des Updatens ein sukzessives Vermindern des Wertes des Detaillevel-Extrapolationsschwellenwertes über eine Mehrzahl von Frames für einen sanften Übergang von extrapolierter Filterung zu interpolierter Filterung aufweist bis ein Endwert erreicht wird, der gleich oder größer als ein Detaillevel-Wert des nicht residenten Mipmap-Levels ist, um sanft von der Verwendung von extrapolierter Filterung zur Verwendung von interpolierter Filterung zum Erzeugen der extrapolierten Texture-Elementwerte überzugehen.

Description

  • ALLGEMEINER STAND DER TECHNIK
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft allgemein Texture Mapping und insbesondere die Verwendung von Extrapolation zur Berechnung von Texture-Map-Werte für Mipmaps, die nicht verfügbar sind.
  • Beschreibung des Standes der Technik
  • Da die Verwendung virtueller Speicher mittlerweile gang und gäbe ist, ist die Anzahl von Texture-Maps, auf die während der Grafikverarbeitung zugegriffen werden kann, nicht mehr durch den Umfang des physikalischen Speichers (lokaler oder Systemspeicher) begrenzt, in dem die Texture-Maps herkömmlich gespeichert sind. Texture-Daten können auf anderen Speicherressourcen, wie Plattenlaufwerken, CD-Laufwerken oder sogar auf Remote-Servern gespeichert werden, die eine höhere Zugriffslatenz aufweisen als der physikalische Speicher. Die Texture-Daten werden während der Verarbeitung abgerufen, wenn sie benötigt werden. Die Bildqualität ist indes im Gegensatz zum Abrufen von Texture-Daten vom physikalischen Speicher während der Zeit, in der die Texture-Daten von den anderen Speicherressourcen abgerufen werden, beeinträchtigt.
  • Es ist insbesondere vorteilhaft, hochauflösende Mipmaps einer Texture in den anderen Speicherressourcen zu speichern, da diese Mipmaps größer sind. Mipmaps mit niedrigerer Auflösung der Texture können im physikalischen Speicher gespeichert und zur Erzeugung von Bildern verwendet werden, während die Mipmaps mit hoher Auflösung von den anderen Speicherressourcen abgerufen werden. Das Ergebnis ist, dass die Texture-Map-Daten verschwommen erscheinen und dann schärfer werden, wenn die Mipmaps mit hoher Auflösung im physikalischen Speicher verfügbar werden.
  • Folglich werden im Fachgebiet Systeme und Verfahren zur Verbesserung des Aussehens von Texture-Map-Daten mit niedriger Auflösung benötigt, die verwendet werden, während die Mipmaps mit hoher Auflösung von einer Speicherressource mit hoher Latenz abgerufen werden. Ferner ist ein sanfter Übergang von der Verwendung von extrapolierter Filterung zur Verwendung von interpolierter Filterung zur Erzeugung der gefilterten Texture-Elementwerte wünschenswert, nachdem eine Mipmap mit hoher Auflösung von der Speicherressource mit hoher Latenz abgerufen wurde.
  • US-Patent 7,061,500 B1 offenbart eine Grafiksystem-Architektur, in welcher kondensierte Zwischenspeicher-Kennzeichen für Textur durch eine Abbildungsoperation erreicht werden, welche die Beziehung zwischen dem Detaillevel-Parameter von mip-Abbildung und der maximalen Auflösung ausnutzt.
  • US-Patent 6,744,438 B1 offenbart eine Grafikverarbeitungseinheit, welche Texturdaten sowohl zuvor holt als auch zuvor lädt. Eine Zwischenspeicherzeile wird zuvor an die Texturdaten zugewiesen ungefähr sobald ein Verfehlen auftritt.
  • US-Patent 5,438,654 offenbart ein System und Verfahren zum interaktiven Vergrößern einer ersten Textur, um ein im Allgemeinen unverschwommenes Hochauflösungs-Anzeigebild bei einem bestimmten Detaillevel zu erzeugen.
  • Das Verfahren umfasst den Schritt eines Extrapolierens von der ersten Textur und einer zweiten Textur, um ein extrapoliertes Frequenzband zu erzeugen. Das extrapolierte Frequenzband approximiert Hochfrequenz-Bildinformation, welche in einer Textur von höherer Auflösung als die erste Textur enthalten ist. Das extrapolierte Frequenzband wird als eine Funktion des bestimmten Detaillevels skaliert, um ein skaliertes extrapoliertes Frequenzband zu erzeugen, wobei das skalierte extrapolierte Frequenzband Hochfrequenz-Bildinformationen approximiert, welche in einem vergrößerten Bild der ersten Textur bei dem bestimmten Detaillevel enthalten ist. Die erste Textur wird unter Benutzung des skalierten extrapolierten Frequenzbandes erweitert, um dadurch ein vergrößertes Bild der ersten Textur bei dem bestimmten Detaillevel zu erzeugen.
  • US-Patent etwa 6,522,337 B1 offenbart ein Bildverarbeitungssystem, welches Aktualisierungsverarbeitung von mipmap-Daten innerhalb eines vordefinierten Bereiches durchführt und während einer Zeichnungsverarbeitung ermittelt das System den Detaillevel, zu welchem Texturdaten aktualisiert worden sind. Wenn Textur-Abbildung durchgeführt wird, werden Texturdaten des Detaillevels benutzt, für welchen Aktualisierung vollendet worden ist. Wenn die erforderlichen Texturdaten noch nicht aktualisiert worden sind, werden sie durch Texturdaten bei einem geringeren Detaillevel ersetzt, für welchen vorher eine Aktualisierung vollendet ist.
  • Das veröffentlichte Dokument mit Titel „Open GL an Silicon Graphics Systems”, ein Handbuch, welches von Silicon Graphics am 31. März 2005 veröffentlicht wurde, Seiten 149–201, offenbart Information, wie Texturierungserweiterungen und Formate in OpenGL angewendet werden.
  • KURZDARSTELLUNG DER ERFINDUNG
  • Ein Multithread-Grafikprozessor ist zum Extrapolieren von Mipmaps mit niedriger Auflösung, die im physikalischen Speicher gespeichert sind, konfiguriert, um extrapolierte Texture-Werte zu erzeugen, während Mipmaps mit hoher Auflösung von einer Speicherressource mit hoher Latenz abgerufen werden, um die Mipmaps mit hoher Auflösung von nicht residenten Mipmaps in residente Mipmaps zu konvertieren. Die extrapolierten Texture-Werte stellen ein verbessertes Bild bereit, das im Vergleich zur Verwendung der Texture-Daten des Mipmap-Levels mit der niedrigen Auflösung anstatt der Texture-Daten des Mipmap-Levels mit der hohen Auflösung schärfer erscheint. Durch die Verwendung eines Mipmap-Filters, der zwei residente Detaillevel-Mipmaps extrapoliert, werden gefilterte Texture-Werte erzeugt, um Kontrast- und Detailsteigerungen anzunähern, die von der Filterung erzeugt würden, wenn die nicht residente Detaillevel-Mipmap resident wäre.
  • Ein Detaillevel-Extrapolationsschwellenwert (auch als Extrapolationsschwellenwert-LOD bezeichnet) wird verwendet, um zu bestimmen, wann die extrapolierte Vergrößerungs- oder Verkleinerungs-Texture-Filterung verwendet wird. Der Extrapolationsschwellenwert-LOD mag zum sanften Übergang von der Verwendung von extrapolierter Filterung zur Verwendung von interpolierter Filterung verwendet werden, wenn eine nicht residente Mipmap in eine residente Mipmap konvertiert wird. Ein DeltaLOD (Level Of Detail – Detaillevel) wird als die Differenz zwischen dem LOD der idealen Mipmap und eines Extrapolationsschwellenwert-LOD (ein Wert, der größer oder gleich dem LOD der residenten Mipmap mit der höchsten Auflösung ist) berechnet. Eine residente Mipmap wird im Gegensatz zu einer nicht residenten Mipmap, die in einer Speicherressource mit hoher Zugriffslatenz gespeichert wird, im physikalischen Speicher (mit geringer Zugriffslatenz) gespeichert. Der DeltaLOD wird verwendet, um einen Extrapolationsgewichtswert zu bestimmen, der zur Erzeugung der extrapolierten Texture-Werte zur Verwendung anstelle der Texture-Daten der Mipmap mit der hohen Auflösung verwendet wird.
  • Verschiedene Ausführungsformen eines Verfahrens der Erfindung zum Konvertieren eines nicht residenten Mipmap-Levels einer Texture-Map in ein residentes Mipmap-Level der Texture-Map beinhaltet das Empfangen einer Aufforderung zum Konvertieren des nicht residenten Mipmap-Levels in ein residentes Mipmap-Level zum Verwenden beim Rendering eines Bildes zum Anzeigem, das Initiieren einer Kopie des nicht residenten Mipmap-Levels von einem nicht residenten Speicher in einen residenten Speicher und das Aktualisieren eines Wertes einer Extrapolationsschwellenwert-Detaillevel (LOD), der zum Erzeugen von gefilterten Texture-Elementwerten des Bildes verwendet wird, wenn die Kopie des nicht residenten Mipmap-Levels abgeschlossen ist.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Es zeigen:
  • 1 eine Veranschaulichung eines Konzeptdiagramms von Mipmaps einer Texture für variierende Detaillevel (Level Of Detail – LOD) gemäß einem oder mehreren Aspekten der vorliegenden Erfindung;
  • 2A ein Ablaufdiagramm von Verfahrensschritten zur Erzeugung eines extrapolierten Texture-Werts für ein nicht residentes Mipmap-Level gemäß einem oder mehreren Aspekten der vorliegenden Erfindung;
  • 2B ein Ablaufdiagramm des Verfahrensschritts 210 von 2A, um gemäß einem oder mehreren Aspekten der vorliegenden Erfindung zu bestimmen, ob eine Mipmap, die zu einem idealen LOD korrespondiert, resident ist oder nicht;
  • 2C ein Ablaufdiagramm von Verfahrensschritten, um gemäß einem oder mehreren Aspekten der vorliegenden Erfindung zu bestimmen, ob ein Texture-Wert aus einem residenten Mipmap-Level extrapoliert werden sollte oder nicht;
  • 3 ein Blockdiagramm, das ein Computersystem veranschaulicht, das zur Ausführung von einem oder mehreren Aspekten der vorliegenden Erfindung konfiguriert ist;
  • 4 ein Blockdiagramm eines Parallelverarbeitungs-Teilsystems für das Computersystem von 3 gemäß einem oder mehreren Aspekten der vorliegenden Erfindung;
  • 5 ein Blockdiagramm einer Parallelverarbeitungseinheit für das Parallelverarbeitungs-Teilsystem von 4 gemäß einem oder mehreren Aspekten der vorliegenden Erfindung;
  • 6A ein Konzeptdiagramm einer Grafikverarbeitungspipeline gemäß einem oder mehreren Aspekten der vorliegenden Erfindung;
  • 6B ein Blockdiagramm der Texture-Einheit von 6A gemäß einem oder mehreren Aspekten der vorliegenden Erfindung; und
  • 7 ein Ablaufdiagramm von Verfahrensschritten zum Konvertieren eines nicht residenten Mipmap-Levels in ein residentes Mipmap-Level gemäß einem oder mehreren Aspekten der vorliegenden Erfindung.
  • AUSFÜHRLICHE BESCHREIBUNG
  • 1 veranschaulicht ein Konzeptdiagramm von Mipmaps eines Texture-Bilds für variierende LODs gemäß einem oder mehreren Aspekten der vorliegenden Erfindung. Jede Mipmap ist eine vorgefilterte Version des Texture-Bilds für eine bestimmte Auflösung oder Detaillevel (Level Of Detail – LOD), wobei die LOD0-Mipmap 110 die höchste Auflösung und die LODN-Mipmap 190 die niedrigste Auflösung aufweist, d. h. bei aufsteigendem LOD-Index nimmt die Auflösung des entsprechenden Mip-Levels ab. Wenn ein virtuelles Speichermapping verwendet wird, um einen größeren Adressraum darzustellen, als im physikalischen Speicher verfügbar ist, sind nicht alle adressierbaren Texture-Daten im physikalischen Speicher resident. Wie in 1 gezeigt, sind LOD0-Mipmap 110, LOD1-Mipmap 120, und LOD2-Mipmap 130 nicht im physikalischen Speicher gespeichert und sind aus diesem Grund nicht residente Mipmaps 100. Residente Mipmaps 140, die LOD3-Mipmap 150, LOD4-Mipmap 160, and LODN-Mipmap 190 einschließen, sind im physikalischen Speicher gespeichert, derart, dass mit geringer Latenz auf die in diesen Mipmaps gespeicherten Texture-Daten zugegriffen werden kann.
  • Wenn eine Softwareanwendung Texture-Filterung auf einem Detaillevel anfordert, in dem alle der erforderlichen Mipmaps im Speicher resident sind, ruft die Texture-Einheit Texture-Elemente oder Texels von den erforderlichen Mipmaps ab und wendet, einen Filter an, der einen Wert erzeugt, der zwischen den Texture-Elementen, die von den residenten Mipmap-Level abgerufen wurden, interpoliert wird, wie im Stand der Technik üblich. Wenn eine Softwareanwendung versucht, auf ein Mipmap-Level, das aus dem physikalischen Speicher ausgelesen wurde, d. h. eine nicht residente Mipmap, zuzugreifen, rufen Ausführungsformen der vorliegenden Erfindung Texture-Elemente von den zwei nächsten residenten Mipmaps ab und wenden ein Filter an, der einen aus den von den residenten Mipmap-Stufen (mipmap level) abgerufenen Texture-Elementen extrapolierten Wert erzeugt. Extrapolierte Texture-Elementwerte werden berechnet und zur Erzeugung von Bildern verwendet, bis die nicht residente Mipmap seitenweise in den physikalischen Speicher gelesen wurde (paged), wodurch sie eine residente Mipmap wird.
  • Zum Beispiel werden, wenn die berechnete LOD für das Texture Mapping LOD2 ist und die LOD2-Mipmap 130 nicht resident ist, extrapolierte Texture-Werte unter Verwendung residenter Mipmaps, der LOD3-Mipmap 150 und der LOD4-Mipmap 160, berechnet, wie in Verbindung mit 2A beschrieben. Die extrapolierten Texture-Werte für eine nicht residente LOD, wie LOD2, werden unter Verwendung eines Extrapolations-Verkleinerungsfilters (minification filter) berechnet. Ein Verkleinerungsfilter wird verwendet, wenn das Verhältnis von Texture-Elementen (Texeln) zu Pixeln kleiner als eins ist. Nachdem die LOD2 in eine residente LOD-Mipmap konvertiert wurde, mögen die Filtergewichte in den LOD2-Texture-Elementen über eine Anzahl von Frames bezüglich der Phase angepasst werden, um einen sanften visuellen Übergang zu erzeugen, anstatt in einem einzigen Frame von einem Extrapolationsfilter auf einen herkömmlichen Interpolationsfilter umzuschalten. Wenn die berechnete LOD kleiner als LOD0 ist, das heißt eine höhere Auflösung aufweist als LOD0, werden die extrapolierten Texture-Werte unter Verwendung eines Extrapolations-Vergrößerungsfilters berechnet. Ein Vergrößerungsfilter wird verwendet, wenn das Verhältnis von Texture-Elementen zu Pixeln größer als eins ist.
  • In herkömmliche Systemen wird eine dem Fachmann bekannte Technik, ”unscharfes Maskieren” oder ”Texture-Schärfung”, verwendet, um die Schärfe der Texture-Lookups zu steigern, wenn die berechnete LOD kleiner als null, d. h. die gewünschte Texture-Auflösung höher als LOD0 ist, indem zwischen LOD0 und LOD1 extrapoliert wird, um den Beitrag der niederfrequenten Komponenten von LOD0 herauszusubtrahieren. Die vorliegende Erfindung verwendet auch Extrapolation (Vergrößerungsextrapolation), um Texture-Elementwerte für berechnete LODs zu erzeugen, die kleiner als null sind, verwendet aber neue Extrapolationsfiltertypen, z. B. extrapoliert mipmapped linear (extrapolated mipmapped linear) und extrapoliert mipmapped nächster Nachbar (extrapolated mipmapped nearest-neighbor). Zusätzlich wird Verkleinerungsextrapolation durchgeführt, um für sämtliche nicht residenten Texturen und nicht nur für LOD-Werte unter LOD0 Texture-Werte zu berechnen.
  • 2A ist ein Ablaufdiagramm von Verfahrensschritten zum Erzeugen eines extrapolierten Texture-Werts für eine nicht residente Mipmap-Stufe, wie die nicht residenten Mipmaps 100, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung. In Schritt 200 berechnet das Verfahren unter Verwendung von dem Fachmann bekannten Techniken eine ideale LOD. Der Integeranteil der idealen LOD entspricht der Mipmap-Stufe, die am besten mit der Auflösung der angewandten Texture übereinstimmt. In Schritt 210 bestimmt das Verfahren, ob die ideale LOD-Mipmap eine nicht residente Mipmap ist und, wenn nicht, dann ist die ideale LOD-Mipmap resident, und in Schritt 225 werden Texture-Elemente von den feinen und groben Mipmaps gelesen. Einzelheiten des Schrittes 210 werden in Verbindung mit 2B beschrieben.
  • Herkömmlich korrespondiert die feine Mipmap zu dem Integeranteil der idealen LOD-Mipmap und die grobe Mipmap korrespondiert zu dem Integeranteil + 1 LOD-Mipmap. In Schritt 228 berechnet das Verfahren bilinear gefilterte Texture-Elementwerte für die feinen und groben Mipmaps und interpoliert dann unter Verwendung der Nachkommaanteils (fractional portion) der idealen LOD zwischen den bilinear gefilterten Texture-Elementwerten, um einen gefilterten Texture-Elementwert zu erzeugen, wenn der Filtertyp extrapoliert mipmapped linear ist. Wenn der Filtertyp extrapoliert mipmapped nächster Nachbar ist, wird ein nächster Texture-Elementwert von den feinen und groben Mipmaps ausgewählt, um zwei punktabgetastete Texture-Elementwerte zu erzeugen. Die zwei punktabgetasteten Texture-Elementwerte werden dann unter Verwendung des Nachkommaanteils der idealen LOD bilinear interpoliert, um den gefilterten Texture-Elementwert zu erzeugen. Die Schritte 225 und 228 werden unter Verwendung herkömmlicher Texture-Map-Filterungstechniken durchgeführt.
  • Wenn das Verfahren in Schritt 210 bestimmt, dass die ideale LOD-Mipmap eine nicht residente Mipmap ist, benachrichtigt das Verfahren in Schritt 230 einen Vorrichtungstreiber, dass eine oder mehrere Mipmaps für die Texture seitenweise in den physikalischen Speicher gelesen (paged into) werden sollte, um diese Mipmaps von nicht residenten Mipmaps in residente Mipmaps zur Verwendung bei der Erzeugung eines Bildes zu konvertieren. In Schritt 210 mag das Verfahren bestimmen, dass die ideale LOD-Mipmap nicht resident ist, wenn die ideale LOD kleiner als null und die LODO-Mipmap nicht resident ist, was anzeigt, dass das Verhältnis von Texture-Elementen zu Pixeln größer als eins ist und der extrapolierte Vergrößerungsfilter verwendet werden sollte. Das extrapolierte Verkleinerungsfilter sollte verwendet werden, wenn die ideale LOD größer als Null und die höchste residente Mipmap subtrahiert von der idealen LOD kleiner als null ist, was anzeigt, dass das Verhältnis von Texture-Elementen zu Pixeln kleiner als eins ist. Wenn die ideale LOD gleich LOD0 ist, mag die extrapolierte Vergrößerung verwendet werden.
  • In Schritt 235 berechnet das Verfahren eine DeltaLOD als die Differenz zwischen der idealen LOD und der Extrapolationsschwellenwert-LOD (ein Wert, der größer oder gleich der LOD der residenten Mipmap mit der höchsten Auflösung ist), d. h. DeltaLOD = ideale LOD – Extrapolationsschwellenwert-LOD. Wenn zum Beispiel mit Bezug auf 1 LOD1 die ideale LOD ist (korrespondierend zu der LOD0-Mipmap 120), ist die DeltaLOD –2, da LOD3 die Extrapolationsschwellenwert-LOD ist (korrespondierend zu der LOD3-Mipmap 150). Es sei erwähnt, dass DeltaLOD auch eine Nachkommaanteil-Komponente aufweisen mag, da die ideale LOD und die Extrapolationsschwellenwert-LOD eine Nachkommaanteil-Komponente aufweisen können.
  • In Schritt 240 verwendet das Verfahren die DeltaLOD zum Bestimmen eines Extrapolationsgewichts. Eine Tabelle speichert die Extrapolationsgewichtswerte, die zu den DeltaLOD-Werten korrespondieren. In einigen Ausführungsformen der vorliegenden Erfindung mag die Tabelle programmiert sein, um die Funktion zu spezifizieren, die zum Bestimmen der Extrapolationsgewichtswerte verwendet wird. Einige Ausführungsformen der vorliegenden Erfindung ermöglichen, dass bis zu 64 (LOD, Gewicht) Paare in absteigernder LOD-Reihenfolge in die Tabelle geladen werden. Diese Tabelle enthält defaultmäßig sechs Paare {(0; 0), (–1; 0,25), (–2; 0,5), (–4; 1,125), (–8; 2,0), (–16; 3,0)}.
  • Bei einer gegebenen DeltaLOD, die kleiner als –16 ist, der letzte Eintrag in der Tabelle(0), wird das Extrapolationsgewicht das Gewicht des letzten Eintrags der Tabelle(3,0), d. h. 3 sein. Wenn DeltaLOD kleiner als Null aber größer als der erste Eintrag in der durch die Anwendung festgelegten Tabelle ist, wird das Extrapolationsgewicht das Gewicht des ersten Eintrags in der Tabelle sein. Bei einem gegebenen DeltaLOD-Wert von –5, der zwischen zwei LOD-Werte in der Tabelle, einem niedrigen Wert von (LOD = –4, Gewicht = 1,125) und einem hohen Wert von (LOD = –8, Gewicht = 2,0) fällt, wird das Extrapolationsgewicht linear interpoliert: Gewichtniedrig* (LODhoch – DeltaLOD)/(LODhoch – LODnedrig) + Gewichthoch* (DeltaLOD – LODniedrig)/(LODhoch – LODniedrig) (Gl. 1)
  • Das Extrapolationsgewicht wird in Schritt 250 verwendet, um ein gefiltertes Texture-Element zu erzeugen unter Verwendung der von der Mipmap mit der groben LOD und der Mipmap mit der feinen LOD gelesenen Texture-Elemente.
  • In Schritt 245 liest das Verfahren vier Texture-Elemente von der Mipmap mit der groben LOD und vier Texture-Elemente von der Mipmap mit der feinen LOD, wenn der angegebene Filtertyp extrapoliert mipmapped linear ist. Wenn der angegebene Filter extrapoliert mipmapped nächster Nachbar ist, liest das Verfahren ein einzelnes Texture-Element von der Mipmap mit der feinen LOD und ein einzelnes Texture-Element von der Mipmap mit der groben LOD. Die Mipmap mit der feinen LOD ist die Mipmap, deren Detaillevel gleich der truncated Extrapolationsschwellenwert-LOD (dem Integeranteil der Extrapolationsschwellenwert-LOD) ist, und die Mipmap mit der groben LOD ist eine residente Mipmap mit niedrigerer Auflösung, die eine LOD aufweist, die gleich der feinen LOD plus eins ist.
  • In Schritt 250 interpoliert das Verfahren, wenn der Filtertyp extrapoliert mipmapped linear ist, bilinear Texture-Elemente, die von den Mipmaps mit den groben und feinen LODs gelesen werden, unter Verwendung der Nachkommaanteile der Texture-Map-Koordinaten, um Texture-Elementwerte, Tfein und Tgrob, zu erzeugen. Wenn der Filtertyp extrapoliert mipmapped nächster Nachbar ist, stellt das Verfahren das von der Mipmap mit der feinen LOD gelesene Texture-Element als Tfein und das von der Mipmap mit der groben LOD gelesene Texture-Element als Tgrob bereit. In Schritt 250 berechnet das Verfahren dann den extrapolierten Texture-Elementwert unter Verwendung von Tfein, Tgrob und des Extrapolationsgewichts W unter Verwendung der folgenden Gleichung: Tfein*(1,0 + W) – Tgrob*W (Gl. 2)
  • Der extrapolierte Texture-Elementwert kann mit zusätzlichen extrapolierten Texture-Elementwerten kombiniert werden, um gefilterte Texture-Elementwerte für anisotropes Texture Mapping oder andere gefilterte Texture-Funktionen zu erzeugen. Der extrapolierte Texture-Elementwert wird dann verwendet, um ein gerendertes Bild zu erzeugen, das gespeichert und/oder angezeigt wird.
  • 2B ist ein Ablaufdiagramm des Verfahrensschritts 210 von 2A, um zu bestimmen, ob eine Mipmap, die einer idealen LOD entspricht, resident ist oder nicht, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung. In Schritt 212 bestimmt das Verfahren, ob die ideale LOD kleiner als null, d. h. geringer als LOD0 ist, und wenn dies der Fall ist, dann bestimmt das Verfahren in Schritt 214, ob die LOD0-Mipmap eine residente Mipmap ist. Wenn das Verfahren in Schritt 214 bestimmt, dass die LOD0-Mipmap resident ist, dann wird in Schritt 216 der für das Vergrößerungs-Texture-Filter festgelegte Filtertyp in Schritt 228 verwendet. Wenn das Verfahren in Schritt 214 bestimmt, dass die LOD0-Mipmap nicht resident ist, dann wird in Schritt 217 der für das extrapolierte VergrößerungsTexture-Filter festgelegte Filtertyp in Schritt 250 verwendet.
  • Wenn das Verfahren in Schritt 212 bestimmt, dass die ideale LOD nicht kleiner als null ist, dann bestimmt das Verfahren in Schritt 218, ob die ideale LOD größer oder gleich der Extrapolationsschwellenwert-LOD ist. Wenn das Verfahren in Schritt 218 bestimmt, dass die ideale LOD-Mipmap größer oder gleich der Extrapolationsschwellenwert-LOD ist, dann wird in Schritt 220 der für das Verkleinerungs-Texture-Filter festgelegte Filtertyp zur Berechnung des gefilterten Texture-Elementwerts unter Verwendung von Interpolation in Schritt 228 verwendet. Andernfalls wird in Schritt 221 der für das extrapolierte Verkleinerungs-Texture-Filter festgelegte Filtertyp verwendet, um in Schritt 250 den gefilterten Texture-Elementwert unter Verwendung von Extrapolation zu berechnen.
  • 2C ist ein Ablaufdiagramm von Verfahrensschritten zum Bestimmen, ob ein Texture-Elementwert von einer residenten Mipmap extrapoliert werden sollte oder nicht, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung. Ein Shaderprogramm, das zur Verarbeitung von Grafikdaten verwendet wird, kann unter Verwendung von Prädikaten oder Bedingungscodes konfiguriert werden, um das anschließende Zweigverhalten im Pixelshaderprogramm zu bestimmen. Prädikative oder bedingte Befehle können verwendet werden, um bedingte Ausführungspfade einzuschließen, wo ein Pfad ausgeführt wird, wenn ein Prädikat- oder Bedingungscode eines Shaderprogramms, der durch einen Befehl festgelegt wird, einen ersten Wert aufweist, und ein anderer Pfad ausgeführt wird, wenn ein Prädikat- oder Bedingungscode des Shaderprogramms einen anderen Wert aufweist. Schritt 200, 210 und 230 werden abgeschlossen, wie in Verbindung mit 2A beschrieben. In Schritt 265 stellt das Verfahren einen bedingten Shaderprogrammwert (Prädikat- oder Bedingungscode) ein, um anzuzeigen, dass die Mipmap, die zu der idealen LOD korrespondiert, eine nicht residente Mipmap ist. In anderen Ausführungsformen der vorliegenden Erfindung berechnet das Verfahren auch die DeltaLOD als einen Shaderprogramm Bedingungswert und speichert sie. In Schritt 270 werden die Shaderprogrammbefehle ausgeführt und interpolierte oder extrapolierte Texture-Elementwerte berechnet. Genauer gesagt, führt das Shaderprogramm, wenn der Standardbedingungswert verwendet wird, ein erstes Befehlsset zur Durchführung von herkömmlicher Interpolation zur Erzeugung eines interpolierten Texture-Elementwerts aus. Wenn der Bedingungswert des Shaderprogramms anzeigt, dass die ideale Mipmap eine nicht residente Mipmap ist, wird ein unterschiedliches Befehlsset ausgeführt, um einen extrapolierten Texture-Elementwert zu erzeugen.
  • Systemüberblick
  • 3 ist ein Blockdiagramm, das ein Computersystem veranschaulicht, das zur Ausführung von einem oder mehreren Aspekten der vorliegenden Erfindung konfiguriert ist. 3 ist ein Blockdiagramm eines Computersystems 300 gemäß einer Ausführungsform der vorliegenden Erfindung. Das Computersystem 300 weist eine Zentraleinheit (CPU) 302 und einen Systemspeicher 304 auf, die über einen Buspfad kommunizieren, der eine Speicherbrücke (memory bridge) 305 aufweist. In einigen Ausführungsformen der vorliegenden Erfindung werden Texture-Daten, wie residente Mipmaps 325, die im Systemspeicher 304 gespeichert sind, als ”resident” betrachtet, da diese Daten einem Parallelverarbeitungs-Teilsystem 312 mit einer deterministischen Latenz bereitgestellt werden können. In anderen Ausführungsformen der vorliegenden Erfindung werden im Systemspeicher 304 gespeicherte Texture-Daten als ”nicht resident” betrachtet, da diese Daten dem Paralellverarbeitungs-Teilsystem 312 nicht mit einer vernünftigen Latenz bereitgestellt werden können. Eine vernünftige Latenz ist erforderlich, um eine interaktive Bildfrequenz zu unterstützen.
  • Der Systemspeicher 304 weist auch einen Vorrichtungstreiber 322 auf, der konfiguriert ist, einen Befehlsstrom bereitzustellen, der den Ort der Daten, wie Mipmaps, und Programmbefehle für das Parallelverarbeitungs-Teilsystem 312 spezifiziert. Die Programmbefehle und die Daten werden durch eine Softwareanwendung erzeugt und mögen im Systemspeicher 304 oder einem Speicher in anderen Vorrichtungen des Systems 300 gespeichert werden. Der Vorrichtungstreiber 322 wird durch die CPU 302 ausgeführt, um Befehle zur Ausführung durch das Parallelverarbeitungs-Teilsystem 312 auf der Grundlage der spezifischen Fähigkeiten des Parallelverarbeitungs-Teilsystems 312 zu übersetzen. Die Befehle mögen durch eine Anwendungsprogrammierschnittstelle (Application Programming Interface – API) festgelegt werden, die eine herkömmliche Grafik-API, wie Direct3D oder OpenGL, sein mag.
  • Die Speicherbrücke 305, die z. B. ein Northbridge-Chip sein mag, ist über einen Bus oder einen anderen Kommunikationspfad 306 (z. B. eine HyperTransport-Verbinndung) mit einer E/A-(Eingangs/Ausgangs-)Brücke 307 verbunden. Die E/A-Brücke 307, die z. B. ein Southbridge-Chip sein mag, empfängt die Benutzereingabe von einer oder mehreren Benutzereingabevorrichtungen 308 (z. B. Tastatur, Maus) und leitet die Eingabe über den Pfad 306 und die Speicherbrücke 305 an die CPU 302 weiter. Das Paralellverarbeitungs-Teilsystem 312 ist über einen Bus oder einen anderen Kommunikationspfad 313 (z. B. einen PCI Express, Accelerated Graphics Port oder einen HyperTransport-Link) an die Speicherbrücke 305 gekoppelt; in einer Ausführungsform ist das Parallelverarbeitungs-Teilsystem 312 ein Grafikteilsystem, das Pixel an eine Anzeigevorrichtung 310 (z. B. einen herkömmlichen CRT- oder LOD-basierten Monitor) liefert. Eine Systemplatte 314 ist auch mit der E/A-Brücke 307 verbunden. Einige Mipmaps, insbesondere Level mit hoher Auflösung, die mehr Speicherplatz erfordern, sind im Speicher mit hoher Latenz, wie der Platte 314 oder auf einem Remote-Server, einem CD-Laufwerk, einem DVD-Laufwerk oder dergleichen gespeichert. Diese Mipmaps, wie die nicht residenten Mipmaps 335, werden in einen Speicher mit geringerer Latenz geladen, wie erforderlich, um residente Mipmaps zu werden, auf die während des interaktiven Renderings durch das Parallelverarbeitungs-Teilsystem 312 zugegriffen werden kann.
  • Ein Schalter 316 stellt Verbindungen zwischen der E/A-Brücke 307 und anderen Bauteilen, wie einem Netzwerkadapter 318 und verschiedenen Add-in-Karten 320 und 321, bereit. Andere Bauteile (nicht im Einzelnen gezeigt), einschließlich USB- oder andere Anschlussverbindungen, CD-Laufwerke, DVD-Laufwerke, Filmaufzeichnungsvorrichtungen und dergleichen mögen auch mit der E/A-Brücke 307 verbunden sein. Die Kommunikationswege, die die verschiedenen Bauteile in 3 miteinander verbinden, mögen unter Verwendung von irgendwelchen zweckmäßigen Protokollen, wie PCI (Peripheral Component Interconnect), PCI Express (PCI-E), AGP (Accelerated Graphics Port), HyperTransport oder irgendeinem/irgendwelchen anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll/en ausgeführt werden und die Verbindungen zwischen unterschiedlichen Vorrichtungen mögen unterschiedliche Protokolle verwenden, wie im Fachgebiet bekannt.
  • Eine Ausführungsform des Parallelverarbeitungs-Teilsystems 312 ist in 4 gezeigt. Das Parallelverarbeitungs-Teilsystem 312 weist eine oder mehrere Parallelverarbeitungseinheiten (Parallel Processing Units – PPUs) 402 auf, von denen jede an einen lokalen Parallelverarbeitungsspeicher (Parallel Processing – PP) 404 gekoppelt ist. Im Allgemeinen weist ein Parallelverarbeitungs-Teilsystem eine Anzahl U von PPUs auf, wobei U ≥ 1. (Hierin werden mehrere Exemplare von gleichartigen Objekten mit Bezugszeichen bezeichnet, die das Objekt identifizieren und, wenn erforderlich, das Exemplar mit Nummern in Klammern identifizieren). Die PPUs 402 und PP-Speicher 404 mögen z. B. unter Verwendung einer oder mehrerer integrierter Schaltungsvorrichtungen, wie programmierbarer Prozessoren, anwendungsspezifischer integrierter Schaltungen (Application Specific Integrated Circuits – ASICs) und Speichern, ausgeführt werden.
  • Wie für die PPU 402(0) im Einzelnen gezeigt, weist jede PPU 402 eine Host-Schnittstelle 406 auf, die über den Kommunikationspfad 313, der mit der Speicherbrücke 305 (oder in einer alternativen Ausführungsform, direkt mit der CPU 302) verbunden ist, mit dem Rest des Systems 300 kommuniziert. In einer Ausführungsform ist der Kommunikationspfad 313 ein PCI-E-Link, in dem jeder PPU 402 dedizierte Spuren (lanes) zugeordnet sind, wie im Fachgebiet bekannt. Es mögen auch andere Kommunikationspfade verwendet werden. Die Hostschnittstelle 406 erzeugt Pakete (oder andere Signale) zum Übertragen auf dem Kommunikationspfad 313 und empfängt auch alle ankommenden Pakete (oder anderen Signale) vom Kommunikationspfad 313 und leitet sie an zweckmäßige Bauteile der PPU 402 weiter. Zum Beispiel mögen Befehle, die die Verarbeitungsaufgaben betreffen, an eine Frontend-Einheit 412 geleitet werden, während Befehle, die Speicheroperationen betreffen (z. B. Lesen von oder Schreiben in einen PP-Speicher 404), an eine Speicherschnittstelle 414 geleitet werden mögen. Die Host-Schnittstelle 406, die Frontend-Einheit 412 und die Speicherschnittstelle 414 mögen eine allgemein herkömmliche Konstruktion aufweisen, auf deren ausführliche Beschreibung verzichtet wird, da sie für die vorliegende Erfindung nicht kritisch ist.
  • Jede PPU 402 implementiert vorzugsweise einen hochparallelen Prozessor. Wie für die PPU 402(0) im Einzelnen gezeigt, weist eine PPU 402 eine Anzahl C von Kernen 408 auf, wobei C ≥ 1. Jeder Verarbeitungskern 408 ist in der Lage, gleichzeitig eine große Anzahl (z. B. Zig oder Hunderte) von Threads auszuführen, wobei jeder Thread eine Instanz eines Programms ist; eine Ausführungsform eines Multithread-Verarbeitungskerns 408 wird unten beschrieben. Kerne 408 empfangen über eine Arbeitsverteilungseinheit 410, die von einer Frontend-Einheit 412 Befehle empfängt, die Verarbeitungsaufgaben definieren, Verarbeitungsaufgaben, die auszuführen sind. Die Arbeitsverteilungseinheit 410 kann eine Vielzahl von Algorithmen zum Verteilen der Arbeit implementieren. Zum Beispiel empfängt die Arbeitsverteilungseinheit 410 in einer Ausführungsform ein ”Bereit” Signal von jedem Kern 408, das anzeigt, ob dieser Kern über ausreichende Ressourcen zum Annehmen einer neuen Verarbeitungsaufgabe verfügt. Wenn eine neue Verarbeitungsaufgabe eintrifft, weist die Arbeitsverteilungseinheit 410 die Aufgabe einem Kern 408 zu, der das Bereit-Signal durchsetzt (asserting); wenn kein Kern 408 das Bereit-Signal durchsetzt (asserts), behält die Arbeitsverteilungseinheit 410 die neue Verarbeitungsaufgabe so lange, bis ein Bereit-Signal durch einen Kern 408 aktiviert wird. Der Fachmann wird erkennen, dass auch andere Algorithmen verwendet werden können und dass die bestimmte Art und Weise, auf die die Arbeitsverteilungseinheit 410 die ankommenden Verarbeitungsaufgaben verteilt, für die vorliegende Erfindung nicht kritisch ist.
  • Kerne 408 kommunizieren mit der Speicherschnittstelle 414 zum Lesen von oder zum Schreiben auf verschiedene externe Speichervorrichtungen. In einer Ausführungsform weist eine Speicherschnittstelle 414 eine Schnittstelle auf, die zur Kommunikation mit dem lokalen PP-Speicher 404 eingerichtet ist, sowie eine Verbindung zur Host-Schnittstelle 406, wodurch die Kerne in die Lage versetzt werden, mit dem Systemspeicher 304 oder einem anderen Speicher, der nicht lokal für die PPU 402 ist, einschließlich der Systemplatte 314, zu kommunizieren. Die Speicherschnittstelle 414 kann im Allgemein von herkömmlicher Konstruktion sein und auf eine ausführliche Beschreibung wird verzichtet.
  • Kerne 408 können programmiert sein, um Verarbeitungsaufgaben auszuführen, die eine große Vielzahl von Anwendungen betreffen, die lineare und nichtlineare Datentransformationen, das Filtern von Video- und/oder Audiodaten, Modellierungsoperationen (z. B. das Anwenden physikalischer Gesetze zum Bestimmen der Position, Geschwindigkeit und anderer Attribute von Objekten), Bildrenderingoperationen (z. B. Vertex-Shader-, Geometrie-Shader-, und/oder Pixel-Shader-Programme) und so weiter einschließen aber nicht darauf beschränkt sind. Die PPUs 402 mögen Daten, wie die residente Mipmap 425 vom Systemspeicher 304 und/oder lokalen PP-Speichern 404 in den internen (on-chip) Speicher übertragen, die Daten verarbeiten, und die Ergebnisdaten zurück in den Systemspeicher 304 und/oder die lokalen PP-Speicher 404 schreiben, wo auf solche Daten durch andere Systemkomponenten, einschließlich z. B. die CPU 302 oder ein anderes Parallelverarbeitungs-Teilsystem 312 zugegriffen werden kann.
  • Erneut mit Bezug auf 3 sind, in einigen Ausführungsformen, einige oder alle der PPUs 402 im Parallelverarbeitungs-Teilsystem 312 Grafikprozessoren mit Rendering-Pipelines, die konfiguriert werden können, um verschiedene Aufgaben durchzuführen, die mit dem Erzeugen von Pixeldaten aus den Grafikdaten verbunden sind, die mittels der CPU 302 und/oder des Systemspeichers 304 über die Speicherbrücke 305 und den Bus 313 gelieferten werden, die mit dem lokalen PP-Speicher 404 interagieren (der als Grafikspeicher verwendet werden kann, der z. B. einen herkömmlichen Framepuffer und Mipmaps aufweist), um Pixeldaten zu speichern und zu aktualisieren, wobei die Pixeldaten an die Anzeigevorrichtung 310 und dergleichen geliefert werden. In einigen Ausführungsformen mag das PP-Teilsystem 312 eine oder mehrere PPUs 402, die als Grafikprozessoren arbeiten, und eine oder mehrere PPUs 402 aufweisen, die zu allgemeinen (general purpose) Berechnungszwecken verwendet werden. Die PPUs mögen identisch oder unterschiedlich sein und jede PPU mag ihre eigenen dedizierten PP-Speichervorrichtung(en) oder keine dedizierten PP-Speichervorrichtung(en) aufweisen.
  • Beim Betrieb ist die CPU 302 der Masterprozessor des Systems 300, der den Betrieb von anderen Systemkomponenten steuert und koordiniert. Insbesondere gibt die CPU 302 Befehle aus, die den Betrieb der PPUs 402 steuern. In einigen Ausführungsformen schreibt die CPU 302 einen Stream von Befehlen für jede PPU 402 in einen Push-Puffer (in 3 nicht im Einzelnen gezeigt), der sich im Systemspeicher 304, PP-Speicher 404 oder einen anderen Speicherplatz befinden mag, auf den sowohl durch die CPU 302 als auch durch die PPU 402 zugegriffen werden kann. Die PPU 402 liest den Befehlsstream vom Push-Puffer und führt asynchron zum Betrieb der CPU 302 Befehle aus.
  • Man wird verstehen, dass das hierin gezeigte System veranschaulichend ist und dass Veränderungen und Abwandlungen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, mag je nach Wunsch verändert werden. Zum Beispiel ist der Systemspeicher 304 in einigen Ausführungsformen anstatt über eine Brücke direkt mit der CPU 302 verbunden, und andere Vorrichtungen kommunizieren über die Speicherbrücke 305 und die CPU 302 mit dem Systemspeicher 304. In anderen alternativen Topologien ist das Parallelverarbeitungs-Teilsystem 312 anstatt mit der Speicherbrücke 305 mit der E/A-Brücke 307 oder direkt mit der CPU 302 verbunden. In noch anderen Ausführungsformen mögen die E/A-Brücke 307 und die Speicherbrücke 305 in einem einzigen Chip integriert sein. Die bestimmten Ausführungsformen, die hierin gezeigt werden, sind optional; zum Beispiel mag irgendeine Anzahl von Add-in-Karten oder Peripheriegeräten unterstützt werden. In einigen Ausführungsformen wird der Schalter 316 beseitigt und der Netzwerkadapter 318 und die Add-in-Karten 320, 321 werden direkt mit der E/A-Brücke 307 verbunden.
  • Auch die Verbindung der PPU 402 mit dem restlichen System 300 mag variiert werden. In einigen Ausführungsformen ist das PP-System 312 als eine Add-in-Karte implementiert, die in einen Erweiterungsschlitz des Systems 300 eingesteckt werden kann. In anderen Ausführungsformen kann eine PPU 402 mit einer Busbrücke, wie einer Speicherbrücke 305 oder einer E/A-Brücke 307 in einen einzigen Chip integriert sein. In noch anderen Ausführungsformen mögen einige oder alle Bauteile der PPU 402 mit der CPU 302 in einem einzigen Chip integriert sein.
  • Eine PPU mag mit irgendeinem lokalen PP-Speicher von irgendeinem Umfang, einschließlich mit keinem lokalen Speicher, versehen sein und mag lokale Speicher und Systemspeicher in irgendeiner Kombination verwenden. Zum Beispiel kann eine PPU 402 ein Grafikprozessor in einer Unified Memory Architecture (UMA) Ausführungsform sein; in solchen Ausführungsformen wird kein oder wenig dedizierter Grafikspeicher (PP) bereitgestellt und die PPU 402 würde den Systemspeicher ausschließlich oder nahezu ausschließlich zum Speichern der residenten Mipmaps 325 verwenden. In UMA-Ausführungsformen mag eine PPU in einen Brückenchip oder Prozessorchip integriert oder als ein getrennter Chip mit einem Hochgeschwindigkeitslink (z. B. PCI-E) bereitgestellt werden, der die PPU, z. B. über einen Brückenchip, mit dem Systemspeicher verbindet.
  • Wie vorhergehend erwähnt, kann irgendeine Anzahl von PPUs in einem Parallelverarbeitungs-Teilsystem enthalten sein. Zum Beispiel können mehrere PPUs auf einer einzigen Add-in-Karte bereitgestellt werden oder es können mehrere Add-in-Karten mit dem Kommunikationspfad 313 verbunden sein oder es könnten eine oder mehrere der PPUs in einen Brückenchip integriert sein. Die PPUs in einem Mehrfach-PPUs-System mögen miteinander identisch oder unterschiedlich voneinander sein; zum Beispiel mögen unterschiedliche PPUs unterschiedliche Anzahlen von Kernen, lokale PP-Speicher mit unterschiedlichen Umfängen, und so weiter, aufweisen. Wo mehrere PPUs vorhanden sind, mögen sie parallel betrieben werden, um die Daten mit einem höheren Durchsatz zu verarbeiten als dies mit einer einzigen PPU möglich ist.
  • Systeme, die eine oder mehrere PPUs aufweisen, können in einer Vielzahl von Konfigurationen und Formfaktoren ausgeführt werden, die Desktops, Laptops oder handgehaltene Personalcomputer, Server, Arbeitsplatzgeräte, Spielkonsolen, eingebettete Systeme (embedded systems) und so weiter einschließen.
  • Kernübersicht
  • 5 ist ein Blockdiagramm einer Parallelverarbeitungseinheit 420 für das Parallelverarbeitungssystem 312 von 4 gemäß einem oder mehreren Aspekten der vorliegenden Erfindung. Die PPU 402 weist einen Kern 408 (oder mehrere Kerne 408) auf, der konfiguriert ist, um parallel eine große Anzahl von Threads auszuführen, wobei der Begriff ”Thread” eine Instanz eines bestimmten Programms bezeichnet, das auf einem bestimmten Eingangsdatensatz ausgeführt wird. In einigen Ausführungsformen werden Single-Instruction Multiple-Data (SIMD) Befehlsausgabetechniken verwendet, um die parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Befehlseinheiten bereitzustellen.
  • In einer Ausführungsform weist jeder Kern 408 ein Array von P (z. B. 8, 16, usw.) Parallelverarbeitungsmaschinen 502 auf, die für den Empfang von SIMD-Befehlen von einer einzigen Befehlseinheit 512 konfiguriert sind. Jede Verarbeitungsmaschine 502 (processing engine) weist vorzugsweise einen identischen Satz von Funktionseinheiten (z. B. arithmetisch-logische Einheiten, usw.) auf. Die Funktionseinheiten mögen in Pipelines angeordnet werden, was erlaubt, dass ein neuer Befehl vor der Beendigung eines vorherigen Befehls ausgegeben wird, wie im Fachgebiet bekannt. Es mag irgendeine Kombination von Funktionseinheiten bereitgestellt werden. In einer Ausführungsform unterstützen die Funktionseinheiten eine Vielzahl von Operationen, die Integer- und Gleitpunktarithmetik (z. B. Addition und Multiplikation), Vergleichsoperationen, Boolesche Verknüpfungen (UND, ODER, XODER), Bit-Verschiebung und die Berechnung verschiedener algebraischer Funktionen (z. B. planare Interpolation, trigonometrische, Exponential- und Logarithmusfunktionen, usw.) aufweisen; und die Hardware der gleichen Funktionseinheit kann wirksam eingesetzt werden, um unterschiedliche Operationen durchzuführen.
  • Jede Verarbeitungseinheit 502 (processing engine) verwendet Platz in einer lokalen Registerdatei (Local Register File – LRF) 504 zur Speicherung ihrer lokalen Eingangsdaten, Zwischenergebnisse und dergleichen. In einer Ausführungsform ist die lokale Registerdatei 504 physikalisch oder logisch in P Spuren unterteilt, von denen jede eine Anzahl von Einträgen aufweist (wo jeder Eintrag z. B. ein 32-Bit-Wort speichern mag). Jeder Verarbeitungsmaschine 502 ist eine Spur zugeordnet und in entsprechende Einträge in unterschiedlichen Spuren können Daten für unterschiedliche Threads, die das gleiche Programm ausführen, eingepflegt werden, um die SIMD-Ausführung zu erleichtern. In einigen Ausführungsformen kann jede Verarbeitungsmaschine 502 nur auf LRF-Einträge auf der Spur zugreifen, die ihr zugewiesen ist. Die Gesamtanzahl von Einträgen in der lokalen Registerdatei 504 ist vorzugsweise groß genug, um mehrere gleichzeitige Threads pro Verarbeitungsmaschine 502 zu unterstützen.
  • Jede Verarbeitungseinheit 502 hat auch Zugriff auf einen geteilten (shared) chipinternen Speicher 506, der unter allen Verarbeitungsmaschinen 502 im Kern 408 geteilt wird. Der geteilte Speicher 506 mag so groß sein wie gewünscht und in einigen Ausführungsformen kann irgendeine Verarbeitungsmaschine 502 von irgendeinem Ort im geteilten Speicher 506 mit gleich geringer Latenz (z. B. vergleichbar mit dem Zugriff auf die lokale Registerdatei 504) lesen oder darauf schreiben. In einigen Ausführungsformen ist der geteilte Speicher 506 als eine geteilte (shared) Registerdatei ausgeführt; in anderen Ausführungsformen kann der geteilte Speicher 506 unter Verwendung eines geteilten Cachespeichers ausgeführt werden.
  • Zusätzlich zum geteilten Speicher 506 stellen einige Ausführungsformen auch zusätzlichen chipinternen Parameterspeicher und/oder Cache/s 508 bereit, die z. B. als ein herkömmlicher RAM oder Cache ausgeführt werden mögen. Der Parameterspeicher/Cache 508 kann z. B. verwendet werden, um Zustandsparameter und/oder andere Daten (z. B. verschiedene Konstanten) zu halten, die von mehreren Threads benötigt werden mögen. Die Verarbeitungsmaschinen 502 haben über die Speicherschnittstelle 414 auch einen Zugriff auf den ”globalen” chipexternen Speicher 520, der z. B. einen PP-Speicher 404 und/oder Systemspeicher 304 aufweisen kann, wobei von der Speicherschnittstelle 414 über die Host-Schnittstelle 406 auf den Systemspeicher 304 zugegriffen werden kann, wie vorhergehend beschrieben.
  • Man wird verstehen, dass irgendein Speicher, der PPU-extern 402 ist, als der globale Speicher 520 verwendet werden mag. Wie in 5 gezeigt, weist der globale Speicher den PP-Speicher 404, den Systemspeicher 304 und die Systemplatte 314 auf. Wie vorhergehend beschrieben, werden Texture-Daten, wie residente Mipmaps 325 und 425, die im globalen Speicher 520 gespeichert sind, als residente Texture-Daten betrachtet, und andere Texture-Daten, wie die nicht residenten Mipmaps 335, die im globalen Speicher 520 gespeichert sind, werden als nicht residente Texture-Daten betrachtet. Wenn die nicht residenten Texture-Daten von der Systemplatte 314 in den Systemspeicher 304 oder den PP-Speicher 404 kopiert werden, werden die Texture-Daten residente Texture-Daten. Ein Treiberprogramm, das auf der CPU 302 von 3 ausgeführt wird, kann verwendet werden, um zu spezifizieren, welche Mipmaps residente Mipmaps sind und welche Mipmaps nicht resident sind. In anderen Ausführungsformen der vorliegenden Erfindung erfolgt die Bestimmung, ob eine Mipmap resident oder nicht resident ist, auf der Grundlage von zumindest einem Abschnitt der Texture-Elementadresse. Die Verarbeitungsmaschinen 502 können über eine (nicht im Einzelnen gezeigte) Verknüpfung, die es jeder Verarbeitungsmaschine 502 ermöglicht, auf den globalen Speicher 520 zuzugreifen, an die Speicherschnittstelle 414 gekoppelt werden.
  • In einer Ausführungsform ist jede Verarbeitungsmaschine 502 eine Multithread-Maschine und kann gleichzeitig bis zu einer bestimmten Anzahl G (z. B. 24) von Threads ausführen, indem z. B. die gegenwärtigen Zustandsinformationen, die mit jedem Thread assoziiert sind, mit einem unterschiedlichen Bereich ihrer zugewiesenen Spur in der lokalen Registerdatei 504 gehalten wird. Die Verarbeitungsmaschinen 502 sind vorzugsweise konstruiert, um schnell von einem Thread zum anderen umzuschalten, derart, dass Befehle von unterschiedlichen Threads ohne Effizienzverlust in jeder Folge ausgegeben werden können.
  • Die Befehlseinheit 512 ist derart konfiguriert, dass der gleiche Befehl (INSTR) für jeden gegebenen Verarbeitungszyklus an alle P Verarbeitungsmaschinen 502 ausgegeben wird. Daher implementiert der Kern 408 auf der Ebene eines einzigen Taktzyklus eine P-Wege-SIMD-Mikroarchitektur. Da die Verarbeitungsmaschine 502 auch eine Multithread-Maschine ist, die gleichzeitig bis zu G Threads unterstützt, kann der Kern 408 in dieser Ausführungsform bis zu P*G Threads aufweisen, die gleichzeitig ausgeführt werden. Wenn zum Beispiel P = 16 und G = 24, dann unterstützt der Kern 408 bis zu 584 gleichzeitige Threads.
  • Da die Befehlseinheit 512 den gleichen Befehl parallel an alle P Verarbeitungsmaschinen 502 ausgibt, wird der Kern 408 vorzugsweise verwendet, um die Threads in ”SIMD-Threadgruppen” zu verarbeiten. Wie hierin verwendet, bezeichnet eine ”SIMD-Threadgruppe” eine Gruppe von bis zu P Ausführungsthreads des gleichen Programms auf unterschiedlichen Eingangsdaten, wobei jeder Verarbeitungsmaschine ein Thread der Gruppe zugewiesen wird. Eine SIMD-Threadgruppe mag weniger als P Threads aufweisen und in diesem Fall werden einige der Verarbeitungsmaschinen 502 während Zyklen, in denen diese SIMD-Threadgruppe verarbeitet wird, nicht in Betrieb (idle) sein. Eine SIMD-Threadgruppe mag auch mehr als P Threads aufweisen und in diesem Fall wird die Verarbeitung über aufeinander folgende Taktzyklen erfolgen. Da jede Verarbeitungsmaschine 502 gleichzeitig bis zu G Threads unterstützten kann, folgt, dass zu jedem gegebenen Zeitpunkt im Kern 408 bis zu G SIMD-Threadgruppen ausgeführt werden können.
  • Bei jedem Taktzyklus wird ein Befehl an alle P Threads ausgegeben, die eine unter den G SIMD-Threadgruppen ausgewählte Gruppe bilden. Zur Anzeige, welcher Thread gegenwärtig aktiv ist, mag eine ”Aktiv-Maske” für den zugehörigen Thread im Befehl enthalten sein. Die Verarbeitungsmaschine 502 verwendet die Aktiv-Maske als eine Kontextkennung, z. B. um zu bestimmen, welcher Abschnitt ihrer zugeordneten Spur in der lokalen Registerdatei 504 bei der Ausführung des Befehls verwendet werden sollte. Daher führen in einem gegebenen Zyklus alle Verarbeitungsmaschinen 502 im Kern 408 nominal den gleichen Befehl für unterschiedliche Threads in der gleichen SIMD-Threadgruppe aus. (In einigen Fällen mögen einige Threads in einer SIMD-Threadgruppe, z. B. aufgrund von bedingten oder prädikativen Befehlen, Divergenzen in Zweigen im Programm oder dergleichen, zeitweise nicht in Betrieb sein.)
  • Der Betrieb des Kerns 408 wird vorzugsweise über eine Kernschnittstelle 503 gesteuert. In einigen Ausführungsformen empfängt die Kernschnittstelle 503 die zu verarbeitenden Daten (z. B. Primitivdaten, Vertexdaten, und/oder Pixeldaten) sowie Zustandsparameter und Befehle, die definieren, wie die Daten zu verarbeiten sind (z. B. welches Programm auszuführen ist), von der Arbeitsverteilungseinheit 410. Threads oder SIMD-Threadgruppen können durch andere Threads oder durch Einheiten mit fester Funktion, wie Dreieck-Rasterizer, gestartet werden. Die Kernschnittstelle 503 kann zu verarbeitende Daten in den geteilten Speicher 506 und Parameter in den Parameterspeicher 508 laden. Die Kernschnittstelle 503 initialisiert auch jede/n neue/n Thread oder SIMD-Threadgruppe in der Befehlseinheit 512 und signalisiert dann der Befehlseinheit 512, mit der Ausführung der Threads zu beginnen. Wenn die Ausführung eines Threads oder einer SIMD-Threadgruppe abgeschlossen ist, benachrichtigt der Kern 408 vorteilhafterweise die Kernschnittstelle 503. Die Kernschnittstelle 503 kann dann andere Prozesse einleiten, um z. B. Ausgangsdaten vom geteilten Speicher 506 abzurufen und/oder den Kern 408 zur Ausführung von zusätzlichen Threads oder SIMD-Threadgruppen vorzubereiten.
  • Man wird verstehen, dass die hierin beschriebene Kernarchitektur veranschaulichend ist und dass verschiedene Veränderungen und Abwandlungen möglich sind. Es kann irgendeine Anzahl von Verarbeitungsmaschinen vorgesehen werden. In einigen Ausführungsformen weist jede Verarbeitungsmaschine ihre eigene lokale Registerdatei auf und die Zuweisung von lokalen Registerdateieinträgen pro Thread kann fest oder je nach Wunsch konfigurierbar sein. Ferner mag eine PPU 402, obgleich nur ein Kern 408 gezeigt wird, irgendeine Anzahl von Kernen 408 aufweisen, die vorteilhafterweise alle eine identische Konstruktion aufweisen, damit das Ausführungsverhalten nicht davon abhängig ist, welcher Kern 408 eine bestimmte Verarbeitungsaufgabe empfängt. Jeder Kern 408 arbeitet vorteilhafterweise unabhängig von den anderen Kernen 408 und weist seine/n eigene/n je nach Wunsch/en, geteilte/n Speicher und so weiter auf.
  • Threadarrays und kooperative Threadarrays
  • In einigen Ausführungsformen kann der Multithread-Verarbeitungskern 408 von 5 unter Verwendung von Threadarrays Berechnungen zu allgemeinen Zwecken (general purpose) ausführen. Wie hierin verwendet, ist ein ”Threadarray” eine Gruppe, die aus einer Anzahl (n0) von Threads besteht, die gleichzeitig das gleiche Programm auf einem Eingangsdatensatz ausführen, um einen Ausgangsdatensatz zu erzeugen. Jedem Thread im Threadarray wird eine eindeutige Threadkennung (”Thread-ID”) zugewiesen, auf die während seiner Ausführung durch den Thread zugegriffen werden kann. Die Thread-ID steuert verschiedene Aspekte des Verarbeitungsverhaltens des Threads. Zum Beispiel mag eine Thread-ID verwendet werden, um zu bestimmen, welcher Anteil des Eingangsdatensatzes durch einen Thread zu verarbeiten ist, und/oder zu bestimmen, welcher Anteil eines Ausgangsdatensatzes durch einen Thread zu erzeugen oder zu schreiben ist.
  • In einigen Ausführungsformen sind die Threadarrays ”kooperative” Threadarrays oder CTAs. Wie andere Typen von Threadarrays ist ein CTA eine Gruppe von mehreren Threads, die gleichzeitig das gleiche Programm (das hierin als ein ”CTA-Programm” bezeichnet wird) auf einem Eingangsdatensatz ausführen, um einen Ausgangsdatensatz zu erzeugen. In einem CTA können die Threads zusammenwirken, indem sie Daten auf eine Weise untereinander teilen, die von der Thread-ID abhängig ist. Zum Beispiel können in einem CTA Daten erzeugt und durch einen anderen konsumiert werden. In einigen Ausführungsformen können an Punkten, wo die Daten zu teilen sind, Synchronisationsbefehle in den CTA-Programmcode eingefügt werden, um sicherzustellen, dass die Daten tatsächlich durch den erzeugenden Thread erzeugt wurden, bevor der konsumierende Thread versucht, darauf zuzugreifen. Das Ausmaß, in dem die Daten gegebenenfalls unter den Threads eines CTA geteilt werden, wird mittels des CTA-Programms bestimmt; daher versteht sich, dass die Threads eines CTA in einer bestimmten Anwendung, die CTAs verwendet, tatsächlich in Abhängigkeit vom CTA-Programm Daten miteinander teilen mögen oder nicht.
  • In einigen Ausführungsformen teilen die Threads in einem CTA Eingangsdaten und/oder Zwischenergebnisse im gleichen CTA unter Verwendung des geteilten Speichers 506 von 5 mit anderen Threads. Zum Beispiel mag ein CTA-Programm einen Befehl zum Berechnen einer Adresse im geteilten Speicher 506 aufweisen, in den bestimmte Daten zu schreiben sind, wobei die Adresse eine Funktion der Thread-ID ist. Jeder Thread berechnet die Funktion unter Verwendung seiner eigenen Thread-ID und schreibt an den entsprechenden Ort. Die Adressfunktion ist vorteilhafterweise derart definiert, dass unterschiedliche Threads an unterschiedliche Orte schreiben; so lange die Funktion deterministisch ist, ist der Ort, an dem durch irgendeinen Thread geschrieben wird, voraussagbar. Das CTA-Programm kann auch einen Befehl zum Berechnen einer Adresse im geteilten Speicher 506 aufweisen, von dem Daten zu lesen sind, wobei die Adresse eine Funktion der Thread-ID ist. Durch die Definition zweckmäßiger Funktionen und das Bereitstellen von Synchronisierungstechniken können Daten durch einen Thread eines CTA an einem gegebenen Ort im geteilten Speicher 506 geschrieben und durch einen anderen Thread des gleichen CTA auf vorhersagbare Weise gelesen werden. Infolgedessen kann jedes gewünschte Muster zum Teilen der Daten unter Threads unterstützt werden und jeder Thread in einem CTA können Daten mit jedem anderen Thread im gleichen CTA teilen.
  • CTAs (oder andere Typen von Threadarrays) werden vorteilhafterweise verwendet, um Berechnungen durchzuführen, die sich zu einer datenparallelen Zerlegung eignen. Wie hierin verwendet, umfasst eine ”datenparallele Zerlegung” jede Situation, in der ein Rechenproblem gelöst wird, indem der gleiche Algorithmus mehrfach parallel auf Eingangsdaten ausgeführt wird, um Ausgangsdaten zu erzeugen; zum Beispiel beinhaltet ein gängiger Fall von datenparalleler Zerlegung die Anwendung des gleichen Verarbeitungsalgorithmus auf unterschiedliche Abschnitte eines Eingangsdatensatzes, um unterschiedliche Abschnitte eines Ausgangsdatensatzes zu erzeugen. Beispiele von Problemen, die datenparalleler Zerlegung zugänglich sind, umfassen Matrixalgebra, lineare und/oder nichtlineare Transformationen in irgendeiner Anzahl von Dimensionen (z. B. schnelle Fourier-Transformationen) und verschiedene Filterungsalgorithmen, die Faltungsfilter in irgendeiner Anzahl von Dimensionen, separable Filter in mehreren Dimensionen, und so weiter, umfassen. Der auf jeden Abschnitt des Eingangsdatensatzes anzuwendende Verarbeitungsalgorithmus wird im CTA-Programm festgelegt und jeder Thread in einem CTA führt das gleiche CTA-Programm auf einem Abschnitt des Eingangsdatensatzes durch. Ein CTA-Programm kann Algorithmen unter Verwendung einer breiten Palette von mathematischen und logischen Operationen implementieren und das Programm kann bedingte oder verzweigte Ausführungspfade und direkten und/oder indirekten Speicherzugriff aufweisen. Wie vorhergehend in Verbindung mit 2B beschrieben, kann ein Shaderprogramm, das zur Verarbeitung von Grafikdaten verwendet wird, konfiguriert werden, um bedingte Ausführungspfade unter Verwendung von prädikativen oder bedingten Befehlen aufzuweisen. Zum Beispiel wird auf der Grundlage eines berechneten DeltaLOD-Werts ein Prädikat oder Bedingungscode bestimmt, der bewirkt, dass das Shaderprogramm Befehle zur Durchführung von Extrapolation zur Erzeugung eines gefilterten Texture-Elementwerts ausführt. Für einen anderen Wert des Prädikats oder Bedingungscodes führt das Shaderprogramm Befehle zur Durchführung von herkömmlicher Interpolation zur Erzeugung eines gefilterten Texture-Elementwerts aus.
  • In einer Ausführungsform schreibt ein Treiberprogramm, das auf der CPU 302 von 3 ausgeführt wird, Befehle, die den CTA definieren, in einen Push-Puffer (nicht im Einzelnen gezeigt) im Speicher (z. B. Systemspeicher 304), von dem die Befehle mittels einer PPU 402 gelesen werden. Die Befehle sind vorteilhafterweise mit Zustandsparametern, wie der Anzahl von Threads im CTA, dem Ort eines unter Verwendung des CTA zu verarbeitenden Eingangsdatensatzes im globalen Speicher 520, welche Mipmaps für eine Texture resident sind, den Ort des auszuführenden CTA-Programms im globalen Speicher 520 und dem Ort im globalen Speicher 520, an dem die Ausgangsdaten zu schreiben sind, verbunden. Die Zustandsparameter mögen zusammen mit den Befehlen in den Push-Puffer geschrieben werden. Als Reaktion auf die Befehle lädt die Kernschnittstelle 503 die Zustandsparameter in den Kern 408 (z. B. in den Parameterspeicher 508) und beginnt dann mit dem Start von Threads, bis die Anzahl von Threads, die in den CTA-Parametern angegeben ist, gestartet wurde. In einer Ausführungsform weist die Kernschnittstelle 503 den Threads sequentiell Thread-IDs zu wie sie gestartet werden. Allgemeiner gesagt, da alle Threads in einem CTA das gleiche Programm im gleichen Kern 408 ausführen, kann irgendeinem Thread irgendeine Thread-ID zugewiesen werden, solange jede gültige Thread-ID nur einem einzigen Thread zugewiesen wird. Irgendeine eindeutige Kennung (numerische Kennungen eingeschlossen, aber nicht darauf beschränkt) kann als eine Thread-ID verwendet werden. In einer Ausführungsform sind die Thread-IDs, wenn ein CTA eine Anzahl (n0) von Threads aufweist, einfach sequentielle (eindimensionale) Indexwerte von 0 bis n0 – 1. In anderen Ausführungsformen können mehrdimensionale Indexierungsschemata verwendet werden. Es sei erwähnt, dass die bestimmte Zuordnung von Threads zu Verarbeitungsmaschinen nicht das Ergebnis der CTA-Ausführung beeinträchtigt, solange das Datenteilen (data sharing) durch Bezugnahme auf Thread-IDs gesteuert wird. Daher kann ein CTA-Programm unabhängig von der bestimmten Hardware sein, auf der es auszuführen ist.
  • Grafikpipelinearchitektur
  • 6A ist ein Konzeptdiagramm einer Grafikverarbeitungspipeline 600 gemäß einem oder mehreren Aspekten der vorliegenden Erfindung. Die PPU 402 von 4 kann konfiguriert sein, um eine Grafikverarbeitungspipeline 600 zu bilden. Zum Beispiel mag der Kern 408 konfiguriert sein, um die Funktionen einer Vertexverarbeitungseinheit 644, Geometrieverarbeitungseinheit 648 und einer Fragmentverarbeitungseinheit 660 durchzuführen. Die Funktionen des Datenassemblers 642, Primitivassemblers 646, Rasterizers 655, und der Rasteroperationseinheit 665 mag auch mittels des Kerns 408 durchgeführt werden oder mögen mittels der Host-Schnittsteile 406 durchgeführt werden.
  • Der Datenassembler 642 sammelt die Vertexdaten für höherwertige Flächen, Primitive und dergleichen und gibt die Vertexdaten an die Vertexverarbeitungseinheit 644 aus. Die Vertexverarbeitungseinheit 644 ist eine programmierbare Ausführungseinheit, die konfiguriert ist, um Vertexshaderprogramme auszuführen und Vertexdaten umzuwandeln, wie durch die Vertexshaderprogramme spezifiziert. Zum Beispiel mag die Vertexverarbeitungseinheit 644 programmiert sein, um die Vertexdaten von einer objektbasierten Koordinatendarstellung (Objektraum) in ein Koordinatensystem auf alternativer Grundlage, wie Weltkoordinaten oder normalisierter Vorrichtungskoordinatenraum (Normalized Device Coordinates – NDC), umzuwandeln. Die Vertexverarbeitungseinheit 644 mag über die Speicherschnittstelle 414 Daten, die im PP-Speicher 404 gespeichert sind, zur Verwendung bei der Verarbeitung der Vertexdaten lesen.
  • Der Primitivassembler 646 empfängt verarbeitete Vertexdaten von der Vertexverarbeitungseinheit 644 und konstruiert Grafikprimitive, z. B. Punkte, Linien, Dreiecke oder dergleichen zur Verarbeitung mittels der Geometrieverarbeitungseinheit 648. Die Geometrieverarbeitungseinheit 648 ist eine programmierbare Ausführungseinheit, die konfiguriert ist, um Geometrieshaderprogramme auszuführen und vom Primitivassembler 646 empfangene Grafikprimitive, wie mittels der Geometrieshaderprogramme spezifiziert, umzuwandeln. Die Geometrieverarbeitungseinheit 648 mag zum Beispiel programmiert werden, um die Grafikprimitive in eine oder mehrere neue Grafikprimitive zu unterteilen und Parameter, wie Ebenengleichungskoeffizienten, zu berechnen, die zum Rastern der neuen Grafikprimitive verwendet werden. Die Geometrieverarbeitungseinheit 648 gibt die Parameter und die neuen Grafikprimitive an den Rasterizer 655 aus. Die Geometrieverarbeitungseinheit 648 mag durch die Speicherschnittstelle 414 Daten, die im PP-Speicher 404 gespeichert sind, zur Verwendung bei der Verarbeitung der Geometriedaten lesen.
  • Der Rasterizer 655 Abtastumwandelt die neuen Grafikprimitive und gibt Fragmente und Erfassungsdaten (coverage data) an die Fragmentverarbeitungseinheit 660 aus. Die Fragmentverarbeitungseinheit 660 ist eine programmierbare Ausführungseinheit, die konfiguriert ist, um unter Umwandlung von Fragmenten, die vom Rasterizer 665 empfangen werden, Fragmentshaderprogramme auszuführen, wie mittels der Fragmentshaderprogramme spezifiziert. Zum Beispiel mögen die Fragmentverarbeitungseinheit 660 und die Texture-Einheit 610 programmiert werden, um Operationen, wie Perspektivenkorrektur, Texture Mapping, Mipmap-Extrapolation, Shading, Blending und dergleichen durchzuführen, um schattierte Fragmente zu erzeugen, die an die Rasteroperationseinheit 665 ausgegeben werden. Die Fragmentverarbeitungseinheit 660 und die Texture-Einheit 610 können auch programmiert sein, um Texture-Filterungsoperationen, z. B. bilinear, trilinear, anisotrop und der gleichen, durchzuführen.
  • Die Fragmentverarbeitungseinheit 660 mag Daten, die im PP-Speicher 404 gespeichert sind, durch die Speicherschnittstelle 414 zur Verwendung bei der Verarbeitung der Fragmentdaten lesen. Die Speicherschnittstelle 414 erzeugt Leseaufforderungen für Daten, die im Grafikspeicher gespeichert sind, und dekomprimiert alle komprimierten Daten. Die Rasteroperationseinheit 665 ist eine Einheit mit fester Funktion, die optional Nah- und Fernebenen-Clipping d und Rasteroperationen, wie Stencil und Z Test und dergleichen durchführt und Pixeldaten als verarbeitete Grafikdaten zur Speicherung im Grafikspeicher ausgibt. Die verarbeiteten Grafikdaten mögen im Grafikspeicher zur Anzeige auf dem Anzeigegerät 310 gespeichert werden.
  • Texture-Einheit
  • 6B ist ein Blockdiagramm der Texture-Einheit 610 von 6A gemäß einem oder mehreren Aspekten der vorliegenden Erfindung. Die Texture-Einheit 610 weist eine LOD-Einheit 615, eine Texture-Abtastereinheit 620, eine Adresserzeugungseinheit 625 und eine Filtereinheit 630 auf. Die Texture-Einheit 610 empfängt Fragmentdaten zur Verarbeitung, einschließlich einer Texture-Mapkennung und Texture-Mapkoordinaten, z. B. s, t oder dergleichen. Die Texture-Mapkoordinaten werden mittels der LOD-Einheit 615 unter Verwendung von Techniken, die dem Fachmann bekannt sind, verarbeitet, um die ideale LOD zu bestimmen (Schritt 200 von 2A und 2C).
  • Die Anwendung spezifiziert den Filtertyp für jeden der Texture-Filter als Elemente der Texture-Bildzustands-Datenstruktur. Die Texture-Filter weisen diejenigen, die im Stand der Technik gebräuchlich sind (Vergrößerung und Verkleinerung) und zwei neue Texture-Filter auf: extrapolierte Vergrößerung und extrapolierte Verkleinerung. Die Filtertypen umfassen diejenigen, die im Stand der Technik gebräuchlich sind (nächster Nachbar, linear, mipmapped nächster Nachbar mit nächster Mipfilterung, mipmapped nächster Nachbar mit linearer Mipfilterung, mipmapped linear mit nächster Mipfilterung, mipmapped linear mit linearer Mipfilterung und transparent schwarz). Der transparent schwarze Filtertyp führt keine Filterung durch und gibt einfach R=G=B=A=0 zurück, was nützlich ist, wenn ein Prädikatwert oder Bedingungscode bewirkt, dass ein Shaderprogramm abwechselnde Arbeitsgänge durchführt. In der OpenGL Grafik-API (Applications Programming Interface – Anwendungsprogrammierschnittstelle) werden diese Filtertypen als GL_NEAREST, GL_LINEAR, GL_NEAREST_MIPMAP_NEAREST, GL_NEAREST_MIPMAP_LINEAR, GL_LINEAR_MIPMAP_NEAREST, GL_LINEAR_MIPMAP_LINEAR bezeichnet. Zusätzliche neue Filtertypen, die festgelegt werden mögen, um die Bildqualität für die extrapolierten Vergrößerungs- und extrapolierten Verkleinerungsfilter zu verbessern, sind: extrapoliert mipmapped nächster Nachbar und extrapoliert mipmapped linear.
  • Der Vorrichtungstreiber 322 stellt der LOD-Einheit 615 die Informationen bereit, die benötigt werden, um zu bestimmen, ob eine LOD zu einer residenten oder nicht residenten Mipmap korrespondiert. Diese Information ist die Extrapolationsschwellenwert-LOD, die in der Texture-Bild-Datenstruktur gespeichert und der LOD-Einheit 615 bereitgestellt wird. In der bevorzugten Ausführungsform der vorliegenden Erfindung ist die Extrapolationsschwellenwert-LOD eine reelle Zahl, die in der Texture-Bild-Datenstruktur gespeichert ist und die das Detaillevel (einschließlich der Nachkommastellenbits) darstellt, unter der die Extrapolationsvergrößerungs- oder Extrapolationsverkleinerungsfilterung ausgewählt wird. Die Extrapolationsschwellenwert-LOD ermöglicht dem Treiber 322 einen sanften Übergang von der extrapolierten Filterung zur interpolierten Filterung, anstatt abrupt auf eine neue residente Mipmap-Auflösung umzuschalten, wenn neue Mipmap-Level von nicht residenten Mipmaps in residente Mipmaps konvertiert werden. In einer alternativen Ausführungsform der vorliegenden Erfindung ist die Extrapolationsschwellenwert-LOD ein Integerwert, der die residente Mipmap-Stufe mit der niedrigsten LOD darstellt, die in der Texture-Bild-Datenstruktur gespeichert ist.
  • Die LOD-Einheit 615 führt den Schritt 210 (von 2A, 2B, und 2C) durch, indem sie die ideale LOD mit der Extrapolationsschwellenwert-LOD vergleicht, um auszuwählen, welches Texture-Filter, z. B. Vergrößerung, Verkleinerung, extrapolierte Vergrößerung oder extrapolierte Verkleinerung, durch die Texture-Abtastereinheit 620 verwendet wird, um das Texture-Bild abzutasten und zu filtern. Die LOD-Einheit 615 gibt das Texture-Filter, den ausgewählten Texture-Filtertyp, die ideale LOD, die Texture-Mapkoordinaten und andere Abtastparameter oder Samplingparameter, die im Stand der Technik gewöhnlich sind, an die Texture-Abtastereinheit 620 weiter. Zusätzlich gibt die LOD-Einheit 615 den Texture-Filtertyp und die Texture-Mapkennung an die Adresserzeugungseinheit 625 aus.
  • Wenn die LOD-Einheit 615 den für den extrapolierten Verkleinerungs- oder extrapolierten Vergrößerungs-Texture-Filter spezifiziert Texture-Filtertyp auswählt, dann benachrichtigt die LOD-Einheit 615 den Vorrichtungstreiber 322 (von 3) über die Host-Schnittstelle 406 (von 4), dass die Anwendung die Filterung der Texture-Elemente (Texel) von einer nichtresidenten Mipmap-Stufe angefordert hat und spezifiziert die angeforderte Mipmap-Stufe. Der Vorrichtungstreiber 322 leitet eine Konvertierung der nicht residenten Mipmap in eine residente Mipmap ein, wie in Verbindung mit 7 beschrieben.
  • Wenn der ausgewählte Texture-Filter eine extrapolierte Vergrößerung oder extrapolierte Verkleinerung ist, berechnet die Texture-Abtastereinheit 620 die DeltaLOD (Schritt 235 von 2A und 2C) mittels der Berechnung der Differenz zwischen der IdealLOD und der Extrapolationsschwellenwert-LOD. Die Texture-Abtastereinheit 620 berechnet dann das Extrapolationsgewicht als eine Funktion von DeltaLOD.
  • In einer Ausführungsform der vorliegenden Erfindung weist die Texture-Abtastereinheit 620 eine Gewichtstabelle 627 auf, die (LOD, Gewicht)-Paare aufweist, die in (von positiv zu negativ) abnehmender LOD-Reihenfolge gespeichert sind. Wenn DeltaLOD kleiner als der niedrigste LOD-Wert in der Gewichtstabelle 627 ist, dann wird der Gewichtswert vom Eintrag in der Tabelle mit der niedrigsten LOD als das Extrapolationsgewicht ausgewählt. Wenn DeltaLOD größer als der größte LOD-Wert in der Gewichtstabelle 627 ist, dann wird der Gewichtswert vom Eintrag in der Tabelle mit der größten LOD als das Extrapolationsgewicht ausgewählt. Wenn DeltaLOD gleich dem LOD-Wert eines Eintrags in der Gewichtstabelle 627 ist, dann wird der Gewichtswert dieses Eintrags als das Extrapolationsgewicht ausgewählt. In einigen Ausführungsformen der vorliegenden Erfindung wird, wenn DeltaLOD zwischen zwei Einträgen in der Gewichtstabelle 627 liegt, das Extrapolationsgewicht über lineare Interpolation unter Verwendung der zwei nächsten Gewichtswerte berechnet. In anderen Ausführungsformen der vorliegenden Erfindung wird, wenn DeltaLOD zwischen den LOD-Werten von zwei benachbarten Einträgen in der Gewichtstabelle 627 liegt, das Extrapolationsgewicht unter Verwendung eines kubischen Catmull-Rom-Splines oder irgendeines anderen interpolierenden Splines berechnet, der dem Fachmann bekannt ist.
  • In einigen Ausführungsformen der vorliegenden Erfindung sind die Inhalte der Gewichtstabelle 627 statisch. In anderen Ausführungsformen der vorliegenden Erfindung lädt der Vorrichtungstreiber 322 die Gewichtstabelle 627 gemäß einem Extrapolationsfilter, der durch ein Anwendungsprogramm spezifiziert wird. In anderen Ausführungsformen der vorliegenden Erfindung lädt der Vorrichtungstreiber 322 die Gewichtstabelle 627 (oder separate Gewichtstabellen für extrapolierte Vergrößerung und extrapolierte Verkleinerung) in die Texture-Abtaster-Datenstruktur. Die Texture-Abtaster-Datenstruktur mag in Registern innerhalb der PPU 402 gespeichert werden oder die Texture-Abtastungs-Datenstruktur mag im PP-Speicher 404 gespeichert und innerhalb der PPU 402 zwischengespeichert werden.
  • Wenn die ideale LOD einem residenten Mipmap-Level oder Mipmap-Stufe entspricht, dann wählt die Texture-Abtastereinheit 620 die feine/n (und falls notwendig, die grobe/n) Mipmap-Stufe/n aus und tastet die Pixelgröße auf der/den ausgewählten Mipmap-Stufe/n unter Verwendung des ausgewählten Texture-Filtertyps und unter Verwendung von Techniken, die dem Fachmann bekannt sind, ab, um einen interpolierten Texture-Elementwert zu erzeugen. Das LOD-Gewicht entspricht dem Nachkommaanteil der idealen LOD. Wenn die ideale LOD einer nicht residenten Mipmap-Stufe entspricht, dann truncated die Texture-Aabtastereinheit 620 den Extrapolationsschwellenwert (der gewöhnlich die niedrigste residente LOD Mipmap-Stufe und die residente Mipmap-Stufe mit der höchsten Auflösung ist), um einen Integeranteil des Extrapolationsschwellenwerts zu erzeugen. Der Integeranteil ist die LOD der feinen Mipmap-Stufe (LODfein) und die feine Mipmap-Stufe + 1 (die gewöhnlich die zweitniedrigste residente LOD-Mipmap-Stufe und die residente Mipmap mit der nächsthöchsten Auflösung ist) ist die LOD der groben Mipmap-Stufe (LODgrob).
  • Wenn der Filtertyp extrapoliert mipmapped nächster Nachbar ist, tastet die Texture-Abtastereinheit 620 die Pixelgröße (pixel footprint) im Texture-Raum ab, wobei sie Abtastungen des nächsten Nachbarn auf den Mip-Stufen LODfein und LODgrob (die der niedrigstenResidentenMipmap und der niedrigstenResidenteMipmap + 1 entsprechen) an die Adresserzeugungseinheit 625 ausgibt. Wenn der Filtertyp extrapoliert mipmapped linear ist, tastet die Texture-Abtastereinheit 620 die Pixelgröße im Texture-Raum ab, wobei sie Abtastungen auf den Mipmap-Stufen LODfein und LODgrob (die der niedrigstenResidentenMipmap und der niedrigstenResidentenMipmap + 1 entsprechen) an die Adresserzeugungseinheit 625 ausgibt. Die Texture-Abtastereinheit 620 verwendet das 1 + Extrapolationsgewicht als das LOD-Gewicht zum Abtasten der Mip-Stufe LODfein und -Extrapolationsgewicht als das LOD-Gewicht zur Abtastung der Mip-Stufe LODgrob, wenn der Filtertyp extrapoliert mipmapped linear oder extrapoliert mipmapped nächster Nachbar ist.
  • Der ausgewählte Filtertyp, das LOD-Gewicht, das anisotrope Gewicht, die feine Mipmap-LOD-Stufe (LODfein), die grobe Mipmap-LOD-Stufe (LODgrob) und Abtastungen (die den Texture-Mapkoordinaten und dem ausgewählten Filtertyp entsprechen) werden mittels der Texture-Abtastereinheit 620 an die Adresserzeugungseinheit 625 ausgegeben. Die Adresserzeugungseinheit 625 erzeugt uv-Gewichte (bilinear oder nächster Nachbar) für jedes Texture-Element gemäß dem ausgewählten Filtertyp unter Verwendung von Techniken, die dem Fachmann bekannt sind. Wenn der Filtertyp der Abtastung für die Texture-Elemente extrapoliert mipmapped linear ist, berechnet die Adresserzeugungseinheit 625 bilineare (u,v) Gewichte für die Texture-Elemente innerhalb jeder Abtastung. Wenn der Filtertyp der Abtastung extrapoliert mipmapped nächster Nachbar ist, berechnet die Adresserzeugungseinheit 625 innerhalb jeder Abtastung für die Texture-Elemente Gewichte des nächsten Nachbarn. Die Adresserzeugungseinheit 625 verwendet die Abtastungen, Texture-Mapkennung, LODfein und LODgrob zum Bestimmen von Adressen zum Lesen von Texture-Elementen von den residenten Mipmaps. Wenn virtuelle Speicheradressierung verwendet wird, mag mittels der Speicherschnittstelle 414 eine zusätzliche Adresskonvertierung vorgenommen werden, um die physikalischen Adressen zu bestimmen, die zum Lesen der Texture-Elemente benötigt werden.
  • In einer Ausführungsform der vorliegenden Erfindung ist jedes Texture-Elementgewicht, das zum Skalieren eines aus einer Mipmap gelesenen Texture-Elements verwendet wird, die Kombination des LOD-Gewichts, der Mip-Stufe des Texture-Elements, des anisotropen Filtergewichts für die Größe (Anisogewicht), und der uv-Gewichte. Die Adresserzeugungseinheit 625 berechnet ein Texture-Elementgewicht mittels Multiplikation des LOD-Gewichts mit dem Anisogewicht und mit dem uv-Gewicht des Texture-Elements und gibt das Ergebnis an die Texture-Filtereinheit 630 weiter. Die Texture-Elemente werden an die Filtereinheit 630 zurückgegeben und durch die mittels der Adresserzeugungseinheit 625 berechneten Texture-Elementgewichte skaliert.
  • In Ausführungsformen der vorliegenden Erfindung mit Filtergewichten, die zu Eins summieren, kumuliert die Filtereinheit 630 die skalierten Texture-Elementwerte in ein Texture-Farben-Akkumulatorregister. Wenn das letzte Texture-Element des letzten Pixels gewichtet und kumuliert wurde, gibt die Texture-Einheit 610 die Inhalte des Texture-Farben-Akkumulatorregisters an die Fragmentverarbeitungseinheit 660 zurück. In Ausführungsformen der vorliegenden Erfindung mit Filtergewichten, die nicht zu Eins summieren, kumuliert die Filtereinheit 630 die skalierten Texture-Elementwerte in ein Texture-Farben-Akkumulatorregister und kumuliert die Texture-Elementgewichte in ein Texture-Gewicht-Akkumulatorregister. Wenn das letzte Texture-Element gewichtet und kumuliert wurde, teilt die Filtereinheit 630 die Inhalte des Farb-Akkumulatorregisters durch die Inhalte des Gewichtakkumulatorregisters und gibt den resultierenden gefilterten Texture-Wert an die Fragmentverarbeitungseinheit 660 zurück.
  • Die Textureinheit 610 kann konfiguriert sein, um Statusinformationen pro Pixel auf eine Weise zurückzugeben, auf die vorteilhafterweise mittels des Pixelshaderprogramms zur Auswahl der Bedingungsausführungspfade zugegriffen werden kann. In einer Ausführungsform der vorliegenden Erfindung kann die Texture-Einheit 610 pro Pixel liefern, ob der Vorgang des Texturierens des Pixels von der Texture-Einheit 610 die Verwendung von Extrapolationsfilterung erforderte und die resultierenden Werte stellen Prädikat- oder Bedingungscodes ein, die verwendet werden können, um das anschließende Zweigverhalten im Pixelshaderprogramm zu bestimmen. Das Shaderprogramm kann Texture-Elemente von nicht residenten Mipmaps bedingungsweise mit zusätzlichen Texture-Lesungen von der gleichen Texture handhaben, um kubische Filterung durchzuführen, oder Texture-Lesungen von anderen Texturen herausgeben, um synthetische Einzelheiten hinzuzufügen oder andere Operationen durchzuführen.
  • 7 ist ein Ablaufdiagramm von Verfahrensschritten zum Konvertieren einer nicht residenten Mipmap-Stufe in eine residente Mipmap-Stufe gemäß einem oder mehreren Aspekten der vorliegenden Erfindung. In Schritt 700 empfängt der Vorrichtungstreiber 322 eine Aufforderung zum Konvertieren einer nicht residenten Mipmap in eine residente Mipmap. In Schritt 710 leitet der Vorrichtungstreiber 322 eine Kopie der nicht residenten Mipmap in einen residenten Speicher ein, auf den mittels der Texture-Einheit 610 zugegriffen werden kann, wie der PP-Speicher 404. In Schritt 720 bestimmt der Vorrichtungstreiber 322, ob die Konvertierung abgeschlossen ist, d. h. ob die Mipmap kopiert wurde und, wenn nicht, wird Schritt 720 wiederholt. In einigen Ausführungsformen der vorliegenden Erfindung mag ein Ressourcenmanager angeben, wann die residente Mipmap-Stufe mit der höchsten Auflösung sich geändert hat, um zu bestätigen, dass die Kopie der nicht residenten Mipmap abgeschlossen wurde.
  • Nachdem die Mipmap kopiert wurde, aktualisiert der Vorrichtungstreiber 322 in Schritt 730 die Extrapolationsschwellenwert-LOD. In einigen Ausführungsformen der vorliegenden Erfindung wird der Extrapolationsschwellenwert mit dem Wert aktualisiert, um der niedrigsten residenten Mipmap-Stufe zu gleichen. In anderen Ausführungsformen der vorliegenden Erfindung wird die Extrapolationsschwellenwert-LOD für einen sanften Übergang über mehrere Frames von extrapolierter Filterung zu interpolierter Filterung verringert, anstatt abrupt in eine neue residente Mipmap-Auflösung zu schalten, und die nicht residente Mipmap-Stufe wird in eine residente Mipmap-Stufe konvertiert. Zum Beispiel mag eine Extrapolationsschwellenwert-LOD von 3,0 schrittweise um 0,1 vermindert werden, bis ein Wert 2,0 erreicht wird, der gleich der niedrigsten residenten Mipmap-Stufe ist. In Schritt 740 bestimmt der Vorrichtungstreiber 322, ob der Endwert der Extrapolationsschwellenwert-LOD erreicht wurde und, wenn nicht, wird Schritt 730 wiederholt. Andernfalls ist in Schritt 750 die Konvertierung der nicht residenten Mipmap-Stufe abgeschlossen.
  • Wenn die Extrapolationsfilterung aktiviert ist und die Texture-Elemente, die zur Filterung erforderlich sind, von nicht residenten Mipmap-Stufen kommen, stellen die Texture-Elemente, die unter Verwendung von extrapolierter Filterung erzeugt wurden, ein verbessertes Bild bereit, das im Verhältnis zur Differenz zwischen der idealen Mip-Stufe und der residenten Mip-Stufe schärfer erscheint. Dies fördert einen zweckmäßigeren Detailgrad im Vergleich zur Verwendung der vorhandenen Texture-Daten der Mipmap mit der niedrigen Auflösung anstatt der Mipmap-Texture-Daten mit der hohen Auflösung. Das Parallel verarbeitungs-Teilsystem 312 ist konfiguriert, um parallel Einzelheiten von residenten Mipmaps zur Verarbeitung mehrerer Threads zur Erzeugung von extrapolierten Texture-Werten zu extrapolieren, während Mipmaps mit hoher Auflösung, z. B. die nicht residenten Mipmaps 325 und 335, vom nicht residenten Speicher, z. B. der Systemplatte 314, dem Systemspeicher 304 und dergleichen abgerufen werden.
  • Eine Ausführungsform der Erfindung mag als ein Programmprodukt zur Verwendung mit einem Computersystem ausgeführt werden. Das/die Programm/e des Programmprodukts definieren Funktionen der Ausführungsformen (einschließlich der hierin beschriebenen Verfahren) und können auf einer Vielzahl von maschinenlesbaren Speichermedien enthalten sein. Veranschaulichende maschinenlesbare Speichermedien umfassen: (i) nicht beschreibbare Speichermedien (z. B. Nurlesespeicher in einem Computer wie CD-ROMs, die durch ein CD-ROM-Laufwerk gelesen werden können, Flash-Speicher, ROM-Chips oder jegliche Typen von nicht flüchtigen Festkörper-Halbleiterspeichern), auf denen Informationen dauerhaft gespeichert sind; und (ii) beschreibbare Speichermedien (z. B. Floppy-Disks in einem Diskettenlaufwerk oder Festplattenlaufwerke jeglichen Typs von Festkörper-Halbleiterspeichern mit wahlfreiem Zugriff), auf denen veränderliche Informationen gespeichert werden.

Claims (6)

  1. Verfahren zur Extrapolation von nicht residenten Mipmap-Levels einer Texture-Map unter Verwendung residenter Mipmap-Levels der Texture-Map, welches aufweist: Empfangen einer Aufforderung zum Konvertieren eines nicht residenten Mipmap-Levels in ein residentes Mipmap-Level zur Verwendung beim Rendering eines Bildes zur Anzeige; Einleiten einer Kopie des nicht residenten Mipmap-Levels von einem nicht residenten Speicher in einen residenten Speicher; Verwenden eines Werts eines Detaillevel-Extrapolationsschwellenwertes zum Erzeugen von gefilterten Texture-Elementwerten des Bildes; und Updaten eines Werts des Detaillevel-Extrapolationsschwellenwertes, wenn die Kopie der nicht residenten Mipmap-Levels abgeschlossen ist, wobei der Schritt des Updatens ein sukzessives Vermindern des Wertes des Detaillevel-Extrapolationsschwellenwertes über eine Mehrzahl von Frames für einen sanften Übergang von extrapolierter Filterung zu interpolierter Filterung aufweist bis ein Endwert erreicht wird, der gleich oder größer als ein Detaillevel-Wert des nicht residenten Mipmap-Levels ist, um sanft von der Verwendung von extrapolierter Filterung zur Verwendung von interpolierter Filterung zum Erzeugen der extrapolierten Texture-Elementwerte überzugehen.
  2. Verfahren gemäß Anspruch 1, das ferner den Schritt des Ladens einer Gewichtstabelle aufweist, die ein Extrapolationsfilter mit DeltaLOD-Gewichtspaaren repräsentiert, wobei jeder Eintrag in der Gewichtstabelle ein Extrapolationsgewicht und einen korrespondierenden DeltaLOD-Wert aufweist, wobei der DeltaLOD-Wert eine Differenz zwischen einem idealen Detaillevel und einem Detaillevel-Extrapolationsschwellenwert aufweist.
  3. Verfahren gemäß Anspruch 2, wobei die Gewichtstabelle das Extrapolationsfilter für ein extrapoliertes Verkleinerungs-Texture-Filter repräsentiert, und das ferner den Schritt des Ladens einer zusätzlichen Gewichtstabelle aufweist, die ein Extrapolationsfilter für ein extrapoliertes Vergrößerungs-Texture-Filter repräsentiert.
  4. Verfahren gemäß einem der Ansprüche 1 bis 3, das ferner die folgenden Schritte aufweist: Berechnen eines idealen Detaillevels, der zu einer idealen Mipmap der Texture-Map korrespondiert; Berechnen einer DeltaLOD als eine Differenz zwischen dem idealen Detaillevel und dem Detaillevel-Extrapolationsschwellenwert; und Bestimmen eines Extrapolationsgewichts auf der Grundlage der DeltaLOD.
  5. Verfahren nach Anspruch 4, das ferner den Schritt des Berechnens der gefilterten Texture-Elementwerte des Bildes unter Verwendung des Extrapolationsgewichts, der Texture-Elementwerte von einer Mipmap, deren Detaillevel gleich einem Integeranteil des Detaillevel-Extrapolationsschwellenwerts ist, und der Texture-Elementwerte von einem residenten Mipmap-Level mit niedrigerer Auflösung aufweist.
  6. Maschinenlesbares Medium, das Befehle aufweist, welche, wenn auf einem Computersystem ausgeführt, das Computersystem steuern, nicht residente Mipmap-Levels einer Texture-Map unter Verwendung residenter Mipmap-Levels der Texture-Map gemäß einem der vorangehenden Ansprüche zu extrapolieren.
DE102008026431.8A 2007-06-07 2008-06-02 Extrapolation von nicht residenten Mipmap-Daten unter Verwendung residenter Mipmap-Daten Active DE102008026431B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/759,598 2007-06-07
US11/759,598 US7948500B2 (en) 2007-06-07 2007-06-07 Extrapolation of nonresident mipmap data using resident mipmap data

Publications (2)

Publication Number Publication Date
DE102008026431A1 DE102008026431A1 (de) 2009-01-08
DE102008026431B4 true DE102008026431B4 (de) 2014-06-12

Family

ID=40092691

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102008026431.8A Active DE102008026431B4 (de) 2007-06-07 2008-06-02 Extrapolation von nicht residenten Mipmap-Daten unter Verwendung residenter Mipmap-Daten

Country Status (6)

Country Link
US (1) US7948500B2 (de)
JP (1) JP4799588B2 (de)
KR (1) KR100965637B1 (de)
CN (1) CN101344961B (de)
DE (1) DE102008026431B4 (de)
TW (1) TWI377520B (de)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7944453B1 (en) * 2007-06-07 2011-05-17 Nvidia Corporation Extrapolation texture filtering for nonresident mipmaps
WO2009113034A1 (en) * 2008-03-12 2009-09-17 Nxp B.V. Look-ahead task management
US8217957B1 (en) * 2008-05-01 2012-07-10 Rockwell Collins, Inc. System and method for digital image storage and representation
KR20100046797A (ko) * 2008-10-28 2010-05-07 삼성전자주식회사 텍스쳐 팩터를 이용한 3차원 그래픽 데이터 처리 장치 및 그 방법
KR101508388B1 (ko) * 2008-12-15 2015-04-06 엘지전자 주식회사 밉맵 생성 장치 및 방법
US9013498B1 (en) * 2008-12-19 2015-04-21 Nvidia Corporation Determining a working set of texture maps
GB2469526B (en) * 2009-04-17 2015-06-24 Advanced Risc Mach Ltd Generating and resolving pixel values within a graphics processing pipeline
US8681169B2 (en) * 2009-12-31 2014-03-25 Nvidia Corporation Sparse texture systems and methods
US8823724B2 (en) * 2009-12-31 2014-09-02 Nvidia Corporation Sparse texture systems and methods
US8860743B2 (en) * 2009-12-31 2014-10-14 Nvidia Corporation Sparse texture systems and methods
US8610737B2 (en) * 2010-05-27 2013-12-17 National Taiwan University Graphic processing unit (GPU) with configurable filtering module and operation method thereof
US9727385B2 (en) 2011-07-18 2017-08-08 Apple Inc. Graphical processing unit (GPU) implementing a plurality of virtual GPUs
US20130063462A1 (en) * 2011-09-08 2013-03-14 Microsoft Corporation Tile-based image processing using mipmaps
KR101926570B1 (ko) 2011-09-14 2018-12-10 삼성전자주식회사 포스트 프레그먼트 쉐이더를 사용하는 그래픽 처리 방법 및 장치
US8274524B1 (en) * 2011-09-28 2012-09-25 Google Inc. Map rendering using interpolation of style parameters across zoom levels
SG10201604445RA (en) * 2011-12-01 2016-07-28 Univ Singapore Polymorphic heterogeneous multi-core architecture
US8654124B2 (en) 2012-01-25 2014-02-18 Google Inc. Texture fading for smooth level of detail transitions in a graphics application
CN102799456B (zh) * 2012-07-24 2015-11-25 上海晨思电子科技有限公司 一种游戏引擎加载资源文件的方法、装置和计算机
US9111393B2 (en) * 2012-11-26 2015-08-18 Nvidia Corporation System, method, and computer program product for sampling a hierarchical depth map
US9349210B2 (en) * 2012-11-30 2016-05-24 Arm Limited Methods of and apparatus for using textures in graphics processing systems
US9659401B2 (en) 2012-11-30 2017-05-23 Arm Limited Methods of and apparatus for using textures in graphics processing systems
US9734598B2 (en) * 2013-01-15 2017-08-15 Microsoft Technology Licensing, Llc Engine for streaming virtual textures
US9165396B2 (en) * 2013-02-26 2015-10-20 Nvidia Corporation Graphics processing unit with a texture return buffer and a texture queue
US9767595B2 (en) 2013-05-02 2017-09-19 Arm Limited Graphics processing systems
US9741089B2 (en) 2013-05-02 2017-08-22 Arm Limited Graphics processing systems
US9070200B2 (en) 2013-05-02 2015-06-30 Arm Limited Graphics processing systems
US9607356B2 (en) 2013-05-02 2017-03-28 Arm Limited Graphics processing systems
US9626789B2 (en) * 2013-05-07 2017-04-18 Advanced Micro Devices, Inc. Implicit texture map parameterization for GPU rendering
US9542724B1 (en) * 2013-07-09 2017-01-10 Google Inc. Systems and methods for stroke rendering on digital maps
CN104331527B (zh) * 2013-07-22 2018-10-02 腾讯科技（深圳）有限公司 图片生成方法及装置
US9514563B2 (en) 2013-08-30 2016-12-06 Arm Limited Graphics processing systems
US20150279055A1 (en) * 2014-03-28 2015-10-01 Nikos Kaburlasos Mipmap compression
US9652882B2 (en) * 2014-04-05 2017-05-16 Sony Interactive Entertainment America Llc Gradient adjustment for texture mapping for multiple render targets with resolution that varies by screen location
US9495767B2 (en) 2014-05-15 2016-11-15 Google Inc. Indexed uniform styles for stroke rendering
KR20160032597A (ko) * 2014-09-16 2016-03-24 삼성전자주식회사 텍스쳐를 처리하는 방법 및 장치
US9934606B2 (en) * 2014-09-16 2018-04-03 Intel Corporation Deferred coarse pixel shading
KR102313020B1 (ko) 2014-11-27 2021-10-15 삼성전자주식회사 그래픽스 프로세싱 유닛과 이를 포함하는 장치
CN105574808B (zh) * 2015-12-11 2018-10-26 中国航空工业集团公司西安航空计算技术研究所 一种流水线纹理贴图单元系统
CN105957133B (zh) * 2016-05-10 2018-06-05 网易（杭州）网络有限公司 一种加载贴图的方法和装置
KR20180048081A (ko) * 2016-11-02 2018-05-10 삼성전자주식회사 텍스쳐 처리 방법 및 장치
GB2557657B (en) * 2016-12-14 2020-08-12 Samsung Electronics Co Ltd Mipmap rendering
US10460502B2 (en) 2016-12-14 2019-10-29 Samsung Electronics Co., Ltd. Method and apparatus for rendering object using mipmap including plurality of textures
CN106875483A (zh) * 2017-01-26 2017-06-20 北京航空航天大学 一种直升机地震救援仿真场景模块化构建方法和系统
US9990909B1 (en) 2017-07-12 2018-06-05 Rtom Corporation Cymbal
KR102489266B1 (ko) * 2018-08-13 2023-01-17 엘지전자 주식회사 모바일 디바이스 및 그 제어 방법
CN111311720B (zh) * 2018-12-12 2023-05-23 网易（杭州）网络有限公司 一种纹理图像的处理方法和装置
US11164293B2 (en) * 2019-01-30 2021-11-02 National Cheng Kung University Adaptive enhancement method for image contrast based on level of detail
GB2583154B (en) * 2019-10-17 2021-04-28 Imagination Tech Ltd Texture filtering
CN111179403A (zh) * 2020-01-21 2020-05-19 南京芯瞳半导体技术有限公司 并行生成纹理映射Mipmap图像的方法、装置及计算机存储介质
US11915337B2 (en) * 2020-03-13 2024-02-27 Advanced Micro Devices, Inc. Single pass downsampler
US20210304488A1 (en) * 2020-03-25 2021-09-30 Advanced Micro Devices, Inc. Sampling for partially resident textures
US20210312592A1 (en) * 2020-04-02 2021-10-07 Sony Corporation Super-resolution of block-compressed texture for texture mapping applications
US11158110B1 (en) 2021-01-06 2021-10-26 Arm Limited Graphics texture mapping
CN113450444B (zh) * 2021-07-09 2023-03-24 网易（杭州）网络有限公司 生成光照贴图的方法、装置、存储介质及电子设备
GB2610371A (en) * 2021-07-22 2023-03-08 Imagination Tech Ltd Texture filtering

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5438654A (en) * 1993-07-09 1995-08-01 Silicon Graphics, Inc. System and method for sharpening texture imagery in computer generated interactive graphics
US6522337B1 (en) * 1999-07-08 2003-02-18 Sega Enterprises, Ltd. Image processing apparatus, image processing method, and recording medium
US6744438B1 (en) * 1999-06-09 2004-06-01 3Dlabs Inc., Ltd. Texture caching with background preloading
US7061500B1 (en) * 1999-06-09 2006-06-13 3Dlabs Inc., Ltd. Direct-mapped texture caching with concise tags

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU6766096A (en) 1995-08-04 1997-03-05 Microsoft Corporation Method and system for rendering graphical objects to image chunks and combining image layers into a display image
US5943242A (en) 1995-11-17 1999-08-24 Pact Gmbh Dynamically reconfigurable data processing system
US7266725B2 (en) 2001-09-03 2007-09-04 Pact Xpp Technologies Ag Method for debugging reconfigurable architectures
DE19651075A1 (de) 1996-12-09 1998-06-10 Pact Inf Tech Gmbh Einheit zur Verarbeitung von numerischen und logischen Operationen, zum Einsatz in Prozessoren (CPU's), Mehrrechnersystemen, Datenflußprozessoren (DFP's), digitalen Signal Prozessoren (DSP's) oder dergleichen
DE19654595A1 (de) 1996-12-20 1998-07-02 Pact Inf Tech Gmbh I0- und Speicherbussystem für DFPs sowie Bausteinen mit zwei- oder mehrdimensionaler programmierbaren Zellstrukturen
DE19654593A1 (de) 1996-12-20 1998-07-02 Pact Inf Tech Gmbh Umkonfigurierungs-Verfahren für programmierbare Bausteine zur Laufzeit
US6338106B1 (en) 1996-12-20 2002-01-08 Pact Gmbh I/O and memory bus system for DFPS and units with two or multi-dimensional programmable cell architectures
DE19704728A1 (de) 1997-02-08 1998-08-13 Pact Inf Tech Gmbh Verfahren zur Selbstsynchronisation von konfigurierbaren Elementen eines programmierbaren Bausteines
US6542998B1 (en) 1997-02-08 2003-04-01 Pact Gmbh Method of self-synchronization of configurable elements of a programmable module
DE19704742A1 (de) 1997-02-11 1998-09-24 Pact Inf Tech Gmbh Internes Bussystem für DFPs, sowie Bausteinen mit zwei- oder mehrdimensionalen programmierbaren Zellstrukturen, zur Bewältigung großer Datenmengen mit hohem Vernetzungsaufwand
DE19861088A1 (de) 1997-12-22 2000-02-10 Pact Inf Tech Gmbh Verfahren zur Reparatur von integrierten Schaltkreisen
DE19807872A1 (de) 1998-02-25 1999-08-26 Pact Inf Tech Gmbh Verfahren zur Verwaltung von Konfigurationsdaten in Datenflußprozessoren sowie Bausteinen mit zwei- oder mehrdimensionalen programmierbaren Zellstruktur (FPGAs, DPGAs, o. dgl.
US6373496B1 (en) * 1998-08-12 2002-04-16 S3 Graphics Co., Ltd. Apparatus and method for texture mapping
AU5688199A (en) * 1998-08-20 2000-03-14 Raycer, Inc. System, apparatus and method for spatially sorting image data in a three-dimensional graphics pipeline
US6452603B1 (en) * 1998-12-23 2002-09-17 Nvidia Us Investment Company Circuit and method for trilinear filtering using texels from only one level of detail
US7003660B2 (en) 2000-06-13 2006-02-21 Pact Xpp Technologies Ag Pipeline configuration unit protocols and communication
JP2001005950A (ja) 1999-06-21 2001-01-12 Fuji Photo Film Co Ltd 画像サーバ装置および画像転送方法
US7210129B2 (en) 2001-08-16 2007-04-24 Pact Xpp Technologies Ag Method for translating programs for reconfigurable architectures
US7444531B2 (en) 2001-03-05 2008-10-28 Pact Xpp Technologies Ag Methods and devices for treating and processing data
RU2216781C2 (ru) * 2001-06-29 2003-11-20 Самсунг Электроникс Ко., Лтд Основанные на изображениях способ представления и визуализации трехмерного объекта и способ представления и визуализации анимированного объекта
US20030030646A1 (en) * 2001-08-10 2003-02-13 Yeh Kwo-Woei Trilinear texture filtering method with proper texel selection
US7434191B2 (en) 2001-09-03 2008-10-07 Pact Xpp Technologies Ag Router
WO2003054796A2 (en) * 2001-12-20 2003-07-03 Koninklijke Philips Electronics N.V. Image rendering apparatus and method using mipmap texture mapping
CN1659620B (zh) 2002-04-11 2010-04-28 格诺色彩技术有限公司 具有增强的属性的彩色显示装置和方法
JP4024072B2 (ja) 2002-04-18 2007-12-19 株式会社タイトー ミップマップデータの高速読出方式
JP2004078296A (ja) 2002-08-09 2004-03-11 Victor Co Of Japan Ltd 画像生成装置
AU2003289844A1 (en) 2002-09-06 2004-05-13 Pact Xpp Technologies Ag Reconfigurable sequencer structure
EP1494175A1 (de) * 2003-07-01 2005-01-05 Koninklijke Philips Electronics N.V. Auswahl eines Mip-Map-Niveaus
JP4170283B2 (ja) 2004-11-01 2008-10-22 株式会社ソニー・コンピュータエンタテインメント 描画処理装置および描画処理方法
JP2006244426A (ja) 2005-03-07 2006-09-14 Sony Computer Entertainment Inc テクスチャ処理装置、描画処理装置、およびテクスチャ処理方法
KR100601880B1 (ko) 2005-04-27 2006-07-18 에스케이 텔레콤주식회사 Ｇｐｕ를 이용하여 실시간 ３차원 그래픽 이미지를점진적으로 전송하는 방법
US7372468B1 (en) * 2005-10-11 2008-05-13 Nvidia Corporation Anisotropic texture filtering with a modified number of texture samples
CN100468461C (zh) * 2005-11-10 2009-03-11 北京航空航天大学 逼真三维地形几何模型的实时绘制方法
US7561156B2 (en) * 2006-02-08 2009-07-14 INOVO Limited Adaptive quadtree-based scalable surface rendering
US7528551B2 (en) * 2007-02-26 2009-05-05 Semiconductor Components Industries, L.L.C. LED control system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5438654A (en) * 1993-07-09 1995-08-01 Silicon Graphics, Inc. System and method for sharpening texture imagery in computer generated interactive graphics
US6744438B1 (en) * 1999-06-09 2004-06-01 3Dlabs Inc., Ltd. Texture caching with background preloading
US7061500B1 (en) * 1999-06-09 2006-06-13 3Dlabs Inc., Ltd. Direct-mapped texture caching with concise tags
US6522337B1 (en) * 1999-07-08 2003-02-18 Sega Enterprises, Ltd. Image processing apparatus, image processing method, and recording medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
OpenGL on Silicon Graphics Systems. Manual, Silicon Graphics, publiziert am 31.3.2005, Kapitel 8, S. 149-201, URL: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=bks&fname=/SGI_Developer/OpenGLonSGI/front.html ,[recherchiert am 29.11.2012]. *

Also Published As

Publication number Publication date
DE102008026431A1 (de) 2009-01-08
JP4799588B2 (ja) 2011-10-26
JP2008305408A (ja) 2008-12-18
TWI377520B (en) 2012-11-21
KR100965637B1 (ko) 2010-06-23
US7948500B2 (en) 2011-05-24
CN101344961B (zh) 2011-06-15
KR20080108051A (ko) 2008-12-11
US20080303841A1 (en) 2008-12-11
TW200905608A (en) 2009-02-01
CN101344961A (zh) 2009-01-14

Similar Documents

Publication Publication Date Title
DE102008026431B4 (de) Extrapolation von nicht residenten Mipmap-Daten unter Verwendung residenter Mipmap-Daten
DE102009039231B4 (de) Einzeldurchgang-Kachelung
DE102013017639B4 (de) Zwischenspeicherung von adaptiv dimensionierten Cache-Kacheln in einem vereinheitlichten L2-Cache-Speicher mit Oberflächenkomprimierung
DE60004827T2 (de) Segmentierung von komprimierten graphischen daten zur parallelen dekomprimierung und darstellung
DE102013114279B4 (de) Oberflächenverarbeitung mit Mehrfachabtastung unter Verwendung einer einzelnen Abtastung
DE112006003473B4 (de) Parallel-Array-Architektur für einen Grafikprozessor
US7184041B2 (en) Block-based fragment filtration with feasible multi-GPU acceleration for real-time volume rendering on conventional personal computer
DE102014004841B4 (de) Grafik auf Kachelbasis
DE102018113845A1 (de) Systeme und Verfahren zum Trainieren von neuronalen Netzwerken mit dünnbesetzten Daten
DE102017124573A1 (de) Systeme und verfahren zum beschneiden von neuronalen netzen für eine betriebsmitteleffiziente folgerung
US20070171234A1 (en) System and method for asynchronous continuous-level-of-detail texture mapping for large-scale terrain rendering
DE19709227B4 (de) Verfahren zum schnellen Herunterladen von Texturen auf eine Hardware für beschleunigte Graphiken und zur Beseitigung von zusätzlichen Softwarekopien von Texeln
DE102013020614A1 (de) Mit Mehrfachauflösung konsistente Rastereinteilung
DE102013020613A1 (de) Umgehung der Pixel-Schattierung für die grafische Bilderzeugung mit geringer Leistung
DE102015113240A1 (de) System, verfahren und computerprogrammprodukt für schattierung unter verwendung eines dynamischen objektraumgitters
DE102018120859A1 (de) Inline-Dateninspektion zur Arbeitslastvereinfachung
DE102013020810A1 (de) Effiziente Super-Abtastung mit Schattierungs-Strängen pro Pixel
DE102013222685B4 (de) System, Verfahren und Computer-Programm-Produkt zum Abtasten einer hierarchischen Tiefe-Karte
DE102010025310A1 (de) Textursampling
DE102016122297A1 (de) Mehrfach-Durchlauf-Rendering in einer Bildschirm-Raum-Pipeline
DE102013020807A1 (de) Handhabung von nachgeordneten Z-Abdeckungsdaten in Rasteroperationen
DE102013218594A1 (de) System, Verfahren und Computerprogrammprodukt zur parallelen Rekonstruktion eines gesampelten Suffixarrays
DE69631718T2 (de) Verfahren und Gerät zur leistungsfähigen Graphikdarstellung dreidimensionaler Szenen
DE102013018136A1 (de) Technik zur Speicherung gemeinsamer Vertices
DE102018125295A1 (de) Vorrichtung und Verfahren zum Ausführen eines kachelbasierten Renderns unter Verwendung von vorabgerufenen Grafikdaten

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R020 Patent grant now final

Effective date: 20150313

R082 Change of representative

Representative=s name: KRAUS & WEISERT PATENTANWAELTE PARTGMBB, DE