DE69635009T2 - Programmunterbrechung durch einen Pufferspeicher um Texturabbildungsdaten in einem virtuellen Speicher zu verwalten - Google Patents

Programmunterbrechung durch einen Pufferspeicher um Texturabbildungsdaten in einem virtuellen Speicher zu verwalten Download PDF

Info

Publication number
DE69635009T2
DE69635009T2 DE69635009T DE69635009T DE69635009T2 DE 69635009 T2 DE69635009 T2 DE 69635009T2 DE 69635009 T DE69635009 T DE 69635009T DE 69635009 T DE69635009 T DE 69635009T DE 69635009 T2 DE69635009 T2 DE 69635009T2
Authority
DE
Germany
Prior art keywords
texture
data
cache
block
texel
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.)
Expired - Fee Related
Application number
DE69635009T
Other languages
English (en)
Other versions
DE69635009D1 (de
Inventor
Ethan W. Gannett
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.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
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 Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Application granted granted Critical
Publication of DE69635009D1 publication Critical patent/DE69635009D1/de
Publication of DE69635009T2 publication Critical patent/DE69635009T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0844—Multiple simultaneous or quasi-simultaneous cache accessing
    • G06F12/0846—Cache with multiple tag or data arrays being simultaneously accessible
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0875—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with dedicated cache, e.g. instruction or stack
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12—Replacement control
    • G06F12/121—Replacement control using replacement algorithms
    • G06F12/123—Replacement control using replacement algorithms with age lists, e.g. queue, most recently used [MRU] list or least recently used [LRU] list
    • 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
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0864—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches using pseudo-associative means, e.g. set-associative or hashing

Description

  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich allgemein auf eine Software-Speicherverwaltung von Texturabbildungen eines Texturabbildungs-Computergrafiksystems und insbesondere auf eine hintergrundroutinenbasierte virtuelle Speicherverwaltung eines Lokal-Cache-Speichersystems einer Hardwarevorrichtung, das Texturabbildungsdaten speichert.
  • Hintergrund der Erfindung
  • Computergrafiksysteme werden allgemein zum Anzeigen von Grafikdarstellungen von Objekten auf einem zweidimensionalen Anzeigeschirm verwendet. Aktuelle Computergrafiksysteme können höchst detaillierte Darstellungen liefern und werden bei einer Vielfalt von Anwendungen verwendet.
  • Bei typischen Computergrafiksystemen wird ein Objekt, das auf dem Anzeigeschirm dargestellt werden soll, in eine Mehrzahl von Grafikgrundelementen zerlegt. Grundelemente sind grundlegende Komponenten eines Grafikbilds und können Punkte, Linien, Vektoren und Vielecke, wie beispielsweise Dreiecke, umfassen. Typischerweise ist ein Hardware/Software-Schema implementiert, um auf dem zweidimensionalen Anzeigeschirm die Grafikgrundelemente aufzubereiten bzw. wiederzugeben, oder zu zeichnen, die die Ansicht eines oder mehrerer Objekte darstellen, die auf dem Bildschirm dargestellt sind.
  • Typischerweise werden die Grundelemente, die das dreidimensionale Objekt definieren, das aufbereitet werden soll, von einem Hostcomputer geliefert, der jedes Grundelement hinsichtlich Grundelementdaten definiert. Wenn beispielsweise das Grundelement ein Dreieck ist, kann der Hostcomputer das Grundelement hinsichtlich der x,y,z-Koordinaten der Scheitel desselben sowie der R,G,B-Farbwerte jedes Scheitels definieren. Eine Aufbereitungshardware interpoliert die Grundelementdaten, um die Anzeigebildschirmpixel zu berechnen, die eingeschaltet werden, um jedes Grundelement darzustellen, und die R,G,B-Werte für jedes Pixel.
  • Frühe Grafiksysteme zeigten Bilder nicht in ausreichend realistischer Weise an, um komplexe dreidimensionale Objekte darzustellen oder zu modellieren. Die Bilder, die durch derartige Systeme angezeigt wurden, zeigten extrem glatte Oberflächen ohne Texturen, Erhebungen, Kratzer, Schatten und andere Oberflächendetails, die bei dem Objekt vorhanden sind, das modelliert wird.
  • Folglich wurden Verfahren entwickelt, um Bilder mit einem verbesserten Oberflächendetail anzuzeigen. Eine Texturabbildung ist ein derartiges Verfahren, das ein Abbilden eines Quellbilds, das als eine Textur bezeichnet wird, auf eine Oberfläche eines dreidimensionalen Objekts und danach ein Abbilden des texturierten dreidimensionalen Objekts auf den zweidimensionalen Grafikanzeigebildschirm betrifft, um das resultierende Bild anzuzeigen. Oberflächendetailattribute, die häufig texturabgebildet werden, umfassen eine Farbe, eine Spiegelreflexion, eine Vektorstörung, eine spiegelnde Eigenschaft (Spekularität), eine Transparenz, Schatten, Oberflächenunregelmäßigkeiten und eine Gradierung.
  • Eine Texturabbildung betrifft ein Anlegen eines oder mehrerer Punktelemente (Texel) einer Textur an jedes Punktelement (Pixel) des angezeigten Abschnitts des Objekts, auf das die Textur abgebildet wird. Eine Texturabbildungshardware ist herkömmlicherweise mit Informationen versehen, die die Weise angeben, in der die Texel in einer Texturabbildung den Pixeln auf dem Anzeigebildschirm entsprechen, die das Objekt darstellen. Jedes Texel in einer Texturabbildung ist durch S- und T-Koordinaten definiert, die die Position desselben in der zweidimensionalen Texturabbildung identifizieren. Für jedes Pixel wird auf das entsprechende Texel oder die entsprechenden Texel, die auf dasselbe abbilden, von der Texturabbildung zugegriffen und dieselben werden in die endgültigen R,G,B-Werte eingegliedert, die für das Pixel erzeugt werden, um das texturierte Objekt auf dem Anzeigebildschirm darzustellen.
  • Es ist klar, dass jedes Pixel in einem Objektgrundelement eventuell nicht in einer Eins-zu-Eins-Entsprechung mit einem einzigen Texel in der Texturabbildung für jede Ansicht des Objekts abbildet. Je näher sich beispielsweise das Objekt an dem Betrachtungstor befindet, das auf dem Anzeigebildschirm dargestellt ist, desto größer erscheint das Objekt. Wenn das Objekt auf dem Anzeigebildschirm größer erscheint, wird die Darstellung der Textur detaillierter. Wenn somit das Objekt einen ziemlich großen Abschnitt des Anzeigebildschirms verbraucht, wird eine große Anzahl von Pixeln verwendet, um das Objekt auf dem Anzeigebildschirm darzustellen und jedes Pixel, das das Objekt darstellt, kann in einer Eins-zu-Eins-Entsprechung mit einem einzigen Texel in der Texturabbildung abbilden oder ein einziges Texel kann zu mehreren Pixeln abbilden. Wenn jedoch das Objekt einen relativ kleinen Abschnitt des Anzeigebildschirms einnimmt, wird eine viel kleinere Anzahl von Pixeln verwendet, um das Objekt darzustellen, was darin resultiert, dass die Textur mit weniger Details dargestellt ist, so dass jedes Pixel zu mehreren Texeln abbilden kann. Jedes Pixel kann ferner zu mehreren Texeln abbilden, wenn eine Textur auf einen kleinen Abschnitt eines Objekts abgebildet ist. Resultierende Texeldaten werden für jedes Pixel berechnet, das auf mehr als ein Texel abbildet. Weil es häufig vorkommt, dass ein Pixel auf mehrere Texel abbildet, stellen resultierende Texeldaten für ein Pixel typischerweise einen Durchschnitt der Texel dar, die auf dieses Pixel abbilden.
  • Texturabbildungshardwaresysteme umfassen typischerweise einen lokalen Speicher, der Daten speichert, die eine Textur darstellen, die dem aufbereiteten Objekt zugeordnet ist. Wie es oben erörtert ist, kann ein Pixel auf mehrere Texel abbilden. Falls es notwendig wäre, dass die Texturabbildungshardware eine große Anzahl von Texeln, die auf ein Pixel abbilden, von dem lokalen Speicher liest, um einen Durchschnittswert zu erzeugen, dann wäre eine große Anzahl von Speicherlesevorgängen und das Mitteln vieler Texelwerte erforderlich, was zeitraubend wäre und eine Systemleistungsfähigkeit verschlechtern würde.
  • Um dieses Problem zu überwinden, wurde ein Schema entwickelt, das die Erzeugung einer Reihe von MIP-Abbildungen für jede Textur und ein Speichern der MIP-Abbildungen der Textur, die dem Objekt zugeordnet ist, das aufbereitet wird, in dem lokalen Speicher der Texturabbildungshardware betrifft. Eine MIP-Abbildung für eine Textur umfasst eine Basisabbildung, die direkt der Texturabbildung entspricht, sowie eine Reihe gefilterter Abbildungen, wobei jede aufeinanderfolgende Abbildung um einen Faktor von Zwei bei jeder der zwei Texturabbildungsabmessungen größenmäßig reduziert ist. Ein darstellendes Beispiel eines Satzes von MIP-Abbildungen ist in 1 gezeigt. Die MIP-Abbildungen (MIP = multum in parvo – viele Dinge in einem kleinen Platz) umfassen eine Basisabbildung 100, die acht mal acht Texel groß ist, sowie eine Reihe von Abbildungen 102, 104 und 108, die vier mal vier Texel, zwei mal zwei Texel bzw. ein Texel groß sind.
  • Die Vier-Mal-Vier-Abbildung 102 wird durch ein Kastenfiltern (Dezimieren) der Basisabbildung 100 erzeugt, derart, dass jedes Texel in der Abbildung 102 einem Durchschnitt von vier Texeln in der Basisabbildung 100 entspricht. Zum Beispiel ist das Texel 110 in der Abbildung 102 gleich dem Durchschnitt der Texel 112 – 115 in der Abbildung 100 und Texel 118 und 120 in der Abbildung 102 sind gleich den Durchschnitten von Texeln 121 – 124 bzw. 125 – 128 in der Abbildung 100. Die Zwei-Mal-Zwei-Abbildung 104 ist auf ähnliche Weise durch ein Kastenfiltern der Abbildung 102 erzeugt, derart, dass ein Texel 130 in der Abbildung 104 gleich dem Durchschnitt der Texel 110 und 118 – 120 in der Abbildung 102 ist. Das einzige Texel in der Abbildung 108 ist durch ein Mitteln der vier Texel in der Abbildung 104 erzeugt.
  • Herkömmliche Grafiksysteme laden allgemein von dem Hauptspeicher des Hostcomputers die vollständige Reihe von MIP-Abbildungen für irgendeine Textur, die bei den Grundelementen verwendet werden soll, die auf dem Anzeigebildschirm aufbereitet werden sollen, zu dem lokalen Speicher der Texturabbildungshardware herunter. Somit kann die Texturabbildungshardware auf Texturdaten von irgendeiner der Reihe von MIP-Abbildungen zugreifen. Die Bestimmung, auf welche Abbildung zuzugreifen ist, um die Texeldaten für irgendein spezielles Pixel zu liefern, basiert auf der Anzahl von Texeln, auf die das Pixel abbildet. Falls beispielsweise das Pixel in einer Eins-zu-Eins-Entsprechung mit einem einzigen Texel in der Texturabbildung abbildet, dann wird auf die Basisabbildung 100 zugegriffen. Falls jedoch das Pixel auf vier, sechzehn oder vierundsechzig Texel abbildet, dann wird auf die Abbildung 102, Abbildung 104 bzw. 108 zugegriffen, weil diese Abbildungen Texeldaten speichern, die einen Durchschnitt von vier, sechzehn bzw. vierundsechzig Texeln in der Texturabbildung darstellen.
  • Ferner arbeiten einige Texturabbildungssysteme pipelineartig, so dass verschiedene Operationen simultan an unterschiedlichen Objektgrundelementen durchgeführt werden. Eine Reihe von MIP-Abbildungen für eine Textur kann jedoch groß sein. Viele Systeme verwenden einen lokalen Speicher, der zum Speichern lediglich einer derartigen großen Reihe von MIP-Abbildungen zu einer Zeit in der Lage ist. Wenn es somit einen Wechsel bei der Textur gibt, die bei einem Aufbereiten von Grundelementen verwendet wird, muss das System eine neue Reihe von MIP-Abbildungen herunterladen.
  • Typischerweise umfasst der Datenweg, der verwendet wird, um die neuen Texturdaten in den lokalen Speicher in der Texturabbildungshardware zu laden, ein Durchlaufen der Grundelementaufbereitungspipeline bzw. -leitung des Systems. Wenn deshalb eine neue Textur abgebildet werden soll, muss ermöglicht werden, dass sich die Grundelementaufbereitungspipeline entleert, bevor die neue Reihe von MIP-Abbildungen heruntergeladen werden kann. Wenn die Reihe von MIP-Abbildungen einmal heruntergeladen ist, muss die Pipeline erneut gefüllt werden. Die Notwendigkeit eines Spülens der Grundelementaufbereitungspipeline jedes Mal, wenn eine neue Textur benötigt wird, reduziert die Bandbreite des Systems.
  • 2 ist ein Blockdiagramm mit teilweise Hardware, teilweise hierarchischer Software eines herkömmlichen Computergrafiksystems, das die Softwareschichten zeigt, die auf dem Prozessor des Systemhostcomputers laufen, sowie die Hardwarevorrichtung, mit der der Hostcomputer kommuniziert, um die texturabgebildeten Bilder aufzubereiten. Der Systemspeicher des Hostcomputers kann mehrere benutzerinteraktive Prozesse PR1, PR2 ... PRN speichern, die auf dem Systemprozessor laufen, wie es in 2 gezeigt ist. Jeder Prozess ist ein Computergrafiksoftwareprogramm oder eine Anwendung auf hoher Ebene wie eine Datenbank, eine CAD/CAM-Anwendung, eine Architekturentwurfsanwendung, eine Bauingenieursanwendung, ein Textverarbeitungspaket oder dergleichen.
  • Innerhalb eines speziellen Prozesses kann ein Benutzer mehrere Kontexte erzeugen. Jeder Kontext, der innerhalb eines Prozesses erzeugt wird, kann eine unterschiedliche Ansicht des gleichen Bilds umfassen. Bei einem Architekturingenieursentwurfsanwendungsprozesses kann ein Benutzer beispielsweise unterschiedliche Ansichten der gleichen Struktur wie eines Gebäudes erzeugen. Jeder Kontext kann eine Texturabbildung erfordern, um das Bild aufzubereiten. Bei diesem Beispiel können Texturabbildungen erforderlich sein, um die Böden, Wände, Decken und anderen Oberflächenattribute des Gebäudes aufzubereiten. Somit liefert der Benutzer die Texturabbildung oder die Texturabbildungen, um das Bild dieses Kontexts aufzubereiten. Weil mehrere Kontexte, die innerhalb des gleichen Prozesses erzeugt werden, typischerweise unterschiedliche Ansichten des gleichen Bilds umfassen, benötigen die Kontexte innerhalb eines Prozesses allgemein die gleiche Textur oder die gleichen Texturen.
  • Wenn ein Kontext durch einen Benutzer erzeugt wird, erteilt der Benutzer einen Befehl, der durch die Prozessprogrammiersprache auf hoher Ebene erkennbar ist, um dieses Bild zu zeichnen. Falls das Bild eine Texturabbildung erfordert, dann wird ein Befehl eingegeben, der diese angibt, und die Texturabbildung wird dann durch den Benutzer von einem externen Eingabegerät, einer Diskette oder dergleichen geliefert. Der Prozess oder die Programmiersprache auf hoher Ebene übersetzt dann diesen Befehl in einen Softwarebefehl auf niedrigerer Ebene und kopiert die Textur, die durch den Benutzer eingegeben wird. Bei Systemen des Stands der Technik, wie beispielsweise diesem, das in 2 gezeigt ist, erfordert jeder Kontext, der innerhalb eines einzigen Prozesses erzeugt wird, seine eigene Kopie dieser Textur. Jeder Kontext speichert seine Kopie der Textur innerhalb eines zweckgebundenen Bereichs eines Systemspeichers auf dem Hostcomputer. Wenn somit mehrere Kontexte innerhalb eines Prozesses die Verwendung der gleichen Textur erfordern, werden mehrere Kopien dieser Textur innerhalb des Systemspeichers gespeichert, wobei eine Kopie jedem Kontext entspricht.
  • Der benutzereingegebene Befehl, um ein Bild unter Verwendung einer speziellen Textur zu zeichnen, wird, wenn derselbe einmal durch den Prozess übersetzt ist, von dem Prozess zu einer zugrundeliegenden Grafikanwendungsprogrammierer-Schnittstelle (Grafik-API; API = application programmer interface) kommuniziert. Wie es in 2 gezeigt ist, kommuniziert eine eindeutige Grafik-API mit jedem Prozess des Systems. Jede Grafik-API ist eine zugrundelie gende Softwaresprache auf niedrigerer Ebene, die an dem Prozessor des Hostcomputers wirksam ist, um jeden Grafikbefehl auf hoher Ebene, der von dem entsprechenden Prozess empfangen wird, in einen Softwarecodebefehl auf niedrigerer Ebene zu übersetzen. Die Grafik-API speichert ferner eine Kopie jeder Textur, die erforderlich ist, um das Bild aufzubereiten, in der eigenen zweckgebundenen Position derselben des Systemspeichers. Die Grafik-API zerlegt das Bild, das aufbereitet werden soll, zusätzlich in Grafikkomponenten, wie beispielsweise Vierecke oder Vielecke. Derartige Informationen werden dann zu einem entsprechenden Hardwaretreiber geliefert.
  • Ein eindeutiger Hardwaretreiber kommuniziert mit jeder Grafik-API. Jeder Hardwaretreiber ist eine weitere zugrundeliegende Grafiksoftwaresprache auf niedrigerer Ebene, die jeden Grafikbefehl auf niedriger Ebene, der von der API empfangen wird, in Hardwarebefehle übersetzt, die durch die Grafikhardwarevorrichtung erkennbar sind, mit der der Hostcomputer verbunden ist. Diese Befehle werden dann von dem Hardwaretreiber zu der Hardwarevorrichtung kommuniziert, die wiederum das texturabgebildete Bild auf einem Anzeigebildschirm aufbereitet, der mit der Hardwarevorrichtung verbunden ist. Wie es in 2 gezeigt ist, kommuniziert eine eindeutige Instanz eines Hardwaretreibers HWD1 , HWD2 ... HWDN mit jeder Grafik-API API1, API2 ... APIN.
  • Bei dem in 2 gezeigten Beispiel sind alle der Hardwaretreiber mit einer einzigen Grafikhardwarevorrichtung 150 verbunden. Wie es Fachleuten auf dem Gebiet klar ist, kann der Hostcomputer jedoch mit mehreren unterschiedlichen Grafikhardwarevorrichtungen verbunden sein, wobei ein unterschiedlicher Hardwaretreiber mit jeder Hardwarevorrichtung kommuniziert.
  • Wenn eine Grafik-API einen Softwarebefehl auf niedriger Ebene liefert, um ein texturabgebildetes Vieleck unter Verwendung einer speziellen Textur, die ebenfalls geliefert wird, aufzubereiten, übersetzt der Grafikhardwaretreiber diesen Befehl auf niedriger Ebene in Hardwarebefehle, die durch die Hardwarevorrichtung 150 erkennbar sind. Der Grafikhardwaretreiber liefert dann die Befehle, um das Vieleck aufzubereiten, zu der Hardwarevorrichtung 150 durch ein Schreiben zu geeigneten Registern und Eingangspuffern innerhalb der Hardwarevorrichtung. Zusätzlich liefert der Grafikhardwaretreiber die Texturdaten für dieses spezielle Vieleck zu dem lokalen Speicher 155 der Hardwarevorrichtung 150, wo dieselben temporär während eines Aufbereitens dieses Vielecks gespeichert werden. Wie es hierin beschrieben ist, laden Computergrafiksysteme des Stands der Technik die gesamte Reihe von MIP-Abbildungen für eine einzige Textur von dem Grafikhardwaretreiber zu dem lokalen Speicher der Hardwarevorrichtung jedes Mal herunter, wenn diese Textur benötigt wird, um ein Bild oder eine Komponente des Bilds aufzubereiten.
  • Bei herkömmlichen Systemen, wie beispielsweise demselben, das in 2 gezeigt ist, werden mehrere Kopien einer einzigen Textur bei unterschiedlichen Positionen des Systemsoftwarespeichers des Hostcomputers gespeichert. Falls beispielsweise ein Kontext 1A und ein Kontext 1B eines Prozesses PR1 die gleiche Textur benötigen, um unterschiedliche Ansichten eines speziellen Bilds aufzubereiten, dann liefert der Benutzer eine erste Kopie dieser Textur, wenn dieselbe anfänglich definiert und zu dem Prozess eingebracht wird. Jeder Kontext 1A und 1B innerhalb dieses Prozesses PR1 speichert ferner eine Kopie der Textur, wobei die Zwischensumme auf drei Softwarekopien der gleichen Textur gebracht wird, die durch den Prozess PR1 gespeichert ist. Die Grafik-API1 erstellt eine vierte Kopie dieser Textur und speichert dieselbe bei der geeigneten Position derselben des Systemsoftwarespeichers. Der Grafikhardwaretreiber HWD1 erstellt eine fünfte Kopie dieser Textur und speichert dieselbe bei der geeigneten Position desselben des Systemsoftwarespeichers. Somit sind fünf eindeutige Kopien der gleichen Textur bei unterschiedlichen Positionen des Systemsoftwarespeichers gespeichert, um zwei Ansichten des gleichen Bilds unter Verwendung dieser gleichen Textur aufzubereiten. Wie es oben beschrieben ist, wird zusätzlich eine sechste Kopie der Textur zu der Hardwarevorrichtung geliefert und in dem lokalen Speicher derselben gespeichert.
  • Eine Reihe von Textur-MIP-Abbildungen kann eine große Menge an Systemsoftwarespeicher für eine Speicherung benötigen. Zum Beispiel erfordert eine Reihe von MIP-Abbildungen für eine Textur, die eine Texturbasisabbildung von 1024 × 1024 Texeln aufweist, mehr als fünf Megabyte Systemsoftwarespeicher, um eine Kopie der MIP-abgebildeten Textur zu speichern. Somit verwenden die mehreren gespeicherten Kopien der MIP-abgebildeten Textur eine erhebliche Menge an Systemsoftwarespeicher.
  • Während der Systemsoftwarespeicher in der Lage sein kann, bis zu einigen Gigabyte an Softwaredaten zu speichern, kann ein typischer zweckgebundener lokaler Hardwaretexturspeicher einer Texturhardwarevorrichtung viel weniger Daten speichern. Ein derartiger lokaler Texturhardwarespeicher kann zwischen vier Megabyte und sechzehn Megabyte liegen. Bei vielen Texturabbildungsanwendungen überschreitet deshalb die Menge an Systemspeicher, die durch Texturen verbraucht wird, bei weitem dieselbe des lokalen Hardwaretexturspeichers. Während der Systemspeicher typischerweise mehrere MIP-abgebildete Texturen für eine Verwendung bei mehreren Kontexten eines Prozesses speichert, kann der lokale Hardwarevorrichtungsspeicher lediglich eine Textur einer begrenzten Größe zu irgendeiner Zeit speichern. Deshalb ist eine ordnungsgemäße Verwaltung des lokalen Texturspeichers der Hardwarevorrichtung entscheidend, um eine maximale Leistungsfähigkeit des Systems zu erreichen.
  • Zusätzlich zu dem großen Verbrauch eines Systemsoftwarespeichers aufgrund der Speicherung mehrerer Kopien von Texturen, leidet eine Systembandbreite allgemein bei her kömmlichen Verwaltungsschemata eines lokalen Hardwaretexturspeichers. Herkömmliche Verwaltungsschemata eines lokalen Hardwarespeichers ersetzen wiederholt ganze Reihen von Textur-MIP-Abbildungen innerhalb des lokalen Hardwarespeichers. Die Reihe von MIP-Abbildungen für eine Textur wird in dem lokalen Speicher jedes Mal ersetzt, wenn diese Textur benötigt wird, um ein Vieleck aufzubereiten. Derartige Schemata betrachten weder die Historie der Verwendung dieser Textur, noch sagen dieselben eine zukünftige Verwendung dieser Textur voraus. Durch ein wiederholtes Herunterladen der ganzen Reihe der gleichen Textur von dem Systemspeicher in den lokalen Hardwaretexturspeicher wird eine Systembandbreite negativ beeinflusst.
  • Weil herkömmliche Texturhardwarespeicher-Ersetzungsalgorithmen ganze Textur-MIP-Abbildungsreihen herunterladen, kann jede Textur-MIP-Abbildungsreihe die physischen Speicherkapazitätsgrenzen des lokalen Hardwaretexturspeichers nicht überschreiten. Deshalb muss der Benutzer des Grafikprozesses, der mit der speziellen Hardwarevorrichtung verbunden ist, die Kapazität des lokalen Texturspeichers kennen, so dass Texturen, die größer als diese Kapazität sind, nicht verwendet werden. Während viele Anwendungen (Prozesse) mit mehreren unterschiedlichen zugrundeliegenden Hardwarevorrichtungen wirksam sein können, jede mit eindeutigen Einschränkungen des lokalen Texturspeichers, fällt die Last auf den Benutzer, eine Kenntnis derartiger Beschränkungen zu haben und Bilder in einer vorrichtungsabhängigen Weise zu erzeugen.
  • Die EP-A-0 438 195 (PHILIPS ELECTRONIC) beschreibt eine Anzeigevorrichtung, die einen Hostprozessor mit einem zugeordneten Hauptspeicher und einen Anzeigeprozessor mit einem zugeordneten Anzeigespeicher und einem Texturspeicher aufweist. Der Hostprozessor speichert zumindest ein pyramidenförmiges Array von Texelwerten, die eine gegebene Textur von zumindest zwei Auflösungspegeln darstellen, in den Texturspeicher. Der Texturspeicher weist zwei getrennte Speicherbänke auf, derart, dass acht Texelwerte simultan für eine trilineare Interpolierung verfügbar sind. Eine Texturspeicherverwaltungseinheit umfasst eine Einrichtung zum Empfangen und Speichern von Seitenpositions-Informationen zum Lokalisieren lediglich der Daten, die wirklich benötigt werden, in dem Texturspeicher von jedem derartigen Array.
  • Die EP-A-0 747 858 (HEWLETT PACKARD), die ein Dokument des Stands der Technik gemäß Artikel 54(3) EPÜ ist, beschreibt einen Textur-Cache zum Verwalten von Texturabbildungsdaten in einem Computergrafiksystem. Das System umfasst einen Hostcomputer, eine Grundelementaufbereitungshardware und einen Grundelementdatenweg, der sich zwischen dem Hostcomputer und der Aufbereitungshardware erstreckt. Die Aufbereitungshardware umfasst einen lokalen Texturspeicher, der lokal Texturabbildungsdaten speichert, die einem der Grundelemente entsprechen, das aufbereitet werden soll. Wenn ein Grundelement aufbereitet werden soll, wird bestimmt, ob die notwendigen Texturabbildungsdaten sich in dem lokalen Texturspeicher befinden, und falls es dieselben nicht sind, werden dieselben von dem Hostcomputer-Hauptspeicher zu der Aufbereitungshardware heruntergeladen.
  • Es ist die der vorliegenden Erfindung zugrundeliegende Aufgabe, ein verbessertes Texturabbildungscomputergrafiksystem und ein verbessertes Verfahren zum Verwalten von Texturdaten in einem derartigen System zu schaffen, das für Einsparungen bei dem notwendigen Speicherplatz sorgt, was aber lediglich in einer geringen Reduzierung der Systembandbreite resultiert.
  • Diese Aufgabe wird durch ein System gemäß Anspruch 1 und durch ein Verfahren gemäß Anspruch 7 gelöst.
  • Kurze Beschreibung der Zeichnungen
  • Für ein besseres Verständnis der vorliegenden Erfindung wird Bezug auf die zugehörigen Zeichnungen genommen, die hierin durch Bezugnahme aufgenommen sind und in denen:
  • 1 eine grafische Darstellung eines Satzes von Textur-MIP-Abbildungen ist;
  • 2 ein Blockdiagramm von teilweise Hardware, teilweise hierarchischer Software eines Computergrafiksystems des Stands der Technik ist;
  • 3 ein Blockdiagramm von teilweise Hardware, teilweise Software eines Computergrafiksystems gemäß der vorliegenden Erfindung ist;
  • 3A ein Blockdiagramm von teilweise Hardware, teilweise Software eines Computergrafiksystems eines anderen Ausführungsbeispiels gemäß der vorliegenden Erfindung ist;
  • 3B ein Blockdiagramm von teilweise Hardware, teilweise Software eines Computergrafiksystems noch eines weiteren anderen Ausführungsbeispiels gemäß der vorliegenden Erfindung ist;
  • 4 ein Blockdiagramm eines Ausführungsbeispiels einer Computergrafikhardwarevorrichtung ist, bei der die Softwarehintergrundroutine der vorliegenden Erfindung verwendet werden kann;
  • 4A ein Blockdiagramm eines anderen Ausführungsbeispiels einer Computergrafikhardwarevorrichtung ist, bei der die Softwarehintergrundroutine der vorliegenden Erfindung verwendet werden kann;
  • 5 ein Blockdiagramm des Texturabbildungshardwarechips der Hardwarevorrichtung von 4 oder 4A ist;
  • 6 ein detaillierteres Blockdiagramm des Parameterinterpolatorelements der Texturabbildungshardware ist;
  • 7 ein Blockdiagramm des Cache-Speichers und eines Abschnitts der Texturabbildungshardware ist;
  • 8 ein Diagramm einer Textur-MIP-Abbildung ist, wobei Texel angeordnet sind, um den lokalen Hardwarevorrichtungsspeicher auszunutzen;
  • 9 ein detailliertes Blockdiagramm der Organisation der Speicherchips ist, die den Cache-Speicher bilden;
  • 10 ein detailliertes Blockdiagramm eines Abschnitts der Texturabbildungshardware ist;
  • 11 ein Diagramm und eine Darstellung ist, die ein Beispiel von Texeln darstellt, auf die von benachbarten MIP-Abbildungen für jeden eines Stroms von Pixeln gemäß einem Texturabbildungsschema zugegriffen wird;
  • 12 ein Diagramm von Texturabbildungshardwarepuffern und zugeordneten Dateneinträgen gemäß dem Beispiel von 11 ist;
  • 13 ein Blockdiagramm einer Schaltung ist, die durch die Texturabbildungshardware verwendet wird;
  • 14 ein Diagramm eines Beispiels eines Satzes von Textur-MIP-Abbildungen ist;
  • 15 ein Diagramm ist, das darstellt, wie die MIP-Abbildungen des Beispiels von 12 gemäß einem Speicherspeicherungsschema in einem Speicher gespeichert sind;
  • 16 ein Diagramm einer MIP-Abbildung ist, das darstellt, wie die MIP-Abbildung gemäß einem Speicherspeicherungsschema partitioniert ist;
  • 17 ein detaillierteres Diagramm von Abschnitten der in 16 gezeigten Abbildung ist, das darstellt, wie die Abbildung gemäß einem Speicherspeicherungsschema weiter partitioniert ist;
  • 18 ein Diagramm ist, das die Weise darstellt, in der die Cache-Blockkennung erzeugt wird;
  • 19 ein Flussdiagramm ist, das ein Verfahren zum Bestimmen der Texeladresse innerhalb eines entsprechenden Texturdatenblocks aus gelieferten interpolierten Texeldaten darstellt;
  • 20 ein Diagramm ist, das die Texeltorregister darstellt, die in dem Texturabbildungschip vorgesehen sind;
  • 21 ein Flussdiagramm ist, das eine Softwareroutine darstellt, die durch den Prozessor des Hostcomputers implementiert wird, zum Verarbeiten einer Unterbrechung und Bestimmen, welcher Block von Daten herunterzuladen ist;
  • 22 ein Blockdiagramm des Cache-Miniverzeichnisses ist;
  • 23 ein Blockdiagramm des Cache-Hauptverzeichnisses ist;
  • 24 ein Blockdiagramm einer Reihe von Komparatoren ist, die vorgesehen sind, um Leistungsfähigkeitseinbußen zu reduzieren, wenn eine Cache-Lesekennung das Miniverzeichnis verfehlt; und
  • 25 ein Blockdiagramm einer darstellenden Implementierung des Cache-Verzeichnisses ist;
  • 26 ein Flussdiagramm der Gesamtoperation der Texturunterbrechungsverwaltungseinrichtung-Softwarehintergrundroutine (TIM-Softwarehintergrundroutine; TIM = texture interrupt manager) der vorliegenden Erfindung ist;
  • 27 ein teilweise Flussdiagramm, teilweise Funktionsblockdiagramm der Operation eines Hardwaretreibers und einer TIM während einer Kommunikation zwischen den zwei betreffenden Texturen ist;
  • 28 ein Flussdiagramm der vorrichtungsunabhängigen Routine der TIM zum Verarbeiten einer Unterbrechung ist;
  • 29 ein Flussdiagramm der vorrichtungsabhängigen Routine der TIM zum Bestimmen ist, welcher Block innerhalb des lokalen Speichers der Hardwarevorrichtung während einer Unterbrechung zu ersetzen ist;
  • 30 ein Funktionsblockdiagramm ist, das die Verfahren zeigt, durch die Texturdaten von einem Hardwaretreiber zu einer TIM und einer Einrichtung der TIM zum Speichern von Kopien von Texturen kommuniziert werden kann;
  • 31 ein Funktionsblockdiagramm ist, das die Texturprioritätslisten zeigt, die durch die Softwareschichten innerhalb des Systems beibehalten wer den, und das Schema zum Bestimmen einer endgültigen Systemtextur-Prioritätsliste darstellt; und
  • 32 ein Funktionsblockdiagramm ist, das unterschiedliche Schemata zum Packen von Texturdaten relativ kleiner Texturen in Blöcke darstellt.
  • Detaillierte Beschreibung
  • I. Systemübersicht
  • Die vorliegende Erfindung bezieht sich auf eine Softwarehintergrundroutine, die auf dem Prozessor eines Computergrafiksystemhostcomputers läuft und die Speicherung von Texturdaten innerhalb des lokalen Speichers einer Texturabbildungsgrafikhardwarevorrichtung verwaltet, die mit dem Hostcomputer verbunden ist. Die Hintergrundroutine verwaltet den lokalen Speicher auf eine derartige Weise, dass der Speicher virtuell erscheint. Im Gegensatz zu Systemen des Stands der Technik, die ganze Reihen von Textur-MIP-Abbildungen in den lokalen Speicher der Hardwarevorrichtung herunterladen, lädt die Softwareverwaltungseinrichtung bzw. der Softwareverwalter der vorliegenden Erfindung lediglich Abschnitte von Textur-MIP-Abbildungen herunter, die zu irgendeiner Zeit notwendig sind, um ein Bild oder einen Bildabschnitt aufzubereiten bzw. wiederzugeben. Die Verwaltungseinrichtung betrachtet die Verwendungshäufigkeit der jüngeren Vergangenheit spezieller Texturabbildungsabschnitte sowie die vorausgesagte zukünftige Verwendung derartiger Abbildungsabschnitte (basierend auf relativen Prioritäten der Texturen) bei einem Bestimmen, welche Abschnitte in dem lokalen Hardwarespeicher zu ersetzen sind, wenn neue Texturdaten durch die Hardwarevorrichtung benötigt werden, um ein Bild oder einen Abschnitt desselben aufzubereiten.
  • Bei einem Ausführungsbeispiel der Erfindung sieht die Verwaltungseinrichtung das gemeinschaftlich verwendete Speichern von Texturen unter der Verwaltungseinrichtung, dem Hardwaretreiber und der entsprechenden Grafik-API innerhalb des Systemspeichers vor. Die Verwaltungseinrichtung sieht ferner ein gemeinschaftlich verwendetes Speichern von Texturen unter mehreren Kontexten eines einzigen Prozesses vor. Das Verwaltungsschema der vorliegenden Erfindung sieht enorme Bandbreiteneinsparungen und Systemsoftware-Speicherplatzeinsparungen im Gegensatz zu dem Stand der Technik vor. Das System ermöglicht zusätzlich, dass der Benutzer der Grafikprozesse auf hoher Ebene Bilder auf eine vorrichtungsunabhängige Weise ohne eine Kenntnis der Speicherkapazitätsgrenzen der lokalen Speicher der zugrundeliegenden Hardwarevorrichtungen erzeugt.
  • Ein erstes Ausführungsbeispiel der Erfindung ist in dem Blockdiagramm von 3 gezeigt, bei dem gleiche Bezugszeichen verwendet werden, um zu diesen von 2 identische Elemente zu bezeichnen. Wie das Ausführungsbeispiel des Stands der Technik von 2, umfasst das System mehrere benutzerinteraktive Prozesse PR1, PR2 ... PRN, die auf dem Systemprozessor laufen. Innerhalb jedes Prozesses kann der Benutzer mehrere Kontexte erzeugen, die die gleichen Texturabbildungen erfordern. Das System umfasst ferner eine zugrundeliegende Grafik-API und einen Grafikhardwaretreiber für jeden Prozess.
  • Die Erfindung bezieht sich auf eine Texturunterbrechungsverwaltungs-Hintergrundroutine (TIM-Hintergrundroutine; TIM = texture interrupt managing) 160, die ein unabhängiger, alleinstehender Softwareprozess ist, der auf dem Prozessor des Hostcomputers ohne Wissen des Benutzers läuft. Die TIM 160 der vorliegenden Erfindung kommuniziert mit jedem der Grafikhardwaretreiber über einen gesonderten Sockel. Wie es Fachleuten auf dem Gebiet klar ist, ist ein Sockel ein Softwarekommunikationsweg, über den zwei Softwareprogramme kommunizieren können. Die TIM kommuniziert ferner mit der Hardwarevorrichtung 150 über einen Bus 162.
  • Die TIM der vorliegenden Erfindung kann auf einem herkömmlichen Prozessor von Computergrafiksystemhostcomputern laufen, die als Computergrafik-Arbeitsplatzrechner bekannt sind. Ein derartiger Arbeitsplatzrechner umfasst z. B. den Hewlett-PackardTM 9000 Reihe J200.
  • Die TIM 160 verwaltet das Speichern von Texturdaten innerhalb des lokalen Speichers 155 der Hardwarevorrichtung 150. Wie es unten detaillierter erläutert wird, umfasst die TIM einen vorrichtungsunabhängigen Abschnitt, der die Softwaretexturspeicherverwaltung und gesockelte Kommunikationen mit den Grafikhardwaretreibern handhabt, und einen vorrichtungsabhängigen Abschnitt, der über den Bus 162 zu der Hardwarevorrichtung schreibt und von derselben liest.
  • Bei einem Ausführungsbeispiel der vorliegenden Erfindung ist der lokale Speicher der Hardwarevorrichtung als ein Cache-Speicher angeordnet, bei dem Abschnitte von Texturen in dem lokalen Speicher der Hardwarevorrichtung zu irgendeiner Zeit gespeichert sind. Der vorrichtungsunabhängige Abschnitt der TIM verfolgt die Verwendung der Abschnitte von Texturdaten, die in dem Cache gespeichert sind, und überwacht die Prioritäten der Texturen, um eine zukünftige Verwendung dieser Abschnitte vorauszusagen. Ein Cache-Fehltreffer bei der Hardware tritt auf, wenn Texturdaten durch die Hardwarevorrichtung benötigt werden, um ein Bild aufzubereiten, das aktuell nicht in dem Cache gespeichert ist. Wenn ein Cache-Fehltreffer auftritt, bestimmt die TIM, welcher Block von Texturdaten innerhalb des Caches zu ersetzen ist, durch ein Betrachten, welcher Block oder welche Blöcke von Texturdaten innerhalb des Caches am weitesten zurückliegend verwendet wurden und welche Texturen die niedrigste Priorität aufweisen.
  • Die TIM weist ferner die Texturdaten in Formate zu, die durch die lokalen Speicher spezieller Hardwarevorrichtungen erkennbar sind, die mit dem Hostcomputer zum Aufbereiten von Bildern verbunden sind. Bei einem Ausführungsbeispiel der Erfindung ist jede Abbildung einer Reihe von MIP-Abbildungen für eine Textur in Quadranten geteilt und unter Blöcken von Daten zugewiesen, die durch die TIM zu dem lokalen Cache-Speicher der Hardwarevorrichtung heruntergeladen werden sollen. Der vorrichtungsabhängige Abschnitt der TIM führt tatsächlich das Herunterladen der Daten durch, wenn eine Cache-Unterbrechung auftritt.
  • Bei einem Ausführungsbeispiel der Erfindung umfasst die TIM eine gemeinschaftlich verwendete Speicherposition innerhalb des Systemspeichers, bei der eine große Textur oder ein Texturabschnitt gespeichert ist und zwischen der Grafik-API, dem Grafikhardwaretreiber und der TIM für einen speziellen Prozess gemeinschaftlich verwendet wird. Wie es unten detaillierter erläutert wird, umfasst jedes der Grafik-API, des Grafikhardwaretreibers (für einen speziellen Prozess) und der TIM 160 einen Zeiger zu einer Position innerhalb des gemeinschaftlich verwendeten Systemspeicherbereichs, um auf die gespeicherte Texturkopie zuzugreifen. Zusätzlich sieht die TIM ein Speicherverwaltungsschema vor, derart, dass alle der Kontexte, die innerhalb eines einzigen Prozesses erzeugt werden, die gleiche Kopie irgendeiner Textur gemeinschaftlich verwenden, die für diese Kontexte benötigt wird. Für bestimmte Anwendungen kann die TIM der vorliegenden Erfindung deshalb enorme Einsparungen eines Systemsoftwarespeicherplatzes liefern.
  • Mit Bezug auf das oben mit Bezug auf 2 beschriebene Beispiel, bei dem der Kontext 1A und der Kontext 1B des Prozesses PR1 die gleiche Textur erfordern, um unterschiedliche Ansichten eines speziellen Bilds aufzubereiten, würde, falls die Textur groß ist, dann die TIM der vorliegenden Erfindung enorme Systemspeicherplatzeinsparungen liefern. Im Gegensatz zu dem beschriebenen System des Stands der Technik kann eine einzige Kopie der Textur gespeichert werden, die zwischen dem Kontext 1A und dem Kontext 1B gemeinschaftlich verwendet würde. Falls zusätzlich die Textur groß genug wäre, um zu garantieren, dass dieselbe bei der gemeinschaftlich verwendeten Speicherposition gespeichert wird, dann wäre lediglich eine andere Kopie der Textur bei der gemeinschaftlich verwendeten Systemspeicherposition gespeichert und würde zwischen der TIM, der Grafik-API1 und dem Grafikhardwaretreiber HWD1 gemeinschaftlich verwendet. Bei diesem Beispiel wären somit lediglich drei eindeutige Kopien der gleichen Textur bei unterschiedlichen Positionen des Systemsoftwarespeichers gespeichert, um zwei Ansichten des gleichen Bilds unter Verwendung der gleichen Textur aufzubereiten. Eine Kopie wäre die Benutzerkopie, eine Kopie würde zwischen den zwei Kontexten des Prozesses PR1 gemeinschaftlich verwendet und eine Kopie würde zwischen der Grafik-API, dem Grafikhardwaretreiber und der TIM gemeinschaftlich verwendet. Bei dem System des Stands der Technik von 2 müssten, wie es oben beschrieben ist, fünf Kopien dieser gleichen Textur in dem Systemsoftwarespeicher gespeichert sein. Deshalb müssen mit der TIM der vorliegenden Erfindung zwei Kopien der Textur weniger in dem Systemsoftwarespeicher gespeichert sein, was bei einer großen Textur in großen Speicherplatzeinsparungen resultiert.
  • Wenn der Benutzer wünscht, ein Bild zu erzeugen, erteilt der Benutzer einen Befehl, der durch die Prozessprogrammiersprache auf hoher Ebene erkennbar ist, um dieses Bild zu zeichnen, und gibt ferner die Textur ein, die erforderlich ist, um dieses Bild texturabzubilden. Der Prozess würde dann diesen Befehl in einen Softwarebefehl auf niedrigerer Ebene übersetzen und würde die Textur kopieren. Der übersetzte Befehl würde dann von dem Prozess zu der zugrundeliegenden Grafik-API kommuniziert, die diesem Prozess zugeordnet ist. Die Grafik-API würde dann den Grafikbefehl, der von dem Prozess empfangen wird, in einen Softwarecodebefehl auf niedrigerer Ebene übersetzen und würde das Bild in Grafikkomponenten zerlegen, wie beispielsweise Vierecke oder Vielecke. Diese Informationen würden dann zu dem Hardwaretreiber geliefert.
  • Wenn diese Informationen zu dem Hardwaretreiber kommuniziert werden, würde der entsprechende Sockel zwischen demselben und der TIM geöffnet. Wie es unten detaillierter erläutert wird, kommuniziert dann der Hardwaretreiber zu der TIM, dass der Benutzer wünscht, ein Bild mit einer speziellen Textur aufzubereiten. Der Hardwaretreiber kommuniziert zu der TIM über den Sockel, zu bestimmen, ob die TIM bereits eine Kopie der Textur gespeichert hat. Falls dem so ist, dann erteilt der Hardwaretreiber einen Befehl an die Computergrafikhardwarevorrichtung, mit der derselbe verbunden ist, um dieses Vieleck unter Verwendung dieser Textur aufzubereiten. Falls nicht, dann kopiert die TIM diese Textur entweder in die eigene zugewiesene Systemsoftwarespeicherposition derselben oder zu der gemeinschaftlich verwendeten Speicherposition derselben oder Abschnitte zu jedem, wie es unten detaillierter erläutert ist.
  • Wenn der Hardwaretreiber zu der TIM kommuniziert, dass eine neue Textur durch den Benutzer angefordert wurde, werden die Priorität der Textur und die Größe der Textur ebenfalls zu der TIM über den Sockel kommuniziert. Die TIM liefert dann einen Texturidentifizierer zu der Textur, falls verfügbar. An diesem Punkt wird eine Bestimmung vorgenommen, abhängig von der Größe der Textur und der Anzahl von MIP-Abbildungspegeln dieser Textur, ob diese Textur bei der gemeinschaftlich verwendeten Speicherposition gespeichert wird oder ob diese Textur bei der eigenen zugewiesenen Systemsoftwarespeicherposition der TIM gespeichert wird. Dieses Schema wird unten detaillierter erläutert.
  • Als ein Teil dessen, dass die TIM eine Kopie der neuen Textur speichert, weist der vorrichtungsunabhängige Abschnitt der TIM die Texturdaten in ein Format zu, das durch die Hardwarevorrichtung erkennbar ist, mit der dieselbe verbunden ist. Bei einem Ausführungsbeispiel der Erfindung werden die Texturdaten in Blöcke zugewiesen und ein Block zu einer Zeit in einen lokalen Cache-Speicher der Hardware vorrichtung heruntergeladen, wie es durch die Hardwarevorrichtung benötigt wird.
  • Hardwarebefehle werden durch den Grafikhardwaretreiber der Hardwarevorrichtung erteilt, um das Bild unter Verwendung der Texturabbildung aufzubereiten. Die Hardwarebefehle werden beispielsweise entlang einem Bus 16 von 4 kommuniziert. Falls die entsprechende Texturabbildung nicht bereits in dem lokalen Speicher der entsprechenden Hardwarevorrichtung gespeichert ist, dann tritt eine Unterbrechung auf und die TIM verarbeitet diese Unterbrechung. Die TIM kommuniziert mit der Hardwarevorrichtung, um den Abschnitt der Textur zu bestimmen, der notwendig ist, um das Bild aufzubereiten, wählt den geeigneten Block innerhalb des Cache-Speichers aus, der mit dem benötigten Texturabschnitt zu überschreiben ist, und schreibt dann den benötigten Block zu dem lokalen Cache-Speicher bei der ausgewählten Position. Die Bestimmung dessen, welcher Block von Texturdaten in dem lokalen Speicher der Hardwarevorrichtung zu ersetzen ist, wenn eine Unterbrechung auftritt, basiert sowohl auf der Historie einer Verwendung dieses Blocks innerhalb der Hardwarevorrichtung als auch der Priorität der Texturen, die in den Blöcken gespeichert sind. Die Priorisierung der Texturen basiert auf externen benutzerdefinierten Prioritäten sowie internen vorgegebenen Prioritäten. Intern wird die höchste Priorität einer Textur oder Texturen gegeben, die zum Aufbereiten neu erzeugter Bilder benötigt wird oder werden, wobei die nächst höchste Priorität der am jüngsten verwendeten Struktur gegeben wird, wie es unten detailliert beschrieben ist. Wenn somit der Benutzer ein neues Bild erzeugt, das eine Textur benötigt, wird dieser Textur zu dieser Zeit die höchste Priorität gegeben.
  • 3A ist ein Blockdiagramm eines anderen Ausführungsbeispiels der vorliegenden Erfindung, bei dem das System einen einzigen Hostcomputer umfasst, der mit drei getrennten Grafikhardwarevorrichtungen 164, 166 und 168 kommuniziert, die auch mit A, B und C etikettiert sind. Jede dieser Hardwarevorrichtungen kann unterschiedliche physische Parameter und Anforderungen umfassen. Drei getrennte TIMs 170, 172 und 174 (die ebenfalls mit A, B und C etikettiert sind) kommunizieren mit den Grafikhardwarevorrichtungen 164, 166 bzw. 168. Jede TIM ist für ein Verwalten der Speicherung von Texturdaten innerhalb des lokalen Speichers der Grafikhardwarevorrichtung verantwortlich, mit der dieselbe verbunden ist. Deshalb weist jede TIM eine Kenntnis der physischen Parameter und Anforderungen der entsprechenden Hardwarevorrichtung auf, wie beispielsweise der Speicherkapazität des lokalen Speichers, Texturformatanforderungen, Busbreiten, Puffergrößen, Registergrößen etc.
  • Jede TIM umfasst eine gemeinschaftlich verwendete Speichersoftwareposition, bei der Texturen, die innerhalb jedes Prozesses erzeugt werden, gespeichert und zwischen der TIM, der Grafik-API und dem Hardwaretreiber dieses Prozesses gemeinschaftlich verwendet werden. Wie es unten detaillierter erläutert ist, speichern die TIM, die Grafik-API und der Hardwaretreiber jeweils einen Zeiger zu der gemeinschaftlich verwendeten Speicherposition, um auf die Texturen zuzugreifen. Das gemeinschaftlich verwendete Speicherschema kann einen enormen Systemspeicherplatz einsparen. Jede TIM umfasst ferner den eigenen zweckgebundenen Systemspeicherbereich derselben, der Kopien von Texturen oder Texturabschnitten speichert. Diese Systembereiche sind in 3A gezeigt.
  • Bei dem System von 3A verwaltet die TIM A 170 die Texturen, die durch die Prozesse PR1 und PR2 benötigt werden, für die durch die Hardwarevorrichtung A 164 Bilder aufbereitet werden. Gleichermaßen verwaltet die TIM B 172 die Texturen, die durch die Prozesse PR3 und PR4 benötigt werden und für die Bilder durch die Hardwarevorrichtung B 166 aufbereitet werden. Die TIM C 174 schließlich verwaltet die Texturen für den Prozess PR5, für den Bilder durch die Hardwarevorrichtung 168 aufbereitet werden.
  • Ein weiteres anderes Ausführungsbeispiel des Systems der Erfindung ist in 3B gezeigt, bei der eine einzige TIM 176 die Texturdatenspeicherung in den lokalen Speichern mehrerer zugrundeliegender Hardwarevorrichtungen 164, 166 und 168 verwaltet. Die TIM 176 umfasst einen vorrichtungsunabhängigen Abschnitt 178 und einen vorrichtungsabhängigen Abschnitt 180. Der vorrichtungsunabhängige Abschnitt 178 der TIM 176 verwaltet den Texturspeicher, steuert die gesockelte Kommunikation mit jedem der Hardwaretreiber und implementiert, wenn Hardwarevorrichtungsunterbrechungen auftreten, Routinen (die wiederum vorrichtungsabhängige Routinen aufrufen), um zu bestimmen, welche Blöcke von Texturdaten durch die Hardwarevorrichtungen benötigt werden und welche Blöcke von Texturdaten innerhalb der lokalen Speicher der Hardwarevorrichtungen überschrieben werden sollten. Die vorrichtungsabhängigen Abschnitte 182, 184 und 188 der TIM 176 lesen von den zugrundeliegenden Hardwarevorrichtungen 164, 166 bzw. 168 und schreiben zu denselben. Wenn eine Unterbrechung innerhalb einer speziellen Hardwarevorrichtung auftritt, würde der entsprechende vorrichtungsabhängige Abschnitt der TIM Daten von der Hardwarevorrichtung lesen und mit dem vorrichtungsunabhängigen Abschnitt der TIM kommunizieren. Es würde dann eine Routine implementiert, um die Texturdaten zu bestimmen, die durch die Hardwarevorrichtung benötigt werden. Dann würde eine andere Routine implementiert, um zu bestimmen, welcher Block von Texturdaten innerhalb des lokalen Speichers dieser Hardwarevorrichtung überschrieben werden sollte. Dann würde eine Routine innerhalb des entsprechenden vorrichtungsabhängigen Abschnitts der TIM die neuen Texturdaten zu der geeigneten Position innerhalb des lokalen Speichers der Hardwarevorrichtung schreiben, mit dem dieselbe verbunden ist.
  • Ein Beispiel einer speziellen Texturabbildungscomputergrafiksystemhardwarevorrichtung, bei der die Softwarehintergrundroutine (TIM) der vorliegenden Erfindung wirksam sein kann, ist unten mit Bezug auf 4 – 24 detailliert beschrieben. Auf die Beschreibung der Hardwarevorrichtung folgt eine detaillierte Beschreibung des Betriebs der Softwarehintergrundroutine der vorliegenden Erfindung.
  • Beispiele des Betriebs der Software der Erfindung sind vorgesehen, die vorrichtungsspezifische Parameter umfassen, die sich auf die Hardwarevorrichtung des unten beschriebenen Beispiels beziehen. Eine derartige vorrichtungsspezifische Beschreibung soll lediglich exemplarisch sein und ist in keiner Weise begrenzend, da die Software der vorliegenden Erfindung bei zahlreichen unterschiedlichen Hardwarevorrichtungen wirksam sein kann, die einen lokalen Hardwarespeicher zum temporären Speichern von Abschnitten von Texturabbildungen umfassen, die benötigt werden, um Bilder aufzubereiten. Wenn die Hardwarevorrichtung eine Textur oder einen Texturabschnitt benötigt, der zu dieser Zeit nicht in dem lokalen Hardwarevorrichtungsspeicher gespeichert ist, tritt eine Unterbrechung auf, die durch die Softwarehintergrundroutine der Erfindung gehandhabt wird, um die erforderliche Textur oder einen Abschnitt derselben herunterzuladen. Die Software der Erfindung läuft auf dem Systemprozessor des Hostcomputers und ist in dem Systemspeicher des Hostcomputers gespeichert, wobei der Hostcomputer mit der Grafikhardwarevorrichtung verbunden ist.
  • II. Hardwarevorrichtungsbeispiel
  • A. Hardwarevorrichtungssystemübersicht
  • 4 ist ein Blockdiagramm eines Ausführungsbeispiels einer Grafiksystemhardwarevorrichtung, bei der die Software der Erfindung verwendet werden kann. Die Vorrichtung umfasst eine Texturabbildungshardware, die einen Cache-Speicher zum lokalen Speichern von Texturdaten aufweist. Es ist klar, dass die gezeigte darstellende Implementierung mit Bezug auf die Anzahl von Platinen und Chips, die Weise, in der dieselben partitioniert sind, die Busbreiten und die Datentransferraten lediglich exemplarisch ist. Zahlreiche andere Implementierungen können verwendet werden. Wie es gezeigt ist, umfasst das System eine Vorderseitenplatine (Front-End-Platine) 10, eine Texturabbildungsplatine 12 und eine Rahmenpufferplatine 14. Die Vorderseitenplatine kommuniziert mit einem Hostcomputer 15 über einen 52-Bit-Bus 16. Die Vorderseitenplatine empfängt Grundelemente, die aufbereitet werden sollen, von dem Hostcomputer über den Bus 16. Die Grundelemente sind durch x,y,z-Vektorkoordinatendaten, R,G,B-Farbdaten und Textur-S,T-Koordinaten für Abschnitte der Grundelemente spezifiziert, wie beispielsweise für die Scheitel, wenn das Grundelement ein Dreieck ist. Daten, die die Grundelemente in drei Dimensionen darstellen, werden dann durch die Vorderseitenplatine 10 zu der Texturabbildungsplatine 12 und der Rahmenpufferplatine 14 über einen 85-Bit-Bus 18 geliefert. Die Texturabbildungsplatine interpoliert die empfangenen Grundelementdaten, um die Bildschirmanzeigepixel zu berechnen, die das Grundelement darstellen werden, und bestimmt entsprechende resultierende Texturdaten für jedes Grundelementpixel. Die resultierenden Texturdaten werden zu der Rahmenpufferplatine über fünf 55-Bit-Busse 28 geliefert, die in 4 als ein einziger Bus gezeigt sind, um die Figur deutlicher zu machen.
  • Die Rahmenpufferplatine 14 interpoliert ebenfalls die Grundelementdaten, die von der Vorderseitenplatine 10 empfangen werden, um die Pixel auf dem Anzeigebildschirm zu berechnen, die jedes Grundelement darstellen werden, und um Objektfarbwerte für jedes Pixel zu bestimmen. Die Rahmenpufferplatine kombiniert dann auf einer pixelweisen Basis die Objektfarbwerte mit den resultierenden Texturdaten, die von der Texturabbildungsplatine geliefert werden, um resultierende R,G,B-Bildwerte für jedes Pixel zu erzeugen. R,G,B-Farbsteuersignale für jedes Pixel werden jeweils über R,G,B-Leitungen 29 geliefert, um die Pixel des Anzeigebildschirms (nicht gezeigt) zu steuern, um ein resultierendes Bild auf dem Anzeigebildschirm anzuzeigen, das das texturabgebildete Grundelement darstellt.
  • Die Vorderseitenplatine 10, die Texturabbildungsplatine 12 und die Rahmenpufferplatine 14 arbeiten jeweils pipelineartig und sind an mehreren Grundelementen gleichzeitig wirksam. Während die Texturabbildungs- und die Rahmenpufferplatine an Grundelementen wirksam sind, die vorhergehend durch die Vorderseitenplatine geliefert wurden, ist die Vorderseitenplatine weiter an neuen Grundelementen wirksam und liefert dieselben, bis die Pipelines bzw. Leitungen in den Platinen 12 und 14 voll werden.
  • Die Vorderseitenplatine 10 umfasst einen Verteilerchip 30, Dreidimensional-Geometrie-Beschleunigerchips (3-D-Geometrie-Beschleunigerchips) 32A, 32B und 32C, einen Zweidimensional-Geometrie-Beschleunigerchip (2-D-Geometrie-Beschleunigerchip) 34 und einen Konzentratorchip 36. Der Verteilerchip 30 empfängt die X,Y,Z-Koordinate und Farbgrundelementdaten über den Bus 16 von dem Hostcomputer und verteilt 3-D-Grundelementdaten gleichmäßig unter den 3-D-Geometrie-Beschleunigerchips 32A, 32B und 32C. Auf diese Weise wird die Systembandbreite erhöht, weil man an drei Gruppen von Grundelementen gleichzeitig wirksam ist. Daten werden über einen 40-Bit-Bus 38A zu den 3-D-Geometrie-Beschleunigerchips 32A und 32B und über einen 40-Bit-Bus 38B zu dem Chip 32C geliefert. Beide Busse 38A und 38B übertragen Daten mit einer Rate von 60 MHZ und liefern eine ausreichende Bandbreite, um zwei 3-D-Geometrie-Beschleunigerchips zu unterstützen. 2-D-Grundelementdaten werden über einen 44-Bit-Bus 40 zu dem 2-D-Geometrie-Beschleunigerchip 34 mit einer Rate von 40 MHZ geliefert.
  • Jeder 3-D-Geometerie-Beschleunigerchip transformiert die x,y,z-Koordinaten, die die empfangenen Grundelemente definieren, in entsprechende Bildschirmraumkoordinaten, bestimmt R,G,B-Objektwerte und S,T-Texturwerte für die Bildschirmraumkoordinaten, zerlegt Grundelement-Vierecke in Dreiecke und berechnet eine Dreiecksebenengleichung, um jedes Dreieck zu definieren. Jeder 3-D-Geometrie-Beschleunigerchip führt ferner Ansichtsabschneideoperationen durch, um eine genaue Bildschirmanzeige des resultierenden Bilds sicherzustellen, wenn mehrere Fenster innerhalb des Bildschirms angezeigt sind oder wenn ein Abschnitt eines Grundelements sich über das Ansichtsvolumen hinaus erstreckt, das auf dem Anzeigebildschirm dargestellt ist. Ausgangsdaten von den 3-D-Geometrie-Beschleunigerchips 32A, 32B und 32C werden über 44-Bit-Busse 42A, 42B bzw. 42C zu dem Konzentratorchip 36 mit einer Rate von 60 MHZ geliefert. Der Zweidimensional-Geometrie-Beschleunigerchip 34 liefert ferner Ausgangsdaten zu dem Konzentratorchip 36 über einen 46-Bit-Bus 44 mit einer Rate von 45 MHZ. Der Konzentratorchip 36 kombiniert die 3-D-Grundelement-Ausgangsdaten, die von den 3-D-Geometrie-Beschleunigerchips 32A–C empfangen werden, ordnet die Grundelemente zu der ursprünglichen Reihenfolge um, die dieselben vor einer Verteilung durch den Verteilerchip 30 aufwiesen, und liefert die kombinierten Grundelement-Ausgangsdaten über den Bus 18 zu der Texturabbildungs- und der Rahmenpufferplatine.
  • Die Texturabbildungsplatine 12 umfasst einen Texturabbildungschip 46 und einen lokalen Speicher 48, der vorzugsweise als ein Cache-Speicher angeordnet ist. Bei einem bevorzugten Ausführungsbeispiel ist der Cache-Speicher aus unten erörterten Gründen aus einer Mehrzahl von SDRAM-Chips (SDRAM = synchronous dynamic random access memory = synchroner dynamischer Direktzugriffsspeicher) gebildet. Wie es unten detaillierter beschrieben ist, speichert der Cache-Speicher 48 Textur-MIP-Abbildungsdaten, die den Grundelementen zugeordnet sind, die in der Rahmenpufferplatine aufbereitet werden. Die Textur-MIP-Abbildungsdaten werden von einem Hauptspeicher 17 des Hostcomputers 15 über einen Bus 40 durch den 2-D-Geometrie-Beschleunigerchip 34 und über einen 24-Bit-Bus 24 heruntergeladen.
  • Der Texturabbildungschip 46 empfängt nacheinander Grundelementdaten über den Bus 18, die die Grundelemente darstellen, die auf dem Anzeigebildschirm aufbereitet bzw. wiedergegeben werden sollen. Wie es oben erörtert ist, umfassen die 22 Grundelemente, die von den 3-D-Geometrie-Beschleunigerchips 32A–C geliefert werden, Punkte, Linien und Dreiecke. Die Texturabbildungsplatine führt keine Texturabbildung von Punkten oder Linien durch und ist lediglich an dreieckigen Grundelementen wirksam. Die Daten, die die dreieckigen Grundelemente darstellen, umfassen die x,y,z-Objektpixelkoordinaten für zumindest einen Scheitel, die R,G,B-Objektfarbwerte des zumindest einen Scheitels, die Koordinaten in S,T der Abschnitte der Texturabbildung, die dem zumindest einen Scheitel entsprechen, und die Ebenengleichung des Dreiecks. Der Texturabbildungschip 46 ignoriert die z-Objektpixelkoordinate und die R,G,B-Objektfarbwerte. Der Chip 46 interpoliert die x,y-Pixelkoordinaten und interpoliert S- und T-Koordinaten, die jedem x,y-Anzeigebildschirmpixel entsprechen, das dem Grundelement entspricht. Für jedes Pixel greift der Texturabbildungschip auf den Abschnitt der Textur-MIP-Abbildung, der demselben entspricht, von dem Cache-Speicher zu und berechnet resultierende Texturdaten für das Pixel, die einen gewichteten Durchschnitt mehrerer Texel umfassen können.
  • Bei einem exemplarischen Ausführungsbeispiel speichert der Cache vierundsechzig Blöcke von 256 × 256-Texeln. Ungleich dem lokalen Speicher, der bei der Texturabbildungshardware von Systemen des Stands der Technik verwendet wird, speichert der Cache-Speicher der vorliegenden Erfindung eventuell nicht die gesamte Reihe von MIP-Abbildungen der Textur, die auf das aufbereitete Grundelement abbildet, wie beispielsweise bei großen Texturen. Ungleich Systemen des Stands der Technik speichert der Cache-Speicher zusätzlich eventuell nicht die Reihe von MIP-Abbildungen für mehrere Texturen, die zu dem aufbereiteten Grundelement abbilden. Vielmehr speichert der Cache-Speicher zu irgendeiner Zeit lediglich die speziellen Abschnitte der Reihe von MIP- Abbildungen, die tatsächlich bei einem aktuellen Aufbereiten des Grundelements verwendet werden. Deshalb ist bei den meisten Anwendungen lediglich ein Abschnitt der vollständigen Texturdaten für das Bild, das aufbereitet wird, zu irgendeiner Zeit in dem Cache-Speicher gespeichert.
  • Die vollständige Reihe von MIP-Abbildungen für jede Textur ist in dem Hauptspeicher 17 des Hostcomputers 15 angeordnet und gespeichert. Die TIM der vorliegenden Erfindung läuft auf dem Prozessor des Hostcomputers. Für jedes Pixel des Grundelements, das aufbereitet wird, greift der Texturabbildungschip 46 auf ein Verzeichnis des Cache-Speichers 48 zu, um zu bestimmen, ob das entsprechende Texel oder die entsprechenden Texel der Textur-MIP-Abbildungen gegenwärtig in dem Cache vorhanden sind. Falls die entsprechenden Texel zur Zeit des Zugriffs in dem Cache-Speicher gespeichert sind, tritt ein Cache-Treffer auf und die Texel werden von dem Cache gelesen und an demselben ist der Texturabbildungschip 46 wirksam, um die resultierenden Texturdaten zu berechnen, die zu der Rahmenpufferplatine geleitet werden.
  • Falls jedoch die entsprechenden Texel für das Grundelementpixel nicht in dem Cache-Speicher gespeichert sind, wenn auf denselben durch den Texturabbildungschip 46 zugegriffen wird, tritt ein Cache-Fehltreffer auf. Wenn ein Cache-Fehltreffer auftritt, wird der Abschnitt der Textur-MIP-Abbildungsdaten, der benötigt wird, um das Grundelement aufzubereiten, von dem Hauptspeicher 17 des Hostcomputers 15 in den Cache-Speicher 48 unter Verwendung der TIM heruntergeladen, wobei möglicherweise einige Daten ersetzt werden, die vorhergehend in denselben gespeichert sind. Ungleich herkömmlichen Texturabbildungssystemen jedoch, die die gesamte Reihe von MIP-Abbildungen für irgendein Grundelement herunterladen, das aufbereitet wird, lädt die TIM der vorliegenden Erfindung lediglich den Abschnitt der Reihe von MIP-Abbildungen herunter, der tatsächlich benötigt wird, um gegenwärtig das Grundelement oder den gegenwärtig aufbereiteten Abschnitt desselben aufzubereiten. Wie es unten detaillierter erläutert ist, wird, wenn ein Cache-Fehltreffer auftritt, ein Unterbrechungssteuersignal durch den Texturabbildungschip 46 erzeugt, um eine Texturunterbrechungsverwaltungseinrichtung in dem Hostcomputer 15 einzuleiten. Das Unterbrechungssteuersignal wird über eine Leitung 94 zu dem Verteilerchip 30 geliefert, der wiederum ein Unterbrechungssignal über eine Leitung 95 zu dem Hostcomputer liefert.
  • Die angeforderten Texturdaten werden durch die TIM aus dem Hauptspeicher derselben wiedererlangt und werden zu der Texturabbildungsplatine 48 über den Bus 24 heruntergeladen, wobei die 3-D-Grundelementaufbereitungspipeline durch die Vorderseitenplatine und den Texturabbildungschip umgangen wird. Wenn somit eine Cache-Fehltreffer-Unterbrechung auftritt, kann die Vorderseitenplatine weiter an 3-D-Grundelementen wirksam sein und Ausgangsgrundelementdaten über den Bus 18 zu dem Texturabbildungschip und der Rahmenpufferplatine liefern, während die Texturdaten, die einem Grundelement zugeordnet sind, das den Cache-Fehltreffer bewirkt hat, von dem Hauptspeicher 17 heruntergeladen werden. Im Gegensatz zu herkömmlichen Texturabbildungssystemen erfordert das Herunterladen von Texturdaten zu der Texturabbildungshardware kein Spülen der 3-D-Grundelementpipeline, wodurch die Bandbreite und Leistungsfähigkeit des Systems erhöht wird.
  • Die resultierenden Texturdaten für jedes Pixel werden durch den Texturabbildungschip 46 zu der Rahmenpufferplatine über fünf Busse 28 geliefert. Die fünf Busse 28 sind mit fünf Rahmenpuffersteuerungschips 50A, 50B, 50C, 50D bzw. 50E gekoppelt, die an der Rahmenpufferplatine vorgesehen sind, und liefern resultierende Texturdaten parallel zu den Rahmenpuffersteuerungschips. Die Rahmenpuffersteuerungschips 50A–E sind jeweils mit Gruppen von zugeordneten VRAM-Chips (VRAM = video random access memory = Video-Direktzugriffsspeicher) 51A–E gekoppelt. Die Rahmenpufferplatine umfasst ferner vier Videoformatchips 52A, 52B, 52C und 52D und einen RAMDAC (random access memory digital-to-analog converter = Direktzugriffsspeicher-Digital-zu-Analog-Wandler) 54. Die Rahmenpuffersteuerungschips steuern unterschiedliche, nichtüberlappende Segmente des Anzeigebildschirms. Jeder Rahmenpuffersteuerungschip empfängt Grundelementdaten von der Vorderseitenplatine über den Bus 18 und resultierende Texturabbildungsdaten von der Texturabbildungsplatine über den Bus 28. Die Rahmenpuffersteuerungschips interpolieren die Grundelementdaten, um die Anzeigebildschirmpixelkoordinaten in den jeweiligen Segmenten derselben, die das Grundelement darstellen, und die entsprechenden R,G,B-Objektfarbwerte für jede Pixelkoordinate zu berechnen. Für diese Grundelemente (d. h. Dreiecke), für die resultierende Texturdaten von der Texturabbildungsplatine geliefert werden, kombinieren die Rahmenpuffersteuerungschips auf einer pixelweisen Basis die Objektfarbwerte und die resultierenden Texturdaten, um endgültige R,G,B-Werte für jedes Pixel zu erzeugen, das auf dem Anzeigebildschirm angezeigt werden soll.
  • Die Weise, in der die Objekt- und Texturfarbwerte kombiniert werden, kann auf eine Anzahl unterschiedlicher Weisen gesteuert sein. In einem Ersetzungsmodus beispielsweise können die Objektfarbwerte einfach durch die Texturfarbwerte ersetzt werden, so dass die Texturfarbwerte bei einem Aufbereiten des Pixels verwendet werden. Alternativ können in einem Moduliermodus die Objekt- und die Texturfarbwerte miteinander multipliziert werden, um die endgültigen R,G,B-Werte für das Pixel zu erzeugen. Ferner kann ein Farbsteuerwort für jedes Texel gespeichert sein, das das Verhältnis spezifiziert, das die Weise definiert, in der die entsprechenden Texturfarbwerte mit den Objektfarbwerten kombiniert werden sollen. Ein resultierendes Farbsteuerwort kann für die resultierenden Texeldaten bestimmt sein, die jedem Pixel entsprechen, und zu den Rahmenpuffersteuerungschips über den Bus 28 geliefert werden, so dass die Steuerungschips das Verhältnis, das durch das entsprechende resultierende Steuerwort spezifiziert ist, verwenden können, um die endgültigen R,G,B-Werte für jedes Pixel zu bestimmen. Die resultierenden Bildvideodaten, die durch die Rahmenpuffersteuerungschips 50A–E erzeugt werden, einschließlich R,G,B-Werte für jedes Pixel, sind in den entsprechenden VRAM-Chips 51A–E gespeichert. Jede Gruppe von VRAM-Chips 51A–E umfasst acht VRAM-Chips, derart, dass vierzig VRAM-Chips an der Rahmenpufferplatine positioniert sind. Jeder Videoformatchip 52A–D ist mit einem unterschiedlichen Satz von zehn VRAM-Chips verbunden und empfängt Daten von demselben. Die Videodaten werden seriell aus den VRAM-Chips verschoben und werden über 64-Bit-Busse 58A, 58B, 58C und 58D zu den vier Videoformatchips 52A, 52B, 52C bzw. 52D mit einer Rate von 33 MHZ geliefert. Die Videoformatchips formatieren die Videodaten, so dass dieselben durch den RAMDAC gehandhabt werden können, und liefern die formatierten Daten über 32-Bit-Busse 60A, 60B, 60C und 60D zu dem RAMDAC 54 mit einer Rate von 33 MHZ. Der RAMDAC 54 wiederum wandelt die digitalen Farbdaten in analoge R,G,B-Farbsteuersignale um und liefert die R,G,B-Steuersignale für jedes Pixel zu einer Bildschirmanzeige (nicht gezeigt) entlang R,G,B-Steuerleitungen 29.
  • Bei einem Ausführungsbeispiel ist eine Hardware an der Texturabbildungsplatine 12 und der Rahmenpufferplatine 14 repliziert, so dass bestimmte Grundelementaufbereitungsaufgaben an mehreren Grundelementen parallel durchgeführt werden können, wodurch die Bandbreite des Systems erhöht wird. Ein Beispiel eines derartigen anderen Ausführungsbeispiels einer Hardwarevorrichtung ist in 4A gezeigt, die ein Blockdiagramm einer Computergrafikhardwarevorrichtung ist, bei der die TIM der Erfindung verwendet werden kann. Die spezielle Hardwarevorrichtung läßt eine bestimmte Hardware replizieren. Das System von 4A umfasst vier 3-D-Geometrie-Beschleunigerchips 32A, 32B, 32C und 32D, zwei Texturabbildungschips 46A und 46B, die Cache-Speichern 48A bzw. 48B zugeordnet sind, und zehn Rahmenpufferchips 50A – 50J, jeweils mit einer zugeordneten Gruppe von VRAM-Chips. Der Betrieb des Systems von 4A ist demselben des Systems von 4, das oben beschrieben ist, ähnlich. Die Replizierung der Hardware bei dem Ausführungsbeispiel von 4A ermöglicht eine erhöhte Systembandbreite, weil bestimmte Grundelementaufbereitungsoperationen parallel an mehreren Grundelementen durchgeführt werden können.
  • B. Texturabbildungschipübersicht
  • Ein Blockdiagramm des Texturabbildungschips 46 ist in 5 gezeigt. Der Chip 46 umfasst eine Vorderseitenpipelineschnittstelle 60, die Objekt- und Texturgrundelementdaten von der Vorderseitenplatine über den 64-Bit-Bus 18 empfängt. Die Dreieck-Grundelemente, an denen der Texturabbildungschip wirksam ist, sind durch bis zu zweiundfünfzig 32-Bit-Digitalwörter definiert, aber können durch Wörter unterschiedlicher Längen definiert sein. Die Pipelineschnittstelle umfasst einen Satz von Master-Registern und einen Satz von entsprechenden Slave-Registern. Während eines Aufbereitens werden die Master-Register sequentiell mit den zweiundfünfzig Digitalwörtern von Daten gefüllt, die das Grundelement definieren. Auf einen Empfang eines geeigneten Aufbereitungsbefehls hin werden dann die Daten in die Slave-Register in der Pipelineschnittstelle verschoben, was in einer pipelineartigen Weise ermöglicht, dass die Master-Register mit Daten gefüllt werden, die ein anderes Grundelement darstellen. Die Grundelementdaten, die über den Bus 18 geliefert werden, umfassen die x,y,z-Vektorkoordinatendaten, die S,T-Texturkoordinaten und die R,G,B-Objektfarbdaten für zumindest einen Dreiecksscheitel, sowie Daten, die die Dreiecksebenengleichung darstellen. Wie es oben erörtert ist, ignoriert der Texturabbildungschip die z-Objektpixelkoordinate und die R,G,B-Objektfarbwerte und speichert lediglich die anderen Daten bei der Vorderseitenpipelineschnittstelle 60.
  • Die Slave-Register der Pipelineschnittstelle 60 übertragen die Grundelementdaten über einen Bus 62 zu einer Parameter interpolatorschaltung 64. Die Parameterinterpolatorschaltung 64 interpoliert jedes Grundelement-Dreieck, um für jede Anzeigebildschirmpixelkoordinate, die das Dreieck darstellt, die S,T-Texturabbildungskoordinaten für die Texturabbildung, die zu dem Pixel abbildet, und einen S- und einen T-Gradientenwert (ΔS, ΔT) zu bestimmen. Der S- und der T-Gradient sind gleich Veränderungen bei der S- bzw. der T-Koordinate zwischen benachbarten Pixeln und werden in einer unten erörterten Weise berechnet.
  • Die Parameter-Interpolatorschaltung 64, die in 6 detaillierter gezeigt ist, umfasst einen Kantenschrittgeber 66, einen FIFO-Puffer (FIFO = „first-in, first-out" = „zuerst hinein, zuerst heraus") 68, einen Spannenschrittgeber 70 und eine Gradienten- und Perspektivenkorrekturschaltung 72, die alle in Reihe geschaltet sind. Der Kantenschrittgeber startet bei der x,y-Pixelkoordinate eines der Dreiecksscheitel und bewegt sich unter Verwendung der Dreiecksebenengleichung schrittweise entlang der Kanten des Dreiecks, um die Pixelkoordinaten zu bestimmen, die die Dreieckskanten definieren. Für jede Pixelkoordinate werden S- und T-Texturabbildungskoordinaten basierend auf den S,T-Werten der Dreiecksscheitel bestimmt, um zu identifizieren, welche Texel in der Texturabbildung jeder Anzeigebildschirmpixelkoordinate entsprechen. Die Pixel- und Texelkoordinaten sind temporär in dem FIFO-Puffer gespeichert und werden zu dem Spannenschrittgeber geliefert. Bei jeder x,y-Pixelposition entlang einer Kante des Dreiecks bewegt sich der Spannenschrittgeber schrittweise über die entsprechende Spanne des Dreiecks, um die S,T-Texelkoordinaten für jede Pixelposition entlang der Spanne zu bestimmen.
  • Jede S- und T-Koordinate für ein Anzeigebildschirmpixel kann einen ganzzahligen Abschnitt und einen Bruchabschnitt aufweisen, falls das Pixel nicht direkt (in einer Eins-zu-Eins-Entsprechung) zu einem einzigen Texel in einer der Reihe von MIP-Abbildungen für die Textur abbildet. Wie es oben erläutert ist, kann jedes Anzeigebildschirmpixel, wenn dasselbe zu der Texturabbildung abgebildet ist, zwischen mehreren Texeln in einer der Reihe von MIP-Abbildungen für die Textur liegen und kann deshalb (größenmäßig) zwischen benachbarten MIP-Abbildungen in der Reihe liegen.
  • Die Gradienten- und Perspektivenkorrekturschaltung 72 bestimmt die Gradientenwerte von S und (ΔS, ΔT) für jedes Anzeigebildschirmpixel. Bei einem Ausführungsbeispiel ist der Gradient ΔS ausgewählt, um der größere eines Gradienten ΔSx und eines Gradienten ΔSy zu sein, wobei der Gradient ΔSx die Veränderung bei der S-Koordinate in der Texturabbildung ist, wenn sich die Koordinate x zwischen benachbarten Pixeln auf dem Anzeigebildschirm verändert, und der Gradient ΔSy die Veränderung bei der S-Koordinate ist, wenn sich die Koordinate y zwischen benachbarten Pixeln verändert. Der Gradient ΔT wird ähnlich berechnet. Die Gradienten ΔS, ΔT für ein Anzeigebildschirmpixel geben die Veränderungsrate bei einer Koordinatenposition innerhalb der Texturabbildung für eine Veränderung eines Pixels auf dem Anzeigebildschirm in der entsprechenden S,T-Abmessung an und werden verwendet, um zu bestimmen, auf welche MIP-Abbildung oder -Abbildungen zugegriffen werden sollte, um die resultierenden Texturdaten für das Pixel zu liefern. Zum Beispiel gibt ein Gradient gleich Zwei für ein Anzeigebildschirmpixel an, das das Pixel zu vier (d. h. 22, wie es unten erörtert ist) Texeln abbildet, so dass auf die MIP-Abbildung, die größenmäßig um zwei von der Basisabbildung (z. B. der 102 in 1) reduziert ist, zugegriffen werden sollte, um die resultierenden Texturdaten für das Pixel zu liefern. Wenn sich somit der Gradient erhöht, ist die Größe der MIP-Abbildung, auf die zugegriffen wird, um die resultierenden Texturdaten für das Pixel zu liefern, reduziert.
  • Bei einem Ausführungsbeispiel wird ein einziger Gradient, der gleich dem Größeren von ΔS und ΔT ist, verwendet, um die geeignete MIP-Abbildung für jedes Pixel auszuwählen, derart, dass der Gradient gleich dem Größten von ΔSx, ΔSy, ΔTx und ΔTy für das Pixel ist. Es ist jedoch klar, dass der Gradient alternativ in einer unterschiedlichen Weise ausgewählt werden kann, wie beispielsweise durch ein Auswählen des kleinsten dieser Werte, eines Durchschnitts dieser Werte oder einer gewissen anderen Kombination. Da ein einziger Gradient ausgewählt wird, der die Veränderungsrate bei lediglich einer der S-, T-Koordinaten angibt, stellt das Quadrat des Gradienten die Anzahl von Texeln dar, die zu dem entsprechenden Pixel abbilden.
  • Aus dem Gradienten bestimmt der Parameterinterpolator die nächste Abbildung, zu der das Pixel abbildet, und den Abstand von dieser Abbildung. Diese Informationen werden als eine ganze Abbildungsnummer der nächsten Abbildung und in einem Abbildungsbruchwert geliefert, wobei der Bruchwert den Abstand des Pixels von der nächsten Abbildung angibt.
  • Unter erneuter Bezugnahme auf das Blockdiagramm des Texturabbildungschips in 5 werden die Texeldaten, die von der Parameterinterpolatorschaltung 64 ausgegeben werden, über eine Leitung 70 zu einem Kachelbilder und Grenzprüfer 72 geliefert, der die Adresse der vier Texel bestimmt, die am nächsten zu der Position bei jeder der Texturabbildungen sind, die durch die Texeldaten spezifiziert sind, und überprüft, um zu bestimmen, ob jede innerhalb der Grenze der Textur ist. Die Texeldaten umfassen die interpolierten S,T-Koordinaten (ganzzahlige und Bruchwerte) sowie die Abbildungsnummer und den Abbildungsbruch. Der Kachelbilder verwendet den ganzzahligen Abschnitt der S- und T-Koordinaten, die durch den Parameterinterpolator 64 berechnet werden, und fügt Eins zu dem ganzzahligen Abschnitt jeder hinzu, um die Adressen der vier nächsten Texel zu erzeugen. Der Grenzprüfer bestimmt dann, ob die S,T-Koordinaten für jegliche dieser vier Texel aus der Grenze der Texturabbildung fallen. Falls ein Anzeigebildschirmpixel zu einer S,T-Koordinatenposition abbildet, die aus der Grenze der Texturabbildung fällt, wird eines von mehreren Texturabbildungsschemata implementiert, um zu bestimmen, ob irgendwelche resultierenden Texturdaten für dieses Pixel erzeugt werden sollen, und wie diese Daten erzeugt werden sollen. Beispiele derartiger Schemata umfassen ein Umhüllen (eine Wiederholung der Textur), ein Spiegeln (eine Wiederholung des Spiegelbilds der Textur), ein Ausschalten einer Texturabbildung außerhalb der Grenze und ein Anzeigen einer ausgefüllten Farbe außerhalb der Grenze.
  • Die Fähigkeit eines Ermöglichens, dass ein Pixel zu einer Position in einer Texturabbildung abbildet, die jenseits der Grenze derselben liegt, liefert eine Flexibilität bei der Weise, in der Texturen zu Objektgrundelementen abgebildet werden können. Es kann beispielsweise erwünscht sein, eine Textur in einer wiederholenden Weise zu einem Objekt abzubilden, derart, dass die Textur zu mehreren Abschnitten des Objekts abgebildet wird. Falls beispielsweise eine Textur als S,T-Koordinaten aufweisend definiert ist, die zwischen einschließlich [0,0] und nicht einschließlich (10,10) liegen, könnte ein Benutzer bestimmte Abschnitte des Objekts spezifizieren, die zu S,T-Koordinaten von einschließlich [10,10] bis nicht einschließlich (20,20) abzubilden sind. Die Notierung der mit eckigen Klammern versehenen einschließlichen Koordinaten gibt an, dass diese Koordinaten in dem Abschnitt der Textur enthalten sind, der zu dem Objekt abgebildet wird, während das Objekt lediglich zu den S,T-Koordinaten bis zu und nicht einschließlich der nicht einschließlichen Koordinaten in runden Klammern abbildet. Falls das Umhüllungsmerkmal für S,T-Koordinaten ausgewählt ist, die aus der Grenze der Textur fallen, würden Pixel, die S,T-Koordinaten von [10,10] bis (20,20) aufweisen, jeweils zu den Texeln bei S,T-Koordinaten [0,0] bis (10,10) abbilden.
  • Wie es oben erörtert ist, können die resultierenden Texturdaten von einer zweidimensionalen Texturabbildung für ein einziges Pixel das Ergebnis einer Kombination von bis zu acht Texeln, d. h. den vier nächsten Texeln in den zwei nächsten MIP-Abbildungen sein. Es gibt eine große Anzahl von Weisen, in denen die acht Texel kombiniert werden können, um die resultierenden Texeldaten zu erzeugen. Zum Beispiel kann das einzige nächste Texel in der nächsten Abbildung ausgewählt werden, so dass keine Mittelung erforderlich ist. Alternativ können das einzige nächste Texel in jeder der zwei nächsten Abbildungen basierend auf dem Wert des Gradienten miteinander gemittelt werden. Derartige Schemata bilden die Textur nicht so genau ab, als wenn die acht nächsten Texel gemittelt werden.
  • Bei einem Ausführungsbeispiel der Hardwarevorrichtung wird eine trilineare Interpolierung unterstützt, bei der die resultierenden Texturdaten für ein einziges Pixel als ein gewichteter Durchschnitt von bis zu acht Texeln berechnet werden können. Der Gradient, der Veränderungsraten von S,T darstellt, wird verwendet, um die zwei nächsten MIP-Abbildungen zu identifizieren, von denen auf Texturdaten zuzugreifen ist, und es wird auf die vier nächsten Texel innerhalb jeder Abbildung zugegriffen. Der Durchschnitt der vier Texel innerhalb jeder Abbildung wird basierend darauf gewichtet, welche Texel am nächsten zu den S,T-Koordinaten der Position in der MIP-Abbildung sind, zu der das Anzeigebildschirmpixel abbildet. Der Bruchabschnitt der S- und T-Koordinaten für das Pixel wird verwendet, um diese Gewichtung durchzuführen. Der Durchschnittswert von jeder der zwei nächsten MIP-Abbildungen wird dann basierend auf dem Wert des Gradienten gewichtet. Ein Bruchwert wird aus dem Gradienten für eine Verwendung bei diesem Gewichtungsprozess berechnet. Zum Beispiel befindet sich ein Gradient von Drei auf halber Strecke zwischen den MIP-Abbildungen, die Gradienten von Zwei bzw. Vier entsprechen.
  • Der Texelinterpolierungsprozess wird durch die Texelinterpolatoren 76 durchgeführt. Die Bruchabschnitte der S- und T-Koordinaten für jedes Anzeigebildschirmpixel werden von den Parameterinterpolatoren durch den Kachelbilder/Grenzprüfer zu dem Texelinterpolator 76 über Leitungen 74 geliefert. Die Bruchabschnitte werden durch den Texelinterpola tor verwendet, um die während einer Interpolierung der mehreren Texel jedem Texel gewährte Gewichtung bei einem Berechnen resultierender Texeldaten zu bestimmen.
  • Wie es oben erörtert ist, sind Textur-MIP-Abbildungen, die einem Grundelement, das aufbereitet wird, zugeordnet sind, lokal in dem Cache-Speicher 48 (8) gespeichert. Bei einem Ausführungsbeispiel ist der Cache vollständig assoziativ. Der Cache umfasst acht SDRAM-Chips, die in vier Verschachtelungen geteilt sind, wobei sich zwei SDRAM-Chips in jeder Verschachtelung befinden. Es sind vier getrennte Steuerungen vorgesehen, wobei einer jeder Verschachtelung entspricht, so dass auf die SDRAM-Chips innerhalb jeder Verschachtelung simultan zugegriffen werden kann. Jeder SDRAM-Chip umfasst zwei gesonderte Speicherbänke, in denen auf unterschiedliche Speicherseiten bei aufeinanderfolgenden Lesezyklen zugegriffen werden kann, ohne Seitenumladungseinbußen zu erleiden, die einem Zugreifen auf Daten von zwei unterschiedlichen Seiten (d. h. von zwei unterschiedlichen Zeilenadressen) bei einem herkömmlichen DRAM häufig zugeordnet sind.
  • Die Texturdaten (d. h. die MIP-Abbildungen) sind in 256 × 256-Texelblöcke von Daten geteilt. Der Cache-Speicher kann bis zu vierundsechzig Datenblöcke zu einer Zeit speichern. Jeder Block weist eine zugeordnete Blockkennung auf, die den Block eindeutig identifiziert. Der Cache umfasst ein Cache-Verzeichnis 78, das die Blockkennungen speichert, die den Datenblöcken entsprechen, die aktuell in dem Cache gespeichert sind. Wie es unten detaillierter beschrieben ist, umfasst jede Blockkennung einen Texturidentifizierer (Textur-ID), der die spezielle Textur identifiziert, die der Datenblock darstellt, eine Abbildungsnummer, die die spezielle MIP-Abbildung innerhalb der Reihe von Abbildungen der Textur identifiziert, die der Datenblock darstellt, und S- und T-Koordinaten hoher Ordnung, die die Position des Datenblocks innerhalb der speziellen Abbildung identifizieren. Die physische Position der Blockkennung innerhalb des Cache-Verzeichnisses stellt die Position des entsprechenden Datenblocks innerhalb des Cache-Speichers dar.
  • MIP-Abbildungen von mehr als einer Textur können in dem Cache-Speicher simultan gespeichert werden, wobei der Texturidentifizierer zwischen den unterschiedlichen Texturen unterscheidet. Einige MIP-Abbildungen enthalten weniger als 256 × 256 Texel und verbrauchen deshalb keinen ganzen Datenblock. Zum Beispiel überschreiten die kleineren Abbildungen in einer Reihe von MIP-Abbildungen oder sogar die größeren Abbildungen für kleine Texturen eventuell nicht 256 × 256 Texel. Um einen Speicherplatz effizient zu nutzen, können Abschnitte mehrerer Abbildungen in einem einzigen Block von Texturdaten gespeichert werden, wobei jeder Abbildungsabschnitt einem Teilblock innerhalb des Blocks zugewiesen ist. Jede der mehreren Abbildungen, die innerhalb eines einzigen Blocks gespeichert sind, weist einen zugeordneten Untertexturidentifizierer (Untertextur-ID) auf, der die Position der Abbildung innerhalb des Blocks identifiziert.
  • Während einer Aufbereitung erzeugt der Kachelbilder/Grenzprüfer 72 eine Lese-Cache-Kennung für den Block von Texturdaten, der zu dem Pixel abbildet, das aufbereitet werden soll. Die Weise, in der die Cache-Blockkennung und die Lese-Cache-Kennung erzeugt werden, ist unten detaillierter erläutert. Die Kennungen sind 23-Bit-Felder, die acht Bits, die den Textur-ID der Texturdaten darstellen, ein Bit, das bei einem Bestimmen der Abbildungsnummer der Texturdaten verwendet wird, und die sieben S- und T-Koordinaten hoher Ordnung der Texturdaten umfassen. Das Cache-Verzeichnis 78 vergleicht die Lese-Cache-Kennung, die von dem Kachelbilder/Grenzprüfer geliefert wird, mit den Blockkennungen, die in dem Verzeichnis gespeichert sind, um zu bestimmen, ob der Block von Texturdaten, der bei einem Aufbereiten verwendet werden soll, sich in dem Cache-Speicher befindet. Falls die Blockkennung der Texturdaten, die zu dem Grundelement abbilden, das aufbereitet werden soll, in dem Cache-Verzeichnis gespeichert ist (d. h. in dasselbe trifft), dann erzeugt das Cache-Verzeichnis einen Blockindex, der die physische Position des Blocks von Texturdaten in dem Cache angibt, die der getroffenen Kennung entspricht. Die Berechnung des Blockindex ist unten detaillierter erörtert. Eine Texeladresse wird ebenfalls durch den Kachelbilder/Grenzprüfer 72 für jedes Texel erzeugt, das von dem Cache gelesen werden soll und gibt die Position des Texels innerhalb des Blocks an. Die Texeladresse umfasst Adressbits niedriger Ordnung der interpolierten S,T-Koordinaten für Abbildungen größerer Größe und wird basierend auf einem unten beschriebenen Algorithmus für Abbildungen kleinerer Größe berechnet. Der Blockindex und die Texeladresse weisen zusammen die Cache-Adresse auf, die die Position des Texels innerhalb des Cache angibt. Wie es unten detaillierter beschrieben ist, werden die LSBs der S- und T-Koordinaten decodiert, um zu bestimmen, in welcher von vier Cache-Verschachtelungen das Texel gespeichert ist, und die verbleibenden Bits der Cache-Adresse werden zu der Texel-Cache-Zugriffsschaltung 82 zusammen mit einem Befehl über eine Leitung 84 geliefert, um die Texeldaten zu lesen, die bei der adressierten Position in dem Cache gespeichert sind.
  • Falls die Lese-Cache-Kennung nicht mit irgendeiner der Blockkennungen übereinstimmt, die in dem Cache-Verzeichnis 78 gespeichert sind, tritt ein Fehltreffer auf und das Cache-Verzeichnis 78 erzeugt ein Unterbrechungssteuersignal über eine Leitung 94 (4) zu dem Verteilerchip 30 an der Vorderseitenplatine, der eine Unterbrechung über eine Leitung 95 zu dem Hostcomputer 15 erzeugt. Ansprechend auf die Unterbrechung liest die TIM, die unten detaillierter erörtert ist, die verfehlte Blockkennung aus dem Cache-Verzeichnis und lädt den entsprechenden Block von Texturdaten in den Cache-Speicher in einer Weise herunter, die die 3-D-Grundelementpipeline in der Vorderseitenplatine 10 und dem Texturabbildungschip 46 umgeht. Die Texturdaten, die von der TIM heruntergeladen werden, werden über den Bus 24 durch das Texeltor 92 (5) zu der Texel-Cache-Zugriffsschaltung 82 geliefert, die die Daten zu den SDRAMs schreibt, die den Cache-Speicher bilden.
  • Wenn ein Cache-Fehltreffer auftritt, wartet der Texturabbildungschip darauf, dass die neuen Texturdaten heruntergeladen sind, bevor derselbe mit einem Verarbeiten des Grundelements fortfährt, an dem der Fehltreffer auftrat. Die Stufen der Pipeline jedoch, die dem Cache-Lesevorgang folgen, verarbeiten diese Grundelemente weiter, die vor dem verfehlten Grundelement empfangen wurden. Auf ähnliche Weise verarbeiten die Stufen der Pipeline, die dem Cache-Lesevorgang vorangehen, ebenfalls Grundelemente weiter, außer und bis die Pipeline sich hinter der Cache-Leseoperation füllt, während auf das Herunterladen der neuen Texturdaten gewartet wird.
  • Während eines Aufbereitens fahren die späteren Stufen der Pipeline in der Rahmenpufferplatine 14 nicht mit einem Verarbeiten eines Grundelements fort, bis die Texturdaten, die dem Grundelement entsprechen, von der Texturabbildungsplatine empfangen werden. Wenn deshalb ein Cache-Fehltreffer auftritt und der Texturabbildungschip darauf wartet, dass die neuen Texturdaten heruntergeladen werden, wartet die Rahmenpufferplatine 14 gleichermaßen darauf, dass die resultierenden Texturdaten von dem Texturabbildungschip geliefert werden. Wie bei dem Texturabbildungschip fahren die Stufen der Pipeline, die der Stufe folgen, die die Texturabbildungsdaten empfängt, fort, diese Grundelemente zu verarbeiten, die vor dem verfehlten Grundelement empfangen wurden, und die Stufen der Pipeline, die der Stufe vorangehen, die Texturabbildungsdaten empfängt, fahren ebenfalls fort, Grundelemente zu verarbeiten, außer und bis sich die Pipeline füllt.
  • Es ist klar, dass, wenn die Pipeline entweder der Texturabbildungsplatine oder der Rahmenpufferplatine bei einem Warten auf neue Texturdaten ansprechend auf einen Cache- Fehltreffer sichert, die Pipeline bei der Vorderseitenplatine 10 gleichermaßen sichert. Weil Cache-Fehltreffer auftreten und in einem Zugriff auf den Hostcomputer-Hauptspeicher und ein Herunterladen von Texturdaten, das mehrere Zyklen benötigt, um abzuschließen, resultiert, ist es erwünscht, sicherzustellen, dass die Pipeline in dem Texturabbildungschip niemals warten muss, weil die Pipeline in der Rahmenpufferplatine gesichert wurde. Deshalb ist bei einem Ausführungsbeispiel die Rahmenpufferplatine mit einer tieferen Grundelementpipeline als die Texturabbildungsplatine versehen, so dass die Texturabbildungspipeline durch ein Warten darauf, dass die Rahmenpufferplatine verfügbar wird, nicht verzögert werden sollte.
  • Bei einem Ausführungsbeispiel ist die Fähigkeit vorgesehen, eine Texturabbildung auszuschalten. Dies wird durch die TIM erzielt, die auf dem Prozessor 19 des Hostcomputers wirksam ist, um ein Register in sowohl der Texturabbildungsplatine 12 als auch der Rahmenpufferplatine 14 zu setzen. Wenn dieselben gesetzt sind, um eine Texturabbildung auszuschalten, unterbinden diese Register jeweils, dass der Texturabbildungschip 46 Texturdaten zu der Rahmenpufferplatine 14 liefert, und weisen die Rahmenpufferplatine an, mit einem Aufbereiten von Grundelementen fortzufahren, ohne auf Texturdaten von der Texturabbildungsplatine zu warten.
  • Wie es oben beschrieben ist, kann für jedes Anzeigebildschirmpixel, das mit Texturdaten aus einer zweidimensionalen Texturabbildung aufbereitet wird, auf bis zu vier Texel aus einer MIP-Abbildung (bilineare Interpolierung) oder acht Texel aus zwei benachbarten MIP-Abbildungen (trilineare Interpolierung) von dem Cache-Speicher zugegriffen werden, um die resultierenden Texturdaten für das Pixel zu bestimmen. Die Texel, die von dem Cache gelesen werden, werden über einen Bus 86 (5) zu dem Texelinterpolator 76 geliefert, der die mehreren Texel interpoliert, um resultierende Texeldaten für jedes Pixel zu berechnen. Die Interpolierung kann abhängig von einem für das System eingerichteten Modus variieren. Wenn ein Punktabtastinterpolierungsmodus eingerichtet ist, sind die resultierenden Texeldaten gleich dem einzigen Texel, das am nächsten zu der Position ist, die durch die S,T-Koordinaten des Pixels in der Texturabbildung definiert ist. Wenn alternativ eine bilineare oder trilineare Interpolierung verwendet wird, sind die resultierenden Texeldaten jeweils ein gewichteter Durchschnitt der vier oder acht nächsten Texel in der einen oder den zwei nächsten Abbildungen. Die Gewichtung, die jedem der mehreren Texel gegeben wird, wird basierend auf dem Wert des Gradienten und der Bruchkomponenten der S- und T-Koordinaten bestimmt, die von dem Kachelbilder/Grenzprüfer zu dem Texelinterpolator 76 geliefert werden.
  • Die resultierenden Texeldaten für die Anzeigebildschirmpixel werden sequentiell über einen Bus 88 zu einem Rahmenpufferschnittstelle-FIFO-Puffer 90 geliefert. Der Rahmenpufferschnittstelle-FIFO-Puffer 90 kann bis zu vierundsechzig resultierende Texel speichern.
  • Jedes resultierende Texel ist ein 32-Bit-Wort, das acht Bits umfasst, um jedes von R,G,B und α darzustellen. Das α-Byte gibt der Rahmenpufferplatine 14 (4) die Weise an, in der die R,G,B-Werte der resultierenden Texturdaten mit den R,G,B-Werten der Objektdaten kombiniert werden sollten, die durch die Rahmenpufferplatine bei einem Berechnen endgültiger R,G,B-Anzeigebildschirmwerte für irgendein Pixel berechnet werden, das zu dem Texel abbildet. Die Ausgänge T0 – T4 des Rahmenpufferschnittstelle-FIFO-Puffers werden zu der Rahmenpufferplatine 14 (4) über den Bus 28 geliefert. Die Rahmenpufferplatine kombiniert die R,G,B-Werte der resultierenden Texeldaten mit den R,G,B-Objektwerten in der Weise, die durch ?a? spezifiziert ist, um endgültige R,G,B-Werte für jedes Anzeigebildschirmpixel zu erzeugen.
  • C. Cache-Speicher-Organisation
  • 7 ist ein Blockdiagramm einer Cache-Speicherimplementierung gemäß einem darstellenden Ausführungsbeispiel, gekoppelt mit Abschnitten des Texturabbildungschips einschließlich des Texeltors 92, des Texturinterpolators 76, des Cache-Verzeichnisses 78 und der Texel-Cache-Zugriffsschaltung 82. Bei diesem darstellenden Ausführungsbeispiel umfasst der Cache-Speicher 48 vier Verschachtelungen 204A, 204B, 204C und 204D. Jede Verschachtelung umfasst zwei SDRAM-Chips (nicht gezeigt), auf die gleichzeitig zugegriffen werden kann, wobei jeder acht Datenbits während eines Lesezyklus liefert. Jedes 32-Bit-Wort von Texeldaten ist in dem Cache in einer einzigen Verschachtelung gespeichert, wobei acht Bits bei jeder von zwei aufeinanderfolgenden Positionen in jedem SDRAM in der Verschachtelung gespeichert sind. Um somit ein Texel von dem Cache zu lesen, werden zwei Lesezyklen an aufeinanderfolgenden Positionen in der geeigneten Verschachtelung durchgeführt, um die 32 Bits von Texeldaten zu liefern. Wie es unten erläutert ist, muss lediglich ein Adresswort (einschließlich Zeilen- und Spaltendaten) zu den SDRAMs innerhalb jeder Verschachtelung geliefert werden, um einen Stoß (Burst) von Daten an zwei aufeinanderfolgenden Zyklen zu ergeben. Der Stoß umfasst sechzehn Bits, die an einem ersten Zyklus von der gegebenen Adresse geliefert werden, und sechzehn Bits, die an einem zweiten Zyklus von einer Adresse geliefert werden, die die gleiche Zeile und eine Spalte aufweist, die um Eins inkrementiert ist.
  • Die Texel-Cache-Zugriffsschaltung 82 umfasst vier getrennte Steuerungen, die mit Steuerung A (200A), Steuerung B (200B), Steuerung C (200C) und Steuerung D (200D) etikettiert sind. Die vier Steuerungen A, B, C und D können simultan auf Daten aus den vier Verschachtelungen 204A, 204B, 204C und 204D durch parallele Busse 202A, 202B, 202C und 202D zugreifen. Die Steuerungen lesen Texeldaten von dem Speicher 48 ansprechend auf Befehle und bei Adressen, die über Busse 84A, 84B, 84C bzw. 84D empfangen werden.
  • Wie es oben beschrieben ist, kann jedes Pixel möglicherweise zu vier Texeln aus einer MIP-Abbildung oder acht Texeln aus mehreren MIP-Abbildungen abbilden. Wie es unten detaillierter erörtert ist, werden die Texeldaten, die zu dem Cache heruntergeladen werden, in dem Hauptspeicher des Hostcomputers durch die TIM organisiert, so dass immer vier benachbarte Texel in jeder MIP-Abbildung in getrennten Verschachtelungen positioniert sind, so dass auf dieselben parallel zugegriffen werden kann. Somit können immer vier benachbarte Texel in einer MIP-Abbildung, die eventuell benötigt werden, um resultierende Texeldaten durch eine bilineare Interpolierung zu erzeugen, in einer einzigen Leseoperation gelesen werden. Wenn eine trilineare Interpolierung verwendet wird, können die zwei Sätze von vier Texeln aus benachbarten MIP-Abbildungen in zwei Leseoperationen gelesen werden.
  • 8 stellt ein Beispiel der Weise dar, in der Blöcke von Texturdaten (es sind lediglich einige Texel gezeigt) organisiert werden, um die Vier-Verschachtelung-Implementierung des Cache-Speichers auszunutzen, um zu ermöglichen, dass immer vier benachbarte Texel in einer MIP-Abbildung simultan gelesen werden. Jedes Texel ist mit A, B, C oder D etikettiert, um die Verschachtelung in dem Cache-Speicher zu identifizieren, in der das Texel gespeichert ist. Das Muster der A–D-Etikette wiederholt sich, so dass irgendeine Position in der Abbildung zwischen vier Texel fällt, die mit A, B, C und D etikettiert sind. Bei einem Pixel, das zu irgendeiner Position innerhalb der Abbildung abbildet, befinden sich somit die vier nächsten Texel in getrennten Verschachtelungen A – D, so dass auf dieselben simultan durch die vier unabhängigen Steuerungen 200A–D zugegriffen werden kann. Zum Beispiel bildet ein Pixel P0 zu einer Position zwischen vier Texeln ab, die mit A, B, C und D etikettiert sind, und ein Pixel P1 bildet zu einer Position zwischen vier Texeln ab, die mit B, A, D und C etikettiert sind.
  • Es ist klar, dass die oben beschriebene Cache-Implementierung lediglich zu darstellenden Zwecken vorgesehen ist und dass andere Implementierungen verwendet werden können. Zum Beispiel kann der Cache in acht getrennten Verschachtelungen implementiert sein, mit acht getrennten Steuerungen, so dass, wenn eine trilineare Interpolierung verwendet wird, auf die acht Texel simultan von dem Cache in einer einzigen Leseoperation zugegriffen werden kann.
  • Jeder SDRAM-Chip in dem Cache-Speicher ist intern in zwei gleich große Bänke geteilt, die simultan getrennte aktive Seiten (d. h. Gruppen von Speicherpositionen, die eine gemeinsame Zeilenadresse aufweisen) beibehalten können. Somit kann auf Daten an aufeinanderfolgenden Lesezyklen von unterschiedlichen Seiten innerhalb der zwei Bänke eines SDRAM-Chips zugegriffen werden, ohne die Seitenumladungseinbuße zu erleiden, die einem aufeinanderfolgenden Lesen von Daten von unterschiedlichen Seiten bei einem herkömmlichen DRAM allgemein zugeordnet ist.
  • Wie es unten detaillierter erläutert ist, sind die Texturdaten in dem Cache-Speicher organisiert, um dieses Merkmal der SDRAMs auszunutzen, um Seitenüberquerungseinbußen zu minimieren, wenn eine trilineare Interpolierung durchgeführt wird. Die acht Texel, die für eine trilineare Interpolierung benötigt werden, umfassen Sätze von vier Texeln aus zwei MIP-Abbildungen. Jeder Satz von vier benachbarten Texeln in einer einzigen Abbildung ist angeordnet, so dass einer in jeder der Verschachtelungen A, B, C und D in der oben beschriebenen Weise gespeichert ist, so dass auf die vier Texel simultan zugegriffen werden kann. Ferner sind gemeinsame Daten aus benachbarten MIP-Abbildungen in der Reihe von Abbildungen für irgendeine Textur in dem Cache in unterschiedlichen SDRAM-Bänken gespeichert. Wenn eine trilineare Interpolierung durchgeführt wird, werden vier Texel aus einer MIP-Abbildung simultan aus einer der SDRAM-Bänke der Verschachtelungen A – D während der zwei Lesezyklen eines ersten Stoßes gelesen und vier Texel aus einer benachbarten MIP-Abbildung werden aus der anderen SDRAM-Bank während der zwei Lesezyklen eines nachfolgenden Stoßes gelesen. Weil beide Bänke der SDRAMs simultan zeilenaktiv sein können, kann auf die zwei Sätze von vier Texeln bei aufeinanderfolgenden Stößen zugegriffen werden, ohne eine Seitenumladungseinbuße zu erleiden. Es ist klar, dass, wenn Pixel eines Objekts aufbereitet werden, benachbarte Pixel häufig zu den gleichen zwei MIP-Abbildungen für die Textur abbilden, was erfordert, dass Lesevorgänge zu dem Cache kontinuierlich zwischen den Cacheblöcken umschalten, die die gemeinsamen Daten in den zwei Abbildungen speichern. Diese Cache-Organisation, die ermöglicht, dass zwei Seiten innerhalb jedes SDRAM aktiv bleiben, ist vorteilhaft, weil dieselbe ermöglicht, dass eine trilineare Interpolierung durchgeführt wird, ohne eine Seitenumladungseinbuße bei jedem Zyklus zu erleiden, wenn zwischen zwei benachbarten MIP-Abbildungen während eines Aufbereitens von Anzeigebildschirmpixeln umgeschaltet wird.
  • 9 ist ein detaillierteres Blockdiagramm der oben beschriebenen darstellenden Implementierung des Cache-Speichers. Der Cache umfasst acht SDRAM-Chips, die mit SD1 – SD8 etikettiert sind und gleichmäßig unter den vier Verschachtelungen 204A – 204D geteilt sind, wobei jede Verschachtelung zwei SDRAM-Chips umfasst. Die zwei SDRAMs in jeder Verschachtelung verwenden die folgenden gemeinsamen Leitungen gemeinschaftlich: eine Adressleitung (ADD), Zeilen- und Spaltenadressübernahmesignale (RAS und CAS), eine Schreibfreigabe (WE), eine Taktfreigabe (CKE) und eine Dateneingabe-/Ausgabemaske (DQM). Die SDRAMs innerhalb jeder Verschachtelung sind mit acht getrennten Datenleitungen gekoppelt, durch die acht Datenbits während jedes Lese- oder Schreibzyklus gelesen bzw. geschrieben werden. Jeder SDRAM-Chip umfasst zwei Speicherbänke, wobei jede Bank bis zu 1048576 8-Bit-Wörter von Texturdaten speichert.
  • Auf die zwei SDRAMs in jeder Verschachtelung kann simultan zugegriffen werden und dieselben liefern sechzehn Datenbits, wobei einer der SDRAMs Datenbits [15:08] liefert und der andere Datenbits [07:00] liefert. Wie es oben erörtert ist, ergeben zwei aufeinanderfolgende Lesezyklen eines einzigen Stoßes ein vollständiges 32-Bit-Texel von Daten aus jeder Verschachtelung, wobei ein getrenntes 8-Bit-Wort jeden der R,G,B- und α-Werte für das Texel darstellt.
  • Die SDRAM-Chips empfangen zwanzig Adressbits, die an der Leitung ADD gemultiplext werden, um die 1048576 8-Bit-Wörter innerhalb jeder Bank zu decodieren. Wie es unten detailliert erläutert ist, werden ein 6-Bit-Blockindex und eine 16-Bit-Texeladresse für jedes Texel berechnet, auf das von dem Cache zugegriffen werden soll. Der Blockindex gibt an, in welchem der vierundsechzig Datenblöcke das Texel positioniert ist, und die Texeladresse gibt die genaue S,T-Koordinatenadresse des Texels innerhalb des Blocks an. Acht S-Bits und acht T-Bits weisen die Texeladresse auf, wobei ein quadratischer Block von 256 × 256 Texeln angenommen wird. Eine Cache-Adresse ist ein Zweiundzwanzig-Bit-Wort, das die Kombination des Blockindex (sechs MSBs) und der Texeladresse (sechzehn LSBs) umfasst. Die Cache-Adresse gibt die genaue Position des Texels innerhalb des Caches an.
  • Während einer Aufbereitung decodiert der Kachelbilder/Grenzprüfer das LSB S-Bit und das LSB T-Bit der Texeladresse (d. h. die LSB S-Koordinate und die LSB T-Koordinate), um zu bestimmen, in welcher der vier Verschachtelungen des Caches das Texel gespeichert ist. Die verbleibenden zwanzig größeren Adressbits der Cache-Adresse werden entlang der Adressleitung ADD zu den zwei SDRAM-Chips innerhalb der geeigneten Verschachtelung geliefert. Von den zwanzig Adressbits, die zu den zwei SDRAMs geliefert werden, werden neun Bits verwendet, um die Spalte auszuwählen, und elf Bits werden verwendet, um die Zeile innerhalb der SDRAMs auszuwählen, um auf die Texeldaten zuzugreifen. Wie es Fachleuten auf dem Gebiet klar sein sollte, werden die Spalten- und Zeilenadressbits getrennt in die SDRAMs an unterschiedlichen Zyklen gelatcht bzw. zwischengespeichert und die RAS- und CAS-Übernahmesignale werden herkömmlicherweise verwendet, um auf die Daten zuzugreifen.
  • Während eines Stoßes mit zwei Zyklen werden sechzehn Bits von der adressierten Position der zwei SDRAMs innerhalb der gleichen Verschachtelung während des ersten Zyklus geliefert und dann, ohne eine andere Adresse zu liefern, werden sechzehn Bits von einer anderen Position der zwei SDRAMs während des zweiten Zyklus geliefert. Die andere Adresse umfasst die gleiche Zeilenadresse und eine Spaltenadresse, die um Eins inkrementiert ist. Es ist ferner klar, dass, wenn einmal eine Seite (spezielle Zeilenadresse) aktiviert ist, dieselbe aktiviert bleibt, bis eine unterschiedliche Zeilenadresse geliefert wird. Falls deshalb aufeinanderfolgende Texel, die aus der gleichen Verschachtelung zugegriffen werden soll, sich in der gleichen Seite befinden (die gleiche Zeilenadresse umfassen), dann muss die Zeilenadresse lediglich einmal während des ersten der aufeinanderfolgenden Stoßes geliefert werden.
  • Zusätzlich werden die RAS-, die CAS- und die WE-Leitung verwendet, um auf eine herkömmliche Weise Daten zu adressieren und dieselben zu dem SDRAM-Chip zu schreiben. Wenn das Taktfreigabesignal bzw. CKE-Signal deaktiviert wird, wird der interne Takt ausgesetzt. Die SDRAMs sprechen auf dieses Signal durch ein intakt Halten von Daten an, wobei beide Bänke inaktiv gemacht werden. Das Daten-Eingang/Ausgang-Maske-Signal bzw. DQM-Signal wirkt als eine Ausgangsfreigabe während eines Lesezyklus und eine Eingangsdatenmaske während eines Schreibzyklus.
  • Eine herkömmliche SDRAM-Verwendung umfasst ein Bestimmen, von welcher zukünftigen Seite auf nachfolgende Daten zugegriffen wird, während auf vorliegende Daten von einer aktuellen Seite zugegriffen wird, und ein Aktivieren dieser zukünftigen Seite, bevor der Lesezyklus der vorliegenden Daten abgeschlossen ist. Weil SDRAMs ermöglichen, dass zwei unterschiedliche Seiten simultan aktiv sind, vermeidet die herkömmliche SDRAM-Verwendung Seitenumladungseinbußen, die einem Zugreifen auf Daten aus unterschiedlichen Seiten bei herkömmlichen DRAMs allgemein zugeordnet sind. Eine herkömmliche SDRAM-Verwendung sieht jedoch diesen Vorteil nicht vor, wenn Daten, die an vielen aufeinanderfolgenden Lesezyklen gelesen werden sollen, in unterschiedlichen Seiten positioniert sind, weil mehr als ein Zyklus erforderlich ist, um vorauszuschauen, und eine zukünftige Seite zu aktivieren. Das hierin beschriebene Texturdatenspeicherverfahren liefert einen Vorteil gegenüber einer herkömmlichen SDRAM-Verwendung durch ein Ermöglichen, dass mehrere aufeinanderfolgende SDRAM-Lesezyklen von unterschiedlichen Seiten auftreten, ohne eine Einbuße zu erleiden. Insbesondere durch ein Speichern gemeinsamer Daten aus benachbarten MIP-Abbildungen einer Textur (auf die während aufeinanderfolgenden Lesezyklen bei einem Ausführen einer trilinearen Interpolierung zugegriffen werden muss) in getrennten Bänken der SDRAMs kann auf die Daten aus den getrennten Bänken bei aufeinanderfolgenden Lesezyklen ohne eine Einbuße zugegriffen werden. Während das hierin beschriebene Verfahren einer Datenspeicherzuweisung zum Verbessern einer SDRRM-Leistungsfähigkeit mit Bezug auf die Speicherung von Texturabbildungsdaten gezeigt und beschrieben wurde, ist klar, dass das Verfahren nicht so begrenzt ist. Insbesondere ist das Verfahren anwendbar, um irgendeinen Typ von Daten zuzuweisen, bei dem mehrere aufeinanderfolgende Lesezyklen auf Daten aus unterschiedlichen Speicherpositionen zugreifen müssen.
  • D. Cache-Steuer-FIFOs
  • 10 ist ein detaillierteres Blockdiagramm eines Abschnitts des Texturabbildungschips, der den Grenzprüfer 72, das Cache-Verzeichnis 78, die Cache-Zugriffsschaltung 82, den Cache-Speicher 48 und den Texelinterpolator 76 umfasst. Die Texel-Cache-Zugriffseinheit 82 umfasst vier Cache-Zugriffsbefehl-FIFOs 206A, 206B, 206C und 206D. Die Cache-Zugriffsbefehl-FIFOs 206A–D speichern Cache-Zugriffsbefehle, die von dem Grenzprüfer über 16-Bit-Busse 84A, 84B, 84C bzw. 84D empfangen werden. Die Cache-Zugriffsbefehl-FIFOs 206A–D entsprechen den jeweiligen Steuerungen 200A–D, die in 7 gezeigt sind. Zum Beispiel rufen Befehle in dem FIFO 206A einen Cache-Zugriff auf die SDRAMs innerhalb der Verschachtelung 204A auf. Bei diesem Ausführungsbeispiel ist jeder Cache-Zugriffsbefehl-FIFO zum temporären Speichern von acht 16-Bit-Befehlen in der Lage. Um somit die Pipelinefähigkeit des Systems zu verbessern, können acht Befehle in jedem der Cache-Zugriffsbefehl-FIFOs gespeichert werden, bevor die Cache-Zugriffseinheit handelt.
  • Wie es oben erörtert ist, vergleicht während einer Aufbereitung der Grenzprüfer 72 die Lese-Cache-Kennung für jeden Block von Texturdaten, der zu dem Pixel abbildet, an dem man wirksam ist, mit jeder der Blockkennungen, die in dem Cache-Verzeichnis 78 gespeichert sind, um zu bestimmen, ob das Texel sich in dem Cache befindet. Falls ein Treffer auftritt, wird der Blockindex erzeugt, der die Position des entsprechenden Blocks von Texturdaten innerhalb des Cache darstellt. Der Kachelbilder/Grenzprüfer implementiert simultan eine Routine, um die Texeladresse aus den interpolierten S,T-Koordinaten den Textur-ID und den Untertextur-ID des speziellen Texels sowie die Abbildungsnummer der Abbildung, von der auf das Texel zugegriffen werden soll und die Größe der Basisabbildung der Textur zu bestimmen, wie es unten detailliert erläutert ist. Aus dem Blockindex und der Texeladresse (die gemeinsam die Cache-Adresse aufweisen) bestimmt der Optimierer dann die spezielle Verschachtelung des Cache, in der das Texel gespeichert ist, und die Spalten- und Zeilenadressbits der SDRAM-Chips dieser Verschachtelung, wie es oben erläutert ist. Die Adressinformationen werden zu dem entsprechenden Cache-Zugriffsbefehl-FIFO zusammen mit einem Befehl geliefert, um den Cache zu lesen.
  • Der Texelinterpolator 76 umfasst acht Texeldaten-FIFOs, die mit 214A0, 214A1, 214B0, 214B1, 214C0, 214C1, 214D0 und 214D1 etikettiert sind. Die Texeldaten-FIFOs 214A0 und 214A1 entsprechen der Verschachtelung 204A des Cache-Speichers, die FIFOs 214B0 und 214B1 entsprechen der Verschachtelung 204B, die FIFOs 214C0 und 214C1 entsprechen der Verschachtelung 204C und die FIFOs 214D0 und 214D1 entsprechen der Verschachtelung 204D.
  • Wie es oben beschrieben ist, kann auf jede der vier Verschachtelungen des Cache-Speichers simultan durch getrennte Cache-Zugriffswege zugegriffen werden. Während einer Aufbereitung, wenn die Texel-Cache-Zugriffseinheit 82 auf Texeldaten aus dem Cache-Speicher 48 zugreift, werden Texelzugriffssteuerwörter über Busse 208A, 208B, 208C und 208D zu dem Cache-Speicher 48 geliefert. Auf vier Texel wird simultan von den vier Verschachtelungen während zwei aufeinanderfolgender 16-Bit-Lesezyklen zugegriffen. Die vier Texel werden über Busse 210A, 210B, 210C bzw. 210D zu einem der Texeldaten-A-FIFOs (214A0 oder 214A1), einem der Texeldaten-B-FIFOs (214B0 oder 214B1), einem der Texeldaten-C-FIFOs (214C0 oder 214C1) bzw. einem der Texeldaten-D-FIFOs (214D0 oder 214D1) geliefert. Das Paar von Texeldaten-FIFOs (d. h. 0 und 1), das jeder Verschachtelung A – D entspricht, wird in abwechselnder Weise geladen. Zum Beispiel wird ein erstes Texel, das von der Verschachtelung A gelesen wird, in dem Texeldaten-FIFO 214A0 gespeichert, wird ein zweites Texel, das von der Verschachtelung A gelesen wird, in dem FIFO 214A1 gespeichert, wird ein drittes Texel von der Verschachtelung A in dem FIFO 214A0 gespeichert etc. Dieses abwechselnde Schema wird aus Gründen verwendet, die unten erörtert sind.
  • Jeder der Texeldaten-FIFOs ist zweiunddreißig Bit breit und acht Stufen tief. In Kombination speichern die acht FIFOs 214 acht pipelineartige Stufen, wobei jede Stufe die acht Texel umfasst, die verwendet werden, um resultierende Texeldaten während einer trilinearen Interpolierung zu bestimmen. Die Busse 210A, 210B, 210C und 210D sind sechzehn Bit breit. Jedes SDRAM-Paar in jeder Verschachtelung liefert während jedes Lesezyklus sechzehn Datenbits. Während jedes Stoßes werden die ersten sechzehn Bits von jedem SDRAM-Paar in ein erstes 16-Bit-Register (nicht gezeigt) geliefert und die nächsten sechzehn Bits werden von jedem SDRAM-Paar in ein zweites 16-Bit-Register (ebenfalls nicht gezeigt) geliefert. Am Ende des zweiten Zyklus des Stoßes werden die Daten aus beiden Registern auf den entsprechenden 32-Bit-Bus 212A, 212B, 212C oder 212D geliefert. Um die resultierenden Texeldaten für irgendein Pixel zu bestimmen, greift der Texelinterpolator 76 auf die FIFOs zu, um die nächste Stufe von acht Texeln zu lesen, und interpoliert diese Texel in der oben beschriebenen Weise. Die resultierenden Texeldaten werden dann über den Bus 28 zu der Rahmenpufferplatine 14 (4) geliefert, wo dieselben bei dem Aufbereiten des Anzeigebildschirmpixels in der oben erörterten Weise verwendet werden.
  • Wenn eine trilineare Interpolierung durchgeführt wird, werden die resultierenden Texeldaten für irgendein Pixel aus vier Texeln in einer MIP-Abbildung und vier Texeln in einer benachbarten MIP-Abbildung interpoliert. Benachbarte Anzeigebildschirmpixel werden allgemein in Folge aufbereitet. Häufig bilden benachbarte Anzeigebildschirmpixel benachbarte Positionen in einer Textur-MIP-Abbildung ab. Folglich ist es häufig, dass einige gemeinsame Texeldaten bei einem Interpolieren resultierender Texeldaten für aufeinanderfolgend aufbereitete Grundelemente verwendet werden können. Bei einem Ausführungsbeispiel, wenn auf gemeinsame Texeldaten mehrere Male innerhalb einer Anzahl eng beabstandeter Lesezyklen zugegriffen wird, wird auf den Cache lediglich für den ersten Lesevorgang zugegriffen, wobei Cache-Lesezyklen für jeden aufeinanderfolgenden Lesevorgang eingespart werden. Die jüngst gelesenen Texel werden innerhalb der Texeldaten-FIFOs gespeichert. Somit werden nachfolgende Zugriffe auf diese Texel also aus den FIFOs und nicht dem Cache vorgenommen. Dies reduziert die Anzahl von erforderlichen Cache-Zugriffen, wodurch eine Systembandbreite erhöht wird.
  • Für jeden der Texeldatenwege A, B, C und D wird, falls die Texeldaten, die jüngst zu einem der Texeldaten-FIFOs 0 oder 1 für ein vorhergehendes Pixel geschrieben wurden, mit den Texeldaten für ein Pixel übereinstimmen, das sich gegenwärtig in der Pipelineposition zum Zugreifen auf den Cache befindet, dann ein Cache-Zugriffsbefehl nicht zu dem entsprechenden Cache-Zugriff-FIFO 206A, B, C oder D geliefert. Anstelle dessen wird ein Befehl zu dem Texelinterpolator gesendet, um anzugeben, dass die Texeldaten bei der jüngst geschriebenen Position des entsprechenden Texeldaten-FIFO 214A, B, C oder D gespeichert sind. Für irgendeinen der Wege A, B, C und D, bei dem die Texeldaten, die dem Pixel entsprechen, das sich gegenwärtig bei der Pipelineposition zum Zugreifen auf den Cache befindet, nicht mit diesen Daten bei der jüngst geschriebenen Position des entsprechenden Texeldaten-FIFO übereinstimmen, wird ein Texel-Cache-Zugriffsbefehl zu dem entsprechenden Texel-Cache-Zugriffsbefehl-FIFO geliefert, um diese Texeldaten aus dem Cache-Speicher 48 zu lesen.
  • Es ist klar, dass ein unterschiedliches Ergebnis für einige der Verschachtelungen A – D für irgendein Pixel auftreten kann, das sich gegenwärtig bei der Pipelineposition befindet, für die ein Cache-Zugriff betrachtet werden muss. Zum Beispiel können gemeinsame Texeldaten für aufeinanderfolgende Pixel für die Verschachtelung A aber nicht für die Verschachtelung B – D existieren. Bei einem derartigen Umstand werden Texeldaten von den Verschachtelungen B – D für das zweite der aufeinanderfolgenden Pixel bei der Pipelineposition zum Zugreifen auf Texeldaten aus dem Cache gelesen, aber die Texeldaten aus der Verschachtelung A für dieses zweite Pixel werden aus der gleichen Position eines der Texeldaten-FIFOs 214A0 oder 214A1 gelesen. Das vorliegende Schema liefert Bandbreiteneinsparungen, wenn Texel aus den Texeldaten-FIFOs für mehrere Pixel wiedergelesen werden, ohne auf den Cache zuzugreifen.
  • Der Texelinterpolator 76 umfasst einen Texelinterpolatorbefehl-FIFO 216, der 53-Bit-Befehle von dem Grenzprüfer 72 über einen 53-Bit-Bus 218 empfängt. Der Texelinterpolatorbefehl-FIFO kann bis zu sechzehn Befehle speichern, die dem Interpolator angeben, welche Texeldaten-FIFO-Positionen die Texeldaten enthalten, die bei einem Interpolieren der resultierenden Texeldaten während jedes Zyklus verwendet werden sollen. Die Interpolatorbefehle geben ferner den Interpolierungsmodus (d. h. Punktabtastung, bilinear oder trilinear) an und umfassen die Gradienten- und Bruchwerte der S- und T-Koordinaten, die die Weise spezifizieren, in der jedes Texel bei der Interpolierung gewichtet sein sollte. Die Befehle umfassen Daten, die angeben, von welchen Texeldaten-FIFOs 214A0, A1, B0, b1, C0, C1, D0 oder D1 jedes der vier (bilinear) oder acht (trilinear) Texel gelesen werden sollen, und ob die Texeldaten neu oder alt sind. Texeldaten sind neu, wenn dieselben von den Texeldaten unterschiedlich sind, die bei der jüngst geschriebenen Position eines Texeldaten-FIFO dieses Wegs gespeichert sind. Wenn dieselben neu sind, ist ein Cache-Lesevorgang erforderlich. Texeldaten sind alt, wenn dieselben die gleichen wie dieselben sind, die bei der jüngst geschriebenen Position eines Texeldaten-FIFO gespeichert sind. Wenn dieselben alt sind, ist kein Cache-Lesevorgang erforderlich. Wenn die Texeldaten neu sind, muss der FIFO-Lesezeiger zu einer nächsten Position innerhalb des FIFO bewegt werden, während, wenn die Texeldaten alt sind, die gleichen Daten von der gleichen FIFO-Position gelesen werden und der Lesezeiger nicht bewegt werden muss.
  • Das folgende, mit Bezug auf 11 und 12 erläuterte Beispiel stellt den Betrieb der in 10 gezeigten Texelzugriffsschaltung weiter dar. 11 zeigt mehrere Texel einer oberen MIP-Abbildung und mehrere Texel einer unteren (größenmäßig kleineren) MIP-Abbildung. Die Texel sind mit An, Bn, Cn und Dn (wobei n eine Ganzzahl darstellt) gemäß dem vorhergehend mit Bezug auf 8 beschriebenen Etikettierungsschema etikettiert. Sieben Pixel, die aufbereitet werden sollen, sind mit P0, P1,... P6 etikettiert. Wie es gezeigt ist, bilden die Pixel, die aufbereitet werden sollen, nicht direkt zu den Pixeln der MIP-Abbildung ab. Bei diesem Beispiel wird eine trilineare Interpolierung durchgeführt, derart, dass auf vier Texel aus der oberen Abbildung und vier Texel aus der unteren Abbildung zugegriffen wird und dieselben für jedes Pixel interpoliert werden. Die Schrittrichtung ist die Richtung eines Aufbereitens und entspricht der numerischen Nummerierung der Pixel.
  • 12 stellt den Cache-Zugriffsbefehl-FIFO (206A), den Texeldaten-FIFO A0 (214A0), den Texeldaten-FIFO A1 (214A1) und den Texelinterpolatorbefehl-FIFO 216 dar. Lediglich die FIFOs, die dem Texeldaten-A-Weg zugeordnet sind, sind einer Zweckmäßigkeit halber gezeigt, weil die FIFOs für jeden der anderen Texeldatenwege B, C und D in der gleichen Weise wirksam sind. Jeder FIFO-Puffer umfasst einen Schreibzeiger und einen Lesezeiger, die zu einzigen Positionen innerhalb des FIFO zeigen, zu denen Daten geschrieben werden sollten bzw. von denen Daten gelesen werden sollten. Die Zeiger können sich bei diesem darstellenden Ausführungsbeispiel um eine Position zu einer Zeit bewegen.
  • Das Pixel P0 bildet zu den Texeln A0, B0, C0 und D0 in der oberen Abbildung und den Texeln A0, B0, C0 und D0 in der unteren Abbildung ab, so dass diese acht Texel interpoliert werden, um die resultierenden Texeldaten für das Pixel P0 zu erzeugen. Für das Pixel P0 wird die Adresse des Texels A0 in der oberen Abbildung (d. h. uA0) zu einer ersten Position in dem Cache-Zugriffsbefehl-FIFO 206A zusammen mit einer Adresse geschrieben, die angibt, dass der Texeldaten-FIFO 214A0 mit den Texeldaten beschrieben werden sollte, die von dem Cache bei dieser Adresse gelesen werden. Als nächstes wird der Schreibzeiger des Cache-Zugriffsbefehl-FIFO 206A um eine Position bewegt und die Adresse des Texels A0 in der unteren Abbildung (d. h. lA0) wird zu der nächsten Position dieses FIFO zusammen mit einer Adresse geschrieben, die angibt, dass der Texeldaten-FIFO 214A1 mit den Texeldaten beschrieben werden sollte, die von dem Cache bei dieser Adresse gelesen werden. Auf diese Weise werden aus den oben erörterten Gründen die Texeldaten-FIFOs 0 und 1 abgewechselt. Die Cache-Zugriffsbefehl-FIFOs 206B–D werden auf eine ähnliche Weise mit Bezug auf die Texel B0, C0 und D0 in der oberen und der unteren Abbildung aktualisiert.
  • Für das Pixel P1 müssen die Texel A1 in der oberen und der unteren Abbildung, die bei Adressen uA1 bzw. 1A1 gespeichert sind, interpoliert werden. Da die Texel A1 in der oberen und der unteren Abbildung neue Texel sind und nicht Texeln von dem vorhergehenden Pixel P0 entsprechen, muss auf dieselben aus dem Cache zugegriffen werden. Somit werden die Texeladressen für diese Texel zu den nächsten zwei Positionen des Cache-Zugriffsbefehl-FIFO 206A zusammen mit den entsprechenden Adressen hinzugefügt, die angeben, dass die Texeldaten, die von diesen Adressen gelesen werden, in den Texeldaten-FIFOs 214A0 bzw. 214A1 gespeichert werden sollen. 12 stellt den Cache-Zugriffsbefehl-FIFO 206A dar, nachdem derselbe mit diesen Informationen aktualisiert wurde.
  • Weil es keine gemeinsamen A-adressierten Texel für die ersten zwei Pixel P0 und P1 gibt, wird auf den Cache-Speicher zugegriffen, um die Texeldaten für beide wiederzuerlangen. Der erste Befehl wird von dem Cache-Zugriffsbefehl-FIFO 206A gelesen, wobei bewirkt wird, dass die Texeldaten bei der Adresse uA0 aus dem Cache-Speicher gelesen und zu der ersten Position des Texeldaten-FIFO 214A0 geschrieben werden. Dann wird der nächste Befehl von dem Cache-Zugriffsbefehl-FIFO gelesen und es wird auf Texeldaten bei der Adresse lA0 von dem Cache zugegriffen und dieselben werden zu der ersten Position des Texeldaten-FIFO 214A1 geschrieben. Der nächste Befehl wird dann von dem Cache-Zugriffsbefehl-FIFO gelesen und es wird auf Texeldaten bei der Adresse uA1 von dem Cache zugegriffen und dieselben werden zu der nächsten Position in dem Texeldaten-FIFO 214A0 geschrieben. Schließlich wird der vierte Befehl von dem Cache-Zugriffsbefehl-FIFO gelesen und es wird auf die Texeldaten bei der Adresse lA1 von dem Cache zugegriffen und dieselben werden zu der nächsten Position des Texeldaten-FIFO 214A1 geschrieben.
  • Für das nächste Pixel P2, das aufbereitet werden soll, müssen Texel bei den Adressen uA1 und 1A1 interpoliert werden. Weil auf diese Texel für das vorhergehend aufbereitete Pixel P1 zugegriffen wurde, sind dieselben in den jüngst geschriebenen Einträgen in den Texeldaten-FIFOs 214A0 bzw. 214A1 gespeichert. Somit werden keine neuen Cache-Zugriffsbefehle für diese Texel zu dem Cache-Zugriffsbefehl-FIFO 206A geliefert. Vielmehr kann, nachdem die resultierenden Texeldaten für das Pixel P1 interpoliert sind, auf die Texeldaten, die bei den Adressen uA1 und 1A1 gespeichert sind, durch den Texelinterpolator von den jüngst gelesenen Positionen der Texeldaten-FIFOs 214A0 bzw. 214A1 zugegriffen werden, ohne auf den Cache zugreifen zu müssen. Ein Lesen von Daten direkt aus einem FIFO-Puffer ist weniger zeitraubend als ein Zugreifen auf Daten von einem Cache-Speicher. Deshalb erhöhen die FIFO-Puffer, die Cache-Zugriffe reduzieren, eine Systembandbreite.
  • Wie es oben erörtert ist, umfassen die Texeldaten-FIFOs 214, die jeder der Verschachtelungen A – D entsprechen, getrennt gesteuerte FIFOs 0 und 1. Die FIFOs sind auf diese Weise geteilt, um eine trilineare Interpolierung effizient zu implementieren. Wie aus dem Vorhergehenden ersichtlich ist, stellen bei dem oben beschriebenen Ausführungsbeispiel die Texeldaten-FIFOs 214 durch ein Beibehalten des Lesezeigers derselben, um für aufeinanderfolgende Lesevorgänge zu dem gleichen Eintrag zu zeigen, jeweils einen Zugriff auf den jüngst gelesenen Eintrag derselben bereit. Obwohl jede Verschachtelung zwischen Lesevorgängen von zwei Abbildungen während aufeinanderfolgender Lesezyklen abwechselt, können somit die getrennten FIFOs aufeinanderfolgende Lesevorgänge innerhalb einer einzigen Abbildung durchführen, wobei ermöglicht wird, dass der Lesezeiger bei aufeinanderfolgenden Zugriffen auf den FIFO zu den gleichen Texeldaten zeigt.
  • Wenn der Kachelbilder/Grenzprüfer 72 an jedem Pixel wirksam ist und Befehle zu dem Cache-Zugriffsbefehl-FIFO geliefert werden, werden Befehle ferner zu dem Texelinterpolatorbefehl-FIFO 216 geschrieben. Wenn beispielsweise der Befehl, um auf das Texel bei der Adresse uA0 zuzugreifen, zu dem Cache-Zugriffsbefehl-FIFO für das Pixel P0 geliefert wird, wird der Befehl New0 zu der ersten Position des Texelinterpolatorbefehl-FIFO 216 geliefert. Der Befehl New0 gibt dem Texelinterpolator an, dass auf die nächsten Texeldaten von der Verschachtelung A von dem Cache zugegriffen wird und dieselben zu dem Texeldaten-FIFO 214A0 geliefert werden, was angibt, dass, um die Texeldaten aus dem FIFO zu lesen, der Texelinterpolator den FIFO-Lesezeiger von der jüngst gelesenen Position um eine Position bewegen sollte.
  • Für den nächsten Befehl, der zu dem Cache-Zugriffsbefehl-FIFO geliefert wird, der der Texeladresse lA0 entspricht, wird der Befehl New1 zu der nächsten Position des Texelinterpolatorbefehl-FIFO geliefert. Der Befehl New1 gibt dem Texelinterpolator an, dass die nächsten Texeldaten aus der Verschachtelung A ebenfalls neu sind und von dem Texeldateninterpolator 214A1 gelesen werden sollten. Gleichermaßen werden für die Befehle, die den Texeladressen uA1 und lA1 zugeordnet sind, die dem Pixel P1 entsprechen, die Befehle New0 und New1 zu den jeweiligen nächsten zwei Positionen des Texelinterpolatorbefehl-FIFO 216 geschrieben.
  • Für das Pixel P2 lauten, da die Texeldaten bei den Adressen uA1 und lA1 identisch zu Daten sind, die zu den FIFOs für das vorhergehende Pixel P1 geschrieben werden, die Befehle, die zu den nächsten zwei Positionen des Texelinterpolatorbefehl-FIFO 216 geschrieben werden, Old0 und Old1, die dem Texelinterpolator angeben, dass die nächsten Texeldaten aus den jüngst gelesenen Positionen der Texeldaten-FIFOs 214A0 bzw. 214A1 wieder gelesen werden sollten. Die Befehle Old0 und Old1 geben an, dass, um die nächsten Texeldaten aus den FIFOs zu lesen, der Texelinterpolator den FIFO-Lesezeiger nicht von der jüngst gelesenen Position bewegen sollte.
  • 11 listet drei Tabellen auf: wobei die erste Tabelle die Texel angibt, die für jedes der Pixel interpoliert werden müssen, wobei die zweite Tabelle die getrennten Texeldatenwerte auflistet, die in den Texeldaten-FIFOs A0, B0, C0 und D0 gespeichert werden müssen; und wobei die dritte Tabelle die getrennten Texeldatenwerte auflistet, die in den Texeldaten-FIFOs A1, B1, C1 und D1 gespeichert werden müssen. Die Leerräume geben gemeinschaftlich verwendete Texeldaten an, die vorhergehend von dem Cache gelesen wurden, die nicht erneut von dem Cache gelesen werden müssen und auf die anstelle dessen von FIFOs zugegriffen werden kann. Wie diese Tabelle angibt, kann, wenn resultierende Texeldaten für mehrere Pixel interpoliert werden, eine große Anzahl von Cache-Zugriffen durch das FIFO-Schema eingespart werden, was in einer Erhöhung bei einer Systembandbreite resultiert.
  • 13 ist ein Blockdiagramm einer Schaltung, die durch den Texturabbildungschip verwendet wird, um zu bestimmen, ob bei jeder Verschachtelung Texeldaten, die für ein Pixel gelesen werden sollen, für das jüngst aufbereitete Pixel gelesen wurden. Diese Schaltung wird verwendet, um zu bestimmen, ob ein neuer Befehl zu einem der Cache- Zugriffsbefehl-FIFOs zu schreiben ist, um zu bewirken, dass neue Daten von dem Cache gelesen werden, oder um einen Befehl zu dem Texelinterpolatorbefehl-FIFO zu schreiben, der angibt, dass die Texeldaten alt sind und von einem der Texeldaten-FIFOs gelesen werden sollten. 13 zeigt lediglich eine einzige Schaltung, die der Verschachtelung A entspricht. Es sind jedoch auch ähnliche Schaltungen für die Verschachtelungen B, C und D vorgesehen. Die Schaltung ist innerhalb des Optimiererelements des Kachelbilders/Grenzprüfers positioniert. Aus dem interpolierten S,T-Wert, der durch den Kachelbilder/Grenzprüfer für jedes Texel, das interpoliert werden soll, empfangen wird, liefert der Optimierer eine Texeladresse (einschließlich der Blockkennung und Texeladresse) an einen Bus 220A. Die Adresse der jüngst verarbeiteten Texel, die den Texeldaten-FIFOs 214A0 und 214A1 zugeordnet sind, werden in den Adressregistern 222A0 bzw. 222A1 gespeichert. Die aktuelle Texeladresse wird mit den Texeladressen, die in den Registern 222A0 und 222A1 gespeichert sind, durch Komparatoren 224A1 bzw. 224A1 verglichen.
  • Wenn die vorliegende Texeladresse nicht mit einer der Adressen übereinstimmt, die in den Registern 222A0 und 222A1 gespeichert sind, muss auf Texeldaten, die dieser Texeladresse entsprechen, von dem Cache-Speicher zugegriffen werden und der geeignete Befehl wird zu dem Cache-Zugriffsbefehl-FIFO geschrieben. Wenn jedoch die Texeladresse mit der Adresse übereinstimmt, die in dem Adressregister 222A0 oder 222A1 gespeichert ist, werden die Texeldaten in dem Texeldaten-FIFO 212A bzw. 212A1 bei der Position gespeichert, die durch den Texelinterpolator unmittelbar vor einem Zugreifen auf die Texeldaten gelesen wird, die der Adresse entsprechen. Deshalb wird kein Cache-Zugriffsbefehl zu dem Cache-Zugriffsbefehl-FIFO geschrieben und ein Befehl wird zu dem entsprechenden Texelinterpolatorbefehl-FIFO geschrieben, der angibt, dass die Texeldaten alt sind und auf dieselben von der jüngst gelesenen FIFO- Position zugegriffen werden sollte, ohne den Lesezeiger zu bewegen.
  • E. Organisation von Texturdatenblöcken
  • 1 zeigt eine Reihe von quadratischen Textur-MIP-Abbildungen, die eine Basisabbildung 100 von 8 × 8 Texeln umfasst. Von der Basisabbildung ist jede aufeinanderfolgende Abbildung größenmäßig zu einer Abbildung 108 mit kleinster Größe (d. h. die lediglich ein Texel umfasst) gefiltert. Der Abbildung 108 kleinster Größe ist eine Abbildungsnummer von Null zugewiesen und die Abbildungsnummer für jede aufeinanderfolgende größere Abbildung ist um Eins inkrementiert, so dass die Basisabbildung 100 bei diesem Beispiel eine Abbildungsnummer von Drei aufweist. Die Abbildungsnummer wird bei einem Bestimmen der Blockkennung für jeden Block von Texturdaten auf eine unten beschriebene Weise verwendet. Gemäß diesem Abbildungsnummerierungsschema entspricht unter der Annahme einer quadratischen Texturbasisabbildung eine Abbildungsnummer von Zehn einer Abbildung von 1024 × 1024 Texeln, entspricht eine Abbildungsnummer von Neun einer Abbildung mit 512 × 512 Texeln, entspricht eine Abbildungsnummer von Acht einer Abbildung mit 256 × 256 Texeln usw. Falls die Texturbasisabbildung nicht quadratisch ist, dann entspricht eine Abbildungsnummer Zehn einer Abbildung, die eine größere Abmessung von 1024 Texeln aufweist. Während diese Erörterung eine quadratische Texturbasisabbildung annimmt, sind auch rechteckige Abbildungen möglich. Falls dieselbe rechteckig ist, ist die Abbildungsnummer durch die Anzahl von Texeln der längeren Abmessung der Abbildung bestimmt. Zum Beispiel weist eine rechteckige Abbildung, die eine Abbildungsnummer von Zehn aufweist, eine längere Abmessung mit 1024 Texeln auf. Es ist ferner klar, dass alternativ andere Abbildungsnummerierungsschemata verwendet werden können.
  • Eine Abbildung mit 1024 × 1024 Texeln, die eine Abbildungsnummer von Zehn aufweist, erfordert zehn Bits von S-Koordinaten S[9:0] und zehn Bits von T-Koordinaten T 9:0, um die Position jedes Texels innerhalb der Abbildung eindeutig zu identifizieren. Gleichermaßen erfordert eine Abbildung, die eine Abbildungsnummer von Neun aufweist, neun Bits von sowohl S- als auch T-Koordinaten, um die Position jedes Texels zu identifizieren, erfordert eine Abbildung, die eine Abbildungsnummer von Acht aufweist, acht Bits von sowohl S- als auch T-Koordinaten, um die Position jedes Texels zu identifizieren usw. Die S- und T-Koordinaten, die die Position eines Texels in einer MIP-Abbildung eindeutig identifizieren, die irgendeinem Pixel entspricht, werden in der oben beschriebenen Weise interpoliert.
  • Wie es unten detaillierter beschrieben ist, sind Texturdaten im Hauptspeicher 17 des Hostcomputers 15 (4) in Blöcken von 256 × 256 Texeln gespeichert. Wenn ein Cache-Fehltreffer auftritt, wird eine Lese-Cache-Kennung, die den Block von Texturdaten identifiziert, der in dem Cache verfehlt wurde, durch die TIM gelesen und dieser Block von Texturdaten wird dann zu dem Cache-Speicher 48 der Texturabbildungsplatine heruntergeladen. Vierundsechzig Blöcke von Texturdaten können in dem Cache-Speicher zu irgendeiner Zeit gespeichert sein. Diese vierundsechzig Blöcke von Texturdaten können Daten aus mehreren MIP-Abbildungen einer oder mehrerer Texturen umfassen. Jeder Block weist eine zugeordnete Blockkennung auf, die denselben eindeutig identifiziert. MIP-Abbildungen, die eine Abbildungsnummer von Neun oder größer aufweisen, umfassen mehr als 256 × 256 Texel und sind deshalb in mehreren Blöcken gespeichert. Die S,T-Koordinaten hoher Ordnung für irgendeine Abbildung, die in mehreren Blöcken gespeichert ist, sind in der Blockkennung für die Blöcke von Daten, die die Abbildung speichern, enthalten.
  • Zum Beispiel weisen MIP-Abbildungen, die eine Abbildungsnummer von Neun aufweisen, eine Abmessung gleich 512 Texeln auf und sind, falls dieselben quadratisch sind, 512 × 512 Texel groß. Die Abbildung ist in vier Blöcke von 256 × 256 Texeln (unter der Annahme einer quadratischen Texturabbildung) geteilt. Deshalb umfasst die Blockkennung für jeden dieser Blöcke ein S-Koordinatenbit hoher Ordnung und ein T-Koordinatenbit hoher Ordnung (d. h. S[8] und T[8]), die die Position des Blocks innerhalb der Abbildung identifizieren. Gleichermaßen sind MIP-Abbildungen, die eine Abbildungsnummer von Zehn aufweisen, 1024 × 1024 Texel groß und sind in sechzehn Datenblöcke geteilt. Deshalb umfassen die Blockkennungen für jeden dieser Blöcke zwei S-Koordinatenbits hoher Ordnung und zwei T-Koordinatenbits hoher Ordnung (d. h. S[9:8] und T[9:8]), die die Position des Blocks innerhalb der Abbildung identifizieren.
  • Wie es unten beschrieben ist, sind, um eine Systembandbreite während einer trilinearen Interpolierung zu reduzieren, die Textur-MIP-Abbildungen unterteilt und in einem Speicher gespeichert, so dass die gleichen Abschnitte benachbarter MIP-Abbildungen in gegenüberliegenden SDRAM-Bänken gespeichert sind. Um zusätzlich eine effiziente Verwendung eines Speicherplatzes innerhalb des Cache-Speichers zu liefern, können mehrere Abbildungen, die kleiner als 256 × 256 Texel sind, in einem einzigen Block eines Cache-Speichers gespeichert sein.
  • 14 zeigt einen Satz von Textur-MIP-Abbildungen für eine spezielle Textur, einschließlich des Oberflächenbilds:
    Wie es in 14 gezeigt ist, ist jede MIP-Abbildung in der Reihe von MIP-Abbildungen für eine Textur in vier Quadranten geteilt, die bei einer quadratischen Texturabbildung gleich groß sind. Bei dem in 14 gezeigten Beispiel weist die Basisabbildung eine Abbildungsnummer von Neun auf und ist in Quadranten 9Q1 (einschließlich des Bilds L), 9Q2 (einschließlich des Bilds A), 9Q3 (ein schließlich des Bilds 9) und 9Q4 (einschließlich des Bilds 5) geteilt. Auf ähnliche Weise ist eine Abbildung Nummer Acht in Quadranten 8Q1, 8Q2, 8Q3, 8Q4 geteilt, einschließlich der Bilder L, A, 9 bzw. 5. Gleichermaßen ist eine Abbildung Nummer Sieben in Quadranten 7Q1, 7Q2, 7Q3, 7Q4 geteilt, einschließlich der Bilder L, A, 9 bzw. 5. Die kleineren Abbildungen sind auf ähnliche Weise in Quadranten unterteilt.
  • Zwei Quadranten jeder MIP-Abbildung sind in einer Bank der SDRAMs gespeichert, die den Cache bilden, während die anderen zwei Quadranten in der gegenüberliegenden Bank gespeichert sind. Gemäß einem Texturdatenzuweisungsschema sind für Texturen, die eine Basisabbildung mit einer Nummer größer oder gleich Acht (was größer oder gleich 256 × 256 Texeln Größe ist) aufweisen, die Speicherpositionen innerhalb der Blöcke von Speicherplatz für alle der Quadranten aller der MIP-Abbildungen dieser Textur vordefiniert. Zum Beispiel sind die Quadranten 9Q1 und 9Q4 der Abbildung Nummer Neun in getrennten Blöcken innerhalb der Cache-Bank Eins gespeichert und die Quadranten 9Q2 und 9Q3 sind innerhalb getrennter Blöcke der Cache-Bank Null gespeichert, wie es in 15 gezeigt ist. Die entsprechenden Quadranten benachbarter MIP-Abbildungen sind in Blöcken innerhalb gegenüberliegender Bänke gespeichert. Bei diesem Beispiel sind somit die Quadranten 8Q1 und 8Q4, die die kastengefilterten Texturdaten der Quadranten 9Q1 bzw. 9Q4 umfassen, in dem gleichen Block innerhalb der Cache-Bank Null gespeichert. Gleichermaßen sind die Quadranten 8Q2 und 8Q3, die die kastengefilterten Texturdaten der Quadranten 9Q2 bzw. 9Q3 umfassen, in dem gleichen Block innerhalb der Cache-Bank Eins gespeichert. 15 ist nicht maßstabsgetreu mit Bezug auf 14 gezeichnet. Es ist klar, dass die Abbildungsquadranten von 14 die gleiche Größe wie dieselben von 15 aufweisen, da dieselben identisch sind.
  • Aufgrund der jeweiligen Größen der Abbildungen nimmt jeder Quadrant der Abbildung Nummer Neun einen vollständigen Block von 256 × 256 Texeln ein, während die Quadranten der Abbildung Nummer Acht jeweils lediglich 1/4 eines Blocks einnehmen. Deshalb nehmen die Quadranten 8Q2 und 8Q3 zusammen 1/2 des gleichen Blocks ein und die Quadranten 8Q1 und 8Q4 nehmen 1/2 eines anderen Blocks innerhalb der gegenüberliegenden Bank ein. Um den Cache-Speicherplatz effizient zuzuweisen, sind die nicht-eingenommenen Positionen innerhalb jedes dieser Blöcke durch geeignete Quadranten von Abbildungen eingenommen, die eine Abbildungsnummer von Sieben oder weniger aufweisen. Deshalb nehmen alle der Abbildungen, die Nummern Null bis Acht aufweisen, zusammen zwei Blöcke ein, wobei jeder der zwei Blöcke sich in einer getrennten Bank befindet.
  • Die Positionen der Quadranten für die Abbildungen, die Abbildungsnummern von Acht oder weniger aufweisen (eine Basisabbildung vorausgesetzt, die eine Abbildungsnummer von Acht oder größer aufweist), sind in der in 15 gezeigten Weise vordefiniert. Wie es gezeigt ist, behalten der obere rechte Quadrant 8Q2 und der untere linke Quadrant 8Q3 die gleiche physische Beziehung bei und nehmen den oberen rechten bzw. den linken unteren Quadranten eines ersten Blocks ein und behalten der obere linke Quadrant 8Q1 und der untere rechte Quadrant 8Q4 ebenfalls die gleiche physische Beziehung bei und nehmen den oberen linken bzw. den rechten unteren Quadranten eines zweiten Blocks ein, der sich in einer unterschiedlichen Bank zu dem ersten Block befindet. Ferner behalten die Quadranten 7Q1 und 7Q4 die gleiche physische Beziehung bei und nehmen jeweils den oberen linken Quadranten des ersten Blocks ein und die Quadranten 7Q2 und 7Q3 behalten die gleiche physische Beziehung bei und nehmen jeweils den oberen rechten Quadranten des zweiten Blocks ein.
  • Während einer trilinearen Interpolierung wird dann auf alle acht Texel von dem Cache zugegriffen, falls ein Pixel zu einer Position in der Texturabbildung abbildet, die sich zwischen vier Texeln in einer MIP-Abbildung und vier Texeln in einer benachbarten MIP-Abbildung befindet. Die Texel, auf die von beiden MIP-Abbildungen zugegriffen wird, umfassen gemeinsame Texturdaten, wobei die Daten aus der kleineren Abbildung eine gefilterte Version der Daten aus der größeren Abbildung sind. Wie es oben erörtert ist, bilden, wenn Pixel eines Objekts aufbereitet werden, benachbarte Pixel häufig zu den gleichen zwei MIP-Abbildungen für die Textur ab, was erfordert, dass Lesevorgänge zu dem Cache kontinuierlich zwischen den Cache-Blöcken umschalten, die die zwei Abbildungen speichern. Durch ein Speichern gemeinsamer Daten aus benachbarten MIP-Abbildungen in unterschiedlichen Bänken der Cache-SDRAM-Chips werden Seitenumladungseinbußen nicht erlitten, wenn Cache-Lesevorgänge zwischen den zwei MIP-Abbildungen während aufeinanderfolgender Lesezyklen umschalten. Dies sorgt für eine effiziente Implementierung einer trilinearen Interpolierung.
  • Wie es aus dem Vorhergehenden ersichtlich ist, ist, wenn eine Textur eine Basisabbildung umfasst, die eine Abbildungsnummer von Acht oder größer aufweist, die Zuweisung der MIP-Abbildungen unter den Blöcken für diese Textur gemäß dem beschriebenen darstellenden Ausführungsbeispiel vordefiniert. Dies ist so, weil zwei Quadranten einer Abbildung, die eine Abbildungsnummer Acht aufweist, bestimmte vordefinierte Positionen eines ersten Blocks innerhalb einer der Bänke einnehmen und die anderen zwei Quadranten der Abbildung, die eine Abbildungsnummer Acht aufweist, bestimmte gegenüberliegende vordefinierte Positionen innerhalb eines anderen Blocks der gegenüberliegenden Bank einnehmen, wie es oben erörtert und in 15 gezeigt ist. Für Texturen jedoch, die eine Basisabbildung mit einer Abbildungsnummer von Sieben oder weniger aufweisen, sind mehrere Positionen innerhalb der zwei Speicherblöcke (ein Block in jeder Bank) verfügbar, um die Abbildungen zu speichern, und werden durch die TIM ausgewählt. Wenn Abschnitte mehrerer Abbildungen einen einzigen Datenblock gemeinschaftlich verwenden, wird eine Untertexturidentifikation (Untertextur-ID) in einer unten beschriebenen Weise zugewiesen, um die Position jeder Abbildung innerhalb des gemeinschaftlich verwendeten Blocks zu identifizieren.
  • Zusätzlich zu der Organisation der Reihe von MIP-Abbildungen von 14 zeigt 15 ferner die Weise, in der eine zweite Reihe von MIP-Abbildungen von einer unterschiedlichen Textur (d. h. einem Schachbrettmuster) unter den Speicherblöcken zugewiesen wird. Die MIP-Abbildungen dieser zweiten Textur werden in der gleichen Weise wie die erste Textur in getrennte Datenblöcke unterteilt und in denselben gespeichert. Obwohl die Organisation von 15 die MIP-Abbildungen der unterschiedlichen Texturen als in getrennten Blöcken organisiert zeigt, ist klar, dass Texturdaten von zwei unterschiedlichen Texturen innerhalb des gleichen Blocks gespeichert sein können.
  • Wie es oben erörtert ist, kann bei einem darstellenden Ausführungsbeispiel der Cache-Speicher bis zu vierundsechzig Blöcke von Texturabbildungsdaten speichern, wobei jeder Block 256 × 256 Texel umfasst. Der Cache-Speicher ist in zwei Bänke geteilt, wobei Blöcke 0 – 31 in einer Bank Null liegen und Blöcke 32 – 63 in einer Bank Eins liegen. Das Cache-Verzeichnis umfasst bis zu vierundsechzig Blockkennungseinträge, die den Blöcken in dem Cache entsprechen. Die physische Position jeder Blockkennung innerhalb des Cache-Verzeichnisses identifiziert die physische Position des entsprechenden Blocks von Texturdaten innerhalb des Cache-Speichers. Ein Blockindex wird aus der Blockkennung erzeugt, die die Position des Blocks angibt. Die Cache-Adresse für irgendein Texel in dem Cache ist aus dem Blockindex für den Block und die Texeladresse innerhalb des Blocks gebildet. Die Texeladresse umfasst die interpolierten S,T-Koordinaten niedriger Ordnung für das Texel und kann ferner Bits aus der Untertextur-ID umfassen, wie es unten erörtert ist.
  • 16 zeigt ein Beispiel einer Textur-MIP-Abbildung, die eine Abbildungsnummer von Neun aufweist und in Quadranten unterteilt ist. Die MIP-Abbildung ist 512 × 512 Texel groß und deshalb ist jeder Quadrant 256 × 256 Texel groß und entspricht einem einzigen Speicherblock. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung wird ein einfaches Schema durch die TIM implementiert, um die Bank in dem Cache zu bestimmen, der jeder Quadrant der MIP-Abbildung zugewiesen werden sollte. Wie es unten erläutert ist, diktieren hierin für jeden MIP-Abbildungsquadranten die Ergebnisse einer logischen ausschließlichen ODER-Operation an den Werten der höchstwertigen Bits der S- und T-Koordinaten für den Quadranten die SDRAM-Bank in dem Cache, der der Quadrant zugewiesen wird.
  • Für eine Abbildung von 512 × 512 Texeln spezifizieren neun S-Koordinaten-Bits S[8:0] und neun T-Koordinaten-Bits T[8:0] die Position jedes Texels innerhalb der Abbildung. Die Quadrantengrenzen werden bei dem Halbwegspunkt der Abbildung bei sowohl den S- als auch den T-Abmessungen eingerichtet, dargestellt durch die höchstwertigen S- und T-Koordinatenbits S[8] und T[8]. Um deshalb die Cache-Bänke für jeden der vier Quadranten einer MIP-Abbildung zu bestimmen, die eine Abbildungsnummer von Neun aufweist, wird eine ausschließliche ODER-Operation für jeden Quadranten an den Werten der entsprechenden höchstwertigen S- und T-Koordinatenbits S[8] und T[8] derselben durchgeführt. Gleichermaßen wird für eine MIP-Abbildung, die eine Abbildungsnummer von Zehn aufweist, die Cache-Bank für jeden Quadranten durch eine ausschließliche ODER-Operation an den entsprechenden Werten der höchstwertigen S- und T-Koordinatenbits S[9] und T[9] derselben bestimmt. Für MIP-Abbildungen, die eine ungerade Abbildungsnummer aufweisen, wird das Ergebnis der ausschließlichen ODER-Operation invertiert, so dass gemeinsame Daten aus benachbarten Abbildungen in unterschiedlichen Bänken gespeichert werden.
  • Bei dem in 16 gezeigten Beispiel entsprechen die Blöcke, die mit Block 1 – Block 4 etikettiert sind, dem oberen linken Quadranten, dem oberen rechten Quadranten, dem unteren linken Quadranten bzw. dem unteren rechten Quadranten der Abbildung mit 512 × 512 Texeln. Für Block 1 – Block 4 sind die Bits S[8], T[8] gleich [0,0], [1,0], [0,1] bzw. [1,1]. Deshalb ist für den Block 1 das Ergebnis der XOR-Operation S[8] XOR T[8] gleich Null. Weil die Abbildung eine ungerade Abbildungsnummer (d. h. Neun) aufweist, wird die Inverse dieses Ergebnisses (gleich Eins) verwendet, um anzugeben, dass der Block 1 in der Bank Eins des Cache gespeichert werden soll. Für den Block 2 ist die Inverse des Ergebnisses der XOR-Operation S[8] XOR T[8] gleich Null, was angibt, dass der Block 2 in der Bank Null in dem Cache gespeichert werden soll. Für Block 3 und Block 4 ist jeweils die Inverse des Ergebnisses der XOR-Operation S[8] XOR T[8] gleich Eins bzw. Null, was angibt, dass der Block 3 in der Bank Eins gespeichert werden soll und der Block 4 in der Bank Null gespeichert werden soll.
  • Für eine Abbildung, die eine Abbildungsnummer von Zehn für die gleiche Textur aufweist, wie es bei dem Beispiel von 16 gezeigt ist, würde sich die Abbildung in sechzehn Blöcke von jeweils 256 × 256 Texeln aufteilen, weil die Abbildung 1024 × 1024 Texel groß ist. Für jeden Block würden die Ergebnisse von S[9] XOR T[9] die Banknummer für diesen speziellen Block angeben. Es ist zu beachten, dass das Ergebnis der XOR-Operationen für jeden Block der Abbildung, die eine Abbildungsnummer von Zehn aufweist, nicht invertiert werden, wie es dieselben für die benachbarte Abbildung, die eine Abbildung Nummer Neun aufweist, wurden, so dass die entsprechenden Quadranten in den zwei Abbildungen in unterschiedlichen Cache-Bänken gespeichert werden.
  • Abhängig von der Größe der Abbildung kann die Blockkennung für Blöcke von Texturdaten, die die Abbildung darstellen, zumindest ein S-Koordinatenbit hoher Ordnung und ein T-Koordinatenbit hoher Ordnung umfassen, die die Position des Blocks innerhalb der speziellen MIP-Abbildung angeben. Für eine MIP-Abbildung mit 512 × 512 Texeln, die eine Abbildungsnummer von Neun aufweist, wären lediglich ein S- Koordinatenbit und ein T-Koordinatenbit in der Blockkennung erforderlich, um die Position jedes Blocks innerhalb der MIP-Abbildung anzugeben. Für eine MIP-Abbildung mit 1024 × 1024 Texeln, die eine Abbildungsnummer von Zehn aufweist und sechzehn Datenblöcke umfasst, wären zwei S-Koordinatenbits und zwei T-Koordinatenbits in der Blockkennung erforderlich, um die Position jedes Blocks innerhalb der MIP-Abbildung anzugeben. Für Abbildungen, die eine Abbildungsnummer von Acht oder kleiner aufweisen, sind keine S- und T-Bits in der Blockkennung erforderlich. Bei einem Herunterladen von Textur-MIP-Abbildungsdaten von dem Hauptspeicher des Hostcomputers zu dem Cache-Speicher decodiert die TIM die S- und T-Koordinatenbits einer oberen Ebene der Blockkennung unter Verwendung des oben erörterten ausschließlichen ODER-Schemas, um die spezielle Bank zu bestimmen, zu der jeder Datenblock geschrieben werden sollte.
  • Um Texturdaten zuzuweisen, so dass unbenutzter Speicherplatz minimiert ist, kann jeder Datenblock ferner in sechzehn Unterblöcke von 64 × 64 Texeln unterteilt werden. Jeder Unterblock von Texturdaten umfasst eine Untertextur-ID, die die Position des speziellen Unterblocks innerhalb des Blocks identifiziert. Die Untertextur-ID umfasst zwei S-Bits S[1:0] und zwei T-Bits T[1:0]. Mehrere Untertexturen aus einer oder mehreren MIP-Abbildungen einer oder mehrerer Texturen können in einem einzigen Block gespeichert sein.
  • 17 stellt den Block1 und den Block2 dar, die den Bänken Null bzw. Eins des Cache zugewiesen sind, die jeweils in sechzehn Untertexturen von 64 × 64 Texeln Größe unterteilt sind. Die Untertexturen jedes Blocks sind mit ST0 – ST15 etikettiert und sind durch eine Untertextur-ID identifiziert, die zwei S-Koordinatenbits und zwei T-Koordinatenbits umfasst. Die Unterstrukturen weisen eine konsistente Etikettierung aber Spiegelpositionen innerhalb der zwei Cache-Bänke auf, um mit dem Speicherzuweisungsschema konsistent zu sein, das oben beschrieben ist. Die Größe der Untertexturen von 64 × 64 Texeln ist ausgewählt, um exemplarisch zu sein und kann geändert werden. Zum Beispiel würde eine kleinere Untertextur ermöglichen, dass mehr Texturen in die gleichen Blöcke gepackt werden können. Es ist klar, dass die Untertextur-ID mehr Bits umfassen müsste, wenn die Größe der Untertextur verringert ist.
  • Während einer Aufbereitung werden für jeden Strom von Texeln, die interpoliert werden sollen, die Textur-ID, die Untertextur-ID und ein 8-Bit-Wort, das die Größe der Basisabbildung für diese Textur darstellt, die diesen Texeln zugeordnet ist, durch die 3-D-Pipeline zu dem Kachelbilder/Grenzprüfer geliefert, der die Daten temporär in einem 20-Bit-Register (nicht gezeigt) speichert. Wenn ein Texel, das interpoliert werden soll, eine unterschiedliche Untertextur-ID oder Textur-ID aufweist, werden die neuen Daten zu dem Kachelbilder/Grenzprüfer geliefert und in dem Register gespeichert. Die Untertextur-ID kann als ein Teil der Texeladresse verwendet werden, wie es unten erläutert ist.
  • Ob die Texeladresse S-, T-Koordinatenbits einer Untertextur-ID umfasst, hängt von der Größe der Abbildung, die adressiert wird, und der Größe der Basisabbildung dieser Textur ab. Falls die Abbildung, die adressiert wird, eine Abbildungsgröße von Sieben oder kleiner aufweist und die entsprechende Basisabbildung derselben ebenfalls eine Größe von Sieben oder kleiner aufweist, dann umfassen bestimmte obere Adressbits der Texeladresse Bits aus der Untertextur-ID, um die Position der Untertextur innerhalb des Blocks zu adressieren, wie es unten detailliert erläutert ist. Wie es oben erläutert ist, sind, wenn die Basisabbildung eine Abbildungsnummer von Acht oder größer aufweist, die Positionen aller der MIP-Abbildungsquadranten für diese Textur innerhalb der jeweiligen Datenblöcke derselben vordefiniert. Wenn deshalb auf ein Texel von einer der Abbildungen für diese Textur zugegriffen wird, die eine Abbildungsnummer von Sieben oder weniger aufweist, sind diese vordefinierten Positionen bekannt und werden verwendet, um die oberen Bits der Texeladresse für jeden Quadranten zu erzeugen, ohne die Untertextur-ID zu verwenden. Wenn jedoch die Basisabbildung einer Textur eine Abbildungsnummer von Sieben oder weniger aufweist, sind die Positionen der MIP-Abbildungsquadranten nicht vordefiniert und die Untertextur-ID-Bits werden als obere Bits der Texeladresse verwendet, um die Position der Untertextur zu bestimmen.
  • Wie es oben angemerkt ist, können mehrere Abbildungen von unterschiedlichen Texturen innerhalb unterschiedlicher Untertexturen eines einzigen Datenblocks gespeichert sein, solange die Basisabbildung von dieser Textur klein genug ist. Wenn dies auftritt, umfassen die Texturadressen für jede Abbildung Untertextur-ID-Bits. Falls z. B. vier unterschiedliche Abbildungen, die Abbildungsnummern von Sieben aufweisen, von vier unterschiedlichen Texturen unter unterschiedlichen Untertexturen innerhalb eines Blocks zugewiesen werden und die Abbildungsnummer für die Basisabbildung jeder Textur Sieben beträgt, dann wären ein S-Koordinatenbit und ein T-Koordinatenbit aus der Untertextur-ID ein Teil der Texeladresse, um zwischen den Texturen zu unterscheiden. Die Routine, durch die der Kachelbilder/Grenzprüfer die Texeladresse berechnet, ist unten mit Bezug auf 19 beschrieben.
  • Bei dem dargestellten Ausführungsbeispiel werden Textur-MIP-Abbildungsdaten blockweise heruntergeladen. Es ist jedoch ersichtlich, dass alternativ eine Untertextur-ID in der Blockkennung enthalten sein kann, so dass Untertexturen von dem Hauptspeicher heruntergeladen werden könnten. Ferner sollen die Größen der Blöcke und Untertexturen, die bei diesem Ausführungsbeispiel beschrieben sind, lediglich exemplarisch sein und können geändert werden, um zu irgendeiner Anwendung zu passen. Bei einem Ausführungsbeispiel der Erfindung kann die TIM die Texturdaten zuweisen, wie es unten mit Bezug auf 32 beschrieben ist.
  • F. Cache-Blockkennung und Blockindex
  • Das Cache-Verzeichnis umfasst eine Blockkennung für jeden der vierundsechzig Einträge desselben und identifiziert einen entsprechenden Blockindex für jeden Eintrag. Der Blockindex identifiziert die physische Position in dem Cache, bei der der Anfang des entsprechenden Blocks von Texturdaten gespeichert ist. Die Blockkennung ist ein 23-Bit-Identifizierer, der jeden Block von Texturdaten eindeutig in der in 18 gezeigten Weise identifiziert.
  • Um irgendein Texel von Texturdaten eindeutig zu identifizieren, muss die Textur, der dasselbe entspricht, identifiziert werden. Bei einem Ausführungsbeispiel unterstützt die Texturabbildungshardware eine 8-Bit-Textur-ID, die eine Textur eindeutig identifiziert. Zusätzlich wird für Texturdaten von unterschiedlichen Texturen, die innerhalb der gleichen Blöcke gespeichert sind, eine zusätzliche 4-Bit-Untertextur-ID durch die Hardware unterstützt, um die Texturen zu identifizieren. Somit unterstützt die Texturabbildungshardware 212 oder viertausendsechsundneunzig eindeutige Texturen, die zu irgendeiner Zeit aktiv sein können.
  • Wie es oben erörtert ist, ist jede Textur durch eine Reihe von MIP-Abbildungen dargestellt. Wie es oben erörtert ist, ist jede der MIP-Abbildungen mit einer Abbildungsnummer versehen, die die Position derselben in der Reihe von MIP-Abbildungen angibt. Somit ist jedes Texel von Daten nicht nur durch die Textur-ID, die Untertextur-ID und die Größe der Basisabbildung für diese Textur identifiziert, sondern auch durch die Abbildungsnummer der MIP-Abbildung, der dasselbe entspricht. Schließlich ist das Texel eindeutig innerhalb der MIP-Abbildung durch die S- und T-Koordinaten desselben (d. h. den interpolierten S,T-Wert desselben) identifiziert.
  • Anders als die Untertextur-ID und die Texturabbildungsbasisgröße werden die oben beschriebenen Parameter, die ein Texel eindeutig identifizieren, verwendet, um die 23-Bit-Blockkennung zu erzeugen. Mit Bezug auf die Abbildungsnummer und die S- und T-Koordinaten ist die Hardware, die verwendet wird, um die S- und die T-Koordinaten zu erzeugen, auf fünfzehn Bits begrenzt. Deshalb weist bei diesem Ausführungsbeispiel die größte Texturabbildung, die durch die Hardware unterstützt wird, ein 15-Bit-S-Feld [14:0] und ein 15-Bit-T-Feld [14:0] auf, was in einer maximalen Texturabbildung resultiert, die 32000 × 32000 Texel groß ist. Wie es oben erörtert ist, umfasst jeder Block von Texeldaten 256 × 256 Texel. Somit werden die S- und T-Bits niedriger Ordnung (d. h. T[7:0] und S[7:0]) verwendet, um ein spezielles Texel innerhalb eines Blocks von Texeldaten zu identifizieren. Lediglich die S- und T-Bits hoher Ordnung (T[14:8] und S[14:8]) werden bei der Blockkennung verwendet, um einen speziellen Block von Texeldaten zu identifizieren.
  • Wie es oben dargelegt ist, ist jeder MIP-Abbildung eine Abbildungsnummer zugewiesen, die dieselbe eindeutig innerhalb der Reihe von Abbildungen für die entsprechende Textur derselben identifiziert. Ungeachtet der Anzahl von MIP-Abbildungen in der Reihe von Abbildungen für eine Textur, ist die kleinste MIP-Abbildung in der Reihe (d. h. ein Texel Größe) zugewiesen, um die Abbildungsnummer Null zu sein. Da die größte Reihe von MIP-Abbildungen für eine Textur von 32000 × 32000 sechzehn MIP-Abbildungen umfasst, lautet die größte unterstützte Abbildungsnummer Fünfzehn.
  • Die Weise, in der die Blockkennung gebildet wird, ist in der Tabelle von 18 gezeigt. Die acht Bits hoher Ordnung der Blockkennung [22:15] entsprechen der Textur-ID der Textur, die durch den Block von Texturdaten dargestellt ist. Die Bits niedriger Ordnung der Blockkennung [13:00] entsprechen den T- und S-Koordinaten hoher Ordnung, T[14:08] und S[14:08]. Die Blockkennung [14] entspricht einem Abbildungsbit, das in Verbindung mit den Werten in dem T-Koordinatenfeld hoher Ordnung die Identifizierung der Abbildungsnummer ermöglicht. Es ist klar, dass Abbildungen, die kleiner als das Maximum von 32000 × 32000 sind, nicht die vollen S- und T-Adressfelder verwenden, derart, dass um so mehr S- und T-Adressbits hoher Ordnung unbenutzt sind, je kleiner die Abbildung ist. Wie es in 18 gezeigt ist, ist für Abbildungen, die eine Abbildungsnummer größer Acht aufweisen, das Blockkennungsbit, das dem niederstwertigen unbenutzten T-Koordinatenbit entspricht, zu einer logischen „0" gesetzt und die Blockkennungsbits, die den verbleibenden T-Koordinatenbits hoher Ordnung und dem Abbildungsbit entsprechen, sind zu einer logischen „1" gesetzt. Für eine Abbildungsnummer Fünfzehn, die alle der T-Koordinatenbits verwendet, ist das Abbildungsbit zu einer logischen „0" gesetzt. Durch ein Lesen von Blockkennungsbits [14:7], die dem Abbildungsbit und den T-Koordinatenbits hoher Ordnung [14:8] entsprechen, gibt die Position der ersten logischen „0", die bei einem Lesen von links nach rechts angetroffen wird, die Abbildungsnummer an, die durch die Blockkennung dargestellt ist. Falls eine logische „1" bei allen Blockkennungsbits [14:08] enthalten ist, dann sind Abbildungsnummern Acht und weniger dargestellt.
  • Wie es oben beschrieben ist, sind alle der Abbildungen einer speziellen Textur, die eine Abbildungsnummer von Acht oder weniger aufweisen, innerhalb zweier Datenblöcke gespeichert, wobei jeder Block innerhalb einer unterschiedlichen Bank des Cache positioniert ist. Zwei Quadranten oder ein halber von jeder der Abbildungen, die Abbildungsnummern von Acht und weniger aufweisen, sind innerhalb jedem der zwei Blöcke gespeichert. Ein Blockkennungsbit [07] stellt dar, in welchem der zwei Blöcke jeder halbe Abschnitt der Abbildungen, die Abbildungsnummern von Acht und weniger aufweisen, gespeichert ist. Für jede der Abbildungen, die eine Abbildungsnummer Acht oder weniger aufweisen, weist somit das Blockkennungsbit [07] einen Wert von „0" für die Hälfte (zwei Quadranten) dieser Abbildung (die in dem Bank-Null-Block gespeichert ist) auf und weist einen Wert von „1" für die andere Hälfte (zwei Quadranten) dieser Abbildung (die in dem Bank-Eins-Block gespeichert ist) auf. Es ist klar, dass, weil alle der Abbildungen von einer speziellen Textur, die eine Abbildungsnummer von Acht oder weniger aufweisen, innerhalb zweier Blöcke gespeichert sind, dann lediglich ein Blockkennungsbit verwendet wird, um diese zwei Blöcke zu identifizieren. Die spezielle Abbildungsnummer für jede der Abbildungen, die eine Nummer von Acht und niedriger aufweisen, ist deshalb nicht als ein Teil des Blockkennungsfelds gespeichert.
  • Der Wert des Blockkennungsbits [07] für jeden Quadranten jeder der Abbildungen, die eine Abbildungsnummer von Acht oder weniger aufweisen, wird basierend auf dem Schema zum Bestimmen der Bank berechnet, in der der Quadrant gespeichert werden sollte. Dieses Schema umfasst die logische ausschließliche ODER-Operation der Werte der MSB-Bits für jeden Quadranten von Abbildungen mit gerader Nummer und die Inverse der Operation für jeden Quadranten von Abbildungen mit ungeraden Nummern.
  • Wie es in 18 gezeigt ist, sind die Blockkennungsbits [6:0], die den S-Adressbits hoher Ordnung entsprechen, zu einer logischen „0" für kleine Abbildungen gesetzt, wenn die S-Adressbits unbenutzt sind, so dass, falls irgendeines dieser Bits als eine logische „1" in Verbindung mit einer Abbildungsnummer erfasst wird, die angibt, dass dieselben gleich einer logischen „0" sein sollten, dasselbe verwendet werden kann, um anzugeben, dass es keine gültigen Daten gibt, die in dem Cache-Verzeichniseintrag enthalten sind.
  • Wie es oben erörtert ist, diktieren für jeden MIP-Abbildungsquadranten die Ergebnisse einer logischen ausschließlichen ODER-Operation (XOR-Operation) an den Werten der höchstwertigen S- und T-Koordinaten für den Quadranten die SDRAM-Bank in dem Cache, der der Quadrant zugewiesen wird. Die Banknummer ist gleich dieser XOR-Operation für Abbildungen, die eine gerade Abbildungsnummer aufweisen, und ist gleich der logischen Inverse der XOR-Operation für Abbildungen, die eine ungerade Abbildungsnummer aufweisen. Dies ist in der rechten Spalte der Tabelle von 18 gezeigt, bei der das Symbol in „A" eine XOR-Operation angibt und das Symbol „!" eine logische Inverse angibt. Für Abbildungen, die eine Abbildungsnummer von Neun oder größer aufweisen, verbraucht jeder Quadrant zumindest einen vollen Datenblock und jeder Datenblock ist in der Bank gespeichert, die durch die XOR-Operation diktiert ist, die in der letzten Spalte der Tabelle von 18 gezeigt ist.
  • Für Abbildungen, die eine Abbildungsnummer von Acht oder weniger aufweisen, nehmen alle dieser Abbildungen zwei Datenblöcke ein, einen Block in jeder Bank. Die letzten zwei Zeilen der Tabelle von 18 entsprechen unterschiedlichen Hälften (zwei Quadranten) irgendeiner Abbildung, die eine Abbildungsnummer von Acht oder weniger aufweisen. Das Blockkennungsbit [07] stellt dar, in welchem des Bank-Null-Blocks oder des Bank-Eins-Blocks die Hälfte der Abbildung gespeichert ist. Der Wert dieses Bits [07] wird basierend auf der beschriebenen XOR-Operation berechnet. Für eine Abbildung, die eine Abbildungsnummer Acht aufweist, wäre beispielsweise für jeden Quadranten der Abbildung das Blockkennungsbit [07] gleich S[7] XOR T[7]. Für jeden Quadranten einer Abbildung, die eine Abbildungsnummer Sieben aufweist, wäre das Blockkennungsbit [07] gleich der Inverse von S[6] XOR T[6]. Das Blockkennungsbit [07] wird für jeden Quadranten kleinerer Abbildungen ähnlich berechnet, wobei das Ergebnis der XOR-Operation lediglich für Abbildungen mit ungeraden Nummern invertiert wird. Aus dem Vorhergehenden ist klar, dass, weil zwei Quadranten jeder Abbildung (die eine Abbildungsnummer von Acht oder weniger aufweist) in dem gleichen Block gespeichert sind, diese zwei Quadranten jeder Abbildung das gleiche Blockkennungsbit [07] aufweisen würden.
  • Wenn ein Treffer zwischen interpolierten S,T-Koordinaten (die ein Texel adressieren, auf das zugegriffen werden soll) und einer der 23-Bit-Blockkennungen in dem Cache-Verzeichnis auftritt, erzeugt das Cache-Verzeichnis einen Blockindex, der die physische Position in dem Cache-Speicher identifiziert, bei der der Cache-Block, der dieses Texel enthält, gespeichert ist. Der Cache speichert vierundsechzig Blöcke von Texeldaten zu irgendeiner Zeit. Um deshalb eine Blockadresse in dem Cache-Speicher zu identifizieren, ist ein 6-Bit-Blockindex vorgesehen, der als die Adressbits hoher Ordnung zu dem Cache dient, wie es oben beschrieben ist.
  • Die Texeladresse ist ein 16-Bit-Wort, das Bits S[7:0] und T[7:0] umfasst und die Position des Texels, auf das zugegriffen werden soll, innerhalb des 256 × 256-Texelblocks angibt. Die Texeladresse wird aus den interpolierten S,T-Koordinaten, der Abbildungsnummer, der Abbildung, auf die zugegriffen werden soll, der Textur- und der Untertextur-ID und der Basisabbildungsgröße der Textur gemäß einer Routine berechnet, die unten mit Bezug auf 19 erörtert ist. Wie es oben erörtert ist, werden das LSB S-Bit und das LSB T-Bit der Texeladresse decodiert, um die geeignete Verschachtelung zu bestimmen, in der das Texel gespeichert ist. Die verbleibenden 14 Bits der Texeladresse in Verbindung mit den 6 Bits des Blockindex dienen als die Cache-Adresse (wobei die sechs Bits des Blockindex die sechs MSBs der Cache-Adresse sind), die zu dem SDRAM-Paar innerhalb der decodierten Verschachtelung des Cache geliefert wird.
  • G. Texeladressberechnung
  • Während einer Aufbereitung empfängt das Kachelbildungs-/Grenzüberprüfungselement 72 von dem Parameterinterpolator 64 den interpolierten S,T-Wert des Texels, auf das zugegriffen werden soll, sowie ein 4-Bit-Wort, das die Abbildungsnummer der Abbildung darstellt, von der auf das Texel zugegriffen werden sollte. Jeder der interpolierten S- und T-Koordinatenwerte, die von dem Parameterinterpolator empfangen werden, umfasst sechzehn ganzzahlige Bits und acht Bruchbits. Das 4-Bit-Wort, das die Abbildungsnummer darstellt, umfasst Abbildungen, die von einer Abbildungsnummer Null (ein Texel Größe) bis zu einer Abbildungsnummer Fünfzehn (32000 × 32000 Texel Größe) reichen und ist aus dem Gradienten berechnet, wie es oben beschrieben ist. Ein Vergleich des interpolierten S,T-Werts mit den Blockkennungseinträgen in dem Cache-Verzeichnis wird dann durchgeführt. Falls ein Treffer bei einer der Blockkennungen auftritt, dann wird der Blockindex erzeugt. Zu der gleichen Zeit, zu der die Cache-Verzeichnissuche durchgeführt wird, wird die Texeladresse gemäß der unten mit Bezug auf das Flussdiagramm von 19 beschriebenen Routine berechnet.
  • Die Texeladresse wird durch den Kachelbilder/Grenzprüfer basierend auf der Textur-ID, der Untertextur-ID, der Abbildungsnummer, der Basisabbildungsnummer und den interpolierten S,T-Koordinaten des Texels berechnet. Der Kachelbilder/Grenzprüfer weist alle diese Informationen auf. Für jedes eindeutige Texel, auf das zugegriffen werden soll, empfängt der Kachelbilder/Grenzprüfer von dem Parameterinterpolator die interpolierten S,T-Koordinaten (einschließlich sechzehn ganzzahligen und acht Bruchbits für jedes von S und T) sowie ein 4-Bit-Wort, das die Abbildungsnummer darstellt, von der auf das Texel zugegriffen werden soll. Zusätzlich wird durch die 3-D-Pipeline (die auch durch den Parameterinterpolator verläuft) ein Befehl empfangen, der die 8-Bit-Textur-ID, die 4-Bit-Untertextur-ID und ein 8-Bit-Wort umfasst, das die Größe der Basisabbildung für diese Textur darstellt. Das 8-Bit-Wort, das die Größe der Basisabbildung darstellt, umfasst vier S-Bits und vier T-Bits, die dem Abbildungsnummerierungsschema entsprechen und die Größe der S-Abmessung bzw. der T-Abmessung der Basisabbildung definieren. Zum Beispiel kann jedes der 4-Bit-S- und T-Wörter einen Wert aufweisen, der zwischen Null (was einer Abmessung von einem Texel entspricht) und Fünfzehn (was einer Abmessung von 32000 Texeln entspricht) liegt. Die zwanzig Datenbits, die die Textur-ID, die Untertextur-ID und die Basisabbildungsnummer umfassen, werden temporär in einem 20-Bit-Register (nicht gezeigt) innerhalb des Kachelbilders/Grenzprüfers gespeichert, bis dieselben mit neuen und unterschiedlichen Daten für ein nachfolgendes Texel ersetzt sind, auf das von dem Cache zugegriffen werden soll. Mit diesen Informationen berechnet der Kachelbilder/Grenzprüfer die Texeladresse für jedes Texel.
  • Wie es oben erläutert ist, weisen bei Texturen, die eine Basisabbildung mit einer Abbildungsnummer größer oder gleich Acht aufweisen (entsprechend einer Basisabbildung von 256 × 256 Texeln oder größer), die Quadranten jeder Abbildung innerhalb dieser Textur eine vordefinierte Position innerhalb der Blöcke von Texturdaten und Cache-Speicherbänken auf. Somit kann jedes Bit der Texeladresse für irgendein Texel einer derartigen Struktur gemäß diesem bekannten vordefinierten Zuweisungsschema berechnet werden. Bei Texturen, die eine Basisabbildung mit einer Abbildungsnummer von Sieben oder weniger aufweisen (entsprechend einer Basisabbildung von 128 × 128 Texeln oder kleiner), ist jedoch eine Anzahl von gesonderten Speicherpositionen für jeden Quadranten der Abbildungen dieser Textur verfügbar und deshalb umfassen bestimmte Bits der oberen Ebene der Texeladresse einige oder alle Bits (oder die Inverse dieser Bits) der Untertextur-ID.
  • Die Routine, die durch den Kachelbilder/Grenzprüfer implementiert wird, um die Texeladresse zu berechnen, ist durch das Flussdiagramm von 19 dargestellt. Die Routine benötigt einen Zyklus, um abzuschließen. Die Routine ist durch einen Satz von Logikgattern (nicht gezeigt) implementiert, die den Grenzüberprüfungsabschnitt des Texturabbildungschips bilden. Fachleuten auf dem Gebiet ist ersichtlich, wie die Logikgatter zu implementieren sind, um die Routine durchzuführen, die durch das Flussdiagramm von 19 umrissen ist. Zum Beispiel kann die Routine in einer Softwaresimulationssprache wie beispielsweise Verilog geschrieben sein und dann durch ein Synthesewerkzeug wie beispielsweise SynopsysTM in eine Logikgatterschaltung umgewandelt werden. Ein derartiges Synthesewerkzeug ist auf einem allgemeinen Prozessor wirksam. Die Routine kann alternativ in einer Software geschrieben sein und durch einen Computerprozessor durchgeführt werden.
  • Die Routine startet bei einem Schritt 250, bei dem die Texeladressbits S[7:0], T[7:0] voreingestellt werden, um gleich den interpolierten S,T-Koordinatenbits S[7:0], T[7:0] zu sein. Jedes der Bits der Texeladresse bleibt als der Wert, zu dem dasselbe bei diesem Schritt voreingestellt ist (gleich der entsprechenden S- oder T-Koordinate), wenn dasselbe nicht später in der Routine rückgesetzt wird. Dann geht die Routine zu einem Schritt 252 über, bei dem bestimmt wird, ob die spezielle Abbildung, innerhalb derer das Texel, das interpoliert wird, gespeichert ist, eine Abbildungsnummer von größer oder gleich Acht aufweist. Falls dem so ist, dann endet die Routine für ein derartiges Texel und die Bitwerte für die Texeladresse bleiben wie voreingestellt gleich den interpolierten S,T-Koordinaten.
  • Falls die Abbildungsnummer nicht größer oder gleich Acht ist, dann geht die Routine zu einem Schritt 254 über, bei dem bestimmt wird, ob das Texel in einer Bank Nummer Eins oder einer Bank Nummer Null gespeichert ist. Wie es oben beschrieben ist, ist durch ein Untersuchen des Werts des Blockkennungsbits [07] bekannt, ob das Texel in der Bank Nummer Eins oder der Bank Nummer Null gespeichert ist.
  • Falls das Texel in der Bank Nummer Eins gespeichert ist, dann geht die Routine zu einem Schritt 256 über, bei dem bestimmte Texeladressbits von den voreingestellten Werten derselben rückgesetzt werden. Bei Abbildungen, die Abbildungsnummern Eins bis Vier aufweisen, ist das Texeladressbit S[4]=1 und bei Abbildungen, die Abbildungsnummern Eins und Zwei aufweisen, ist das Texeladressbit S[2]=1. Falls das Texel in der Bank Null gespeichert ist, dann geht die Routine zu einem Schritt 258 über, bei dem bei Abbildungen, die Abbildungsnummern Null bis Fünf aufweisen, das Texeladressbit S[5]=1 ist, bei Abbildungen, die Abbildungsnummern Null bis Drei aufweisen, das Texeladressbit S[3]=1 ist und bei Abbildungen, die Abbildungsnummern Null und Eins aufweisen, das Texeladressbit S[1]=1 ist.
  • Von einem der Schritte 256 und 258 geht die Routine zu einem Schritt 260 über, bei dem bestimmt wird, ob die Basisabbildung eine Abbildungsnummer aufweist, die größer oder gleich Acht ist. Falls dem so ist, dann geht die Routine zu einem Schritt 262 über, bei dem bestimmt wird, ob das Texel innerhalb der Bank Null oder der Bank Eins gespeichert ist. Falls das Texel in der Bank Eins gespeichert ist, dann geht die Routine zu einem Schritt 264 über, bei dem bei einer Abbildung, die eine Abbildungsnummer von Sieben aufweist, das Texeladressbit S[7]=0 ist und bei Abbildungen, die Abbildungsnummern Null bis Sechs aufweisen, die Texeladressbits S[7:6]=0:1 sind. Die Routine ist dann für ein derartiges Texel fertiggestellt. Bei einem Texel, das in der Bank Null gespeichert ist, geht die Routine zu einem Schritt 266 über, bei dem bei einer Abbildung, die eine Abbildungsnummer von Sieben aufweist, das Texeladressbit S[7]=1 ist und bei Abbildungen, die Abbildungsnummern Null bis Sechs aufweisen, die Texeladressbits S[7:6]=1:0 sind. Die Routine ist dann für ein derartiges Texel fertiggestellt.
  • Falls die Basisabbildung keine Abbildungsnummer größer oder gleich Acht aufweist, dann geht die Routine zu einem Schritt 268 über, bei dem bestimmt wird, ob die Basisabbildung eine Abbildungsnummer gleich Sieben aufweist. Falls dem so ist, dann geht die Routine zu einem Schritt 270 über, bei dem bestimmt wird, ob das Texel in der Bank Null oder Eins gespeichert ist. Falls das Texel in der Bank Eins gespeichert ist, dann geht die Routine zu einem Schritt 272 über, bei dem bei einer Abbildungsnummer Sieben das Texel adressbit S[7] gleich der Inverse des Untertextur-ID-Bits S[1] ist und das Texeladressbit T[7] gleich dem Untertextur-ID-Bit T[1] ist und bei Abbildungen, die Abbildungsnummern Null bis Sechs aufweisen, die Texeladressbits S[7:6] gleich der Inverse des Untertextur-ID-Bits S[1] bzw. 1 sind und das Texeladressbit T[7] gleich dem Untertextur-ID-Bit T[1]ist. Die Routine endet dann für ein derartiges Texel. Falls das Texel in der Bank Null gespeichert ist, dann geht die Routine zu einem Schritt 274 über, bei dem bei einer Abbildung, die eine Abbildungsnummer Sieben aufweist, das Texeladressbit S[7] gleich dem Untertextur-ID-Bit S[1] ist und das Texeladressbit T[7] gleich dem Untertextur-ID-Bit T[1] ist und bei Abbildungen, die Abbildungsnummern Null bis Sechs aufweisen, die Texeladressbits S[7:6] gleich dem Untertextur-ID-Bit S[1] bzw. 0 sind und das Texeladressbit T[7] gleich dem Untertextur-ID-Bit T[1] ist. Die Routine endet dann für ein derartiges Texel.
  • Falls die Basisabbildung der Textur keine Abbildungsnummer größer oder gleich Acht aufweist (bei dem Schritt 260 bestimmt) und auch nicht gleich Sieben ist (bei dem Schritt 268 bestimmt), dann ist natürlich bekannt, dass die Basisabbildung der Textur eine Abbildungsnummer kleiner oder gleich Sechs aufweist, und die Routine geht zu einem Schritt 276 über, bei dem bestimmt wird, ob das Texel in der Bank Null oder der Bank Eins gespeichert ist. Falls das Texel in der Bank Eins gespeichert ist, dann geht die Routine zu einem Schritt 278 über, bei dem die Texeladressbits S[7:6] gleich der Inverse der Untertextur-ID-Bits S[1:0] sind und die Texeladressbits T[7:6] gleich den Untertextur-ID-Bits T[1:0] sind. Die Routine ist dann für ein derartiges Texel vollständig. Falls das Texel in der Bank Null gespeichert ist, dann geht die Routine zu einem Schritt 280 über, bei dem die Texeladressbits S[7:6] gleich den Untertextur-ID-Bits S[1:0] sind und die Texeladressbits T[7:6] gleich den Untertextur-ID-Bits T[1:0] sind. Die Routine ist dann für ein derartiges Texel abgeschlossen.
  • H. Texturdatenorganisationsbeispiele
  • Das folgende Beispiel beschreibt die Prozedur, durch die die TIM Texturdaten gemäß dem oben beschriebenen Ausführungsbeispiel der Erfindung organisiert. Bei einer speziellen Anwendung kann ein Grundelement A, das aufbereitet werden soll, zu einer Textur A abbilden und ein Grundelement B kann zu einer Textur B abbilden. Eine Möglichkeit bestünde darin, dass die TIM die Textur A in eine Mehrzahl von Blöcken von Texturdaten organisiert und dann die Textur B in unterschiedliche Untertexturen innerhalb der gleichen Blöcke wie die Textur A organisiert. Die TIM würde die Blöcke von Texturdaten einschließlich der Texturen A und B in den Cache-Speicher herunterladen, bevor die Grundelemente A und B aufbereitet werden.
  • Alternativ kann die TIM die Textur A in eine Mehrzahl von Blöcken von Texturdaten organisieren und dann die Blöcke einschließlich der Textur A in den Cache-Speicher herunterladen. Die TIM könnte dann die Textur B in dem Hauptspeicher innerhalb unterschiedlicher Untertexturen in den gleichen Blöcken wie die Textur A organisieren. In dieser Situation würde die TIM einen Befehl erteilen, um den Betrieb des Texturabbildungschips 46 (4) anzuhalten, und würde die neu organisierten Blöcke von Texturdaten (einschließlich der Texturen A und B in den gleichen Blöcken) zu dem Cache-Speicher des Texturabbildungssystems herunterladen. Wie es ersichtlich ist, könnte während des Aufbereitens des Grundelements B auf falsche Texturabbildungsdaten zugegriffen werden, falls die ANHALTEN-Bedingung nicht implementiert würde und die neu organisierten Daten von dem Hauptspeicher nicht in den Cache-Speicher des Texturabbildungssystems heruntergeladen würden. Dies ist so, weil bei einem Aufbereiten des Grundelements B ein Treffer in dem Cache-Verzeichnis auftreten würde, weil die Lesecachekennung für den Datenblock, der die Textur B umfasst, mit der Blockkennung übereinstimmen würde, die den Datenblöcken in dem Cache entspricht, die die Textur A speichern. Die Datenblöcke in dem Cache speichern jedoch lediglich Texturdaten bezüglich der Textur A, nicht der Textur B.
  • I. Umgehung der dreidimensionalen Grundelementpipeline und Unterbrechungsschema zum Herunterladen von Texturabbildungen
  • Wie es oben erörtert ist, ermöglicht ein Merkmal der Hardwarevorrichtung, dass eine MIP-Abbildung für eine neue Textur zu dem lokalen Speicher in der Texturabbildungshardware durch einen Datenweg heruntergeladen wird, der von der Pipeline zum Handhaben von 3-D-Grundelementdaten getrennt ist. Unter Bezugnahme auf das darstellende Ausführungsbeispiel, das in den Figuren offenbart ist, weisen die Texturabbildungsplatine 12 (4) und der Texturabbildungschip 46 (5) jeweils getrennte Tore zum Empfangen von 3-D-Grundelementdaten bzw. Texturdaten auf. Die 3-D-Grundelementdaten werden von dem Konzentratorchip 36 über den Bus 18 empfangen, während die Texturdaten von dem 2-D-Geometrie-Beschleunigerchip 34 über den Bus 24 empfangen werden. Wenn deshalb neue Texturdaten von dem Hostcomputer 15 durch die TIM zu dem Texturabbildungschip 46 heruntergeladen werden, muss die 3-D-Grundelementpipeline durch die Vorderseitenplatine 10 und den Texturabbildungschip 46 nicht gespült werden, wodurch eine erhöhte Bandbreite verglichen mit herkömmlichen Texturabbildungssystemen geliefert wird, die ein Spülen der 3-D-Grundelementpipeline erfordern, wann immer neue Texturdaten zu dem lokalen Speicher in der Texturabbildungshardware heruntergeladen werden.
  • Der getrennte Datenweg zum Herunterladen von Texturdaten, der die 3-D-Grundelementpipeline umgeht, ist besonders vorteilhaft in Verbindung mit dem oben beschriebenen Ausführungsbeispiel, bei dem der lokale Speicher einer Texturabbildungsplatine 12 als ein Cache implementiert ist. Wie es oben erörtert ist, wird, wenn neue Texturdaten zu dem Cache heruntergeladen werden, lediglich der Abschnitt der MIP-Abbildung, der erforderlich ist, heruntergeladen und nicht die gesamte Reihe von MIP-Abbildungen für die Textur. Somit ermöglicht die 3-D-Pipelineumgehung, dass Cache-Fehltreffer gehandhabt werden, ohne die Pipeline zu spülen.
  • Wie es oben erörtert ist, sind bei einem in 4A gezeigten Ausführungsbeispiel Abschnitte des Grafiksystems dupliziert, um eine Systembandbreite zu erhöhen. Die Texturabbildungsplatine 12 ist mit zwei Texturabbildungschips 46A und 46B und zwei Cache-Speichern 48A und 48B versehen. Bei diesem Ausführungsbeispiel behalten beide Cache-Speicher 48 die gleichen Texturdaten zu allen Zeiten bei, weil die zwei Texturabbildungschips typischerweise unter Verwendung der gleichen Texturdaten simultan an Grundelementen wirksam sind. Durch ein Aktualisieren beider Caches zu irgendeiner Zeit, zu der ein Fehltreffer von einem empfangen wird, bewahrt deshalb dieses Ausführungsbeispiel eine Systembandbreite durch ein Sicherstellen, dass die gesamten Texturdaten nicht bei getrennten Operationen zu den zwei Caches heruntergeladen werden müssen.
  • Bei dem Doppeltexturabbildungschip-Ausführungsbeispiel von 4A wird jeder Cache-Speicher lediglich mit Texturdaten aktualisiert, die von Hostcomputer heruntergeladen werden, und wird nicht lokal von der Texturabbildungshardware beschrieben. Deshalb wird eine Konsistenz zwischen den zwei Cache-Speichern durch ein Sicherstellen beibehalten, dass, wann immer Texturdaten von dem Hostcomputer ansprechend auf einen Fehltreffer von einem der Caches heruntergeladen werden, beide Caches mit den neuen Texturdaten aktualisiert werden. Wenn somit ein Cache-Fehltreffer von einem der Texturabbildungschips 46 auftritt und eine Unterbrechung erzeugt wird, werden beide Texturabbildungschips 46 angehalten, so dass beide Cache-Speicher mit den heruntergeladenen Texturdaten aktualisiert werden können. Zusätzlich unterstützt die Hardware simultane Cache-Fehltreffer von den zwei Texturabbildungschips 46 zu unterschiedlichen Cache-Blöcken und spricht durch ein Herunterladen beider neuer Blöcke von Texturdaten zu beiden Caches ansprechend auf die Fehltreffer an.
  • Bei dem in 4 gezeigten darstellenden Ausführungsbeispiel wird das Umgehen der 3-D-Grundelementpipeline durch ein Verwenden der 2-D-Grundelementpipeline durch den 2-D-Geometrie-Beschleunigerchip 34 erzielt, um Texturdaten herunterzuladen. Es ist klar, dass der Datenweg zum Herunterladen von Texturdaten zu dem Texturabbildungschip 46 in einer Anzahl alternativer Weisen implementiert sein kann, während die 3-D-Grundelementpipeline immer noch umgangen wird. Zum Beispiel kann ein zweckgebundener Datenweg von dem Hostcomputer zu der Texturabbildungsplatine vorgesehen sein.
  • Der Hostcomputer kann ein Betriebssystem wie beispielsweise UNIX verwenden, das mehrere simultan wirksame Prozesse aufweisen kann und das ein gewisses Schema zum Ermöglichen vorsieht, dass ein Prozess bestimmte Systemressourcen verriegelt, derart, dass ein Prozess nicht unterbrochen werden kann, wenn derselbe verriegelt ist. Durch ein Verwenden des Verriegelungsschemas kann ein Prozess, der bestimmte Hardwareressourcen verwendet, sicherstellen, dass der Prozess nicht ausgetauscht wird, bis derselbe diese Ressourcen entriegelt.
  • Bei einem Ausführungsbeispiel sind zwei Typen von Verriegelungen für eine Verwendung durch Prozesse vorgesehen, d.h. eine schnelle Verriegelung und eine langsame Verriegelung. Wenn eine schnelle Verriegelung verwendet wird, überprüft ein Prozess, der eingetauscht wird, die geeigneten Hardwareressourcen, um zu bestimmen, ob derselbe der letzte Prozess war, der diese Ressourcen verwendet. Falls derselbe es war, dann fährt der Prozess einfach fort, ohne den Zustand der Hardwareressourcen wiederherzustellen. Falls jedoch der Prozess nicht der letzte war, der die Ressourcen verwendet hat, dann wird eine langsame Verriegelung angefordert, was in der Wiederherstellung der Hardwareressourcen zu dem Zustand resultiert, in dem sich dieselben befanden, als der Prozess zuletzt ausgetauscht wurde. Es ist klar, dass eine Anzahl von alternativen Techniken verwendet werden kann, um die gleichen Ergebnisse zu erreichen.
  • Bei dem Ausführungsbeispiel, bei dem die 2-D-Grundelementpipeline verwendet wird, um Texturdaten herunterzuladen, während 3-D-Grundelemente aufbereitet werden, werden 2-D- und 3-D-Prozesse nicht simultan betrieben. Diese Einschränkung wird durch ein Sicherstellen durch die Verwendung des Verriegelungsschemas, das durch das Betriebssystem des Hostcomputers vorgesehen ist, eingehalten, dass kein 2-D-Prozess beginnt, wenn die 3-D-Pipeline nicht leer ist, und dass kein 3-D-Prozess beginnt, wenn die 2-D-Pipeline nicht leer ist. Wenn ein 3-D-Prozess beginnt, aktiviert derselbe eine Verriegelung, und wenn der vorhergehende Prozess ein 2-D-Prozess war, wartet derselbe, bis die 2-D-Pipeline leer ist, bevor derselbe beginnt. Wenn gleichermaßen ein 2-D-Prozess beginnt, aktiviert derselbe eine Verriegelung, und wenn der vorhergehende Prozess ein 3-D-Prozess war, wartet derselbe, bis die 3-D-Pipeline leer ist, bevor derselbe beginnt.
  • Einige Prozesse führen sowohl 3-D- als auch 2-D-Operationen durch und können zwischen 3-D-Grundelementen und 2-D-Grundelementen umschalten, ohne die langsame Verriegelung aufzugeben. Derartige Prozesse implementieren ferner ein Schema zum Sicherstellen, dass die 3-D-Pipeline leer ist, bevor 2-D-Grundelementdaten zu der Hardware heruntergeladen werden, und zum ähnlichem Sicherstellen, dass die 2-D-Pipeline leer ist, bevor 3-D-Grundelementdaten heruntergeladen werden. Um dieses Ergebnis zu erzielen, können Registerstatusbits geliefert werden, die angeben, ob jede der 2-D- und 3-D-Grundelementpipelines leer ist. Irgendein Prozess, der sowohl 2-D- als auch 3-D-Grundelementdaten verwendet, liest dieses Statusregister, um sicherzustellen, dass die Pipelines leer sind, bevor zwischen 2-D- und 3-D-Grundelementdaten umgeschaltet wird.
  • Es ist klar, dass, obwohl das darstellende Ausführungsbeispiel, das in den Figuren offenbart ist, einen lokalen Speicher an der Texturabbildungsplatine umfasst, der als ein Cache implementiert ist, das Ausführungsbeispiel nicht so begrenzt ist. Das Texturabbildungssystem kann alternativ implementiert sein, so dass der lokale Speicher an der Texturabbildungsplatine kein Cache ist und andere Techniken verwendet werden, um sicherzustellen, dass jeder Block von Texturabbildungsdaten, der benötigt wird, um ein Grundelement aufzubereiten, durch einen Weg heruntergeladen wird, der von der 3-D-Grundelementpipeline getrennt ist, bevor das Grundelement aufbereitet wird, so dass die Texturabbildungsdaten aus dem lokalen Speicher verfügbar sind, wenn das Grundelement aufbereitet wird.
  • Ferner ist klar, dass das Schema zum Erzeugen einer Unterbrechung zu einem Hostcomputer, um Blöcke von Daten in einem lokalen Speicher zu aktualisieren, bei vielen anderen Anwendungen verwendet werden kann und nicht auf eine Verwendung bei einem Texturabbildungshardwaresystem begrenzt ist. Dieses Schema ist bei irgendeinem Datenverarbeitungssystem nützlich, das einen Hostcomputer mit einem Hauptspeicher, der Datenblöcke speichert, die verarbeitet werden sollen, und eine Datenverarbeitungshardware umfasst, die einen lokalen Speicher aufweist, der Datenblöcke speichert, die verarbeitet werden.
  • J. Cache-Blockersetzungsschema
  • Wie es oben erörtert ist, lädt, wenn ein Fehltreffer für einen Block von Texturdaten auftritt, der sich nicht in dem Cache befindet, die TIM den angeforderten Block von Texturdaten zu dem Cache 48 (4) herunter. Falls der Cache voll war, als der Fehltreffer auftrat, wird dann einer der Cacheblöcke durch den neu heruntergeladenen Block von Texturdaten ersetzt. Bei einem Ausführungsbeispiel der Erfindung bestimmt die Software-Hintergrundroutine, welcher Block zu ersetzen ist, durch ein Betrachten, welche Blöcke am weitesten zurückliegend verwendet wurden und welche Blöcke Texturdaten einer geringen Priorität aufweisen. Die Routine zum Vornehmen dieser Bestimmung ist unten erörtert. Der Texturabbildungschip 46 umfasst zwei Sätze von Registern, die die Software bei einem Bestimmen unterstützen, welcher Cache-Block zu ersetzen ist. Wenn ein Cache-Fehltreffer auftritt, werden diese Register durch die TIM durch den 3-D-Umgehungsdatenweg gelesen und bei einem Bestimmen verwendet, welcher Cache-Block zu ersetzen ist.
  • Der erste Satz von Registern umfasst zwei jüngst verwendete 32-Bit-Register MRU0 und MRU1 (allgemein MRU), die den Bänken Null bzw. Eins des Cache 48 entsprechen. Jedes Bit in diesen Registern entspricht einem der Zweiunddreißig Cache-Blöcke, die innerhalb der entsprechenden Cache-Bank desselben enthalten sind. Jedes Mal, wenn ein Treffer zu einem Block in dem Cache auftritt, wird das entsprechende Bit in dem MRU0 oder dem MRU1 gesetzt, so dass die Jüngst-Verwendet-Register Treffer für den Cache sammeln.
  • Der zweite Satz von Registern umfasst zwei 32-Bit-Aktuell-Verwendet-Register CU0 und CU1 (allgemein CU), die ebenfalls den Bänken Null bzw. Eins des Cache entsprechen. Wenn ein Bit entweder in dem CU0 oder dem CU1 gesetzt ist, gibt dasselbe an, dass der entsprechende Cache-Block sich gegenwärtig in einem Miniverzeichnis des Cache befindet und nicht ersetzt werden sollte. Das Cache-Miniverzeichnis ist unten detailliert beschrieben.
  • K. Sperren einer Cache-Operation
  • Bei einem Ausführungsbeispiel ist eine Fähigkeit vorgesehen, um die Cache-Operation des lokalen Speichers 48 einer Texturabbildungsplatine durch ein Sperren von Cache-Fehltreffern zu sperren, so dass Texturdaten für irgendein 3-D-Grundelement in den Speicher 48 heruntergeladen werden, bevor dieselben während eines Aufbereitens des Grundelements benötigt werden. Jeder Texturabbildungschip 46 umfasst ein Statusbit, das angibt, dass eine Operation des lokalen Speichers desselben als ein Cache freigegeben ist. Wenn dieses Statusbit aktiviert ist, resultieren Cache-Fehltreffer in einer Unterbrechung des Hostcomputers und einem Anhalten des Texturabbildungschips. Wenn jedoch das Statusbit deaktiviert ist, ist der lokale Speicher 48 an der Texturabbildungsplatine nicht als ein Cache wirksam und die Texturdaten für irgendein Grundelement werden in den Speicher 48 heruntergeladen, bevor dieselben durch das Grundelement benötigt werden, so dass Fehltreffer zu dem Speicher nicht auftreten. Bei einem Ausführungsbeispiel der Erfindung werden, wenn die Operation des lokalen Speichers als ein Cache gesperrt ist, Texturdaten durch die TIM zu dem lokalen Speicher an der Texturabbildungsplatine durch die 3-D-Grundelementpipeline heruntergeladen, um eine Synchronisation der Texturdaten mit den entsprechenden 3-D-Grundelementdaten zu erleichtern.
  • L. Texteltorregister, die das Schema zum Herunterladen von Texturdaten ansprechend auf einen Cache-Fehltreffer unterstützen
  • Wie es oben erörtert ist, umfasst der Texturabbildungschip 46 (4) ein Texeltor 92 (5), das verwendet wird, um Texturdaten zu empfangen, die durch die TIM heruntergeladen werden. Das Texeltor umfasst eine Anzahl von Registern, die das Herunterladen von Texturdaten unterstützen. Einige dieser Register wurden oben erörtert, einschließlich der Register MRU und CU. Die anderen Texeltorregister umfassen ein Befehlsregister, ein Statusregister, ein Texeldatenregister, ein Verzeichniskennungsregister, ein Cache-Adressregister und ein Leitungskennungsregister, von denen jedes unten erörterte Funktionen durchführt.
  • Es ist ein Zugriff auf die Texeltorregister bereitgestellt, um zu ermöglichen, dass dieselben durch die 3-D-Grundelementpipeline beschrieben werden. Die Texeltorregister können beschrieben werden, selbst wenn die 3-D-Pipeline belegt ist, und die Daten zum Beschreiben der Register werden einfach in die Pipeline platziert. Ferner kann auf die Texeltorregister auch durch die 3-D-Pipelineumgehung zugegriffen werden, die über den 24-Bit-Bus 24 (4) bereitgestellt ist. Bei einem Zugreifen auf die Texeltorregister werden acht Bits des Bus 24 als eine Registeradresse verwendet, um zu spezifizieren, welches Texeltorregister gelesen oder beschrieben werden soll und wann Daten zu einem Texeltorregister geschrieben werden sollen, wobei die anderen sechzehn Bits des Bus die Daten liefern.
  • Die Organisationen der Texeltorregister sind in 20 gezeigt. Bei einem Ausführungsbeispiel umfasst jedes der Texeltorregister 32 Bits, obwohl eine Anzahl der Bits in einigen der Register unbenutzt ist.
  • 1. Texelbefehlsregister
  • Das Texelbefehlsregister umfasst eine Anzahl von Bits, die durch die TIM verwendet werden, die unten detaillierter erläutert ist und Cache-Fehltreffer bedient. Ein Anhalten-Bit 350 wird durch die TIM gesetzt und weist den Texturabbildungschip an, die Operation desselben anzuhalten. Wie es oben dargelegt ist, werden bei dem Ausführungsbeispiel, bei dem zwei Texturabbildungschips vorgesehen sind, beide Texturabbildungschips mit den gleichen Texturdaten ansprechend auf einen Cache-Fehltreffer von einem aktualisiert, so dass die Caches konsistent bleiben. Wenn somit ein Fehltreffer von einem Texturabbildungschip empfangen wird, werden durch ein Setzen des Anhalten-Bits 350 in den jeweiligen Texelbefehlsregistern derselben beide angehalten. Das Anhalten-Bit wird durch die Softwareroutine, die den Cache-Fehltreffer handhabt, durch ein Schreiben zu dem Befehlsregister gelöscht, um das Bit zu löschen, nachdem neue Texturdaten von dem Hostcomputer durch die TIM ansprechend auf den Cache-Fehltreffer heruntergeladen wurden.
  • Ein Unterbrechung-Freigegeben-Bit 352 gibt, wenn dasselbe aktiviert ist, Unterbrechungen von dem Texeltor frei, wenn ein Cache-Fehltreffer auftritt. Dieses Bit ist deaktiviert, um die oben beschriebene Fähigkeit eines nicht als ein Cache wirksam sein Lassens des lokalen Speichers 48 an der Texturabbildungsplatine 12 (4) zu liefern.
  • Schreiben-Loki0- und Schreiben-Loki1-Bits 354 und 356 sind Schreibfreigaben für die Texeltorregister. Loki ist ein Name in Kurzschreibweise, der verwendet wird, um den Texturabbildungschip 46 zu identifizieren. Bei dem Ausführungsbeispiel, bei dem zwei derartige Chips verwendet werden, werden die Chips als Loki0 bzw. Loki1 bezeichnet. Wenn lediglich ein einziger Texturabbildungschip verwendet wird, ist derselbe als Loki0 identifiziert. Wenn ein Befehl über den Texeltorbus 24 empfangen wird, um zu irgendeinem der Texeltorregister zu schreiben, prüft jeder Texturabbildungschip (d.h. Loki0 und Loki1) das Befehlsregister desselben, um zu bestimmen, ob das Schreiben-Bit desselben freigegeben ist, und aktualisiert, falls dasselbe es ist, die Texeltorregister desselben gemäß dem empfangenen Schreibbefehl. Durch ein Steuern der Werte der Schreiben-Loki0- und Schreiben-Loki1-Bits 354 und 356 kann somit die TIM zu den Texeltorregistern in den zwei Texturabbildungschips entweder getrennt oder in Kombination schreiben.
  • Ein Loki-Lesen-Bit 358 gibt Lesevorgänge der Texeltorregister von einem der Texturabbildungschips frei. Wenn ein Befehl über den Texelbus 24 empfangen wird, um ein Texeltorregister zu lesen, spricht lediglich einer der Texturab bildungschips zu einer Zeit an, um die Inhalte des Texeltorregisters desselben auf den Bus zu liefern. Bei dem Ausführungsbeispiel, bei dem zwei Texeltorabbildungschips vorgesehen sind, kann jeder mit einem Anschlussstift versehen sein, der fest verdrahtet ist, um anzugeben, ob der Chip Loki0 oder Loki1 ist. Wenn das Loki-Lesen-Bit durch eine Software gesetzt ist, gibt dasselbe an, dass Lesevorgänge von Loki1 freigegeben sind, und, wenn das Lesen-Bit deaktiviert ist, gibt dasselbe an, dass Lesevorgänge für Loki0 freigegeben sind. Aus dem Vorhergehenden ist ersichtlich, dass das Format des Texelbefehlsregisters ermöglicht, dass dasselbe zu beiden Texturabbildungschips (Loki0 und Loki1) simultan mit denselben Daten geschrieben wird, wodurch lediglich ein einziger Schreibzyklus erforderlich ist, um beide Befehlsregister zu beschreiben.
  • 2. Texelstatusregister
  • Das Texeltorstatusregister umfasst ein Dual-Loki-Bit 360, das, wenn dasselbe aktiviert ist, angibt, dass das System zwei Texturabbildungschips umfasst. Ein Unterbrechung-Freigegeben-Bit 362 ist aktiviert, wann immer das Bit 352 in dem Befehlsregister aktiviert ist, und gibt an, dass der lokale Speicher in dem Texturabbildungschip als ein Cache wirksam ist, der Fehltreffer erzeugen wird, die den Hostcomputer unterbrechen, wenn Texturdaten benötigt werden, die sich nicht in dem Cache befinden. Dieses Bit ist in dem Statusregister sowie dem Befehlsregister enthalten, so dass der Status des Texeltors durch ein einfaches Lesen des Statusregisters gelesen werden kann.
  • Ein Unterbrechung-Gültig-Bit 364 ist aktiviert, wenn eine Unterbrechung von dem Texturabbildungschip aufgetreten ist und der Chip darauf wartet, dass neue Texturdaten heruntergeladen werden. Dieses Bit wird gelöscht, wenn das Cache-Verzeichniskennungsregister (unten erörtert) mit einer Cache-Kennung beschrieben ist, die mit der Cache- Lesekennung übereinstimmt, die in dem Leitungskennungsregister (unten erörtert) gespeichert ist und die Kennung ist, die in dem Cache fehlte.
  • Das Statusregister umfasst zwei Bits, die das Anhalten des Texturabbildungschips unterstützen, wenn ein Cache-Fehltreffer auftritt. Ein Anhalten-Freigegeben-Bit 368 wird durch die TIM gesetzt und gelöscht, wann immer das Anhalten-Bit 350 in dem Befehlsregister gesetzt bzw. gelöscht wird, und weist den Texturabbildungschip an, sich selbst anzuhalten, wenn das Bit aktiviert ist. Dieses Bit ist in dem Statusregister sowie dem Befehlsregister vorgesehen, so dass der Status des Texturabbildungschips in einem einzigen Register gespeichert ist. Unterbrechung-Gültig 368 wird durch eine Hardware in dem Texturabbildungschip gesetzt, wenn ein Cache-Fehltreffer aufgetreten ist und das Cache-Verzeichnis darauf wartet, dass Daten heruntergeladen werden. Dieses Bit wird gelöscht, wenn das Cache-Verzeichniskennungsregister (unten erörtert) mit einer Cache-Kennung beschrieben wird, die mit der Blockadresse übereinstimmt, die in dem Cache fehlte.
  • 3. Leitungskennungsregister
  • Das Leitungskennungsregister speichert die letzte Blockkennung, die durch die Pipeline in dem Texturabbildungschip indexiert wurde. Wenn ein Cache-Fehltreffer auftritt, speichert das Leitungskennungsregister die Blockkennung 370, die in dem Cache fehlte. Durch ein Lesen des Leitungskennungsregisters über den Texeltorbus 24 kann somit die Software, die auf den Cache-Fehltreffer anspricht, die Kennung für den Cache-Block bestimmen, der ansprechend auf den Fehltreffer zu dem Cache heruntergeladen werden sollte.
  • 4. Texeldatenregister
  • Das Texeldatenregister wird verwendet, um Texturdaten zu dem Cache 48 herunterzuladen, wenn ein Cache-Fehltreffer auftritt. Wie es oben angegeben ist, ist jedes Texel durch 32 Datenbits dargestellt, wobei ein Byte 372 Alpha darstellt, ein Byte 374 den Rotwert darstellt, ein Byte 376 den Grünwert darstellt und ein Byte 378 den Blauwert darstellt.
  • 5. Texel-Cache-Adressregister
  • Das Texel-Cache-Adressregister wird verwendet, um Texeldaten zu dem Cache und Blockkennungen zu dem Cache-Verzeichnis zu schreiben. Wie es oben erörtert ist, speichert der Cache 64 Blöcke von Texturdaten, wobei jeder Block ein Array von 256 × 256 Texeln umfasst. Das Texel-Cache-Adressregister umfasst ein 6-Bit-Blockindexfeld 380, das den speziellen der vierundsechzig Blöcke in dem Cache identifiziert, der gelesen oder geschrieben werden soll. Zusätzlich umfasst das Register ein 16-Bit-Blockadressfeld 382, das die spezielle Texeladresse identifiziert, die innerhalb des Blocks gelesen oder geschrieben wird, der in dem Blockindexfeld identifiziert ist. Wenn Daten zu dem Texturspeicher ansprechend auf einen Cache-Fehltreffer heruntergeladen werden, wird der Blockindex durch die Softwareroutine unter Verwendung des unten erörterten Ersetzungsschemas gesetzt und das Blockadressfeld 382 wird auf Nullen initialisiert, um das erste Texel in dem Block zu schreiben. Das Cache-Adressregister implementiert automatisch das Blockadressfeld 382, wann immer auf das Texeldatenregister zugegriffen wird. Somit kann das Blockadressfeld durch alle der Blockadressen innerhalb des Cache-Blocks hindurch implementiert werden, um den neuen Block von Texeldaten in den Cache zu schreiben.
  • 6. Texelverzeichniskennungsregister
  • Das Texelverzeichniskennungsregister umfasst ein 32-Bit-Blockkennungsfeld 384, das die Cache-Blockkennung darstellt, und wird verwendet, um den Cache-Verzeichniseintrag, der durch das Blockindexfeld 380 in dem Cache-Adressregister definiert ist, zu schreiben. Wie es oben erörtert ist, stellen die dreiundzwanzig Bits der Cache-Blockkennung acht Bits der Textur ID, sieben Bits von S-Koordinaten, sieben Bits von T-Koordinaten und ein zusätzliches Bit dar, das die Abbildungsnummer in der Reihe von MIP-Abbildungen der Abbildung identifiziert, die durch den Block von Texturdaten dargestellt ist, der der Blockkennung entspricht. Wenn ein neuer Block von Texturdaten durch die TIM ansprechend auf einen Cache-Fehltreffer heruntergeladen wird, wird die Blockkennung desselben in das Verzeichniskennungsregister über den Texelbus 24 geladen. Aus dem Verzeichniskennungsregister wird die Blockkennung in das Cache-Verzeichnis in den Eintrag geschrieben, der durch das Blockindexfeld 380 des Cache-Adressregisters identifiziert ist. Wie es oben angegeben ist, wird die Cache-Fehltrefferunterbrechung gelöscht, wenn eine Blockkennung in das Verzeichniskennungsregister geschrieben wird, die mit der Kennung in dem Leitungskennungsregister übereinstimmt (das dieses ist, dessen Lesevorgang in einem Cache-Fehltreffer resultierte).
  • M. Softwareroutine zum Bedienen von Cache-Fehltrefferunterbrechungen
  • Wie aus dem Vorhergehenden ersichtlich ist, werden die Texeltorregister durch eine TIM verwendet, die an dem Hostcomputer 14 wirksam ist und die Cache-Fehltrefferunterbrechungen bedient, um die notwendigen Texturdaten herunterzuladen. Ein Flussdiagramm dieser TIM-Operation ist in 21 gezeigt. Bei einem Schritt 400 wird das Texelbefehlsregister für sowohl Loki0 als auch Loki1 beschrieben, um das Anhalten-Bit 350 in beiden zu setzen. Das Verfahren geht dann zu einem Schritt 402 über, um das Angehalten-Bit 368 in den Texelstatusregistern zu lesen, um zu bestimmen, ob beide Lokis angehalten haben. Das Verfahren liest die Statusregister von Loki0 und Loki1 weiter, bis bestimmt ist, dass beide angehalten haben, und geht dann zu einem Schritt 404 über. Wenn das System lediglich einen einzigen Texturabbildungschip 46 (d.h. Loki0) umfasst, dann spricht Loki0 durch ein Liefern der Inhalte der Register desselben an dem Texelbus 24 ferner auf Anforderungen an, um die Texeltorregister von Loki1 zu lesen. Wenn somit die TIM bei dem Schritt 402 überprüft, um zu bestimmen, ob beide Lokis angehalten haben, spricht Loki0 auf Lesevorgänge von Loki1 an, derart, dass, wenn Loki0 angehalten hat, das Verfahren zu dem Schritt 404 übergeht.
  • Bei dem Schritt 404 wird das Unterbrechung-Gültig-Bit 364 in dem Texelstatusregister von Loki0 gelesen, um zu bestimmen, ob Loki0 unterbrochen hat, um den Cache-Fehltreffer zu bewirken, und wenn derselbe es hat, geht das Verfahren zu einem Schritt 406 über, bei dem das Leitungskennungsregister von Loki0 gelesen wird, um die Blockkennung des Blocks von Texturdaten, der in dem Cache fehlte, zu identifizieren. Die TIM verwendet diese Blockkennung, um auf den entsprechenden Block von Texturdaten in dem Speicher 17 (4) zuzugreifen, und geht zu einem Schritt 408 über, um zu bestimmen, welcher Block in dem Cache mit dem neuen Cache-Block, der heruntergeladen werden soll, ersetzt werden sollte. Diese Bestimmung wird unter Verwendung des Niedrigste-Priorität- und Am-Weitesten-Zurückliegend-Verwendet-Schemas der Erfindung vorgenommen, wie es unten beschrieben ist.
  • Wie es oben dargelegt ist, werden, wenn das System zwei Texturabbildungschips umfasst, die Caches in jedem beibehalten, um identische Einträge aufzuweisen. Deshalb werden Texturdaten, die von dem Hostcomputer ansprechend auf einen Cache-Fehltreffer von einem der Texturabbildungschips heruntergeladen werden, zu den Caches in beiden Chips geschrieben. Wenn somit einmal der Cache-Block, der ersetzt werden soll, identifiziert wurde, geht das Verfahren zu einem Schritt 410 über, bei dem das Cache-Adressregister in Loki0 und Loki1 (falls Loki1 existiert) mit dem Blockindex beschrieben wird, der während des Schritts 408 bestimmt wird. Bei einem Schritt 412 wird das Verzeichniskennungsregister mit der Blockkennung des Blocks von Texturdaten beschrieben, der zu dem Textur-Cache ansprechend auf einen Cache-Fehltreffer heruntergeladen werden soll, und bei einem Schritt 414 werden die Texturdaten zu dem Texeldatenregister geschrieben. Auf diese Weise spricht das Verfahren auf den Cache-Fehltreffer durch ein Herunterladen des Blocks von Texturdaten, der in dem Cache fehlte, und ein Schreiben dieses Blocks von Texturdaten zu dem Cache an.
  • Nachdem der Block von Texturdaten zu Loki0 und Loki1 bei den Schritten 406 und 414 heruntergeladen ist, oder falls bei dem Schritt 404 bestimmt wird, dass Loki0 nicht unterbrach, geht das Verfahren zu einem Schritt 416 über, bei dem eine Bestimmung vorgenommen wird, ob das Unterbrechung-Gültig-Bit 364 in dem Loki1-Statusregister gesetzt wurde, was angibt, dass ein Cache-Fehltreffer in Loki1 auftrat. Wie es oben erörtert ist, spricht, falls das System lediglich einen einzigen Texturabbildungschip aufweist, Loki0 auf Lesevorgänge der Loki1-Texeltorregister an. Wenn Loki0 auf einen Lesevorgang des Statusregisters von Loki1 anspricht, maskiert derselbe das Unterbrechung-Gültig-Bit 364 desselben, so dass die TIM bei dem Schritt 416 bestimmt, dass Loki1 nicht unterbrach. Dieses Maskieren wird vorgenommen, so dass die TIM die Unterbrechung von Loki0 nicht wieder durch ein erneutes Herunterladen des Blocks von Texturdaten, der bei den Schritten 406–414 heruntergeladen wurde, verarbeitet. Deshalb bestimmt bei einem System, bei dem lediglich ein einziger Texturabbildungschip vorgesehen ist, das Verfahren bei dem Schritt 416, dass Loki1 nicht unterbrach, und geht zu einem Schritt 418 über, bei dem das Befehlsregister in Loki0 beschrieben wird, um das Anhalten-Bit 350 zu deaktivieren, wobei ermöglicht wird, dass der Texturabbildungschip mit einem Verarbeiten der Grundelemente in der Pipeline desselben fortfährt.
  • Wenn das System zwei Texturabbildungschips umfasst, bestimmt das Verfahren bei dem Schritt 416, ob Loki1 unterbrochen hat, und geht, falls derselbe es nicht hat, ebenfalls direkt zu dem Schritt 418 über, bei dem das Anhalten-Bit in beiden Texturabbildungschips deaktiviert wird, wobei ermöglicht wird, dass dieselben mit einem Verarbeiten von Grundelementen fortfahren. Wenn jedoch bei dem Schritt 416 bestimmt wird, dass Loki1 ansprechend auf einen Cache-Fehltreffer unterbrochen hat, geht das Verfahren durch Schritte 420–424 vor, um die Unterbrechung in der gleichen Weise zu verarbeiten, wie es oben in Verbindung mit den Schritten 406–414 zum Handhaben der Unterbrechung von Loki0 erörtert wurde. Das Verfahren geht dann zu dem Schritt 418 über, bei dem die Anhalten-Bits in beiden Texturabbildungschips deaktiviert werden.
  • Es ist klar, dass bei einem System, bei dem zwei Texturabbildungschips vorgesehen sind, beide Chips eine Cache-Fehltrefferunterbrechung simultan für die gleiche Blockkennung oder für unterschiedliche Blockkennungen erzeugen können. Wenn beide Texturabbildungschips Cache-Fehltrefferunterbrechungen für die gleiche Blockkennung erzeugen, wird die Unterbrechung bei den Schritten 400–414 verarbeitet. Bei dem Schritt 416 erfasst deshalb das Verfahren keine Unterbrechung von Loki1, weil die Unterbrechung von Loki1 durch das Schreiben der verfehlten Blockkennung zu dem Verzeichniskennungsregister beider Lokis bei dem Schritt 412 gelöscht wird. Somit ist das in 21 gezeigte Verfahren zum Ansprechen auf eine Unterbrechung von einem Texturabbildungschip einzeln oder von beiden simultan in der Lage.
  • N. Cache-Miniverzeichnis und Hauptverzeichnis
  • Wie es oben angemerkt ist, umfasst bei einem Ausführungsbeispiel der Cache vierundsechzig Blöcke von 256 × 256 Texeln von Daten und ein vollständig assoziatives Cache-Verzeichnis, das vierundsechzig Einträge von 23-Bit-Blockkennungen umfasst. Wenn die Vorrichtung in einem Trilinear-Interpolierung-Modus wirksam ist, werden acht Texel-Lesevorgänge durchgeführt, um die resultierenden Texeldaten für ein Pixel zu bestimmen, wobei vier Texel in einer Abbildung simultan bei einer Leseoperation gelesen werden und vier Texel in der anderen Abbildung simultan bei einer zweiten Leseoperation gelesen werden. Falls das Pixel, an dem man wirksam ist, zu einer Position in einer Abbildung abbildet, die benachbart zu einer Cache-Blockgrenze ist, können sich die vier Texel, die von dem Cache gelesen werden, um die resultierenden Texeldaten innerhalb einer Abbildung zu erzeugen, jeweils in einem unterschiedlichen Cache-Block befinden. Somit könnte das simultane Lesen von vier Texeln aus dem Cache für jedes Pixel vier getrennte Vergleiche mit den vierundsechzig Blockkennungseinträgen in dem Cache-Verzeichnis erfordern.
  • Herkömmliche vollständig assoziative Caches sind in einer von zwei Weisen wirksam. Erstens sehen Einige getrennte Hardwarekomparatoren für jeden Cache-Kennungseintrag vor, so dass eine Lesekennung mit dem Cache-Kennungseintrag in einem einzigen Zyklus verglichen werden kann. Eine derartige Technik würde große Hardwarekosten einfahren, wobei vier Lesevorgänge simultan vorgenommen werden, und würde zweihundertsechsundfünfzig (d.h. 4 × 64) 23-Bit-Komparatoren erfordern. Eine zweite Technik, die durch herkömmliche vollständig assoziative Caches verwendet wird, verwendet einen einzigen Cache-Kennungskomparator und jeder Cache-Eintrag wird mit der Lesekennung seriell bzw. in Reihe verglichen. Eine derartige Technik würde eine Systembandbreite negativ beeinflussen, wobei möglicherweise zweihundertsechsundfünfzig Lesezyklen des Cache-Verzeichnisses erforderlich wären, um zu bestimmen, ob jedes der vier Texel, die während einer einzigen Leseoperation gelesen werden, in dem Cache vorhanden waren.
  • Um diese Probleme zu überwinden, umfasst das Cache-System sowohl ein Miniverzeichnis (22) als auch ein Hauptverzeichnis (23). Das Miniverzeichnis ist vollständig assoziativ und umfasst die fünf jüngst gelesenen Cache-Blockkennungen sowie einen entsprechenden Blockindex für jede. Wie es in 22 gezeigt ist, umfasst das Miniverzeichnis 500 fünf Einträge, die von dem Miniverzeichnis über jeweilige Ausgänge 501–505 ausgegeben werden, von denen jeder mit vier Gruppen von Kennungskomparatoren 507–510 gekoppelt ist. Jede Gruppe von Kennungskomparatoren 507–510 umfasst fünf 23-Bit-Komparatoren (nicht gezeigt) und entspricht einer der vier Cache-Lesekennungen, die bei einer einzigen Leseoperation durchgeführt werden, wenn eine bilineare oder trilineare Interpolierung durchgeführt wird. Somit ist die vollständig assoziative Beschaffenheit des Miniverzeichnisses mit zwanzig 23-Bit-Komparatoren gleich der Anzahl simultan gelesener Kennungen multipliziert mit der Anzahl von Einträgen in dem Miniverzeichnis implementiert.
  • Die vier Cache-Lesekennungen, die simultan für ein Pixel gelesen werden, identifizieren die Cache-Blöcke, die die vier Texel umfassen, die am nächsten zu der Position in der Abbildung sind, zu der das Pixel abbildet, und werden als eine obere linke (UL = upper left) Kennung, eine obere rechte (UR = upper right) Kennung, eine untere linke (LL = lower left) Kennung und eine untere rechte (LR = lower right) Kennung bezeichnet. Die Cache-Lesekennungen für das obere linke, das obere rechte, das untere linke und das untere rechte Texel sind mit Gruppen des oberen linken, des oberen rechten, des unteren linken bzw. des unteren rechten Kennungskomparators 507–510 verbunden. Jede Gruppe der Kennungskomparatoren 507–510 vergleicht die entsprechende Cache-Lesekennung derselben mit den fünf Blockkennungen, die in dem Miniverzeichnis gespeichert sind, und erzeugt eine Treffer-Ausgabe, die angibt, ob die Kennung mit einem der Miniverzeichniseinträge übereinstimmt, und gibt, wenn dieselbe es tut, einen Blockindex aus, der die Position in dem Cache angibt, bei der der entsprechende Block von Texeldaten gespeichert ist.
  • Wie es aus dem Vorhergehenden ersichtlich ist, ist, falls jede der vier Cache-Lesekennungen (UL, UR, LL, LR) sich in dem Miniverzeichnis befindet, lediglich ein einziger Verzeichniszugriff erforderlich, um die Blockindizes zu bestimmen, die die Positionen in dem Cache identifizieren, bei denen die entsprechenden vier Blöcke von Texeldaten gespeichert sind. Ein Zugriff wird auf das Hauptcacheverzeichnis lediglich vorgenommen, falls eine oder mehrere der Lesekennungen sich nicht in dem Miniverzeichnis befinden. Das Miniverzeichnis 500 wird jedes Mal aktualisiert, wenn eine Cache-Lesekennung in dem Miniverzeichnis fehlt, so dass zu allen Zeiten das Miniverzeichnis 500 die Blockkennungen der fünf jüngst zugegriffenen Blöcke von Texturdaten umfasst.
  • Falls eine oder mehrere der vier Cache-Lesekennungen nicht in das Miniverzeichnis trifft, wird ein Zugriff auf das Hauptcacheverzeichnis 520 (23) vorgenommen. Wie es oben angemerkt ist, umfasst das Hauptverzeichnis vierundsechzig Einträge, die jeweils eine Blockkennung umfassen. Das Hauptverzeichnis ist mit vierundsechzig 23-Bit-Komparatoren 522 versehen, so dass eine Cache-Lesekennung in einem einzigen Zyklus mit dem ganzen Hauptverzeichnis verglichen werden kann. Die Komparatoren 522 liefern ein Signal, das angibt, ob die Cache-Lesekennung eine der Einträge in dem Hauptverzeichnis getroffen hat, und wenn dieselbe es hat, wird die Position des Komparators, die die Lesekennung in Übereinstimmung brachte, ferner verwendet, um einen Blockindex zu erzeugen, der identifiziert, wo der entsprechende Block von Texturdaten in dem Cache liegt. Falls die Lesekennung nicht mit irgendeinem der Einträge in dem Hauptcacheverzeichnis übereinstimmt, wird ein Cache- Fehltreffer erzeugt, was bewirkt, dass der Hostcomputer unterbrochen wird, um den erforderlichen Block von Texturdaten in der oben beschriebenen Weise herunterzuladen.
  • Wie es oben dargelegt ist, wird auf das Hauptcacheverzeichnis 520 lediglich zugegriffen, wenn eine oder mehr der vier Cache-Lesekennungen (UL, UR, LL, LR) nicht das Miniverzeichnis trifft. Falls zwei oder mehr Cache-Lesekennungen das Miniverzeichnis verfehlen, ist es erwünscht, die Leistungsfähigkeitseinbuße zu reduzieren, die erlitten würde, falls auf das Hauptverzeichnis in getrennten Zyklen für jede Cache-Lesekennungen zugegriffen werden müsste. Um dieses Ergebnis zu erreichen, ist bei einem Ausführungsbeispiel eine Gruppe von sechs zusätzlichen Komparatoren 526–530 vorgesehen, wie es in 24 gezeigt ist. Die sechs Komparatoren vergleichen jede der vier Cache-Lesekennungen, auf die simultan zugegriffen wird, mit den anderen, um zu bestimmen, ob irgendwelche identisch sind. Die Komparatoren umfassen den Komparator 526, der die UL-Kennung mit der UR-Kennung vergleicht, den Komparator 527, der die UL- und die LL-Kennung vergleicht, den Komparator 528, der die UL- und die LR-Kennung vergleicht, den Komparator 529, der die UR- und die LL-Kennung vergleicht, den Komparator 530, der die UR- und die LR-Kennung vergleicht, und den Komparator 533, der die LL- und die LR-Kennung vergleicht.
  • Die durch die Komparatoren 526–532 durchgeführten Vergleiche können parallel zu anderen Vergleichen durchgeführt werden, um keine Leistungsfähigkeitseinbuße zu erleiden. Zum Beispiel können diese Vergleiche während des Zyklus durchgeführt werden, wenn die Cache-Lesekennungen mit dem Miniverzeichnis verglichen werden, oder während des Zyklus, wenn eine erste Cache-Lesekennung, die in dem Miniverzeichnis fehlte, mit dem Hauptverzeichnis verglichen wird. Wenn bestimmt wird, dass zumindest zwei Cache-Lesekennungen nicht das Hauptverzeichnis treffen und gleich sind, werden die Ausgangssignale der Komparatoren 526–532 verwendet, um anzugeben, dass auf das Hauptverzeichnis lediglich ein Mal für diese zumindest zwei Cache-Lesekennungen zugegriffen werden muss. Auf diese Weise müssen nicht mehrere Zyklen bei einem Zugreifen auf das Hauptverzeichnis für Kennungen eingefahren werden, die identisch sind, wodurch die Auswirkung auf eine Systembandbreite minimiert wird, wenn zwei oder mehr Cache-Lesekennungen das Miniverzeichnis verfehlen.
  • Wie aus dem Vorhergehenden ersichtlich ist, gleicht das Ausführungsbeispiel, das das Cache-Miniverzeichnis verwendet, die konkurrierenden Ziele eines Verwendens einer relativ kleinen Menge von Hardware, um das Cache-Verzeichnis zu implementieren, wirksam aus, während eine hohe Systembandbreite erreicht wird. Die Leistungsfähigkeitseinbußen, die erlitten werden, wenn zwei oder mehr Cache-Lesekennungen das Miniverzeichnis verfehlen, sind anwendungsabhängig. Obwohl es möglich ist, dass zwei eindeutige Sätze von vier Cache-Lesekennungen alle zwei Zyklen durch das Miniverzeichnis verarbeitet werden, glaubt man, dass typischerweise lediglich eine oder zwei eindeutige Blockkennungen in jedem Satz von vier Cache-Lesekennungen erscheinen. Wie es oben erörtert ist, bilden, wenn Pixel eines Objekts aufbereitet werden und eine trilineare Interpolierung verwendet wird, benachbarte Pixel häufig zu den gleichen zwei Abbildungen für die MIP-Abbildung ab, was erfordert, dass Lesevorgänge zu dem Cache kontinuierlich zwischen den Cache-Blöcken umschalten, die die zwei Abbildungen speichern. Bei dem in 22 gezeigten darstellenden Ausführungsbeispiel speichert das Miniverzeichnis fünf Blockkennungen, um sicherzustellen, dass, selbst falls vier eindeutige Cache-Kennungen für einen gegenwärtig verarbeiteten Satz von Lesekennungen in dem Mini-Cache resident sind, zumindest eine Kennung, auf die bei dem vorhergehenden Satz von Lesekennungen zugegriffen wird, in dem Miniverzeichnis bleibt. Selbst bei einem Umschalten zwischen zwei Sätzen von vier eindeutigen Cache-Kennungen während einer trilinearen Interpolierung bleibt somit zumindest eine der Lesecachekennungen für jeden Satz in dem Miniver zeichnis, so dass vier Cache-Kennungen nicht mit dem Hauptverzeichnis auf eine serielle Weise verglichen werden müssen.
  • Während eines Aufbereitens von Texeln lesen, wenn eine trilineare Interpolierung verwendet wird, aufeinander folgende Lesevorgänge zu dem Cache einen ersten Satz von vier Texeln in einer Abbildung und einen zweiten Satz von vier Texeln in einer anderen. Wenn ein Grundelement aufbereitet wird, wird auf benachbarte Texel innerhalb jeder von zwei Abbildungen bei jedem zweiten Zyklus zugegriffen und zwei oder mehrere Texel sind allgemein innerhalb eines einzigen Cache-Blocks positioniert. Falls deshalb lediglich eine oder zwei eindeutige Kennungen in jedem Satz von vier Cache-Lesekennungen erscheinen, kann eine große Anzahl von Pixeln aufbereitet werden, wobei jede Cache-Lesekennung das Miniverzeichnis 500 trifft. Falls lediglich eine Cache-Lesekennung in jedem Satz von vier das Miniverzeichnis verfehlt, wird keine Leistungsfähigkeitseinbuße erlitten, weil diese Kennung mit dem Hauptverzeichnis verglichen werden kann, während der nächste Satz von vier Lesekennungen mit dem Miniverzeichnis verglichen wird.
  • Es ist klar, dass das Cache-Verzeichnis, das sowohl ein Hauptverzeichnis als auch kleineres Miniverzeichnis umfasst, bei vielen anderen Anwendungen verwendet werden kann und nicht auf eine Verwendung bei einem Texturabbildungshardwaresystem begrenzt ist. Das Minicacheverzeichnisschema ist bei einem Implementieren eines vollständig assoziativen Cache und Reduzieren der Kosten von Verzeichniskennungsvergleichen besonders nützlich, wenn mehrere Cache-Kennungslesevorgänge simultan verarbeitet werden und wenn Cache-Lesekennungen mit aufeinander folgend zugegriffenen, vorhergehend verwendeten Kennungen korreliert werden. Zum Beispiel es ist bei einem Cache-Speicher, der X Kennungen zu irgendeiner Zeit speichert und bei dem N Cache-Lesekennungen simultan mit den Verzeichnisblockkennungen verglichen werden, ausreichend, ein Miniverzeichnis beizu behalten, das M Kennungen umfasst, wobei M größer oder gleich N ist. Jede der M Miniverzeichniskennungen wird in einer einzigen Leseoperation mit den N Cache-Lesekennungen verglichen. Auf das Hauptverzeichnis wird seriell für irgendeine Cache-Lesekennung zugegriffen, die nicht in das Miniverzeichnis trifft. Derartige Lesekennungen werden mit den Hauptverzeichniskennungen in einem einzigen Zyklus verglichen. Die Hardwareeinsparungen hinsichtlich Komparatoren von einem System, bei dem jede der X Kennungen in dem Hauptverzeichnis mit den N Lesekennungen in einer einzigen Leseoperation verglichen wird, hängt von dem Verhältnis von (X+M·N)/(X·N) ab.
  • Die Leistungsfähigkeitseinbuße, die erlitten wird, um diese Hardwareeinsparungen zu erreichen, ist anwendungsabhängig, basierend auf dem Verhalten der Sequenz von Kennungen, auf die bei aufeinander folgenden Leseoperationen zugegriffen wird. Falls nicht mehr als eine Kennung in jedem Lesesatz das Miniverzeichnis verfehlt, wird keine Einbuße erlitten, da die verfehlte Kennung mit dem Hauptverzeichnis parallel zu dem nächsten Satz von Lesekennungen verglichen werden kann, die mit dem Miniverzeichnis verglichen werden.
  • Mit Bezug auf die oben beschriebenen Komparatoren 526–530, die verwendet werden, um Leistungsfähigkeitseinbußen zu reduzieren, wenn zwei oder mehr Cache-Lesekennungen in dem Miniverzeichnis verfehlen, werden sechs verwendet, weil auf vier Lesekennungen simultan zugegriffen wird. Die Anzahl von Komparatoren, die verwendet werden, um jede Cache-Lesekennung mit den anderen zu vergleichen, hängt von der Anzahl N von Lesekennungen ab, auf die simultan zugegriffen wird, und ist gleich (N–1) Fakultät bzw. faktoriell.
  • Eine darstellende Implementierung eines Cache-Verzeichnisses, das das Miniverzeichnis und das Hauptverzeichnis von 22–23 umfasst, ist in 25 gezeigt. Es ist klar, dass die in 25 gezeigte Implementierung lediglich zu darstellenden Zwecken vorgesehen ist und dass andere Implementierungen ebenfalls verwendet werden können.
  • Die Miniverzeichniseinträge 501–505 (22) sind in eine Kennungskomponente, die in Kennungsregistern 501T 505T gespeichert ist, und eine Indexkomponente getrennt, die in Indexregistern 501I–505I gespeichert ist. Wie es oben erörtert ist, empfängt das Cache-Verzeichnis einen Satz von vier Lese-Cache-Kennungen, die den vier Texeln (d.h. UL, UR, LL und LR) entsprechen, die der Position in einer MIP-Abbildung am nächsten sind, zu der ein Pixel abbildet, an dem man wirksam ist. Jede der vier Lesekennungen wird zu sechs Kennungskomparatoren 541–546 geliefert. Fünf der Komparatoren (d.h. 542–546) sind ferner mit einem jeweiligen der fünf Miniverzeichniskennungsregister 501T–505T gekoppelt. Zum Beispiel ist der Komparator 542 mit dem Kennungsregister 501T für einen Eintrag1 des Miniverzeichnisses gekoppelt und erzeugt ein Ausgangssignal, das angibt, ob die Kennung in diesem Eintrag des Miniverzeichnisses mit der Kennung irgendeiner der Lese-Cache-Kennungen UL, UR, LL oder LR übereinstimmt. Die Komparatoren 543–546 sind auf eine ähnliche Weise wirksam und vergleichen die Lese-Cache-Kennungen UL, UR, LL bzw. LR mit den Kennungsregistern 502T–505T, die die jeweiligen Kennungen für Eintrag2-Eintrag5 des Miniverzeichnisses speichern. Jeder neue Satz von vier Lese-Cache-Kennungen wird in einem einzigen Zyklus mit dem Miniverzeichnis verglichen. Am Ende dieses Zyklus sind die vier Kennungen UL, UR, LL bzw. LR in Registern 550–553 gespeichert. Wie es in 25 gezeigt ist, ist jedes der Register 550–553 ferner mit einer Steuerschaltung 559 gekoppelt, die die Ausgangssignale der Miniverzeichniskennungskomparatoren 542–546 empfängt. Am Ende des Zyklus, bei dem ein neuer Satz von vier Lesekennungen mit den Miniverzeichniskennungen verglichen wird, wird jedes der Register 550–553 ferner mit Daten geladen, die identifizieren, ob die entsprechende Kennung desselben (d.h. UL, UR, LL, LR) mit einem der Miniverzeichniseinträge übereinstimmte, und falls dem so ist, welcher Eintrag in Übereinstimmung gebracht wurde.
  • Falls, wie es oben erörtert ist, lediglich eine einzige Cache-Lesekennung in dem Miniverzeichnis verfehlt, wird diese Kennung mit dem Hauptverzeichnis verglichen, während ein nächster Satz von vier Texellesekennungen mit dem Miniverzeichnis verglichen wird. Wenn ein Fehltreffer in dem Miniverzeichnis auftritt, wird das Miniverzeichnis aktualisiert, um die Kennung zu umfassen, die fehlte, so dass das Miniverzeichnis immer die fünf jüngst zugegriffenen Cache-Kennungen wiederspiegelt. Während des Zyklus, bei dem eine Lese-Cache-Kennung, die in dem Miniverzeichnis fehlte, mit dem Hauptverzeichnis verglichen wird, während ein nächster Satz von vier Lesekennungen mit dem Miniverzeichnis verglichen wird, wurden die Miniverzeichniskennungsregister 501T–505T noch nicht aktualisiert, um die Cache-Kennung zu umfassen, die in dem Miniverzeichnis bei dem vorhergehenden Zyklus fehlte. Wenn deshalb der nächste Satz von Lese-Cache-Kennungen mit dem Miniverzeichnis verglichen wird, wird ein sechster Komparator 541 verwendet, um die vier Lesekennungen (UL, UR, LL und LR) mit der Kennung zu vergleichen, die in dem Miniverzeichnis bei dem vorhergehenden Zyklus fehlte, und wird mit dem Hauptverzeichnis verglichen.
  • Falls mehr als eine eindeutige Kennung in dem Satz von vier Cache-Lesekennungen (UL, UR, LL und LR) das Miniverzeichnis verfehlt, wird die Pipeline durch das Cache-Verzeichnis angehalten, weil mehrere Vergleiche mit dem Hauptverzeichnis auftreten. Falls jedoch lediglich eine eindeutige Kennung das Miniverzeichnis verfehlt, fährt die Pipeline in der folgenden Weise fort, so dass das Cache-Verzeichnis einen neuen Satz von vier Cache-Lesekennungen bei jedem Zyklus empfängt.
  • Wie es oben dargelegt ist, sind die Lesekennungen, die mit dem Miniverzeichnis bei dem vorhergehenden Zyklus vergli chen wurden, in den Registern 550–553 gespeichert. Die Ausgänge dieser Register sind mit einem Vier-Zu-Eins-Multiplexer 555 gekoppelt, der eines dieser Register zu einer Zeit auswählt, um mit dem Hauptverzeichnis verglichen zu werden und am Ende des Zyklus in das Miniverzeichnis geladen zu werden, so dass das Miniverzeichnis mit den jüngst empfangenen Lese-Cache-Kennungen aktualisiert wird. Der Ausgang des Multiplexers 555 ist ferner mit dem sechsten Komparator 541 gekoppelt, so dass die Cache-Lesekennung, die das Miniverzeichnis bei dem vorhergehenden Zyklus verfehlte, mit jeder des neuen Satzes von Lesekennungen UL, UR, LL und LR verglichen wird. In Kombination mit den Komparatoren 542–546 stellt der Komparator 541 sicher, dass das Miniverzeichnis jeden Satz von vier Cache-Lesekennungen, die durch das Cache-Verzeichnis empfangen werden, mit den fünf jüngst empfangenen Lesekennungen vergleicht.
  • Wie es oben dargelegt ist, wird die Cache-Lesekennung, die von dem Multiplexer 555 ausgegeben wird, ferner in eines der Miniverzeichniskennungsregister 501T–505T am Ende des Zyklus geladen, bei dem dieselbe mit dem Hauptverzeichnis verglichen wird. Somit ist das Miniverzeichnis aktualisiert, um die jüngst zugegriffenen Cache-Kennungen zu umfassen. Die Bestimmung dessen, welcher Eintrag mit der neuen Cache-Kennung von dem Multiplexer 555 beschrieben wird, wird durch ein unten erörtertes Ersetzungsschema vorgenommen.
  • Der Satz von sechs Komparatoren 526–532, der oben in Verbindung mit 24 erörtert ist, ist in 25 der Zweckmäßigkeit halber als ein einziger Komparatorblock gezeigt. Die Ausgangssignale dieser Komparatoren, sowie die Ausgangssignale der Komparatoren 541–546, werden jeweils zu der Steuerschaltung 559 geliefert, die mehrere Funktionen durchführt. Wenn ein Fehltreffer zu dem Miniverzeichnis auftritt, bestimmt die Steuerschaltung 559, welcher Eintrag in dem Miniverzeichnis mit der neuen Lese-Cache-Kennung ersetzt werden soll. Die Steuerschaltung 559 ersetzt keinen Eintrag, der ein Treffer war, durch eine der vier neu empfangenen Lese-Cache-Kennungen, die mit dem Miniverzeichnis verglichen werden, oder der letzten Lese-Cache-Kennung, die mit dem Hauptverzeichnis verglichen wurde, und weist diesen Einträgen eine höchste Priorität für ein beibehalten Werden in dem Miniverzeichnis zu. Zusätzlich speichert die Steuerschaltung 559 Zustandsinformationen hinsichtlich dessen, welche Miniverzeichniseinträge durch den vorhergehenden Satz von vier Lesekennungen getroffen wurden, und weist denselben die nächsthöchste Priorität für ein beibehalten Werden in dem Miniverzeichnis zu. Den verbleibenden Einträgen wird eine niedrigere Priorität zugewiesen.
  • Die Steuerschaltung 559 wählt einen Eintrag für eine Ersetzung aus, der sich in der niedrigsten Prioritätsgruppe befindet, die zumindest einen Eintrag umfasst. Falls es somit zumindest einen Eintrag in der niedrigsten Prioritätsgruppe gibt, der nicht durch eine vier neu empfangenen Lese-Cache-Kennungen getroffen wurde, die mit dem Miniverzeichnis verglichen werden, nicht die letzte Lese-Cache-Kennung war, die mit dem Hauptverzeichnis verglichen wurde, und nicht in dem vorhergehenden Satz von vier Lesekennungen war, wird einer der Einträge in der niedrigsten Prioritätsgruppe für eine Ersetzung ausgewählt. Falls es jedoch keine Einträge in der niedrigeren Prioritätsgruppe gibt, wird eine größere Gruppe von Einträgen ausgewählt, die lediglich die Einträge mit der höchsten Priorität ausschließt (d.h. dieselben, die durch eine der vier neu empfangenen Lese-Cache-Kennungen und die letzte Lese-Cache-Kennung getroffen wurden, die mit dem Hauptverzeichnis verglichen wurde), und ein Eintrag aus dieser Gruppe wird für eine Ersetzung ausgewählt.
  • Wenn die Gruppe der niedrigsten Priorität von verfügbaren Miniverzeichniseinträgen identifiziert ist, wird eine Bestimmung dessen, welcher Eintrag in der Gruppe ersetzt werden sollte, gemäß einem Ersetzungsschema vorgenommen, der jeden der fünf Miniverzeichniseinträge jedes Mal zyklisch durchläuft, wenn einer ersetzt wird. Dies kann in einer Anzahl von Weisen vorgenommen werden. Bei einem Ausführungsbeispiel sind die Miniverzeichniseinträge mit Eins bis Fünf etikettiert. Der Eintrag, der ersetzt werden soll, wird aus der niedrigsten Prioritätsgruppe durch zuerst ein Identifizieren des Eintrags mit der höchsten Nummer, der sich nicht in der Gruppe befindet, und dann ein Auswählen des Eintrags mit der nächsthöchsten Nummer, der sich in dieser Gruppe befindet, für eine Ersetzung ausgewählt. Wenn Eintrag Fünf sich nicht in der Gruppe befindet, kreist das Schema umher, so dass Eintrag Eins als der Eintrag mit der nächsthöchsten Nummer behandelt wird. Durch dieses Ersetzungsschema durchläuft die Steuerschaltung 559 die Miniverzeichniseinträge jedes Mal zyklisch, wenn einer ersetzt werden muss, und steuert das Laden des ausgewählten Miniverzeichniskennungsregisters 501T–505T.
  • Die Steuerschaltung 559 decodiert ferner die Ausgangssignale der Komparatoren 541–546, um Daten für jede der vier Lesekennungen (UL, UR, LL und LR) zu erzeugen, die angeben, ob die Lesekennung mit einem Eintrag in dem Miniverzeichnis übereinstimmte, und falls dem so ist, welcher Eintrag in Übereinstimmung gebracht wurde. Diese Daten sind in den entsprechenden Registern 550–553 für jede der Lesekennungen UL, UR, LL und LR gespeichert. Falls beispielsweise die Lesekennung UL mit dem Eintrag3 des Miniverzeichnisses übereinstimmte, würden die Daten, die durch die Steuerschaltung 559 decodiert werden, in dem UL-Register 550 gespeichert, um anzugeben, dass diese Lesekennung mit dem Eintrag3 des Miniverzeichnisses übereinstimmt. Wie es unten erörtert ist, werden diese Daten durch die Cache-Verzeichnispipeline geführt und geben an, dass der Blockindex für das UL-Texel in dem Register 503I gespeichert ist, das den Blockindex für den Eintrag3 des Miniverzeichnisses hält.
  • Wenn lediglich eine eindeutige Kennung für den Satz von Lesekennungen UL, UR, LL und LR das Miniverzeichnis verfehlt, wird jedes der Register 550–553, das diese Lesekennung speichert, mit Daten geladen, die angeben, dass der Blockindex für die entsprechenden Texturdaten sich nicht in dem Miniverzeichnis befindet. Während des nächsten Zyklus wird das Ausgangssignal eines der Register 550–553, das die fehlende Kennung speichert, mit dem Hauptverzeichnis 520 verglichen und der Blockindex für die Lesekennung wird aus dem Hauptverzeichnis in ein Register 561 geladen, das den Hauptverzeichnisblockindex speichert. Die Daten, die angeben, dass der Blockindex nicht irgendeinem Eintrag in dem Miniverzeichnis entspricht, sind ebenfalls in dem Register 561 von dem Eingangssignal 562 gespeichert, das von dem Ausgang des Multiplexers 555 geliefert wird.
  • Wie es oben beschrieben ist, umfasst der Cache-Speicher vier Verschachtelungen A–D, so dass auf vier Texel simultan zugegriffen werden kann. Der Satz von vier Texellesekennungen UL, UR, LL und LR kann auf irgendeine Weise den Verschachtelungen A–D entsprechen. Die Daten, die in den Registern 550–553 gespeichert sind und identifizieren, welcher Miniverzeichniseintrag den Blockindex speichert, der jedem der Texel UL, UR, LL und LR entspricht, werden durch einen Trommelschieber 563 geführt, der gesteuert ist, um jedes der Texel UL, UR, LL und LR mit der entsprechenden Verschachtelung A–D desselben zu korrelieren. Die Ausgangssignale des Trommelschiebers werden in Verschachtelungsindexsteuerregister 565–568 geladen, die den jeweiligen Verschachtelungen A–D entsprechen und die jeweils den Miniverzeichniseintrag, falls es welche gibt, identifiziert, der den Blockindex für die Verschachtelung speichert. Wenn lediglich eine eindeutige Lese-Cache-Kennung das Miniverzeichnis verfehlt, tritt das Verschieben der Ausgangssignale von den Registern 550–553 und das Laden der Register 565–568 parallel mit dem Zugriff auf das Hauptverzeichnis 520 auf.
  • Wie es oben angegeben ist, identifizieren die Daten, die in die Register 565–568 geladen sind, welcher Miniverzeichniseintrag, falls es irgendwelche gibt, den Blockindex für die entsprechende Verschachtelung speichert. Diese Daten werden verwendet, um eine Mehrzahl von Verschachtelungsindexmultiplexern zu steuern, die bei 571 identifiziert sind und den entsprechenden Blockindex für jede Verschachtelung aus einem der Miniverzeichnisindexregister 501I–505I und dem Hauptverzeichnisblockindexregister 561 auswählen. Die Mehrzahl von Verschachtelungsindexmultiplexern 571 stellt vier unabhängige Sechs-Zu-Eins-Multiplexer dar. Ein Multiplexer entspricht jeder Verschachtelung und wählt zwischen den fünf Miniverzeichnisindexregistern 501I–505I und dem Hauptverzeichnisblockindexregister 561 aus. Jeder Verschachtelungsindexmultiplexer ist durch eines der Register 565–568 gesteuert, das der gleichen Verschachtelung entspricht und identifiziert, welcher Miniverzeichniseintrag den Blockindex für die Verschachtelung speichert. Wenn diese Daten angeben, dass der Blockindex für eine Verschachtelung nicht in irgendeinem Miniverzeichniseintrag gefunden wird, wählt der entsprechende Multiplexer den Index aus, der von dem Hauptverzeichnisblockindexregister 561 geliefert wird und der einen Blockindex speichert, der von dem Hauptverzeichnis nach einem Fehltreffer zu dem Miniverzeichnis gelesen wird. Der Blockindex für jede der Verschachtelungen A–D wird über Leitungen 580–583 geliefert und wird verwendet, um die Cache-SDRAMs in der oben beschriebenen Weise zu adressieren.
  • Wie es oben erörtert ist, wird, wenn mehr als eine des Satzes von Lese-Cache-Kennungen UL, UR, LL und LR das Miniverzeichnis verfehlt, aber lediglich eine einzige eindeutige Cache-Kennung umfasst, auf das Hauptverzeichnis 520 lediglich einmal zugegriffen, um den Blockindex für diese Lesekennung zu liefern. Dieser Prozess ist ferner durch die Steuerschaltung 559 gesteuert, die die Ausgangssignale der Komparatoren 526–532 verwendet, um zu identifizieren, ob irgendwelche zwei der vier Lesekennungen über einstimmen. Falls zwei oder mehr des Satzes von vier Lesekennungen das Miniverzeichnis verfehlen, aber die gleiche Cache-Kennung umfassen, wird jedes der entsprechenden Register 550–553 durch die Steuerschaltung 559 gesetzt, um anzugeben, dass der Blockindex nicht in irgendeinem Miniverzeichniseintrag enthalten ist. Wenn somit die Daten, die diesen Lesekennungen entsprechen, in die Verschachtelungsindexregister 565–568 geführt werden, wählt jedes das Hauptverzeichnisblockindexsteuerregister 561 aus, um durch den jeweiligen Verschachtelungsindexmultiplexer 571 desselben geführt zu werden.
  • Die Steuerschaltung 559 setzt ferner ein Verzeichnissteuerregister 573, das steuert, welches der Lesekennungsregister 550–553 mit dem Hauptverzeichnis verglichen werden soll. Das Register 573 steuert den Multiplexer 555, um eines der Register 550–553 auszuwählen, um mit dem Hauptverzeichnis zu einer Zeit verglichen zu werden. Falls mehr als eine der Lesekennungen UL, UR, LL, LR das Miniverzeichnis verfehlt, aber eine gemeinsame Kennung gemeinschaftlich verwendet, wird das Steuerregister 573 gesetzt, um anzugeben, dass lediglich eines der Register mit dem Hauptverzeichnis verglichen werden sollte. Auf diese Weise wird auf das Hauptverzeichnis lediglich einmal zugegriffen, wenn der Satz von vier Lesecachekennungen lediglich eine einzige eindeutige Kennung umfasst, die das Miniverzeichnis verfehlt.
  • Falls der Satz von vier Lese-Cache-Kennungen (UL, UR, LL, LR) mehr als eine eindeutige Kennung umfasst, die das Miniverzeichnis verfehlt, ist der oben beschriebene Fluss durch die Cache-Verzeichnispipeline verändert und das Cache-Verzeichnis wird belegt und empfängt keinen neuen Satz von Lesekennungen bei dem nächsten Zyklus. Das Verzeichnis gibt an, dass dasselbe belegt ist, so dass jedes der Register 550–553, das eine Lesekennung umfasst, die das Miniverzeichnis verfehlte, mit dem Hauptverzeichnis verglichen werden kann und nicht mit einer neuen Lesekennung überschrieben wird. Ferner ist der Fluss durch die Verzeichnispipeline verändert, so dass auf das Hauptverzeichnis für jede Lesekennung zugegriffen werden kann, die das Miniverzeichnis verfehlte, und der Blockindex, der diesen entspricht, von dem Hauptverzeichnis in eines der Register 501I–505I oder 561 geladen werden kann. Die Pipeline ist angeordnet, um die Daten in irgendwelchen der Register 550–553 daran zu hindern, durch den Trommelschieber 563 geführt zu werden, bis alle der Blockindizes für den Satz von Lesekennungen (UL, UR, LL, LR) entweder von dem Hauptverzeichnis gelesen wurden oder bereits in dem Miniverzeichnis vorhanden sind. Somit sind die Sätze von Texeln UL, UR, LL und LR mit den entsprechenden Verschachtelungen derselben als eine Gruppe korreliert.
  • Wenn mehr als eine eindeutige Kennung in einem Satz von Lesekennungen das Miniverzeichnis verfehlt, werden die verfehlten Kennungen seriell verarbeitet. Während des ersten Zyklus (d.h. wenn der Satz von Kennungen mit dem Miniverzeichnis verglichen wird) bestimmt die Steuerschaltung 559, welcher Eintrag in dem Miniverzeichnis durch eine erste verfehlte Lesekennung ersetzt werden soll, und das entsprechende Register 550–553 wird mit Daten geladen, die angeben, dass der Blockindex desselben in diesem Miniverzeichniseintrag gespeichert wird. Wenn das Ausgangssignal des Registers 550–553, das die erste verarbeitete Fehltreffer-Kennung speichert, mit dem Hauptverzeichnis 520 während eines zweiten Zyklus verglichen wird, wird das Hauptverzeichnisblockindexregister 561 mit den Daten aktualisiert, die angeben, welches Miniverzeichnisindexregister 501I–505I ersetzt werden soll. Während eines dritten Zyklus wird der entsprechende Blockindex aus dem Register 561 in das Register 501I–505I geladen, das dem Miniverzeichniseintrag entspricht, der für eine Ersetzung ausgewählt ist.
  • Jede der nachfolgend verarbeiteten eindeutigen Kennungen, die das Miniverzeichnis verfehlten, wird in der gleichen Weise gehandhabt, bis die letzte Fehltreffer-Kennung verar beitet wird, die eine zweite Fehltreffer-Kennung sein kann, falls lediglich zwei eindeutige Kennungen das Miniverzeichnis verfehlten, oder eine dritte oder vierte Fehltreffer-Kennung sein kann. Die letzte Fehltreffer-Kennung, die durch das Cache-Verzeichnis verarbeitet wird, wird gehandhabt, als ob dieselbe die einzige eindeutige Kennung in dem Satz von Lesekennungen wäre, die das Miniverzeichnis verfehlt. Wenn ein Verarbeiten der letzten Fehltreffer-Kennung beginnt, deaktiviert das Verzeichnis das Signal, das angibt, dass dasselbe belegt ist, so dass dasselbe einen neuen Satz von Lesekennungen empfangen kann.
  • Für die letzte verarbeitete Fehltreffer-Kennung lädt die Steuerschaltung 559 das entsprechende Register 550–553 desselben mit Daten, die angeben, dass der Blockindex für die Kennung nicht in irgendeinem Miniverzeichniseintrag gespeichert ist. Dies kann während des ersten Zyklus vorgenommen werden, bei dem alle die Lesekennungen mit dem Miniverzeichnis verglichen werden, oder parallel zu dem Verarbeiten der anderen Fehltreffer-Kennungen. Während des Zyklus, bei dem die letzte Fehltreffer-Kennung mit dem Hauptverzeichnis verglichen wird, werden die Daten in den Registern 550–553 durch den Trommelschieber 563 geführt und in die Verschachtelungssteuerregister 565–568 geladen und der Blockindex für die Fehltreffer-Kennung wird aus dem Hauptverzeichnis in das Hauptverzeichnisblockindexregister 561 geladen. Bei der letzten Pipelinestufe des Verzeichnisses schließlich werden die Ausgangssignale der Verschachtelungsindexsteuerregister 565–568 verwendet, um die entsprechenden Verschachtelungsindexmultiplexer 571 derselben zu steuern, so dass der Index für die letzte verarbeitete Fehltreffer-Kennung von dem Hauptverzeichnisblockindexregister 561 geliefert wird und der Blockindex für jede der anderen Lesekennungen in dem Satz von dem entsprechenden Miniverzeichnisindexregister 501I–505I desselben geliefert wird. Es ist klar, dass durch ein Zugreifen auf den Blockindex für die letzte verarbeitete Fehltreffer-Kennung von dem Hauptverzeichnisblockindexregister 561 ein Zyklus dadurch gespart wird, dass nicht darauf gewartet wird, dass der Blockindex für diese Kennung in das Miniverzeichnisindexregister desselben geladen wird.
  • III. TIM-Softwarehintergrundroutine der vorliegenden Erfindung
  • A. Gesamtoperation
  • 26 ist ein Flussdiagramm, das die Operation der TIM-Softwarehintergrundroutine der vorliegenden Erfindung darstellt. In dem oberen Abschnitt des Flussdiagramms sind die Schritte der vorrichtungsunabhängigen Operation der TIM gezeigt und in dem unteren Abschnitt des Flussdiagramms sind die Schritte der vorrichtungsabhängigen Operation der TIM gezeigt. Ferner ist verbunden mit den vorrichtungsabhängigen Routinen der TIM eine Grafikhardwarevorrichtung 660 gezeigt, die texturabgebildete Bilder aufbereitet, die durch einen Benutzer eines Prozesses auf hoher Ebene (oben beschrieben) angefordert werden. Die Grafikhardwarevorrichtung 660 könnte irgendeine Anzahl von Grafikhardwarevorrichtungen sein. Der Einfachheit einer Darstellung halber, wird angenommen, dass die Grafikhardwarevorrichtung einen lokalen Cache-Speicher umfasst, der Blöcke von Texturdaten speichert und für den Unterbrechungen verarbeitet werden. Die Hardwarevorrichtung kann identisch mit der oben beschriebenen oder derselben ähnlich sein.
  • Eine Operation beginnt bei dem vorrichtungsunabhängigen Abschnitt der TIM bei einem Schritt 600. Die Operation beginnt zum ersten Mal, wenn ein erster Befehl, um einen Kontext zu erzeugen, in einem der Hardwaretreiber ansprechend auf einen Benutzerbefehl innerhalb des zugeordneten Prozesses erzeugt wird. An diesem Punkt geht die Routine zu einem Schritt 602 über, bei dem alle Routinen und Datenstrukturen innerhalb der TIM initialisiert werden. Der Initialisierungsschritt 602 umfasst einen Schritt 604, bei dem die TIM sich von dem speziellen Prozess löst, der dieselbe aufrief, so dass dieselbe unabhängig von diesem Prozess als eine Hintergrundroutine laufen kann. Mit anderen Worten ruft der Prozess, innerhalb dessen der Benutzer ein Bild erzeugt hat, das aufbereitet werden soll, die TIM durch die entsprechende Grafik-API und Grafikhardwaretreiber auf und dann löst sich während einer Initialisierung die TIM von diesem aufrufenden Prozess.
  • Die TIM beginnt dann bei einem Schritt 604 eine Operation unabhängig von diesem Prozess. Eine Operation geht zu einem Schritt 606 über, bei dem die TIM sowohl die Datenstrukturen derselben als auch in den vorrichtungsunabhängigen Routinen derselben initialisiert, so dass dieselben später aufgerufen werden können, um von vorrichtungsunabhängigen Routinen wirksam zu sein. Die TIM umfasst eine Anzahl von Datenstrukturen, die Daten speichern, auf die die TIM während eines Betriebs zugreift. Diese Datenstrukturen werden während des Schritts 606 initialisiert. Mit anderen Worten werden die Speicherpositionen in dem Systemsoftwarespeicher, die für derartige Datenstrukturen zugewiesen sind, mit einigen Anfangswerten versehen, wie beispielsweise einer binären Null.
  • Die Datenstrukturen umfassen eine Texturspeicherdatenstruktur, die eine vorrichtungsunabhängige Datenstruktur der TIM ist, die Kopien aller Texturen (außer dieser, die in der gemeinschaftlich verwendeten Speicherdatenstruktur gespeichert sind) beibehält, die für jeden Kontext innerhalb eines speziellen Prozesses verfügbar sind, und ferner die entsprechenden Prioritäten und Softwaretextur-IDs (unten erläutert) dieser Texturen speichert. Wie es unten detaillierter erläutert wird, umfasst die Texturspeicherdatenstruktur die eigene Softwarekopie der TIM von den Texturen oder einen Zeiger zu einer gemeinschaftlich verwendeten Speicherposition für Kopien von Texturen, die mit der Grafik-API und dem Grafikhardwaretreiber gemeinschaftlich verwendet werden.
  • Diese Initialisierung tritt auf, wenn der erste Kontext innerhalb des ersten Prozesses, der mit der TIM verbunden ist, geöffnet wird. Zu dieser Zeit ruft der verbundene Hardwaretreiber die TIM mit einer CRT-ID und einer Vorrichtungsdatei als Parameter des Aufrufs auf. Die CRT-ID ist ein 32-Bit-Wort (Binärzahl), das die spezielle Hardwarevorrichtung darstellt, die mit diesem Prozess verbunden ist und die das Bild dieses Kontexts aufbereitet. Unter Verwendung der CRT-ID initialisiert die TIM die vorrichtungsunabhängigen Routinen, die vorrichtungsabhängige Routinen erfordern (die sich auf diese spezielle Hardwarevorrichtung beziehen), so dass die vorrichtungsunabhängigen Routinen eingerichtet sind, um die vorrichtungsabhängigen Routinen aufzurufen. Insbesondere TIM-Variablen, die Funktionszeiger genannt werden, innerhalb der vorrichtungsunabhängigen Routinen zeigen zu den geeigneten vorrichtungsabhängigen Routinen (die sich auf die spezielle Hardwarevorrichtung beziehen), so dass die vorrichtungsunabhängigen Routinen die korrekten vorrichtungsabhängigen Routinen aufrufen. Diese Vorrichtungsunabhängige-Routine-Initialisierung tritt ebenfalls bei dem Schritt 606 auf.
  • Die Vorrichtungsdatei, die der Hardwaretreiber zu der TIM sendet, wenn der erste Kontext innerhalb des ersten Prozesses geöffnet wird, ist eine Zeichenfolge, die die spezielle Hardwarevorrichtung darstellt, die diesem Hardwaretreiber entspricht. Die spezielle Hardwarevorrichtung wird über die Vorrichtungsdatei zu einem aufeinander folgenden Speicherblock innerhalb des Systemsoftwarespeichers abgebildet. Die Datei kann geöffnet werden, um die Grafikvorrichtung abzubilden. Wenn die Vorrichtungsdatei geöffnet wird, wird dem System mitgeteilt, die Hardwarevorrichtung zu beschreiben. Ansprechend darauf liefert das System eine Hardwarevorrichtungs-ID. Diese Hardwarevorrichtungs-ID wird mit der CRT-ID verglichen, die zu der TIM durch den Hardwaretreiber geliefert wird. Falls die Vorrichtungs-ID mit der CRT-ID identisch ist, dann ist die Hardwarevorrichtung ordnungsgemäß abgebildet. Falls dieselben identisch sind, dann entspricht die Vorrichtungsdatei, die verwendet wird, um diese Hardwarevorrichtung abzubilden, der erwarteten Grafikhardwarevorrichtung, die durch die CRT-ID identifiziert ist. Wenn dieselbe abgebildet ist, entsprechen Register innerhalb der Hardwarevorrichtung bestimmten Adressspeicherpositionen innerhalb des Hostcomputersystems. Wenn somit Daten über die vorrichtungsabhängigen Routinen zu den Adresspositionen innerhalb des Systemspeichers geschrieben werden, werden die entsprechenden Register innerhalb der Hardwarevorrichtung beschrieben. Das Abbilden tritt bei einem Schritt 608 auf.
  • Der Initialisierungsoperationsschritt 602 geht dann zu einem Schritt 610 über, bei dem die geeigneten vorrichtungsabhängigen Routinen, die sich auf die angegebene spezielle Hardwarevorrichtung (durch die CRT-ID dargestellt) beziehen, initialisiert werden. Bei dem Schritt 610 werden ferner die Datenstrukturen initialisiert, die sich auf die vorrichtungsabhängigen Routinen beziehen. Eine vorrichtungsabhängige Datenstruktur umfasst die Cache-Spiegeldatenstruktur, die bei der geeigneten Systemsoftwarespeicherposition derselben eine Aufzeichnung aller Blöcke von Texturdaten, die gegenwärtig in dem lokalen Speicher (wie beispielsweise einem Cache-Speicher) der zu Grunde liegenden Hardwarevorrichtung gespeichert sind, und die entsprechenden Prioritäten dieser Texturen speichert.
  • Die Initialisierungsroutine geht dann zu einem Schritt 612 über, bei dem Texturtransferpuffer erzeugt werden. Wie es unten detaillierter erläutert ist, ist ein Texturtransferpuffer eine Einrichtung, durch die eine Textur von einem Hardwaretreiber zu der TIM geliefert werden kann, so dass die TIM eine Kopie dieser Textur in der eigenen zugewiesenen Texturspeicherdatenstruktur derselben speichern kann. Die Erzeugung der Texturtransferpuffer wird auf herkömmliche Weise vorgenommen, wie es Fachleuten auf dem Gebiet klar ist.
  • Die Initialisierungsroutine geht dann zu einem Schritt 614 über, bei dem der Kommunikationssockel erzeugt wird. Wie es oben erläutert ist, existiert eine virtuelle Schaltungsverbindung für diesen Sockel zwischen jedem Hardwaretreiber und der TIM. Wie es Fachleuten auf dem Gebiet klar ist, ist ein Kommunikationssockel ein Weg, durch den zwei Softwareroutinen kommunizieren können. Die Erzeugung des Sockels umfasst ein Erzeugen von Puffern, die von dem Kommunikationsweg lesen und zu dem Kommunikationsweg schreiben. Bei einem Einrichten einer Kommunikation über einen Sockel, fordert eine Routine an, über eine virtuelle Schaltungsverbindung mit dem Sockel zu kommunizieren. Zuerst wird der Sockel erzeugt und an einen Namen gebunden, dann beginnt der Erzeuger des Sockels nach virtuellen Schaltungsverbindungen mitzuhören. Danach kann eine Kommunikationsvorrichtung anfordern, über eine virtuelle Schaltung eine Verbindung mit dem Sockel herzustellen, und ein Kommunizieren über diese neue Verbindung beginnen.
  • Nachdem der Sockel bei dem Schritt 614 erzeugt ist, ist die Initialisierungsroutine von Schritt 602 abgeschlossen und die TIM befindet sich im Leerlauf als eine unabhängige Hintergrundroutine, die auf dem Prozessor läuft, bei einem Schritt 616. Während die TIM bei dem Schritt 616 im Leerlauf ist, wartet dieselbe darauf, dass eines von drei Ereignissen auftritt, bevor dieselbe aus dem Leerlaufzustand derselben erwacht. Diese Ereignisse umfassen eine Hardwareunterbrechung, eine virtuelle Schaltungsverbindung oder eine Sockelkommunikation. Die Routine geht von dem Leerlaufzustand 616 zu Schritten 618, 620 und 622 über und kehrt dann in einer Schleife zu dem Leerlaufzustand bei dem Schritt 616 zurück.
  • Bei dem Schritt 618 bestimmt die TIM, ob eine Hardwareunterbrechung aufgetreten ist. Wie es oben in Verbindung mit dem Beispiel der speziellen Hardwarevorrichtung beschrieben ist, tritt eine Unterbrechung auf, wenn ein Cache-Fehltreffer während eines Aufbereitens eines texturierten abgebildeten Vielecks innerhalb der Hardwarevorrichtung aufgetreten ist. Wenn der Cache-Fehltreffer auftritt, wird ein Unterbrechungssignal von der Hardwarevorrichtung zu dem Hostcomputer geliefert. Falls eine Unterbrechung aufgetreten ist, geht die Routine zu einem Schritt 624 über, bei dem die Unterbrechung mit einer vorrichtungsunabhängigen Routine verarbeitet wird. Diese vorrichtungsunabhängige Routine der TIM zum Verarbeiten der Unterbrechung ist unten detailliert mit Bezug auf das Flussdiagramm von 28 beschrieben.
  • Zusätzlich zu der vorrichtungsunabhängigen Routine zum Verarbeiten der Unterbrechung werden zwei vorrichtungsabhängige Routinen zum Verarbeiten der Unterbrechung implementiert. Diese vorrichtungsabhängigen Routinen umfassen die vorrichtungsabhängigen Routinen 642 zum Bestimmen des Texturblocks, der durch die Hardwarevorrichtung benötigt wird, und Auswählen des Blocks, der in dem Cache-Speicher zu ersetzen ist, und die vorrichtungsabhängige Routine 648 zum Schreiben des benötigten Blocks von Texturdaten zu der ausgewählten Position innerhalb des lokalen Cache-Speichers der Hardwarevorrichtung 660.
  • Falls keine Hardwareunterbrechung aufgetreten ist, wie es bei dem Schritt 618 bestimmt wird, oder nachdem die Unterbrechung durch die vorrichtungsunabhängige Routine des Schritts 624 verarbeitet wurde, geht die vorrichtungsunabhängige Routine zu dem Schritt 620 über, bei dem die TIM bestimmt, ob eine neue Sockelverbindungsanforderung empfangen wurde. Falls eine Anforderung nach einer neuen Sockelverbindung empfangen wurde, was auftritt, wenn der Hardwaretreiber wünscht, einen neuen Sockel zum Kommunizieren von Informationen zu der TIM zu öffnen, dann geht die Routine zu einem Schritt 626 über, bei dem der neue Sockel verbunden wird.
  • Falls keine Anforderung nach einer neuen Sockelverbindung empfangen wurde, nachdem die Bestimmung während des Schritts 620 aufgetreten ist, oder falls ein neuer Sockel bei dem Schritt 626 verbunden wurde, dann geht die Routine zu dem Schritt 622 über, bei dem die TIM bestimmt, ob eine Sockelkommunikation auftritt. Falls nicht, dann geht die Routine zurück zu dem Schritt 616 über, bei dem die TIM sich im Leerlauf befindet. Falls eine Sockelkommunikation auftritt, dann geht die Routine zu einem Schritt 628 über, bei dem die TIM die Sockelkommunikation verarbeitet. Mit anderen Worten hört die TIM an dem Sockel und empfängt die Informationen, die über den Sockel kommuniziert werden. Diese Informationen könnten ein Datenpaket oder einen Datenstrom umfassen.
  • Von dem Schritt 628 geht die Routine zu einem Schritt 630 über, bei dem die TIM bestimmt, ob der Prozess, von dem die Kommunikation stammte, immer noch existiert. Der Prozess kann durch den Benutzer nach einem Erzeugen bestimmter Kontexte innerhalb dieses Prozesses beendet worden sein. Falls der Prozess durch den Benutzer beendet wurde, dann geht die Routine zu einem Schritt 632 über, bei dem die Texturen, die dem beendeten Prozess zugeordnet sind, als verwaiste Texturen bekannt, verarbeitet werden. Bei diesem Schritt löscht die vorrichtungsunabhängige Routine Kopien der TIM von den verwaisten Texturen aus der Texturkopiedatenstruktur der TIM. Zusätzlich hört bei dem Schritt 632 die TIM auf, an dem Sockel zu hören, über den die Kommunikation gesendet wurde. Die vorrichtungsunabhängige Routine des Schritts 632 ruft ferner die vorrichtungsabhängige Routine 654 auf, wenn ein Prozess beendet wurde. Wie es unten detaillierter erläutert ist, hebt die vorrichtungsabhängige Routine 654 die Blöcke auf, die gegenwärtig in dem Cache-Speicher der Hardwarevorrichtung gespeichert sind und die Texturdaten von der beendeten Textur umfassen. Die vorrichtungsunabhängige Routine geht dann zurück zu dem Schritt 634 (oben beschrieben) über.
  • Aus dieser Erörterung und dem Flussdiagramm von 26 ist klar, dass die vorrichtungsabhängigen Routinen initiali siert werden und aufgerufen werden, um durch bestimmte Schritte oder Routinen des gesamten vorrichtungsunabhängigen Abschnitts der TIM wirksam zu sein. Während des Schritts 608 der vorrichtungsunabhängigen Routine beispielsweise, während dem vorrichtungsabhängige Routinen initialisiert werden, wird der Initialisierung-Vorrichtungsunabhängige-Routine-Schritt 636 aufgerufen. Diese vorrichtungsabhängige Routine umfasst die vorrichtungsabhängige Routine eines Schritts 638, während dem die Texelcache-Datenstruktur initialisiert wird. Wie es oben erläutert ist, zeichnet diese Struktur auf, welche Blöcke von Texturdaten gegenwärtig in dem Cache-Speicher der Hardwarevorrichtung 660 gespeichert sind. Die vorrichtungsabhängige Routine 636 umfasst ferner die vorrichtungsabhängige Routine eines Schritts 640, während dem irgendwelche existierenden Unterbrechungen der Hardwarevorrichtung bis zu einem Abschluss verarbeitet werden.
  • Die vorrichtungsabhängigen Routinen der TIM weisen gemeinschaftlich verwendete Bibliotheken auf, die Daten aus mehreren Hardwarevorrichtungen speichern. Falls somit eine zu Grunde liegende Grafikhardwarevorrichtung zu dem System hinzugefügt wird, werden vorrichtungsabhängige Daten für diese Hardwarevorrichtung in den gemeinschaftlich verwendeten Bibliotheken gespeichert.
  • Die vorrichtungsunabhängige Routine des Schritts 624 zum Verarbeiten der Unterbrechung ruft die vorrichtungsabhängige Routine eines Schritts 642 zum Verarbeiten der Unterbrechung auf. Diese vorrichtungsabhängige Routine zum Verarbeiten der Unterbrechung des Schritts 642 umfasst die Routine eines Schritts 644 zum Bestimmen des Texturblocks, der durch die Hardwarevorrichtung 660 benötigt wird, um das aktuelle Grundelement aufzubereiten. Diese Routine ist oben detailliert mit Bezug auf die Hardwarevorrichtung beschrieben. Wie es oben erläutert ist, umfasst die Routine ein Lesen der Leitungskennung des verfehlten Blocks und ein Decodieren derselben, um den speziellen erforderlichen Block von Texturdaten zu bestimmen. Die vorrichtungsabhängige Routine des Schritts 642 zum Verarbeiten der Unterbrechung umfasst ferner die vorrichtungsabhängige Routine eines Schritts 646 zum Auswählen des Texturblocks, der innerhalb des lokalen Cache-Speichers der Hardwarevorrichtung 660 zu ersetzen ist. Die Routine des Schritts 646 ist unten mit Bezug auf 29 beschrieben.
  • Die vorrichtungsunabhängige Routine des Schritts 624 zum Verarbeiten der Unterbrechung ruft ferner die vorrichtungsabhängige Routine eines Schritts 648 zum Schreiben des Texturblocks zu dem Cache-Speicher der Hardwarevorrichtung 660 bei der ausgewählten Blockposition auf. Wie es oben detailliert erläutert ist, wird der Block von Texturdaten zu dem Cache-Speicher über einen Bus geschrieben, der die 3-D-Aufbereitungspipeline des Hardwarespeichers meidet.
  • Wenn der vorrichtungsunabhängige Abschnitt der TIM eine Sockelkommunikation bei dem Schritt 628 verarbeitet, ruft diese vorrichtungsunabhängige Routine irgendeine von vorrichtungsabhängigen Routinen 650, 652 und 654 auf. Die vorrichtungsabhängige Routine 650 wird aufgerufen, wenn eine ANHALTEN-Bedingung aufgetreten ist. Wie es oben detaillierter erläutert ist, tritt eine ANHALTEN-Bedingung auf, wenn ein Block, der eine erste Textur umfasst, in den Cache heruntergeladen wird und dann die TIM eine zweite Textur in diesen gleichen Block packt. An diesem Punkt wird die vorrichtungsabhängige Routine 650 eingeleitet und die Operation der Hardwarevorrichtung wird angehalten und der modifizierte Texturblock wird zu der vorexistierenden Position des vorhergehenden Blocks innerhalb des Cache-Speichers geschrieben.
  • Die vorrichtungsabhängige Routine des Schritts 652 wird aufgerufen, wenn ein Block von Texturdaten zu dem Cache-Speicher der Hardwarevorrichtung 660 heruntergeladen wurde. Die vorrichtungsabhängige Routine des Schritts 652 aktualisiert die Priorität des Texturblocks in der Cache- Datenstruktur, die heruntergeladen wurde. Die Texturprioritäten sind unten detaillierter beschrieben.
  • 27 ist teilweise ein Funktionsblockdiagramm, teilweise ein Flussdiagramm, das eine Operation eines Hardwaretreibers und einer TIM während einer Kommunikation zwischen den zweien darstellt. Die Operationsbeziehung zwischen der TIM und mehreren Hardwaretreibern ist in dem Blockdiagramm von 3 gezeigt. Jeder der Hardwaretreiber würde mit der TIM gemäß der Routine von 27 kommunizieren. Die Routine von 27 ist durch den Hardwaretreiber und die TIM implementiert, um die drei folgenden Funktionen auszuführen: (1) Kommunizieren von Prioritäten von Texturen von dem Hardwaretreiber zu der TIM; (2) die TIM jeder neuen Textur einer Hardware-ID zuweisen lassen oder verifizieren lassen, dass eine vorexistierende Hardwaretextur-ID für diese Textur korrekt ist; und (3) die TIM Texturen in den eigenen Systemspeicherbereich derselben kopieren lassen, die dieselbe noch nicht aufweist. Das Flussdiagramm, das die Operation des Grafikhardwaretreibers darstellt, ist auf der linken Seite von 27 gezeigt, während Funktionen der TIM ansprechend auf bestimmte der Operationen des Hardwaretreibers auf der rechten Seite von 27 gezeigt sind.
  • Wie es oben erörtert ist, wird, wenn der Benutzer einen Kontext innerhalb eines Prozesses auf hoher Ebene erzeugt, der eine Texturabbildung erfordert, ein Befehl von dem Prozess zu der Grafik-API und dann zu dem Hardwaretreiber sowie eine Kopie der Textur, die in dem Systemsoftwarespeicher der Grafik-API/des Hardwaretreibers für diesen speziellen Zweck gespeichert ist, geleitet. Zusätzlich wird das Bild dieses Kontexts in Bildkomponenten wie Vielecke zerlegt, die ebenfalls zu dem Grafikhardwaretreiber geliefert werden. Wenn diese Informationen zu dem Grafikhardwaretreiber geliefert werden, beginnt die Routine von 27 bei einem Schritt 700, bei dem der Grafikhardwaretreiber bestimmt, ob die zu Grunde liegende Grafikhardwarevorrichtung, mit der der Prozess verbunden ist, die ausgewählte Textur handhaben kann. Der Grafikhardwaretreiber nimmt diese Bestimmung durch ein Untersuchen von Attributen wie der Größe der Textur und ein Bestimmen vor, ob derartige Attribute durch die zu Grunde liegende Grafikhardwarevorrichtung unterstützt werden können. Die zu Grunde liegende Grafikhardwarevorrichtung kann physische Begrenzungen wie Registergrößen, eine begrenzte lokale Texturspeicherkapazität, Puffergrößen etc. aufweisen, die durch Attribute der Textur oder der Einrichtung überschritten werden können, durch die dieselbe auf das Vieleck angewendet wird. Wie es oben beschrieben ist, weist der Grafikhardwaretreiber eine Kenntnis der physischen Begrenzungen der zu Grunde liegenden Grafikhardwarevorrichtung auf und nimmt mit dieser Kenntnis die Bestimmung des Schritts 700 vor. Wie es Fachleuten auf dem Gebiet klar ist, ist zusätzlich die zu Grunde liegende Grafikhardwarevorrichtung eventuell nicht in der Lage, bestimmte Funktionen durchzuführen, die durch den Benutzer angefordert werden. Falls bei dem Schritt 700 der Hardwaretreiber bestimmt, dass die zu Grunde liegende Hardwarevorrichtung die angeforderte Texturabbildungsfunktion physisch nicht handhaben kann, dann geht die Routine zu einem Schritt 705 über, bei dem die angeforderte Texturabbildungsfunktion durch eine Software durchgeführt wird, exklusive der Hardwarevorrichtung. Eine Softwaretexturabbildung (Texturabbildung ohne Verwendung einer Hardwarevorrichtung) sollte Fachleuten auf dem Gebiet klar sein und wird deshalb hierin nicht beschrieben.
  • Falls während des Schritts 700 der Grafikhardwaretreiber alternativ bestimmt, dass die zu Grunde liegende Hardwarevorrichtung die angeforderte Texturabbildungsfunktion handhaben kann, dann geht die Routine zu einem Schritt 720 über, bei dem der Grafikhardwaretreiber jede neue Texturpriorität zu der TIM kommuniziert. Eine Texturprioritätsliste umfasst die Softwaretextur-IDs für die gegenwärtig verfügbaren Texturen für den entsprechenden Prozess in der Reihenfolge der Priorität. Diese Liste kann so klein wie eine Textur für die neu erzeugte Textur sein. Diese Priori tätsliste ist in dem Softwaresystemspeicher in einem zugewiesenen Bereich gespeichert. Die Prioritäten können sowohl benutzerdefinierte Prioritäten als auch interne Prioritäten umfassen. Benutzerdefinierte Prioritäten, die gegenüber internen Prioritäten Vorrang haben, wie es unten mit Bezug auf 31 beschrieben ist, sind Priorisierungen, die auf einer benutzergelieferten Kenntnis einer vorausgesagten Verwendung von Texturen basieren. Intern gibt das System den jüngst verwendeten Texturen eine höchste Priorität. Einer neu erzeugten oder gegenwärtig aktiven Textur wird die höchste Priorität sowohl über den benutzerdefinierten Prioritäten als auch den jüngst verwendeten internen Prioritäten gegeben, wie es unten erläutert ist.
  • Bei dem Schritt 720 wird jede neue Texturpriorität von dem Grafikhardwaretreiber zu der TIM kommuniziert. Jedes Mal, wenn eine neue Textur zu der internen Prioritätsliste hinzugefügt wird, verändern sich alle Prioritäten der Texturen innerhalb dieser Liste. Somit werden die neuen Prioritäten von dem Hardwaretreiber zu der TIM kommuniziert. Die Prioritäten werden über einen Sockel 728 in der Form eines Informationspakets kommuniziert, wobei jedes Paket die Prozess-ID des Prozesses, der diesem Grafikhardwaretreiber entspricht, die Softwaretextur-IDs jeder Textur in der Prioritätsliste und die entsprechenden Prioritäten dieser Texturen umfasst. Wie es oben beschrieben ist, sind sowohl die Prozess-ID als auch die Softwaretextur-ID 32-Bit-Digitalwörter. Die Priorität wird als eine Ganzzahl kommuniziert. Die TIM hat vorhergehend die Texturen aufgezeichnet, die bereits zu derselben für diesen speziellen Prozess gesendet wurden. Deshalb kann die TIM bereits einige der Texturen in dieser Prioritätsliste gespeichert haben. Die TIM modifiziert dann die Prioritäten der Texturen, die dieselbe bereits für diesen Prozess aufweist.
  • Falls die TIM keine der Texturen, die durch die IDs dargestellt sind, die in dem Paket gesendet werden, in dem eigenen zugewiesenen Bereich eines Systemspeichers dersel ben gespeichert hat, dann ignoriert die TIM diese Textur-ID. Die Textur, die durch diese Textur-ID dargestellt ist, wird später von dem Hardwaretreiber geliefert, oder dieselbe wird nicht benötigt. In dem speziellen Fall, wenn der Benutzer eine Verwendung einer speziellen Textur beendet, wird dann die Priorität für diese Textur zu der TIM als eine Priorität 0 kommuniziert und die TIM entfernt diese Textur von der eigenen zugewiesenen Systemsoftwarespeicherposition derselben oder von der gemeinschaftlich verwendeten Speicherposition (unten beschrieben) und die TIM ruft eine vorrichtungsabhängige Routine auf, um diese Textur aus dem lokalen Texturspeicher der Hardwarevorrichtung zu entfernen. Diese vorrichtungsabhängige Routine ist die Routine 654 von 26. Für die spezielle, oben beschriebene Hardwarevorrichtung beispielsweise werden die Datenblöcke, die in dem lokalen Cache-Speicher gespeichert sind, einschließlich dieser beendeten Textur, durch diese vorrichtungsabhängige Routine entfernt. Die Operationen der TIM sind bei einem Schritt 725 gezeigt.
  • Die Routine geht dann zu einem Schritt 730 über, bei dem der Grafikhardwaretreiber bestimmt, ob eine Hardwaretextur-ID für die neu angeforderte Textur existiert. Eine Datenstruktur, die in einem zugewiesenen Speicherbereich des Systemsoftwarespeichers gespeichert ist, speichert die Softwaretextur-IDs und entsprechende Hardwaretextur-IDs (wenn zugewiesen) für jeden Prozess. Die Hardwaretextur-IDs und Untertextur-IDs sind (hierin beschrieben) IDs, die durch die zu Grunde liegende Hardwarevorrichtung erkennbar sind. Bei dem oben beschriebenen Beispiel ist die Hardwaretextur-ID ein 8-Bit-Wort, das Texturen voneinander unterscheidet. Der Hardwaretreiber bestimmt, ob eine Hardwaretextur-ID zugewiesen wurde, durch ein Nachsehen innerhalb der Datenstruktur zu der adressierten Position der Softwaretextur-ID und ein Sehen, ob eine entsprechende Hardwaretextur-ID aufgelistet ist.
  • Falls keine Hardwaretextur-ID zugewiesen wurde, dann geht die Routine zu einem Schritt 740 über, bei dem der Hardwaretreiber eine Zuweisung einer Hardwaretextur-ID von der TIM anfordert. Diese Anforderung wird zu der TIM über den Sockel 728 in einem Informationspaket gesendet. Das Paket umfasst die Prozess-ID für den entsprechenden Prozess, die Softwaretextur-ID und einen Wert für die Hardwaretextur-ID, der der TIM angibt, dass noch keine Hardwaretextur-ID zugewiesen wurde, sowie die Größe der Textur hinsichtlich der S,T-Koordinatenwerte der Basisabbildung. Bei einem Schritt 745 weist dann die TIM dieser Textur eine Hardwaretextur-ID zu und gibt diese Hardwaretextur-ID über den Sockel 728 zu dem Grafikhardwaretreiber zurück.
  • Bei einem Zuweisen der Hardwaretextur-ID prüft die TIM die Größe der Basistexturabbildung durch ein Schauen auf die S,T-Koordinatenwerte, die durch den Grafikhardwaretreiber geliefert werden. Falls die Texturbasisabbildung weniger als 128 × 128 Texel groß ist, dann bestimmt die TIM, ob es einen leeren Raum in irgendeinem der Blöcke von Texturdaten für den entsprechenden Prozess gibt, die in dem eigenen zugewiesenen Systemspeicherbereich der TIM gespeichert sind, der durch die neue Textur eingenommen werden könnte. Falls ein leerer Raum existiert, dann ist die Hardwaretextur-ID, die dieser neuen Textur zugewiesen wird, die gleiche wie dieselbe der Textur, die in dem Block gespeichert ist, der den leeren Raum aufweist, und der neuen Textur wird eine gesonderte Untertextur-ID zugewiesen. Dies ist oben bei der Beschreibung der Hardwarevorrichtung und unten mit Bezug auf 32 erläutert. An dem Punkt, an dem die neue Textur in den gleichen Block mit einer vorhergehend existierenden Textur innerhalb der zweckgebundenen Texturspeicherdatenstruktur der TIM gepackt wird, tritt ein ANHALTEN auf und die entsprechende vorrichtungsabhängige Routine zum Herunterladen dieses Blocks oder von Blöcken, um die gegenwärtig in dem Cache gespeicherten Blöcke zu überschreiben, tritt auf. Das Auftreten einer ANHALTEN-Situation ist oben detailliert mit Bezug auf die Hardware vorrichtung erörtert. Die vorrichtungsabhängige Routine zum Verarbeiten eines ANHALTEN ist in 26 bei dem Schritt 650 gezeigt.
  • Dieses Schema zum Zuweisen von Textur-IDs und Untertextur-IDs basiert auf dem speziellen Texturzuweisungsschema, das oben mit Bezug auf die exemplarische Hardwarevorrichtung beschrieben ist. Es ist jedoch ersichtlich, dass dieses spezielle Schema lediglich exemplarisch sein soll und nicht begrenzend ist. Wie es oben erläutert ist, ist dies so, weil die TIM der vorliegenden Erfindung bei unterschiedlichen Hardwarevorrichtungen wirksam sein kann, die unterschiedliche Texturspeicherzuweisungsanforderungen als diese des oben beschriebenen Ausführungsbeispiels aufweisen.
  • Falls die neue Textur größer als 128 × 128 Texel ist, dann weist die TIM der Textur eine neue Hardwaretextur-ID zu. Zu dieser Zeit öffnet bei dem Schritt 745 die TIM auch einen Raum innerhalb des eigenen Systemspeicherbereichs derselben zum Speichern einer Kopie dieser neuen Textur. Die neu zugewiesene Hardwaretextur-ID wird zu dem Grafikhardwaretreiber über den Sockel 728 über ein Rückgabepaket zurückgegeben. Der Hardwaretreiber speichert dann die neu zugewiesene Hardwaretextur-ID bei der geeigneten Position in der Textur-ID-Datenstrukturliste.
  • Die Routine geht von dem Schritt 740 zu einem Schritt 750 über, bei dem der Grafikhardwaretreiber bestimmt, ob eine Hardwaretextur-ID zugewiesen wurde. Weil die Hardwaretextur-ID ein 8-Bit-Wort ist, sind lediglich 256 gesonderte Hardwaretextur-IDs verfügbar. Es ist deshalb möglich, dass alle 256 gesonderten Hardwaretextur-IDs zugewiesen wurden. Falls dem so ist, bestimmt dann die TIM, ob irgendwelche der 256 Texturen eine Priorität aufweisen, die niedriger als eine andere ist. Falls dem so ist, dann kann die TIM eine der vorhergehend zugewiesenen Hardwaretextur-IDs für eine Textur mit niedrigerer Priorität der neuen Textur neu zuweisen. In dem Fall, dass alle 256 Texturen Texturen mit der höchsten Priorität sind, dann wird eine neue Hardwaretextur-ID nicht zugewiesen und die Routine geht zu einem Schritt 755 über, bei dem die Texturabbildung in einer Software fertig ist.
  • Falls eine Hardwaretextur-ID zugewiesen wurde, dann geht die Routine von dem Schritt 750 zu einem Schritt 760 über, bei dem der Grafikhardwaretreiber bestimmt, ob die Textur zu der TIM kopiert werden muss. Mit anderen Worten bestimmt der Grafikhardwaretreiber, ob die TIM bereits eine Kopie der Textur in der zugewiesenen Systemsoftwaretexturdatenstruktur aufweist oder ob diese Textur, oder ein Abschnitt derselben, bei der gemeinschaftlich verwendeten Speicherposition gespeichert ist. Falls die TIM nicht bereits eine Kopie dieser Textur gespeichert hat, wird dann diese Textur bei einem Schritt 750 durch den Grafikhardwaretreiber zu der TIM kopiert. Es existieren drei gesonderte Verfahren zum Kopieren der Textur zu der TIM und sind hierin mit Bezug auf 30 detailliert beschrieben. Details der Größe und andere Parameter der Textur werden zu der TIM in einem Paket über den Sockel 728 gesendet, wie es unten mit Bezug auf 30 detailliert beschrieben ist. Die TIM kopiert dann bei einem Schritt 775 die Textur und bei Texturen und Abschnitten derselben, die in der eigenen Datenstruktur der TIM gespeichert werden sollen, werden die Texturen in Blöcke gepackt, die durch die Hardwarevorrichtung erkennbar sind. Die Blöcke werden dann in der zugewiesenen Datenstruktur der TIM gespeichert. Wie es unten detaillierter beschrieben ist, werden große Texturen und Abschnitte großer Texturen in dem gemeinschaftlich verwendeten Speicherbereich gespeichert, ohne zuerst in Blöcke gepackt zu werden, die durch die Hardware erkennbar sind, und die TIM speichert einen Zeiger zu der Textur in dem gemeinschaftlich verwendeten Speicherbereich in der eigenen Speicherdatenstruktur der TIM. Nach dem Schritt 770 endet die Routine.
  • Falls bei dem Schritt 730 bestimmt wird, dass eine Hardwaretextur-ID bereits der angeforderten Textur zugewiesen wurde, dann geht die Routine zu einem Schritt 790 über, bei dem der Grafikhardwaretreiber verifiziert, dass die vorhergehend zugewiesene Hardwaretextur-ID sich nicht verändert hat. Der Grafikhardwaretreiber führt diese Verifizierung durch ein Kommunizieren sowohl der Softwaretextur-ID als auch der vorhergehend zugewiesenen Hardwaretextur-ID über den Sockel zu der TIM durch. Die TIM betrachtet ansprechend darauf bei einem Schritt 795 sowohl die Softwaretextur-ID als auch die entsprechende Hardwaretextur-ID, die durch den Hardwaretreiber gesendet werden, und vergleicht diese mit der gespeicherten ID-Liste der TIM. Falls sich die Hardwaretextur-ID verändert hat, was auftreten kann, falls die TIM die vorhergehend zugewiesene Hardwaretextur-ID einer anderen Textur zugewiesen hat, dann weist die TIM eine neue Hardwaretextur-ID zu, falls verfügbar. Die TIM verifiziert deshalb entweder, dass sich die Hardware-ID nicht verändert hat, oder, falls eine neue ID zugewiesen wird, kommuniziert dann die neue ID zu dem Hardwaretreiber über den Sockel 728.
  • Von dem Schritt 790 geht die Routine zu dem Schritt 750 über, bei dem bestimmt wird, ob eine ID zugewiesen wurde. Dann fährt die Routine fort, wie es oben umrissen ist.
  • Falls bei dem Schritt 760 die Textur nicht kopiert werden muss, weil die TIM bereits eine gespeicherte Kopie dieser Textur aufweist, dann ist die Routine abgeschlossen.
  • 28 ist ein Flussdiagramm, das die Schritte der vorrichtungsunabhängigen Routine zum Verarbeiten einer Unterbrechung zeigt. Diese Routine tritt bei dem Schritt 624 von 26 auf. Wenn eine Unterbrechung in der Hardwarevorrichtung auftritt, nachdem ein Cache-Fehltreffer aufgetreten ist, wird ein Unterbrechungssignal von der Hardware zu dem Prozessor des Hostcomputers geliefert, der ein Unterbrechungs-Flag setzt. Dieses Flag wird durch den Prozes sor gelesen und die TIM wird bei dem Schritt 618 in 26 geweckt.
  • Die vorrichtungsunabhängige Routine zum Verarbeiten einer Unterbrechung beginnt dann bei einem Schritt 800 und geht zu einem Schritt 802 über, bei dem eine Softwarevariable, die als NICHT-ANGEHALTEN bezeichnet wird, gleich falsch gesetzt wird. Die Routine geht dann zu einem Schritt 804 über, bei dem die TIM bestimmt, ob die Variable NICHT-ANGEHALTEN wahr ist. Weil die Routine gerade begonnen hat und die Variable NICHT-ANGEHALTEN bei dem Schritt 802 gleich falsch gesetzt wurde, lautet die Antwort der Bestimmung des Schritts 804 Nein und die Routine geht zu einem Schritt 806 über. Wenn die Variable NICHT-ANGEHALTEN falsch ist, wurde die Unterbrechung noch nicht verarbeitet.
  • Bei dem Schritt 806 wird eine Variable, die ABBILDUNGSNUMMER genannt wird, gleich –1 gesetzt. Die Variable ABBILDUNGSNUMMER stellt die tatsächliche Abbildungsnummer dar. Wenn somit die Variable ABBILDUNGSNUMMER nicht gleich –1 ist, dann ist dieser Unterbrechung eine gültige Textur zugeordnet.
  • Die Routine geht dann zu einem Schritt 808 über, bei dem die vorrichtungsabhängige Routine zum Verarbeiten der Unterbrechung aufgerufen wird, um zu laufen. Diese vorrichtungsabhängige Routine ist die Routine 644 von 26. Diese Routine umfasst ein Anhalten der Hardwarevorrichtung und ein Bestimmen des Texturblocks, der durch die Hardwarevorrichtung benötigt wird, um dieses spezielle Vieleck aufzubereiten. Bei einem Bestimmen des benötigten Blocks, wird die Leitungskennung gelesen und werden aus der Leitungskennung die Textur-ID, ABBILDUNGSNUMMER und S,T-MSB-Koordinaten bestimmt. Dieses Schema ist oben bei der Beschreibung der Hardwarevorrichtung detailliert erläutert. Die vorrichtungsabhängige Routine setzt dann die Variable ABBILDUNGSNUMMER zu der geeigneten MIP-Abbildungsnummer des benötigten Blocks rück.
  • Die Routine geht dann zu einem Schritt 810 über, bei dem bestimmt wird, ob die Variable ABBILDUNGSNUMMER nicht gleich –1 ist. Weil die vorrichtungsabhängige Unterbrechungsroutine des Schritts 808 die Variable ABBILDUNGSNUMMER zu der Abbildungsnummer des Blocks setzt, der durch die Hardwarevorrichtung benötigt wird, lautet die Antwort auf die Bestimmung des Schritts 810 Ja.
  • Die Routine geht dann zu einem Schritt 812 über, bei dem die TIM bestimmt, ob die Textur, die durch die Hardwaretextur-ID dargestellt ist, die durch die vorrichtungsabhängige Routine des Schritts 808 definiert wird, für den vorliegenden Prozess existiert. Die TIM bestimmt, ob die Textur existiert, durch ein Durchsuchen der Datenstruktur nach der Textur, die dieser Textur-ID zugeordnet ist. Falls diese Textur nicht existiert, dann geht die Routine zu einem Schritt 814 über. Bei dem Schritt 814 ruft die vorrichtungsunabhängige Routine die vorrichtungsabhängige Herunterladeroutine auf, die bei dem Schritt 648 von 26 gezeigt ist. Der vorrichtungsabhängigen Routine wird mitgeteilt, die Unterbrechung zu löschen, und dieselbe setzt ferner die Variable NICHT-ANGEHALTEN auf wahr. Die Routine geht dann zu dem Schritt 804 über, bei dem die TIM bestimmt, ob die Variable NICHT-ANGEHALTEN wahr ist. Weil die Variable NICHT-ANGEHALTEN gerade gleich wahr gesetzt wurde, lautet die Antwort auf diese Bestimmung Ja und die Routine ist abgeschlossen. In dieser Situation kann die Textur beendet worden sein oder der Prozess, innerhalb dessen die Textur erzeugt wurde, kann durch den Benutzer beendet worden sein.
  • Falls alternativ die Textur existiert, die durch die Textur-ID dargestellt ist, die durch die vorrichtungsabhängige Unterbrechungsroutine des Schritts 808 gefunden wird, dann geht die Routine zu einem Schritt 816 über. Bei dem Schritt 816 bestimmt die TIM, ob die benötigte Textur bei der gemeinschaftlich verwendeten Speicherposition gespeichert ist. Falls die Textur nicht bei der gemeinschaftlich ver wendeten Speicherposition gespeichert ist, dann geht die Routine zu einem Schritt 818 über. Bei dem Schritt 818 wird der Blockzeiger der Datenstruktur des eigenen zugewiesenen Systemspeichers der TIM zu der Anfangsadresse einer speziellen MIP-Abbildung dieser Textur vorgeschoben, die durch die ABBILDUNGSNUMMER-Variable dargestellt ist. Der Blockzeiger der Datenstruktur kann zu irgendeinem Block zeigen, der innerhalb der eigenen Systemspeicherdatenstruktur der TIM gespeichert ist. Wie es oben mit Bezug auf die Hardwarevorrichtung detailliert erläutert ist, nimmt bei Abbildungen, die eine Abbildungsnummer größer Acht aufweisen, wobei diese Abbildungen größer als 256 × 256 Texel sind, jede Abbildung zumindest einen Datenblock ein. Beispielsweise bei einer Abbildung, die eine Abbildungsnummer Neun aufweist und 512 × 512 Texel groß ist, wären vier Datenblöcke (wobei jeder Block 256 × 256 Texel groß ist) erforderlich, um die Daten dieser Abbildung zu speichern. Auf ähnliche Weise wären sechzehn Blöcke erforderlich, um alle der Daten für eine Abbildung zu speichern, die eine Abbildungsnummer Zehn aufweist und 1024 × 1024 Texel groß ist, usw. Für Abbildungen jedoch, die Abbildungsnummern Acht und weniger aufweisen, sind alle der Abbildungen in zwei Datenblöcke gepackt, wobei einer dieser zwei Blöcke in einer Bank des Cache-Speichers gespeichert ist und der andere dieser zwei Blöcke in der anderen Bank des Cache-Speichers gespeichert ist. Dieses Speicherzuweisungsschema ist oben mit Bezug auf 14 – 16 detailliert beschrieben.
  • Die Routine geht dann zu einem Schritt 820 über, bei dem die TIM bestimmt, ob die Abbildungsnummer größer als Acht ist. Die TIM bestimmt, ob die Abbildungsnummer größer als Acht ist, durch ein Schauen auf die Variable ABBILDUNGSNUMMER (die gleich der Abbildungsnummer ist). Falls die Abbildungsnummer größer als Acht ist, dann geht die Routine zu einem Schritt 822 über, bei dem der Blockzeiger der Speicherdatenstruktur zu dem Anfang des speziellen Blocks vorgeschoben wird, der den Datenabschnitt der speziellen MIP-Abbildung speichert, der durch die Hardwarevorrichtung benötigt wird, unter Verwendung der S,T-MSB-Koordinaten. Wie es oben mit Bezug auf 14 – 16 detailliert erörtert ist, speichern, falls die spezielle benötigte MIP-Abbildung eine Abbildungsnummer Neun ist, dann vier unterschiedliche Blöcke die Daten von dieser Abbildung. Somit wären eine S-MSB-Koordinate und eine T-MSB-Koordinate erforderlich, um zu bestimmen, welche der vier Blöcke den Texturdatenabschnitt der Abbildung Neun speichern, der durch die Hardwarevorrichtung benötigt wird. Folglich wird unter Verwendung einer S-MSB-Koordinate und einer T-MSB-Koordinate der Blockzeiger zu dem geeigneten der vier Blöcke der Abbildung vorgeschoben.
  • Falls die benötigte MIP-Abbildung eine Abbildungsnummer Zehn aufweist, existieren dann sechzehn unterschiedliche Blöcke zum Speichern der Daten der Abbildung. Somit sind zwei MSB-S-Koordinaten und zwei MSB-T-Koordinaten zum Decodieren erforderlich, welche der sechzehn Blöcke den Texturdatenabschnitt der Abbildung umfassen, der durch die Hardwarevorrichtung benötigt wird. Unter Verwendung der S- und T-MSB-Koordinatenbits wird der geeignete Block bestimmt und der Blockzeiger wird zu diesem Block vorgeschoben.
  • Falls bei dem Schritt 820 bestimmt wird, dass die Abbildungsnummer kleiner oder gleich Acht ist, dann geht die Routine zu einem Schritt 824 über. Bei dem Schritt 824 wird der Blockzeiger von einem der zwei Blöcke, der die Texturdaten der Abbildungen speichert, die Abbildungsnummern Acht und weniger aufweisen, zu dem anderen Block bewegt, falls das T-MSB-Bit gesetzt ist. Wie es oben erläutert ist, sind alle der Texturdaten der Abbildungen, die Abbildungsnummern Acht und weniger aufweisen, innerhalb zweier Blöcke gespeichert. Somit ist lediglich ein Bit erforderlich, um zu decodieren, welcher der zwei Blöcke der geeignete Block ist, der herunterzuladen ist. Somit wird das T-MSB-Bit verwendet, um zu decodieren, welcher der zwei Blöcke der geeignete Block für irgendwelche der Abbildungen ist, die Abbildungsnummern Acht und weniger aufweisen.
  • Falls bei dem Schritt 816 bestimmt wird, dass die erforderliche Textur bei der gemeinschaftlich verwendeten Speicherposition des Systems gespeichert ist, geht dann die Routine zu einem Schritt 826 über, bei dem bestimmt wird, ob die Abbildungsnummer kleiner oder gleich Acht ist. Falls die Abbildungsnummer kleiner oder gleich Acht ist, geht dann die Routine zu einem Schritt 828 über, bei dem der Blockzeiger der gemeinschaftlich verwendeten Speicherdatenstruktur zu dem Anfang der zwei Blöcke vorgeschoben wird, die die erforderliche Abbildung speichern. Dann geht die Routine zu dem Schritt 824 über, bei dem der Blockzeiger von einem der Blöcke zu dem anderen vorgeschoben wird, falls das T-MSB-Bit gesetzt ist, wie es oben erläutert ist.
  • Falls alternativ bei dem Schritt 826 bestimmt wird, dass die Abbildungsnummer größer als Acht ist, geht dann die Routine zu einem Schritt 830 über, bei dem der Blockzeiger zu dem Anfangsblock der mehreren Blöcke vorgeschoben wird, die die Texturabschnitte der speziellen erforderlichen MIP-Abbildung speichern. Wie es vorhergehend beschrieben ist, ist, falls die erforderliche Abbildung eine Abbildungsnummer von Neun aufweist, dann einer von vier unterschiedlichen Blöcken der erforderliche Block. Falls die erforderliche Abbildung eine Abbildungsnummer Zehn aufweist, dann ist einer von sechzehn unterschiedlichen Blöcken der spezielle erforderliche Block.
  • Die Routine geht dann zu einem Schritt 832 über, bei dem der Blockzeiger zu dem speziellen erforderlichen Block innerhalb der gemeinschaftlich verwendeten Speicherdatenstruktur unter Verwendung der S,T-MSB-Koordinatenbits vorgeschoben wird, ähnlich dazu, wie es bei dem Schritt 822 vorgenommen wurde, der oben beschrieben ist.
  • Von jedem der Schritte 822, 824 und 832, bei denen der geeignete Blockzeiger vorgeschoben wird, um zu dem speziellen erforderlichen Block zu zeigen, der heruntergeladen werden soll, geht die Routine zu einem Schritt 834 über.
  • Bei dem Schritt 834 ruft die vorrichtungsunabhängige Routine die vorrichtungsabhängige Herunterladeroutine auf, um den erforderlichen Block herunterzuladen und dann die Unterbrechung zu löschen, falls keine weiteren Unterbrechungen existieren. Die vorrichtungsabhängige Routine zum Herunterladen des ausgewählten Blocks ist die bei dem Schritt 648 in 26 gezeigte Herunterladeroutine.
  • Diese vorrichtungsabhängige Routine zum Herunterladen des Blocks lädt den Block herunter, zu dem durch den Zeiger gezeigt wird, wie es bei den Schritten 822, 824 oder 832 durchgeführt wird. Wie es oben detailliert erläutert ist, wird der Block für die Hardwarevorrichtung dieses Beispiels durch den 2-D-Weg heruntergeladen, wobei der pipelineartige 3-D-Aufbereitungsweg der Hardwarevorrichtung vermieden wird. Der spezielle Block wird zu einer ausgewählten Position in dem Cache-Speicher heruntergeladen. Diese ausgewählte Position umfasst ein Überschreiben eines der vierundsechzig Blöcke, die dann in dem Cache-Speicher gespeichert sind. Der optimale zu überschreibende Block, um zukünftige Unterbrechungen für Bandbreiteneinsparungen zu vermeiden, wird bei der vorrichtungsabhängigen Routine bestimmt, die bei den Schritten 646 in 26 gezeigt ist und hierin mit Bezug auf das Flussdiagramm von 29 detailliert beschrieben ist.
  • Die Routine von 28 geht dann von dem Schritt 834 zu dem Schritt 804 über, bei dem bestimmt wird, ob die Variable NICHT-ANGEHALTEN wahr ist. Falls dem so ist, ist dann die Routine abgeschlossen. Die vorrichtungsabhängige Herunterladeroutine des Schritts 834 setzt die Variable NICHT-ANGEHALTEN auf wahr, nachdem der Block heruntergeladen ist und bestimmt ist, dass keine weiteren Unterbrechungen existieren. Dies löscht die Unterbrechung und beendet die Routine.
  • Falls bei dem Schritt 810 bestimmt wird, dass die Abbildungsnummer nicht gleich –1 ist, dann geht die Routine zu dem Schritt 814, oben beschrieben, über.
  • 29 ist ein Blockdiagramm der vorrichtungsabhängigen Routine, die durch die TIM implementiert wird, um zu bestimmen, welcher Block innerhalb des lokalen Cache-Speichers der Hardwarevorrichtung zu ersetzen ist, wenn eine Unterbrechung auftritt. Diese vorrichtungsabhängige Routine ist als der Schritt 646 von 26 gezeigt. Wie es oben mit Bezug auf 26 erläutert ist, wird die vorrichtungsabhängige Routine durch die vorrichtungsunabhängige Routine des Schritts 624 aufgerufen, wenn eine Unterbrechung verarbeitet wird. Das Schema zum Auswählen eines zu ersetzenden Blocks in dem Cache-Speicher betrachtet sowohl die Häufigkeit einer vergangenen Verwendung aller der Blöcke, die sich dann in dem Cache-Speicher befanden, sowie die vorausgesagte zukünftige Verwendung derartiger Blöcke basierend auf den relativen Prioritäten der Texturen, die in den Blöcken gespeichert sind. Das Schema zielt auf ein Reduzieren der Anzahl zukünftiger Unterbrechungen, um eine Systembandbreite zu reduzieren.
  • Die mit Bezug auf 29 beschriebene Routine nimmt eine Verwendung der oben beschriebenen spezifischen Hardwarevorrichtung an. Wie es unten detailliert beschrieben ist, aktualisiert somit die Routine auch die Jüngst-Verwendet- (MRU = most recently used) und Gegenwärtig-Verwendet- (CU = currently used) Register der Hardwarevorrichtung. Es ist jedoch klar, dass die Routine von 29 verändert werden könnte, um zu irgendeiner zu Grunde liegenden Hardwarevorrichtung zu passen, bei der das System der Erfindung verwendet werden könnte. Zum Beispiel muss die Vorrichtung nicht den identischen physischen Aufbau wie derselbe des beschriebenen Beispiels aufweisen, sondern müsste in der Lage sein, einen Abschnitt der Texturdaten zu speichern, die in dem Systemspeicher gespeichert sind, und müsste Unterbrechungen erteilen, wenn Texturdaten, die dann benö tigt werden, um Bilder aufzubereiten, nicht in dem lokalen Speicher vorhanden sind.
  • Die Routine von 29 beginnt bei einem Schritt 900, wenn eine Unterbrechung bei der Hardwarevorrichtung auftritt, ein Signal von der Hardwarevorrichtung zu dem Prozessor gesendet wird, dieses Signal gelesen wird, die TIM geweckt wird und die TIM diese Routine von der vorrichtungsunabhängigen Routine des Schritts 624 von 26 aufruft. Die Routine von 29 geht zu einem Schritt 902 über, bei dem die TIM die MRU- und CU-Register, die jeder SDRAM-Bank entsprechen, von der Hardwarevorrichtung liest. Diese Register verfolgen, welche Blöcke von Texturdaten in dem Cache jüngst verwendet wurden (MRU) oder gegenwärtig in Verwendung sind (CU). Wie es oben beschrieben ist, ist jedes der Register ein 32-Bit-Register, wobei ein Bit jedem der zweiunddreißig Blöcke in der entsprechenden Bank entspricht. Ein Bit in dem MRU-Register ist aktiviert, wenn der entsprechende Block verwendet wurde (d.h. auf Texel von diesem Block in dem Cache zugegriffen wurde), und ein Bit in dem CU-Register ist aktiviert, wenn der entsprechende Block sich in dem Miniverzeichnis (oben beschrieben) befindet.
  • Wie es in der vorhergehenden Hardwarebeschreibung beschrieben ist, bilden aufeinander folgende Pixel häufig zu Texeln ab, die in dem gleichen Block oder den gleichen Blöcken gespeichert sind, was erfordert, dass der gleiche Satz von Blöcken bei einem Aufbereiten von Pixeln eines Grundelements (d.h. eines Abschnitts eines Vielecks, wie beispielsweise ein Dreieck) wiederholt verwendet wird. Um somit wiederholte Unterbrechungen zu vermeiden, ist es erwünscht, Blöcke, die kürzlich verwendet wurden, nicht zu ersetzen, weil auf diesen Block eventuell bei einem Aufbereiten eines nachfolgenden Pixels zugegriffen werden muss. Durch ein Auswählen von zu ersetzenden Blöcken, die eine geringere oder geringste Wahrscheinlichkeit aufweisen, durch die Hardwarevorrichtung bei einem Aufbereiten nachfolgender Pixel benötigt zu werden, wird eine Systembandbreite minimiert.
  • Nach einem Lesen des MRU- und des CU-Registers geht die Routine zu einem Schritt 904 über, bei dem entweder Bank Null oder Bank Eins der SDRAMs des Cache-Speichers ausgewählt wird, um beschrieben zu werden. Die Bestimmung, zu welcher Bank geschrieben werden soll, wird gemäß dem oben in Verbindung mit der Hardwarevorrichtung beschriebenen Schema vorgenommen.
  • Die Routine geht dann zu einem Schritt 906 über, bei dem die Variable BLOCKNUMMER gleich minus Eins gesetzt wird, was verwendet wird, um anzugeben, wann die Iteration vollständig ist und ein Block für eine Ersetzung ausgewählt wurde, wie es unten beschrieben ist. Die Variable BLOCKNUMMER stellt die tatsächliche Blocknummer dar, die für eine Ersetzung ausgewählt wurde.
  • Die Routine geht dann zu einem Schritt 908 über, bei dem bestimmt wird, ob die Variable BLOCKNUMMER gleich minus Eins ist. Bei der ersten Iteration wird die Antwort Ja lauten, da dieselbe gerade gesetzt wurde, und die Routine geht zu einem Schritt 910 über, bei dem bestimmt wird, welche Bank bei dem Schritt 904 ausgewählt wurde, um beschrieben zu werden. Falls die Bank, zu der geschrieben werden soll, eine Bank Null ist, dann geht die Routine zu Schritten 912 und 914 über. Falls alternativ die Bank, zu der geschrieben werden soll, eine Bank Eins ist, dann geht die Routine zu Schritten 916 und 918 über. Die zwei Paare von Schritten für jede Bank führen eine ähnliche Operation durch. Die Operation ist entworfen, um irgendwelche Blöcke, die entweder jüngst verwendet wurden oder aktuell verwendet werden, nicht verfügbar zu machen, wobei die Blöcke den Bits entsprechen, die dann in dem MRU- und dem CU-Register aktiviert sind.
  • Wie es in der Texturhardwarespeicherbeschreibung dargelegt ist, kann der Cache bis zu vierundsechzig Blöcke von Texturdaten halten. Jeder Block ist durch eine Blockkennung identifiziert. Alle vierundsechzig Blöcke werden für eine Ersetzung auf eine Verfügbarkeit hin überprüft. Wie es oben beschrieben ist, hält die Bank Null des Cache-Speichers Blöcke Null bis Einunddreißig, während die Bank Eins Blöcke Zweiunddreißig bis Vierundsechzig hält. Bei dem Schritt 912 wird der Block Null als der Anfangsblock bei einem Prüfen auf eine Verfügbarkeit hin für eine Ersetzung bezeichnet und der Block Einunddreißig wird als der Endblock bei einem Überprüfen auf eine Verfügbarkeit hin für eine Ersetzung der Blöcke der Bank Null bezeichnet. Dies wird durch ein Setzen einer Variable ANFANGSBLOCK auf Null und ein Setzen einer Variable ENDBLOCK auf Einunddreißig erzielt. Gleichermaßen wird bei dem Schritt 916 für die Bank Eins die Variable ANFANGSBLOCK gleich Zweiunddreißig gesetzt und die Variable ENDBLOCK gleich Dreiundsechzig gesetzt, was bezeichnet, dass bei dem Prüfen auf eine Verfügbarkeit hin für eine Ersetzung der Blöcke der Bank Eins der Anfangsblock der Block Zweiunddreißig ist und der Endblock der Block Dreiundsechzig ist.
  • Für jede der Bänke Null und Eins ist eine Variable, die ZU VERWENDENDE BLÖCKE genannt wird, ein 32-Bit-Wort, wobei jedem Block in dieser Bank ein Bit entspricht, das darstellt, ob irgendeiner der Blöcke für eine Ersetzung verfügbar ist. Falls einer der Blöcke in der Variable ZU VERWENDENDE BLÖCKE aktiviert ist, dann ist der entsprechende Block innerhalb dieser Bank für eine Ersetzung verfügbar.
  • Die Routine geht von dem Schritt 912, falls die Bank Null ausgewählt ist, zu dem Schritt 914 über, bei dem die Variable ZU VERWENDENDE BLÖCKE gleich der Variable ZU VERWENDENDE BLÖCKE BANK NULL gesetzt wird und dann die Bits innerhalb der Variable ZU VERWENDENDE BLÖCKE deaktiviert werden, die irgendwelchen Bits entsprechen, die in entweder dem MRU- oder dem CU-Register der Bank Null aktiviert sind, wobei or eine logische ODER-(OR-)Operation ist. Falls gleichermaßen die Bank Eins für eine Ersetzung ausgewählt ist, dann geht die Routine von dem Schritt 916 zu dem Schritt 918 über, bei dem die Variable ZU VERWENDENDE BLÖCKE gleich der Variable ZU VERWENDENDE BLÖCKE BANK EINS gesetzt wird und die Bits innerhalb der Variable ZU VERWENDENDE BLÖCKE, die in dem MRU- oder dem CU-Register von Bank Eins aktiviert sind, deaktiviert werden.
  • Von entweder Schritt 914 oder 918 geht die Routine zu einem Schritt 920 über. Bei dem Schritt 920 werden die Variable VERFÜGBARE BLÖCKE und die Variable BLOCKPRIORITÄT beide auf Null gesetzt. Dieser Schritt 920 wird während jeder Iteration für jeden Block bei einem Bestimmen, ob irgendwelche verfügbaren Blöcke für diese Bank existieren, einmal besucht. Die Variable VERFÜGBARE BLÖCKE wird verwendet, um die Blöcke innerhalb dieser Bank zu zählen, die verfügbar sind, um ersetzt zu werden. Die Anzahl verfügbarer Blöcke innerhalb dieser Bank beeinflusst, wie die Routine fließt, wie es unten beschrieben ist. Die Variable BLOCKPRIORITÄT wird verwendet, um die Prioritäten der verfügbaren Blöcke innerhalb dieser Bank zu überwachen, um die niedrigste Priorität der verfügbaren Blöcke auszuwählen, die zu ersetzen sind.
  • Schritte 922 – 936 sind eine Reihe von Schritten, die für jeden Block innerhalb jeder Bank iterativ durchlaufen werden, um die Anzahl verfügbarer Blöcke und die niedrigste Priorität der verfügbaren Blöcke zu bestimmen. Von dem Schritt 920 geht die Routine zu dem Schritt 922 über, bei dem bestimmt wird, ob die Variable ANFANGSBLOCK kleiner oder gleich der Variable ENDBLOCK ist. Falls die Variable ANFANGSBLOCK kleiner oder gleich der Variable ENDBLOCK ist, dann wurden nicht alle der Blöcke innerhalb dieser Bank auf eine Ersetzungsverfügbarkeit hin überprüft. Während jeder Iteration durch die Reihe von Schritten 922–936 wird die Variable ANFANGSBLOCK um zumindest Eins inkrementiert 934 und stellt den aktuell geprüften Block dar. Wenn ANFANGSBLOCK größer als ENDBLOCK ist, dann geht die Routine zu einem Schritt 938, unten beschrieben, über.
  • Falls die Variable ANFANGSBLOCK kleiner oder gleich der Variable ENDBLOCK ist, dann müssen Blöcke für diese Bank immer noch auf eine Ersetzungsverfügbarkeit hin überprüft werden und die Routine geht zu dem Schritt 924 über. Bei dem Schritt 924 wird bestimmt, ob das Bit, das dem Block entspricht, der überprüft wird, in der Variable ZU VERWENDENDE BLÖCKE gleich Eins ist. Falls das Bit in der Variable ZU VERWENDENDE BLÖCKE, das dem Block entspricht, der aktuell überprüft wird, gleich Eins ist, dann ist dieser Block für eine Ersetzung verfügbar und die Routine geht zu dem Schritt 926 über, bei dem die Variable VERFÜGBARE BLÖCKE um Eins inkrementiert wird.
  • Von dem Schritt 926 geht die Routine zu dem Schritt 928 über, bei dem bestimmt wird, ob die Priorität des gegenwärtig verfügbaren Blocks, d.h. die Priorität des Blocks, der der Variable ANFANGSBLOCK entspricht, größer oder kleiner als die niedrigste Priorität irgendwelcher Blöcke ist, die bis jetzt durch die Iteration der Schritte 922–936 als verfügbar befunden wurden. Die niedrigste Priorität irgendwelcher verfügbaren Blöcke ist in der Variable BLOCKPRIORITÄT gehalten. Falls die Priorität des vorliegenden Blocks geringer als die niedrigste Priorität irgendwelcher bis jetzt verfügbarer Blöcke ist, dann geht die Routine von dem Schritt 928 zu dem Schritt 930 über, bei dem die Variable BLOCKNUMMER gleich der Variable ANFANGSBLOCK gesetzt wird, so dass die Variable BLOCKNUMMER die Blocknummer der niedrigsten Priorität der bis jetzt verfügbaren Blöcke speichert.
  • Die Routine geht dann zu dem Schritt 932 über, bei dem die Variable BLOCKPRIORITÄT auf die Priorität des vorliegenden Blocks gesetzt wird, der durch die Variable ANFANGSBLOCK dargestellt ist. Falls bei dem Schritt 928 bestimmt wird, dass die Priorität des gegenwärtig verfügbaren Blocks (durch die Variable ANFANGSBLOCK dargestellt) nicht geringer als die niedrigste Priorität der bis jetzt verfügbaren Blöcke ist (durch die Variable BLOCKPRIORITÄT dargestellt), dann werden die Schritte 930 und 932 umgangen und die Routine geht zu dem Schritt 934 über. In einem derartigen Fall werden weder die Variable BLOCKNUMMER noch die Variable BLOCKPRIORITÄT aktualisiert.
  • Falls bei dem Schritt 924 bestimmt wird, dass das Bit in der Variable ZU VERWENDENDE BLÖCKE, das dem vorliegenden Block entspricht, der auf eine Verfügbarkeit hin überprüft wird, nicht gleich Eins ist, dann ist dieser Block nicht für eine Ersetzung verfügbar und die Routine geht zu dem Schritt 934 über. Bei dem Schritt 934 wird die Variable ANFANGSBLOCK um Eins inkrementiert, so dass der nächste Block innerhalb dieser Bank auf eine Verfügbarkeit hin überprüft wird. Die Routine geht dann zu dem Schritt 936 über. Bei dem Schritt 936 wird die Variable ZU VERWENDENDE BLÖCKE zu dem nächsten Bit vorgeschoben, das dem nächsten Block entspricht, der auf eine Verfügbarkeit hin überprüft werden soll. Dann geht diese Routine zurück zu dem Schritt 922 für eine andere Iteration über.
  • Wenn alle der Blöcke innerhalb dieser Bank auf eine Verfügbarkeit hin überprüft wurden, ist die Variable ANFANGSBLOCK größer als die Variable ENDBLOCK und die Routine geht von dem Schritt 922 zu „1" über, was in 29 (Forts.) gezeigt ist. Von „1" geht die Routine zu einem Schritt 938 über, bei dem bestimmt wird, ob die Variable VERFÜGBARE BLÖCKE gleich Null ist. Falls die Variable VERFÜGBARE BLÖCKE nicht gleich Null ist, dann geht die Routine zu einem Schritt 940 über, bei dem bestimmt wird, ob die Variable VERFÜGBARE BLÖCKE kleiner oder gleich Zehn ist. Falls die Variable VERFÜGBARE BLÖCKE größer als Zehn ist, dann geht die Routine zu „2" und dann zu dem Schritt 908 über. Bei dem Schritt 908 wird bestimmt, ob die Variable BLOCKNUMMER gleich –1 ist. Weil herausgefunden wurde, dass mehr als zehn Blöcke verfügbar sind, von denen einer eine niedrigste Priorität aufweist, ist die Variable BLOCKNUMMER gleich der Blocknummer mit der niedrigsten Priorität der verfügbaren Blöcke und die Antwort auf diese Bestimmung lautet Nein.
  • Deshalb geht die Routine zu einem Schritt 942 über, bei dem bestimmt wird, ob der Block, der ersetzt werden soll, sich in der Bank Null oder der Bank Eins befindet. Falls sich der Block in der Bank Null befindet, dann geht die Routine zu einem Schritt 944 über, bei dem das Bit innerhalb der Variable ZU VERWENDENDE BLÖCKE für diese Bank, das dem Block entspricht, der für eine Ersetzung ausgewählt ist (dieser Block, der durch die Variable BLOCKNUMMER dargestellt ist), deaktiviert wird. Falls der Block, der ersetzt werden soll, sich in der Bank Null befindet, dann geht die Routine zu einem Schritt 946 über, der eine ähnliche Funktion ausführt, die bei dem Schritt 944 ausgeführt wird. Dann ist die Routine bei einem Schritt 980 abgeschlossen, wenn der Block, der durch die Variable BLOCKNUMMER dargestellt ist und die niedrigste Priorität aller der verfügbaren Blöcke aufweist, für eine Ersetzung ausgewählt wurde. Es ist aus dem Vorhergehenden klar, dass alle der verfügbaren Blöcke, die durch die Variable VERFÜGBARE BLÖCKE dargestellt sind, diese sind, die nicht kürzlich verwendet wurden oder gegenwärtig verwendet werden, und von diesen der Block, der für eine Ersetzung ausgewählt wird, dieser ist, der die Textur mit der geringsten Priorität speichert.
  • Falls bei dem Schritt 940 bestimmt wird, dass die Anzahl verfügbarer Blöcke kleiner oder gleich Zehn ist, dann geht die Routine zu einem Schritt 948 über, bei dem bestimmt wird, ob die verfügbaren Blöcke sich innerhalb der Bank Null oder Bank Eins befinden. Falls sich dieselben in der Bank Null befinden, dann geht die Routine zu einem Schritt 950 über. Falls sich dieselben in der Bank Eins befinden, dann geht die Routine zu einem Schritt 952 über. Bei den Schritten 950 und 952 werden die Hardwareregister MRU (für die Bänke Null bzw. Eins) auf Null rückgesetzt. Durch den Schritt von 950 oder 952 wird das MRU-Register für diese Bank in der Situation rückgesetzt, in der die Anzahl verfügbarer Blöcke für die Bank gering ist. Dies wird vorgenommen, so dass alle der Bits in dem MRU-Register nicht aktiviert sind und für eine zukünftige Unterbrechung einen zu ersetzenden Block zufällig auswählen müssen. Von einem der Schritte 950 oder 952 geht die Routine zu „2" über, was wieder bei dem Schritt 908, oben beschrieben, beginnt.
  • Falls bei dem Schritt 938 bestimmt wird, dass die Anzahl verfügbarer Blöcke für diese Bank gleich Null ist, dann geht die Routine zu einem Schritt 954 über, bei dem bestimmt wird, ob dies das erste Mal für diese Bank ist, dass die Routine sich bei diesem Schritt befunden hat. Falls dem so ist, dann geht die Routine zu einem Schritt 956 über, bei dem bestimmt wird, ob dieselbe die Blöcke in der Bank Null oder der Bank Eins überprüft. Falls es Bank Null ist, dann geht die Routine zu einem Schritt 958 über. Falls es Bank Eins ist, dann geht die Routine zu einem Schritt 960 über. Bei einem der Schritte 958 oder 960 werden die Bits in der Variable ZU VERWENDENDE BLÖCKE (für die entsprechende Bank), die den Bits entsprechen, die in entweder dem MRU-Register oder dem CU-Register (dieser Bank) nicht aktiviert sind, aktiviert. Mit anderen Worten werden bei den Schritten 958 und 960 die Bits in der Variable ZU VERWENDENDE BLÖCKE gleich Eins gesetzt, was Blöcken entspricht, die dann nicht durch aktivierte Bits in dem MRU- oder dem CU-Register für diese Bank dargestellt sind. Diese Operation ist unterschiedlich zu derselben, die bei den Schritten 914 und 918 durchgeführt wird und die die Bits in der Variable ZU VERWENDENDE BLÖCKE für alle der Blöcke deaktiviert, die dann durch die aktivierten Bits in dem MRU- oder CU-Register der entsprechenden Bank dargestellt sind. Die Operation der Schritte 958 und 960 ist ein Versuch, mehr Blöcke in dieser Bank verfügbar zu machen. Von einem der Schritte 958 oder 960 geht die Routine zu „2" über, bei dem die Routine dann bei dem Schritt 908 wieder beginnt und eine andere Iteration zum Überprüfen, ob verfügbare Blöcke existieren, ausgeführt wird.
  • Falls die Iteration erneut auftritt und keine Blöcke für diese Bank als verfügbar bestimmt werden, dann lautet bei dem Schritt 954 die Antwort auf die Bestimmung, ob die Routine für diese Bank vorher dort war, Ja und die Routine geht zu einem Schritt 962 über. Bei dem Schritt 962 wird bestimmt, ob die Blöcke in der Bank Null oder der Bank Eins überprüft werden. Falls es die Bank Null ist, dann geht die Routine zu Schritten 964 und 966 über. Falls es die Bank Eins ist, dann geht die Routine zu Schritten 968 und 970 über. Bei den Schritten 964 und 968 werden die Bits des MRU-Registers für die entsprechende Bank auf Null rückgesetzt. Bei den Schritten 966 und 970 werden dann für die entsprechende Bank die Bits der Variable ZU VERWENDENDE BLÖCKE, die den deaktivierten Bits des CU-Registers für diese Bank entsprechen, aktiviert. Dann geht die Routine zu „2" über, wo dieselbe erneut bei dem Schritt 908 beginnt. Durch ein Aktivieren der Bits innerhalb des Registers ZU VERWENDENDE BLÖCKE, die in dem CU-Register deaktiviert sind, bei den Schritten 966 und 970 versucht die Routine, eine ausreichende Anzahl verfügbarer Blöcke für die nachfolgende Iteration zu liefern. Von einem der Schritte 966 oder 970 geht die Routine zu „2" über und dann wird die nachfolgende Iteration begonnen.
  • 30 ist eine grafische Darstellung, die die unterschiedlichen Weisen zeigt, in denen Softwaretexturdaten von der Grafik-API/dem Grafikhardwaretreiber eines speziellen Prozesses zu der TIM übertragen werden können. In dem oberen linken Abschnitt des Diagramms ist die Grafik-API/der Hardwaretreiber 850 eines speziellen Prozesses gezeigt. Die Grafik-API/der Hardwaretreiber 850 weist einen eigenen zugewiesenen Systemsoftwarespeicherbereich desselben 851 zum Speichern von Kopien von Texturen auf, die innerhalb dieses Prozesses erzeugt werden. Innerhalb dieses Bereichs 851 zeigt das Beispiel von 30 Texturen T1 und T2, die gespeichert sind, sowie einen Zeiger 860 zu einer gemeinschaftlich verwendeten Speichertextur T3. Bei diesem Beispiel ist die Textur T1 256 × 256 Texel groß, ist die Textur T2 16 × 16 Texel groß und ist die Textur T3 1024 × 1024 Texel groß.
  • In dem oberen rechten Abschnitt des Diagramms ist die TIM 160 der vorliegenden Erfindung gezeigt. Die TIM 160 umfasst einen eigenen Datenspeicherbereich derselben 854, innerhalb dessen Kopien bestimmter Texturen, oder Abschnitte derselben, gespeichert sind. Wie es gezeigt ist, sind innerhalb des Datenspeicherbereichs 854 Blöcke 870, 871, 872 und 873 sowie der Zeiger 860 gespeichert. Innerhalb der Blöcke 870 und 871 befinden sich Abschnitte der Texturen T1 und T2. Weil die Textur T1 256 × 256 Texel groß ist und die Textur T2 weniger als 128 × 128 Texel groß ist, wird die Textur T1 unter den zwei Blöcken 870 und 871 zugewiesen und es existiert ein leerer Raum in diesen Blöcken für ein Speichern der Textur T2. Somit packt die TIM die Textur T2 in die gleichen Blöcke wie die Textur T1 und weist der Textur T2 einen Untertexturidentifizierer zu, wie es detailliert oben mit Bezug auf die Hardwarevorrichtung und unten mit Bezug auf 32 beschrieben ist.
  • Die Blöcke 872 und 873 umfassen Abschnitte der Textur T3. Diese Abschnitte umfassen MIP-Abbildungspegel Acht und weniger der Textur T3. Wie es oben beschrieben ist, werden Abbildungen, die eine Abbildungsnummer von Acht und weniger aufweisen, einer speziellen Textur unter zwei Blöcken zugewiesen.
  • In dem unteren linken Abschnitt des Diagramms ist ein gemeinschaftlich verwendeter Speicherbereich 852 gezeigt, der bei dem darstellenden Ausführungsbeispiel von 30 die Textur T3 speichert. Der Datenspeicherbereich 851 der Grafik-API/des Hardwaretreibers umfasst einen Zeiger 860 zu dieser Textur innerhalb des gemeinschaftlich verwendeten Speicherbereichs 852 und ein Datenspeicherbereich 854 der TIM speichert ferner einen anderen Zeiger 860 zu dieser Position innerhalb des gemeinschaftlich verwendeten Speichers 852, bei der die Textur T3 gespeichert ist.
  • Das Softwareschema der vorliegenden Erfindung liefert drei unterschiedliche Verfahren, durch die Texturdaten von der Grafik-API/dem Hardwaretreiber zu der TIM kommuniziert werden können. Das erste Verfahren besteht darin, Datenblöcke über einen gemeinschaftlich verwendeten Speichertransferpuffer 856 zu übertragen. Bei diesem Verfahren zerlegt der Hardwaretreiber die Abbildungen in Blöcke, die durch die Hardwarevorrichtung erkennbar sind. Bei diesem speziellen Beispiel sind diese Blöcke jeweils 256 × 256 Texel groß. Wenn dieselben einmal zerlegt sind, sendet dann der Hardwaretreiber ein Paket über den Sockel 858 zu der TIM. Das Paket umfasst einen Indikator, dass ein Block oder Blöcke von Texturdaten über den gemeinschaftlich verwendeten Speichertransferpuffer 856 kommen werden. Das Paket umfasst ferner die Softwaretextur-ID, die Prozess-ID, der die Textur zugeordnet ist, die S,T-Texturbasisabbildungsgröße, die Anzahl von MIP-Abbildungspegeln dieser Textur und die. Anzahl von Blöcken, die kommuniziert werden. Bei einem Ausführungsbeispiel der Erfindung ist die Softwaretextur-ID ein 32-Bit-Wort und ist die Prozess-ID ebenfalls ein 32-Bit-Wort. Die Softwaretextur-ID unterscheidet Texturen innerhalb eines speziellen Prozesses voneinander und die Prozess-ID unterscheidet Prozesse, die durch die TIM verwaltet werden, voneinander. Die TIM empfängt dann diese Informationen und bereitet sich auf ein Lesen der Texturblöcke aus dem gemeinschaftlich verwendeten Speichertransferpuffer vor.
  • Für Abbildungen, die eine Abbildungsnummer größer Acht aufweisen, wird jeder Block durch den gemeinschaftlich verwendeten Speichertransferpuffer einschließlich Daten lediglich von dieser speziellen Abbildung übertragen. Für jeden dieser Blöcke kopiert die TIM dann den Block und speichert diesen Block in dem eigenen Datenspeicherbereich 854 derselben. Für Abbildungen, die eine Abbildungsnummer von Acht aufweisen, wird die gesamte Abbildung innerhalb eines Blocks mit 256 × 256 Texeln gesendet. Die TIM kopiert dann diesen Block, weist die Abschnitte der Abbildung unter zwei Blöcken in dem Format zu, das für die Hardwarevorrichtung optimal ist, und speichert diese Blöcke in dem Datenspeicherungsspeicherbereich 854 derselben. Für Abbildungen, die eine Abbildungsnummer Sieben und weniger aufweisen, werden alle der Abbildungen durch den Hardwaretreiber in einen einzigen Block gepackt und über den gemeinschaftlich verwendeten Speichertransferpuffer 856 gesendet. Die TIM empfängt den Block von dem Transferpuffer und weist die Texturdaten unter den zwei Blöcken für eine nachfolgende Speicherung in zwei getrennte Bänke der SDRAMs in dem Cache-Speicher zu, wie es oben beschrieben ist. Falls eine andere Hardwarevorrichtung, als diese, die bei dem obigen Beispiel offenbart ist, verwendet wird, packt dann die TIM die Abbildungen, die Abbildungsnummern Acht und weniger aufweisen, in ein Muster, das durch den speziellen lokalen Speicher der Hardwarevorrichtung erkennbar ist.
  • Wie es bei dem Beispiel von 30 gezeigt ist, wird die Textur T1, die 256 × 256 Texel groß ist, über den gemeinschaftlich verwendeten Speichertransferpuffer als ein einziger Block kommuniziert. Dann kopiert die TIM diesen Block und weist die Textur T1 unter zwei Blöcken 870 und 871 zu, die durch die Hardwarevorrichtung erkennbar sind, so dass diese Blöcke in getrennte Bänke der SDRAMs des Cache-Speichers heruntergeladen werden können. Dann werden diese Blöcke 870 und 871 innerhalb der Datenspeicherungsspeicherposition 854 der TIM 160 gespeichert.
  • Das zweite Verfahren, durch das Texturdaten von der Grafik-API/dem Hardwaretreiber zu der TIM kommuniziert werden können, ist durch ein Senden der Textur über den Sockel 858. Bei einem darstellenden Ausführungsbeispiel der Erfindung werden Texturen über den Sockel gesendet, wenn dieselben 64 × 64 Texel groß und weniger sind. Bevor die Textur daten über den Sockel gesendet werden, sendet der Hardwaretreiber ein Paket über den Sockel 858 zu der TIM, das der TIM angibt, dass Texturdaten über den Sockel kommuniziert werden. Das Paket umfasst ferner die S,T-Koordinaten, die die Basisgröße dieser Textur darstellen, die Softwaretextur-ID der Textur, die Prozess-ID, die dieser Textur entspricht, eine Angabe dessen, wie viele MIP-Abbildungspegel sich innerhalb dieser Textur befinden, und die physische Größe der Texturdaten hinsichtlich der Anzahl von Bytes. Die TIM empfängt diese Informationen durch ein Lesen des Pakets von dem Sockel und bereitet sich auf ein Lesen der Texturdaten vor. Dann werden die Texturdaten über den Sockel von dem Hardwaretreiber in der Form eines Datenstroms kommuniziert. Die TIM liest dann die Texturdaten von dem Sockel und packt die Texturdaten in Blöcke, die durch die Hardwarevorrichtung erkennbar sind.
  • Bei dem in 30 gezeigten Beispiel, wird die Textur T2, die 16 × 16 Texel groß ist, über den Sockel kommuniziert und die TIM liest dann die Textur T2 und packt diese Textur T2 zwischen den Blöcken 870 und 871, die ebenfalls Abschnitte der Textur T1 speichern. Wie es oben in Verbindung mit dem Hardwarevorrichtungsbeispiel beschrieben ist, würde der Textur T2 dann die gleiche Textur-ID wie der Textur T1, aber eine unterschiedliche Untertextur-ID zugewiesen, um dieselbe von der Textur T1 zu unterscheiden. Die Untertextur-ID ist ein Vier-Bit-Wort, das zwei S-Koordinatenbits und zwei T-Koordinatenbits umfasst, die die Position der Untertextur innerhalb des Blocks identifizieren.
  • Das dritte Verfahren, durch das Texturdaten von der Grafik-API/dem Hardwaretreiber zu der TIM kommuniziert werden können, ist durch ein Speichern dieser Texturdaten bei der gemeinschaftlich verwendeten Speicherposition, auf die dann sowohl durch die Grafik-API/den Hardwaretreiber als auch die TIM zugegriffen werden kann, die jeweils Zeiger zu den adressierten Positionen der Texturen speichern, die in dem gemeinschaftlich verwendeten Speicherbereich 852 gespei chert sind. Wenn Texturen in dem gemeinschaftlich verwendeten Speicherbereich 852 gespeichert werden sollen, sendet der Hardwaretreiber ein Paket über den Sockel 858 zu der TIM, das der TIM angibt, dass eine Textur in dem gemeinschaftlich verwendeten Speicherbereich 852 gespeichert wird. Das Paket umfasst ferner die Softwaretextur-ID, die gleich der gemeinschaftlich verwendeten Speicher-ID ist, die Prozess-ID, die S,T-Basisabbildungsgröße dieser Textur und die Anzahl von MIP-Abbildungspegeln dieser Textur. Die TIM liest dann das Paket und wandelt die gemeinschaftlich verwendete Speicher-ID in einen Zeiger um und speichert diesen Zeiger in dem eigenen Datenspeicherbereich 854 derselben. Der Zeiger zeigt zu einer Adressposition innerhalb des gemeinschaftlich verwendeten Speicherbereichs, die eine Anfangsadresse der speziellen Textur ist, die in dem gemeinschaftlich verwendeten Speicherbereich gespeichert ist.
  • Die TIM bestimmt ferner, ob die MIP-Abbildungspegel für diese spezielle Textur Abbildungen Acht oder weniger umfassen. Falls diese Textur MIP-Abbildungspegel Acht oder weniger umfasst, dann kopiert die TIM lediglich die MIP-Abbildungspegel Acht oder weniger dieser speziellen Textur und packt dieselben in zwei Blöcke gemäß dem oben umrissenen Zuweisungsschema. Dann werden die gepackten Blöcke von Texturdaten, die die MIP-Abbildungspegel Acht und weniger für diese Textur umfassen, in dem eigenen Speicherbereich 854 der TIM gespeichert, während die Abbildungspegel Neun und größer in dem gemeinschaftlich verwendeten Speicherbereich 852 gespeichert werden. Die TIM speichert einen Zeiger in dem eigenen Bereich 854 derselben zu der Anfangsadresse der Abbildungspegel Neun und größer dieser Textur.
  • Das in 30 gezeigte Beispiel sollte dieses Schema besser darstellen. Man nehme an, dass die Textur T3 eine Basistexturabbildungsgröße von 1024 × 1024 Texeln aufweist. Auf Grund der Größe derselben wird bestimmt, dass die Textur in dem gemeinschaftlich verwendeten Speicherbereich 852 gespeichert werden sollte, anstatt zwei getrennte Kopien der Textur in den Bereichen 851 und 854 gespeichert aufzuweisen. Falls die Textur T3 ferner MIP-Abbildungspegel Acht bis Null umfasst, dann kopiert die TIM Abbildungen Acht bis Null der Textur T3 und packt dieselben in zwei getrennte Blöcke 872 und 873 von Daten. Die Blöcke 872 und 873 werden dann in dem zugewiesenen Systemspeicherbereich 854 der TIM gespeichert. Wie es oben beschrieben ist, speichert die TIM ferner einen Zeiger 860, der zu der Anfangsadresse innerhalb des gemeinschaftlich verwendeten Speichers 852 zeigt, wo die Textur T3 gespeichert ist. Wenn somit die Abbildungen, die Abbildungsnummern Neun und Zehn aufweisen, für die Textur T3 erforderlich sind, kann die TIM auf diese Daten unter Verwendung des Zeigers 860 zu der gemeinschaftlich verwendeten Speicherposition 852 zugreifen.
  • Weil die TIM keine Kopie der Abbildungen Neun und Zehn der Textur T3 aufweist, die in dem eigenen Speicherbereich 854 derselben gespeichert ist, werden die Abbildungen Neun und Zehn der Textur T3 nicht in die Blöcke geteilt, die durch die Hardwarevorrichtung erkennbar sind, bis eine Unterbrechung auftritt. Somit tritt ein geringes Opfer hinsichtlich einer Systembandbreite auf, wenn eine Textur, oder ein Abschnitt einer Textur, in dem gemeinschaftlich verwendeten Speicherbereich 852 gespeichert ist. Jedoch treten enorme Systemspeicherplatzeinsparungen durch ein Speichern einer Textur, oder eines Abschnitts einer Textur, in dem gemeinschaftlich verwendeten Speicherbereich auf. Somit wird bei einem Bestimmen, ob eine Textur, oder ein Abschnitt derselben, in dem gemeinschaftlich verwendeten Speicherbereich zu speichern ist, ein Ausgleich zwischen Speichereinsparungen und einer Systemleistungsfähigkeit vorgenommen. Bei einem Ausführungsbeispiel der vorliegenden Erfindung werden Texturen, die eine Basisabbildung von 1024 × 1024 Texeln Größe und größer aufweisen, in dem gemeinschaftlich verwendeten Speicherbereich 852 des Systems gespeichert. Der Benutzer des Systems könnte jedoch eine Textur irgendeiner Größe als eine Grenzgröße zum Speichern von Texturen in dem gemeinschaftlich verwendeten Speicherbereich auswählen.
  • 31 ist ein Funktionsblockdiagramm, das zeigt, wie die Texturprioritäten für einen speziellen Prozess definiert werden. In der oberen Zeile des Diagramms ist die Benutzeranwendung oder der Benutzerprozess 1030 gezeigt. Unter diesem sind sowohl die Grafik-API 1032 als auch der Grafik-Hardwaretreiber 1034 gezeigt. Unter dem Hardwaretreiber ist die TIM 1036 gezeigt. Bei dem Prozess 1030 kann der Benutzer eine Texturprioritätsliste 1040 für definierte Texturen liefern.
  • Bei diesem Beispiel hat der Benutzer fünf vorhergehend erzeugten Texturen Prioritäten zugewiesen, was in der Texturprioritätsliste 1040 gezeigt ist. Jeder Textur ist eine unterschiedliche Textur-ID zugewiesen. Die Prioritätsliste 1040, die durch den Benutzer geliefert wird, umfasst bei diesem speziellen Beispiel Texturen, die die folgenden IDs aufweisen: ID 3, ID 1, ID 5, ID 2 und ID 6 in dieser Prioritätsreihenfolge. Zusätzlich ist die Textur, die die ID 8 aufweist, durch den Benutzer neu definiert und steht im Begriff, durch die Grafik-API oder den Hardwaretreiber verarbeitet zu werden. Eine derartige Textur (ID 8) kann beispielsweise einem neu erzeugten Kontext zugeordnet sein, der im Begriff steht, durch die API oder den Hardwaretreiber bearbeitet zu werden.
  • Die Grafik-API 1032 verfolgt die kürzliche Verwendung der Texturen für jeden Prozess, einschließlich des Prozesses 1030. Die Textur, die die ID 7 aufweist, die Textur, die die ID 4 aufweist, und die Textur, die die ID 1 aufweist, wurden durch die Grafik-API kürzlich für den Prozess 1030 verarbeitet, wobei die Textur, die die ID 7 aufweist, bei dem in 31 gezeigten Beispiel jüngst verarbeitet wurde. Die Prioritätsliste 1044 kürzlich verarbeiteter Texturen wird durch die API für den Prozess 1030 beibehalten und ist in einem Systemspeicher gespeichert. Von den kürzlich verarbeiteten Texturen (diesen, die in der Liste 1044 beibehalten sind) wird der jüngst verarbeiteten Textur (die bei diesem Beispiel die ID 7 aufweist) die höchste Priorität gegeben, wobei sich jede Textur in der Priorität um Eins nach unten verschiebt, wenn eine neue Textur verarbeitet wurde. Somit ist der Textur, die die ID 7 aufweist, die höchste Priorität gegeben und der Textur, die die ID 1 aufweist, ist die niedrigste Priorität der jüngst verarbeiteten Texturen gegeben, die in der Prioritätsliste 1044 der jüngst verarbeiteten Texturen aufgelistet sind, die durch die Grafik-API 1032 beibehalten wird.
  • Dann verschmilzt die Grafik-API 1032 die benutzergelieferte Texturprioritätsliste 1040 mit der Prioritätsliste 1044 jüngst verarbeiteter Texturen, um die Gesamttexturprioritätsliste 1042 des Systems zu berechnen. Die Grafik-API gibt den benutzergelieferten Prioritäten den Vorzug gegenüber den jüngst verarbeiteten Prioritäten. Somit wird den Texturen, die die IDs ID 3, ID 1, ID 5, ID 2 und ID 6 aufweisen, gegenüber den Texturen, die die IDs ID 7 und ID 4 aufweisen, Priorität gegeben. Der Textur, die die ID 8 aufweist, wird die höchste Priorität gegeben, weil dieselbe eine neu definierte Textur ist, die im Begriff steht, durch die Grafik-API verarbeitet zu werden. Die Prioritätsliste 1042 wird gemäß diesem Schema kontinuierlich aktualisiert und ist in dem Systemsoftwarespeicher gespeichert. Der Hardwaretreiber verwendet die Texturprioritätsliste 1042, die durch die Grafik-API erzeugt wird, um Texturprioritäten zu der TIM zu kommunizieren.
  • Wie es oben mit Bezug auf 27 erläutert ist, wird die Texturprioritätsliste 1042 zu der TIM kommuniziert und die TIM speichert ferner die Prioritäten der Texturen in einer Liste 1048. Die Texturprioritätsliste 1048 der TIM ist ebenfalls in 31 gezeigt und stimmt mit derselben der Texturprioritätslisten der Grafik-API und des Grafik-Hardwaretreibers überein. Der Benutzer kann zu irgendeiner Zeit die benutzergelieferte Prioritätsliste 1040 aktuali sieren, in welchem Fall die Grafik-API die eigene Prioritätsliste 1042 derselben aktualisiert, und, wie es oben erläutert ist, wird den benutzergelieferten Texturprioritäten gegenüber den jüngst verarbeiteten Texturprioritäten der Vorzug gegeben. Falls keine benutzergelieferte Prioritätsliste vorgesehen ist, dann ist die Gesamtprioritätsliste 1042 der Grafik-API diese der Prioritätsliste 1044 jüngst verarbeiteter Texturen, außer neu erzeugten (noch nicht verarbeiteten) Texturen, denen die höchste Priorität gegeben wird.
  • 32 ist eine grafische Darstellung, die drei unterschiedliche Weisen zeigt, in denen Texturen innerhalb des gleichen Blocks zugeteilt werden können und denselben unterschiedliche Untertextur-IDs zugewiesen werden können, gemäß dem Speicherzuteilungsschema der speziellen Hardwarevorrichtung des oben beschriebenen Beispiels. Jeder Block ist 256 × 256 Texel groß. Für eine erste Textur T1, die eine Basisabbildung mit einer Abbildungsnummer Acht aufweist, die 256 × 256 Texel groß ist, würde diese Abbildung unter zwei Blöcken zugewiesen, wobei ein Block in einer Bank Null gespeichert ist und ein Block in einer Bank Eins der SDRAMs innerhalb des Cache-Speichers gespeichert ist. Somit würde ein leerer Raum innerhalb jedes Blocks die Speicherung einer anderen Textur T2 ermöglichen, die innerhalb des gleichen Prozesses wie die Textur T1 erzeugt wird und 128 × 128 Texel groß ist. Einer dieser Blöcke 1000 ist in 32 gezeigt. Die Texturen T1 und T2 würden die gleiche Textur-ID, aber eine unterschiedliche Untertextur-ID umfassen, wie es oben in der Beschreibung der Hardwarevorrichtung beschrieben ist.
  • Als ein anderes Beispiel könnten vier Texturen T3, T4, T5 und T6, die jeweils 128 × 128 Texel groß sind und alle innerhalb des gleichen Prozesses erzeugt werden (und möglicherweise unter mehreren Kontexten innerhalb dieses Prozesses gemeinschaftlich verwendet werden), in vier Quadranten eines anderen Blocks 1010 gepackt werden. Jeder der Textu ren T3, T4, T5 und T6 würde eine unterschiedliche Untertextur-ID zugewiesen, aber dieselbe würde die gleiche Textur-ID umfassen, wie es oben erläutert ist.
  • Ein drittes Beispiel umfasst sechzehn eindeutige Texturen T7 – T22, wobei jede Textur 64 × 64 Texel groß oder kleiner ist und innerhalb des gleichen Prozesses erzeugt wird. Alle sechzehn Texturen T7 – T22 könnten innerhalb des gleichen Blocks 1020 gepackt sein, wobei jeder Textur die gleiche Textur-ID und eine unterschiedliche Untertextur-ID zugewiesen sind. Wie es oben erörtert ist, würde die Untertextur-ID zwei S-Koordinatenbits und zwei T-Koordinatenbits umfassen, um zwischen den sechzehn unterschiedlichen Untertexturen innerhalb des Blocks zu unterscheiden.
  • Nachdem somit zumindest ein darstellendes Ausführungsbeispiel der Erfindung beschrieben wurde, fallen verschiedene Änderungen, Modifikationen und Verbesserungen Fachleuten auf dem Gebiet ohne weiteres ein. Derartige Änderungen, Modifikationen und Verbesserungen sollen innerhalb der Wesensart und des Schutzbereichs der Erfindung liegen. Folglich ist die vorhergehende Beschreibung lediglich beispielhaft und ist nicht als begrenzend beabsichtigt. Die Erfindung ist lediglich begrenzt, wie es in den folgenden Ansprüchen und den Äquivalenten zu denselben definiert ist.

Claims (10)

  1. Ein Texturabbildungscomputergrafiksystem, das folgende Merkmale aufweist: einen Hostcomputer (15), der einen Prozessor (19) und einen Systemspeicher (17) aufweist, der Texturdaten speichert, einschließlich zumindest einer Reihe von Textur-MIP-Abbildungen (100 – 108); eine Grafikhardwarevorrichtung (150), die mit dem Hostcomputer (15) gekoppelt ist und die einen lokalen Speicher (155) aufweist, der zwei getrennte Speicherbänke aufweist, die in gleich großen Blöcken zumindest einen Abschnitt der Texturdaten speichern, die zu irgendeiner Zeit in dem Systemspeicher (17) gespeichert sind, wobei die Hardwarevorrichtung (150) texturabgebildete Bilder unter Verwendung der Texturdaten, die in dem lokalen Speicher (155) gespeichert sind, aufbereitet; und eine Softwareprozedur (160), die auf dem Prozessor (19) des Hostcomputers (15) läuft und Blöcke von Texturdaten von dem Systemspeicher (17) zu dem lokalen Speicher (155) herunterlädt, wenn dieselben durch die Hardwarevorrichtung (150) benötigt werden, um ein Bild aufzubereiten, wobei, wenn eine Abbildung der zumindest einen Reihe von MIP-Abbildungen der zumindest einen Textur (T3) eine Größe aufweist, die gleich oder geringer als eine vorbestimmte Abbildungsgröße ist, die Softwareprozedur (160) zwei getrennte Abschnitte der Abbildung aus dem Systemspeicher (17) in zwei getrennte Blöcke (872, 873) des Systemspeichers (17) kopiert, so dass die zwei Abschnitte der Abbildung in den zwei getrennten Blöcken in getrennte Bänke des lokalen Speichers (155) heruntergeladen werden; und wobei, wenn eine Abbildung eine Größe aufweist, die größer als die vorbestimmte Abbildungsgröße ist, die Softwareprozedur (160) lediglich einen Zeiger (860) zu der Position in dem Systemspeicher (17) speichert, wo die Abbildung positioniert ist.
  2. Das Texturabbildungscomputergrafiksystem gemäß Anspruch 1, bei dem der Prozessor (16) zumindest einen Computergrafikprozess (PR1 – PRN), eine darunter liegende Grafik-API (API1 – APIN) für jeden Prozess (PRI – PRN) und einen darunter liegenden Hardwaretreiber (HWD1 – HWDN) für jeden Prozess (PRI – PRN) ausführt, wobei die Hardwarevorrichtung (150) mit dem Prozessor (19) gekoppelt ist und ferner einen gemeinschaftlich verwendeten Speicherbereich (852) zum Speichern von Texturdaten aufweist, die durch die Softwareprozedur (160), die Grafik-API (API1 – APIN) und den Hardwaretreiber (HWD1 – HWDN) zugreifbar sind.
  3. Das Texturabbildungscomputergrafiksystem gemäß Anspruch 2, bei dem ein Benutzer mehrere Kontexte (IA – IN) innerhalb jedes Prozesses (PR1) erzeugen kann, wobei die Softwareprozedur (160) folgende Merkmale aufweist: einen vorrichtungsunabhängigen Abschnitt (178), der Texturdaten für jeden Prozess (PR1) getrennt verwaltet, derart, dass eine einzige gespeicherte Kopie einer Textur unter einer Mehrzahl von Kontexten (IA – IN) innerhalb des gleichen Prozesses (PRI) gemeinschaftlich verwendet wird; und einen vorrichtungsabhängigen Abschnitt (180) zum Schreiben von Texturdaten zu der Grafikhardwarevorrichtung (150).
  4. Das Texturabbildungscomputergrafiksystem gemäß Anspruch 3, bei dem der vorrichtungsabhängige Abschnitt (180) gemeinschaftlich verwendete Bibliothekspositionen umfasst.
  5. Das Texturabbildungscomputergrafiksystem gemäß einem der Ansprüche 1 bis 4, bei dem die Softwareprozedur (160) folgende Merkmale aufweist: einen Prozess, der jede Abbildung der zumindest einen Reihe von MIP-Abbildungen (100 – 108) der zumindest einen Textur unter einem oder mehreren Blöcken zum Herunterladen zu der Hardwarevorrichtung (150) zuweist; eine Routine (644), die während einer Unterbrechung bestimmt, welcher Block durch die Hardwarevorrichtung (150) benötigt wird; eine Routine (646), die während der Unterbrechung den Block innerhalb der Hardwarevorrichtung (150) auswählt, der mit dem erforderlichen Block ersetzt werden soll; und eine Routine (648), die während der Unterbrechung den erforderlichen Block zu der Hardwarevorrichtung (150) herunterlädt, um den ausgewählten Block innerhalb der Hardwarevorrichtung (150) zu ersetzen.
  6. Das Texturabbildungscomputergrafiksystem gemäß Anspruch 5, bei dem die Routine (646), die den Block auswählt, der ersetzt werden soll, folgende Merkmale aufweist: eine Subroutine, die verfügbare Blöcke, die durch die Hardwarevorrichtung am weitesten zurückliegend verwendet wurden, und unter den verfügbaren Blöcken diese Blöcke bestimmt, die Texturen speichern, die eine geringste Priorität aufweisen.
  7. Ein Verfahren zum Verwalten von Texturdaten in einem Texturabbildungscomputergrafiksystem, wobei das System einen Hostcomputer (15), der einen Prozessor (19) und einen Systemspeicher (17) aufweist, der Texturdaten speichert, einschließlich zumindest einer Reihe von Textur-MIP-Abbildungen (100 – 108), und eine Grafikhardwarevorrichtung (150) umfasst, die mit dem Hostcomputer (15) gekoppelt ist und einen lokalen Speicher (155) aufweist, der zwei getrennte Speicherbänke aufweist, die in gleich großen Blöcken zumindest einen Abschnitt der Texturdaten speichern, die zu irgendeiner Zeit in dem Systemspeicher (17) gespeichert sind, wobei die Hardwarevorrichtung (150) texturabgebildete Bilder unter Verwendung der Texturdaten, die in dem lokalen Speicher (155) gespeichert sind, aufbereitet, wobei Blöcke von Texturdaten aus dem Systemspeicher (17) zu dem lokalen Speicher (155) heruntergeladen werden, wenn dieselben durch die Hardwarevorrichtung (150) benötigt werden, um ein Bild aufzubereiten, wobei das Verfahren folgende Schritte aufweist: Kopieren zweier getrennter Abschnitte der Abbildung aus dem Systemspeicher (17) in zwei getrennte Blöcke (872, 873) des Systemspeichers (17), wenn eine Abbildung der zumindest einen Reihe von MIP-Abbildungen von zumindest einer Textur (T3) eine Größe aufweist, die gleich oder geringer als eine vorbestimmte Abbildungsgröße ist, so dass die zwei Abschnitte der Abbildung in den zwei getrennten Blöcken in getrennte Bänke des lokalen Speichers (155) heruntergeladen werden; und Speichern eines Zeigers (860) zu der Position in dem Systemspeicher (17), wo die Abbildung positioniert ist, wenn eine Abbildung eine Größe aufweist, die größer als die vorbestimmte Abbildungsgröße ist.
  8. Das Verfahren gemäß Anspruch 7, das ferner folgenden Schritt aufweist: vor einem Zuweisen jeder Abbildung der zumindest einen Reihe von Textur-MIP-Abbildungen, Teilen jeder Abbildung (100 – 108) der zumindest einen Reihe von MIP-Abbildungen in zumindest zwei Abbildungsabschnitte (Q1 – Q4), wobei das Zuweisen jeder Abbildung der zumindest einen Reihe von Textur-MIP-Abbildungen ein Zuweisen der Abbildungsabschnitte (Q1 – Q4) jeder zugewiesenen Abbildung aufweist, derart, dass die Abbildungsabschnitte (Q1 – Q4) in die Mehrzahl von Blöcken (Block 1 – Block N) von Daten zugewiesen werden.
  9. Das Verfahren gemäß Anspruch 7 oder 8, das ferner folgenden Schritt aufweist: vor dem Herunterladen der bestimmten Blöcke von dem Hostcomputer, Auswählen von am weitesten zurückliegend verwendeten Datenblöcken mit niedrigster Priorität in der Hardwarevorrichtung (150), die ersetzt werden sollen.
  10. Das Verfahren gemäß Anspruch 9, bei dem das Auswählen von am weitesten zurückliegend verwendeten Datenblöcken mit niedrigster Priorität folgende Schritte aufweist: Überwachen der Verwendung der Datenblöcke, die in der Hardwarevorrichtung (150) gespeichert sind; und Verfolgen der Prioritäten von Texturen der zumindest einen Reihe von Textur-MIP-Abbildungen (100 – 108).
DE69635009T 1995-06-08 1996-05-09 Programmunterbrechung durch einen Pufferspeicher um Texturabbildungsdaten in einem virtuellen Speicher zu verwalten Expired - Fee Related DE69635009T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US486447 1995-06-08
US08/486,447 US5790130A (en) 1995-06-08 1995-06-08 Texel cache interrupt daemon for virtual memory management of texture maps

Publications (2)

Publication Number Publication Date
DE69635009D1 DE69635009D1 (de) 2005-09-08
DE69635009T2 true DE69635009T2 (de) 2006-05-24

Family

ID=23931928

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69635009T Expired - Fee Related DE69635009T2 (de) 1995-06-08 1996-05-09 Programmunterbrechung durch einen Pufferspeicher um Texturabbildungsdaten in einem virtuellen Speicher zu verwalten

Country Status (4)

Country Link
US (1) US5790130A (de)
EP (1) EP0749100B1 (de)
JP (1) JP3888477B2 (de)
DE (1) DE69635009T2 (de)

Families Citing this family (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5760783A (en) * 1995-11-06 1998-06-02 Silicon Graphics, Inc. Method and system for providing texture using a selected portion of a texture map
US6121974A (en) * 1996-06-27 2000-09-19 Cirrus Logic, Inc. Priority storage system for fast memory devices
US5781197A (en) * 1996-07-26 1998-07-14 Hewlett-Packard Company Method for maintaining contiguous texture memory for cache coherency
US5936632A (en) * 1996-07-26 1999-08-10 Hewlett-Packard Co. Method for fast downloading of textures to accelerated graphics hardware and the elimination of extra software copies of texels
US5828382A (en) * 1996-08-02 1998-10-27 Cirrus Logic, Inc. Apparatus for dynamic XY tiled texture caching
US5844576A (en) * 1996-12-30 1998-12-01 Cirrus Logic, Inc. Tiled linear host texture storage
US5852451A (en) * 1997-01-09 1998-12-22 S3 Incorporation Pixel reordering for improved texture mapping
JP3104643B2 (ja) * 1997-05-07 2000-10-30 株式会社セガ・エンタープライゼス 画像処理装置及び画像処理方法
US6085292A (en) * 1997-06-05 2000-07-04 Digital Equipment Corporation Apparatus and method for providing non-blocking pipelined cache
US6266753B1 (en) 1997-07-10 2001-07-24 Cirrus Logic, Inc. Memory manager for multi-media apparatus and method therefor
US6046747A (en) * 1997-08-04 2000-04-04 Hewlett-Packard Company Graphics application programming interface avoiding repetitive transfer of texture mapping data
KR100231707B1 (ko) * 1997-08-04 2000-01-15 정선종 통신 장비의 디엠에이 처리 방법 및 그 장치
US7136068B1 (en) * 1998-04-07 2006-11-14 Nvidia Corporation Texture cache for a computer graphics accelerator
WO2000004496A1 (en) * 1998-07-17 2000-01-27 Intergraph Corporation Graphics processor with texture memory allocation system
US6732187B1 (en) * 1999-09-24 2004-05-04 Cisco Technology, Inc. Opaque packet handles
US7050063B1 (en) * 1999-02-11 2006-05-23 Intel Corporation 3-D rendering texture caching scheme
US6919895B1 (en) * 1999-03-22 2005-07-19 Nvidia Corporation Texture caching arrangement for a computer graphics accelerator
US7061500B1 (en) * 1999-06-09 2006-06-13 3Dlabs Inc., Ltd. Direct-mapped texture caching with concise tags
US6750872B1 (en) * 1999-09-17 2004-06-15 S3 Graphics, Co., Ltd. Dynamic allocation of texture cache memory
JP3619143B2 (ja) * 1999-11-18 2005-02-09 キヤノン株式会社 画像処理装置およびその方法
US7710425B1 (en) 2000-06-09 2010-05-04 3Dlabs Inc. Ltd. Graphic memory management with invisible hardware-managed page faulting
US6917364B2 (en) * 2001-01-31 2005-07-12 International Business Machines Corporation Method and apparatus for managing texture memory in a data processing system
US7043726B2 (en) * 2001-03-20 2006-05-09 Hewlett-Packard Development Company, L.P. Binding of processes in network systems
US7619633B2 (en) * 2002-06-27 2009-11-17 Microsoft Corporation Intelligent caching data structure for immediate mode graphics
US7161599B2 (en) 2001-10-18 2007-01-09 Microsoft Corporation Multiple-level graphics processing system and method
US7443401B2 (en) * 2001-10-18 2008-10-28 Microsoft Corporation Multiple-level graphics processing with animation interval generation
US7064766B2 (en) * 2001-10-18 2006-06-20 Microsoft Corporation Intelligent caching data structure for immediate mode graphics
JP2003132347A (ja) * 2001-10-26 2003-05-09 Sony Corp 画像処理装置
JP3761085B2 (ja) * 2001-11-27 2006-03-29 株式会社ソニー・コンピュータエンタテインメント 画像処理装置及びその構成部品、レンダリング処理方法
US7336713B2 (en) * 2001-11-27 2008-02-26 Samsung Electronics Co., Ltd. Method and apparatus for encoding and decoding data
US7809204B2 (en) 2002-10-18 2010-10-05 Samsung Electronics Co., Ltd. Method and apparatus for encoding and decoding key value data of coordinate interpolator
US7466315B2 (en) 2003-03-27 2008-12-16 Microsoft Corporation Visual and scene graph interfaces
US7486294B2 (en) 2003-03-27 2009-02-03 Microsoft Corporation Vector graphics element-based model, application programming interface, and markup language
US7417645B2 (en) 2003-03-27 2008-08-26 Microsoft Corporation Markup language and object model for vector graphics
US7088374B2 (en) * 2003-03-27 2006-08-08 Microsoft Corporation System and method for managing visual structure, timing, and animation in a graphics processing system
US7088371B2 (en) * 2003-06-27 2006-08-08 Intel Corporation Memory command handler for use in an image signal processor having a data driven architecture
US7015915B1 (en) * 2003-08-12 2006-03-21 Nvidia Corporation Programming multiple chips from a command buffer
US7525547B1 (en) 2003-08-12 2009-04-28 Nvidia Corporation Programming multiple chips from a command buffer to process multiple images
US7075541B2 (en) * 2003-08-18 2006-07-11 Nvidia Corporation Adaptive load balancing in a multi-processor graphics processing system
US7511718B2 (en) 2003-10-23 2009-03-31 Microsoft Corporation Media integration layer
US7340547B1 (en) 2003-12-02 2008-03-04 Nvidia Corporation Servicing of multiple interrupts using a deferred procedure call in a multiprocessor system
US7583269B2 (en) * 2004-02-17 2009-09-01 Sun Microsystems, Inc. Window system 2D graphics redirection using direct texture rendering
US7289125B2 (en) * 2004-02-27 2007-10-30 Nvidia Corporation Graphics device clustering with PCI-express
US7525551B1 (en) * 2004-11-01 2009-04-28 Nvidia Corporation Anisotropic texture prefiltering
US7522167B1 (en) 2004-12-16 2009-04-21 Nvidia Corporation Coherence of displayed images for split-frame rendering in multi-processor graphics system
US7525549B1 (en) 2004-12-16 2009-04-28 Nvidia Corporation Display balance/metering
US7545380B1 (en) 2004-12-16 2009-06-09 Nvidia Corporation Sequencing of displayed images for alternate frame rendering in a multi-processor graphics system
US7383412B1 (en) 2005-02-28 2008-06-03 Nvidia Corporation On-demand memory synchronization for peripheral systems with multiple parallel processors
US7363456B2 (en) * 2005-04-15 2008-04-22 International Business Machines Corporation System and method of allocating contiguous memory in a data processing system
US7602395B1 (en) 2005-04-22 2009-10-13 Nvidia Corporation Programming multiple chips from a command buffer for stereo image generation
US7616207B1 (en) * 2005-04-25 2009-11-10 Nvidia Corporation Graphics processing system including at least three bus devices
US7456833B1 (en) 2005-06-15 2008-11-25 Nvidia Corporation Graphical representation of load balancing and overlap
US7817849B2 (en) * 2005-08-18 2010-10-19 Hewlett-Packard Development Company, L.P. Method and apparatus for graphical data compression
US7629978B1 (en) * 2005-10-31 2009-12-08 Nvidia Corporation Multichip rendering with state control
US7475197B1 (en) 2005-10-25 2009-01-06 Nvidia Corporation Cross process memory management
US7932912B1 (en) 2006-10-04 2011-04-26 Nvidia Corporation Frame buffer tag addressing for partitioned graphics memory supporting non-power of two number of memory elements
US8212832B2 (en) * 2005-12-08 2012-07-03 Ati Technologies Ulc Method and apparatus with dynamic graphics surface memory allocation
JP4594892B2 (ja) * 2006-03-29 2010-12-08 株式会社東芝 テクスチャマッピング装置、方法およびプログラム
US7884829B1 (en) 2006-10-04 2011-02-08 Nvidia Corporation Partitioned graphics memory supporting non-power of two number of memory elements
US8072463B1 (en) * 2006-10-04 2011-12-06 Nvidia Corporation Graphics system with virtual memory pages and non-power of two number of memory elements
US7999817B1 (en) 2006-11-02 2011-08-16 Nvidia Corporation Buffering unit to support graphics processing operations
US8139071B1 (en) * 2006-11-02 2012-03-20 Nvidia Corporation Buffering unit to support graphics processing operations
US8289326B2 (en) * 2007-08-16 2012-10-16 Southwest Research Institute Image analogy filters for terrain modeling
US7814276B2 (en) * 2007-11-20 2010-10-12 Solid State System Co., Ltd. Data cache architecture and cache algorithm used therein
US20100061030A1 (en) * 2008-09-09 2010-03-11 Norman Werbner Anti-shock device
WO2010121945A2 (en) * 2009-04-21 2010-10-28 International Business Machines Corporation Method and system for interaction with unmodified 3d graphics applications
US10169072B2 (en) * 2009-09-23 2019-01-01 Nvidia Corporation Hardware for parallel command list generation
US9563971B2 (en) 2011-09-09 2017-02-07 Microsoft Technology Licensing, Llc Composition system thread
WO2013142861A1 (en) 2012-03-23 2013-09-26 Polycore Software, Inc. Apparatus and method for providing a multicore programming platform
JP2014013506A (ja) * 2012-07-04 2014-01-23 Canon Inc 情報処理装置、制御方法、及びプログラム
US9946666B2 (en) * 2013-08-06 2018-04-17 Nvidia Corporation Coalescing texture access and load/store operations
US11200060B1 (en) * 2020-12-23 2021-12-14 Advanced Micro Devices, Inc. Broadcast synchronization for dynamically adaptable arrays

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4692880A (en) * 1985-11-15 1987-09-08 General Electric Company Memory efficient cell texturing for advanced video object generator
JP2612260B2 (ja) * 1986-09-24 1997-05-21 ダイキン工業株式会社 テクスチヤマツピング装置
US4935879A (en) * 1987-08-05 1990-06-19 Daikin Industries, Ltd. Texture mapping apparatus and method
US4945495A (en) * 1987-10-21 1990-07-31 Daikin Industries, Ltd. Image memory write control apparatus and texture mapping apparatus
US5097427A (en) * 1988-07-06 1992-03-17 Hewlett-Packard Company Texture mapping for computer graphics display controller system
GB2240015A (en) * 1990-01-15 1991-07-17 Philips Electronic Associated Texture memory addressing
US5222205A (en) * 1990-03-16 1993-06-22 Hewlett-Packard Company Method for generating addresses to textured graphics primitives stored in rip maps
US5224208A (en) * 1990-03-16 1993-06-29 Hewlett-Packard Company Gradient calculation for texture mapping
US5179638A (en) * 1990-04-26 1993-01-12 Honeywell Inc. Method and apparatus for generating a texture mapped perspective view
JPH0628485A (ja) * 1992-07-09 1994-02-04 Toshiba Corp テクスチャーアドレス生成器、テクスチャーパターン生成器、テクスチャー描画装置及びテクスチャーアドレス生成方法
GB2270243B (en) * 1992-08-26 1996-02-28 Namco Ltd Image synthesizing system
US5537224A (en) * 1992-11-24 1996-07-16 Sony Corporation Texture mapping image processing method and apparatus

Also Published As

Publication number Publication date
JP3888477B2 (ja) 2007-03-07
EP0749100A3 (de) 1999-05-26
EP0749100A2 (de) 1996-12-18
JPH0916785A (ja) 1997-01-17
US5790130A (en) 1998-08-04
DE69635009D1 (de) 2005-09-08
EP0749100B1 (de) 2005-08-03

Similar Documents

Publication Publication Date Title
DE69635009T2 (de) Programmunterbrechung durch einen Pufferspeicher um Texturabbildungsdaten in einem virtuellen Speicher zu verwalten
DE69635638T2 (de) Pufferspeicher für Texturdaten
DE19620847B4 (de) Verfahren und Vorrichtung zur Texturabbildung
DE69630165T2 (de) Herunterladen von Texturdaten unter Umgehung der 3D-Schaltungen
DE69635066T2 (de) Unterbrechungsschema zum Aktualisieren eines Lokalspeichers
DE102013017639B4 (de) Zwischenspeicherung von adaptiv dimensionierten Cache-Kacheln in einem vereinheitlichten L2-Cache-Speicher mit Oberflächenkomprimierung
US6426753B1 (en) Cache memory for high latency and out-of-order return of texture data
DE102016211642B4 (de) Patch-speichersystem
US7333115B2 (en) Image processing apparatus and method thereof
DE19709227B4 (de) Verfahren zum schnellen Herunterladen von Texturen auf eine Hardware für beschleunigte Graphiken und zur Beseitigung von zusätzlichen Softwarekopien von Texeln
DE69728002T2 (de) Steuerprozessor für einen drei-dimensionalen Beschleuniger, der die Fähigkeit geometrischer Dekompression besitzt und Verfahren zur Bearbeitung von geometrischen Daten in diesem Beschleuniger
US7944441B2 (en) Compression and decompression of data using plane equations
US5920326A (en) Caching and coherency control of multiple geometry accelerators in a computer graphics system
US6144392A (en) Method and apparatus for formatting a texture in a frame buffer
EP0747860B1 (de) Verfahren und System zur Zuordnung von Speicherplätzen an Texturabbildungsdaten
EP0747825A2 (de) SDRAM-Datenzuweisungsanordnung und -verfahren
US6650333B1 (en) Multi-pool texture memory management
US6762763B1 (en) Computer system having a distributed texture memory architecture
DE102007016179A1 (de) Speicherverwaltungssystem und Verfahren für ein GPU basiertes Volumenwiedergeben
DE102013202173A1 (de) Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads
DE102013205886A1 (de) Dynamische Bankmodus-Adressierung für Speicherzugriff
KR20210066727A (ko) 그래픽 처리 시스템
DE102020118860A1 (de) Techniken zum vorladen von texturen beim rendering von graphik
DE112021001345T5 (de) On-demand speicherzuweisung
DE102019101871A1 (de) Verfahren und Vorrichtung zum Gewinnen von Abtastpositionen von Textuieroperationen

Legal Events

Date Code Title Description
8327 Change in the person/name/address of the patent owner

Owner name: HEWLETT-PACKARD DEVELOPMENT CO., L.P., HOUSTON, TE

8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee