DE19709227A1 - Verfahren zum schnellen Herunterladen von Texturen auf eine Hardware für beschleunigte Graphiken und zur Beseitigung von zusätzlichen Softwarekopien von Texeln - Google Patents

Description

Die vorliegende Erfindung bezieht sich auf ein Verfahren zum schnellen Herunterladen von Texturen auf eine Hardware für beschleunigte Graphiken und zur Beseitigung von zusätzlichen Softwarekopien von Texeln. Insbesondere bezieht sich die Er­ findung auf eine Software-Speicherverwaltung von Texturta­ bellen eines Texturabbildungs-Computergraphiksystems und noch spezieller auf einen neuen Lösungsansatz, der das Her­ unterladen von Texturen beträchtlich beschleunigt, wenn ein Texturunterbrechungs-Verwaltungshintergrundprozeß ("TIM"-Daemon; TIM = Texture Interveniere Management), der auf ei­ nem virtuellen Speicherverwaltungssystem basiert, verwendet ist, um ein Hardwarevorrichtungs-Lokal-Cache-Speichersystem zum Speichern von Texturabbildungsdaten zu liefern.

Gegenwärtige Implementierungen einer Texturabbildung, wie detaillierter in der U.S.-Patentanmeldung Seriennr. 08/486,447, eingereicht am 8. Juni 1995, mit dem Titel TEXEL CACHE INTERRUPT DAEMON FOR VIRTUAL MEMORY MANAGEMENT OF TEX­ TURE MAPS, von Ethan W. Gannett, der Anmelderin der vorlie­ genden Anmeldung, deren Inhalt hiermit durch Bezugnahme auf­ genommen ist, beschrieben ist, speichern eine Kopie der Tex­ tur des Benutzers softwaremäßig, um einen Mechanismus für eine Texturabfrage zu liefern und das hardwaremäßige Zwi­ schenspeichern (Cacheing) von Texeln zu ermöglichen, wenn nicht ausreichend Speicher existiert, daß alle Texel gleich­ zeitig in die Hardware passen.

Bei typischen Computergraphiksystemen ist ein Objekt, das auf dem Anzeigebildschirm dargestellt werden soll, in eine Mehrzahl von Graphik-Grundelementen unterteilt. Grundelemen­ te sind elementare Komponenten eines Graphikbilds und können Punkte, Linien, Vektoren oder Polygone, beispielsweise Drei­ ecke, enthalten. Typischerweise ist ein Hardware/Software-Schema implementiert, um die Graphikgrundelemente, die die Ansicht von einem oder mehreren Objekten, das (die) auf dem Bildschirm dargestellt wird (werden), darstellen, für den zweidimensionalen Anzeigebildschirm aufzubereiten oder auf demselben zu zeichnen.

Typischerweise werden die Grundelemente, die das dreidimen­ sionale Objekt, das aufbereitet werden soll, definieren, von einem Hostcomputer geliefert, der jedes Grundelement in Form von Grundelementdaten definiert. Wenn das Grundelement bei­ spielsweise ein Dreieck ist, kann der Hostcomputer das Grundelement in Form von x-, y-, z-Koordinaten der Scheitel­ punkte desselben definieren, ebenso wie von R-, G-, B-Farb­ werten jedes Scheitelpunkts. Eine Aufbereitungshardware in­ terpoliert die Grundelementdaten, um die Anzeigebildschirm­ pixel zu berechnen, die eingeschaltet werden, um jedes Grundelement darzustellen, ebenso wie die R-, G-, B-Werte für jedes Pixel.

Frühe Graphiksysteme waren nicht in der Lage, Bilder auf eine ausreichend realistische Art und Weise anzuzeigen, um komplexe dreidimensionale Objekte darzustellen oder zu mo­ dellieren. Die Bilder, die durch solche Systeme angezeigt wurden, zeigten extrem glatte Oberflächen ohne Texturen, Er­ hebungen, Vertiefungen, Schatten oder anderen Oberflächen­ details, die bei dem Objekt, das modelliert wird, vorliegen.

Folglich wurden Verfahren entwickelt, um Bilder mit verbes­ serten Oberflächeneinzelheiten anzuzeigen. Die Texturabbil­ dung ist ein solches Verfahren, das das Abbilden eines Quel­ lenbilds, das hierin als eine "Textur" bezeichnet wird, auf eine Oberfläche eines dreidimensionalen Objekts und nachfol­ gend das Abbilden des texturierten dreidimensionalen Objekts auf dem zweidimensionalen Graphikanzeigebildschirm, um das resultierende Bild anzuzeigen, enthält. Oberflächen-Detail­ attribute, die üblicherweise mittels der Texturabbildung ab­ gebildet werden, umfassen die Farbe, Spiegelreflexionen, Vektorperturbationen, das Spiegelvermögen, die Transparenz, Schatten, Oberflächen-Unregelmäßigkeiten sowie Abstufungen.

Die Texturabbildung umfaßt das Anwenden von einem oder meh­ reren Punkttexturelementen ("Texeln") auf jedes Punktelement ("Pixel") des angezeigten Abschnitt des Objekts, auf das die Textur abgebildet wird. Die Texturabbildungshardware wird üblicherweise mit Informationen beliefert, die die Art und Weise anzeigen, auf die die Texel in einer Texturtabelle den Pixeln auf dem Anzeigebildschirm, der das Objekt darstellt, entsprechen. Jedes Texel in einer Texturtabelle ist durch S- und T-Koordinaten definiert, die den Ort desselben in der zweidimensionalen Texturtabelle identifizieren. Für jedes Pixel wird aus der Texturtabelle auf das entsprechende Texel oder die Texel, die auf dasselbe abbilden, zugegriffen, wo­ bei dieselben in die endgültigen R-, G-, B-Werte, die für das Pixel erzeugt werden, eingearbeitet werden, um das tex­ turierte Objekt auf dem Anzeigebildschirm darzustellen.

Es sollte offensichtlich sein, daß jedes Pixel in einem Ob­ jektgrundelement für jede Ansicht des Objekts nicht in einer Eins-zu-Eins-Entsprechung auf ein einzelnes Texel in der Texturtabelle abbildet. Beispielsweise wird, je näher das Objekt der Sichtebene, die auf dem Anzeigebildschirm darge­ stellt ist, ist, das Objekt umso größer erscheinen. Wenn das Objekt auf dem Anzeigebildschirm größer erscheint, wird die Darstellung der Textur detaillierter. Wenn das Objekt einen ziemlich großen Abschnitt des Anzeigebildschirms belegt, wird somit eine große Anzahl von Pixeln verwendet, um das Objekt auf dem Anzeigebildschirm darzustellen, wobei jedes Pixel, das das Objekt darstellt, in einer Eins-zu-Eins-Ent­ sprechung auf ein einzelnes Texel in der Texturtabelle ab­ bilden kann, wobei alternativ ein einzelnes Texel auf meh­ rere Pixel abbilden kann. Wenn das Objekt jedoch einen rela­ tiv kleinen Abschnitt auf dem Anzeigebildschirm besetzt, ist eine viel kleinere Anzahl von Pixeln verwendet, um das Ob­ jekt darzustellen, was zur Folge hat, daß die Textur weniger detailliert dargestellt wird, so daß jedes Pixel auf eine Mehrzahl von Texeln abbilden kann. Außerdem kann jedes Pixel in eine Mehrzahl von Texeln abbilden, wenn eine Textur auf einen kleinen Abschnitt eines Objekts abgebildet wird. Für jedes Pixel, das auf mehr als ein Texel abbildet, werden re­ sultierende Texeldaten berechnet. Da es üblich ist, daß ein Pixel auf mehrere Texel abbildet, stellen resultierende Te­ xeldaten für ein Pixel typischerweise einen Mittelwert der Texel, die auf dieses Pixel abbilden, dar.

Texturabbildungs-Hardwaresysteme weisen typischerweise einen lokalen Speicher auf, der Daten speichert, die eine Textur darstellen, die dem Objekt, das aufbereitet wird, zugeordnet ist. Wie oben erläutert wurde, kann ein Pixel auf mehrere Texel abbilden. Wenn es notwendig wäre, daß die Texturabbil­ dungshardware eine große Anzahl von Texeln, die auf ein Pi­ xel abbilden, aus dem Lokalspeicher liest, um einen Mittel­ wert zu erzeugen, dann wäre eine große Anzahl von Speicher-Auslesungen und die Mittelwertbildung von vielen Texelwerten erforderlich, was zeitaufwendig wäre und das Systemverhalten verschlechtern würde.

Um dieses Problem zu lösen, wurde ein Schema entwickelt, das die Erzeugung einer Reihe von Tabellen, die "MIP"-Tabellen ("MIP" bedeutet "multum in parvo" = viele Dinge an einem kleinen Ort) genannt werden, für jede Textur enthält, und das Speichern der MIP-Tabellen der Textur, die dem Objekt, das aufbereitet wird, zugeordnet ist, in dem Lokalspeicher der Texturabbildungshardware. Eine MIP-Tabelle für eine Tex­ tur weist eine Basistabelle auf, die direkt der Texturtabel­ le entspricht, ebenso wie eine Reihe von gefilterten Tabel­ len, in denen jede aufeinanderfolgende Tabelle größenmäßig um einen Faktor von zwei in jeder der zwei Texturtabellendi­ mensionen reduziert ist. Ein darstellendes Beispiel eines Satzes von MIP-Tabellen ist in Fig. 1 gezeigt. Die MIP-Ta­ bellen weisen eine Basistabelle ("Ebene 0") 100 auf, die acht mal acht Texel groß ist, ebenso wie eine Reihe von Ta­ bellen 102, 104 und 108, die eine Ebene 1, die vier mal vier Texel groß ist, eine Ebene 2, die zwei mal zwei Texel groß ist, bzw. eine Ebene 3, die 1 Texel groß ist, darstellen.

Die Ebene-1-Tabelle 102 der Größe vier mal vier wird durch eine Blockfilterung (Dezimierung) der Basistabelle 100 er­ zeugt, derart, daß jedes Texel in der Ebene-1-Tabelle 102 einem Mittelwert von vier Texeln aus der Ebene-0-Basistabel­ le 100 entspricht. Beispielsweise ist das Texel 110 in der Ebene-1-Tabelle 102 gleich dem Mittelwert der Texel 112 bis 115 der Ebene-0- (Basis-) Tabelle 100. In gleicher Weise sind die Texel 118 und 120 in der Ebene-1-Tabelle 102 gleich den Mittelwerten der Texel 121 bis 124 bzw. 125 bis 128 der Ebene-0- (Basis-) Tabelle 100. Die Ebene-2-Tabelle 104 der Größe zwei mal zwei ist in gleicher Weise durch eine Block­ filterung der Ebene-1-Tabelle 102 gebildet, derart, daß das Texel 130 in der Ebene-2-Tabelle 104 gleich dem Mittelwert der Texel 110 und 118 bis 120 der Ebene-1-Tabelle 102 ist. Das einzelne Texel in der Ebene-3-Tabelle 108 ist durch die Mittelwertbildung der vier Texel in der Ebene-2-Tabelle 104 erzeugt.

Herkömmliche Graphiksysteme laden üblicherweise die gesamte Reihe von MIP-Tabellen für jede Textur, die für die Grund­ elemente, die auf dem Anzeigebildschirm gezeichnet werden sollen, verwendet werden soll, aus dem Hauptspeicher des Hostcomputers in den Lokalspeicher der Texturabbildungshard­ ware. Folglich kann die Texturabbildungshardware auf Textur­ daten aus jeder der Reihe von MIP-Tabellen zugreifen. Die Bestimmung dessen, auf welche Tabelle zuzugreifen ist, um die Texeldaten für jedes spezielle Pixel zu liefern, basiert auf der Anzahl von Texeln, die dem Pixel zugeordnet ist. Wenn dem Pixel ein einzelnes Texel in der Texturtabelle in einer Eins-zu-Eins-Entsprechung zugeordnet ist, wird bei­ spielsweise auf die Basistabelle 100 zugegriffen. Wenn das Pixel jedoch auf vier, sechzehn oder vierundsechzig Texel abbildet, wird jeweils auf die Tabellen 102, 104 und 108 zugegriffen, da diese Tabellen jeweils Texeldaten speichern, die einen Mittelwert von vier, sechzehn und vierundsechzig Texeln in der Texturtabelle speichern.

Überdies sind einige Texturabbildungssysteme pipelineartig aufgebaut, so daß verschiedene Operationen auf unterschied­ lichen Objektgrundelementen gleichzeitig durchgeführt wer­ den. Jedoch kann eine Reihe von MIP-Tabellen für eine Textur groß sein. Die meisten Systeme verwenden einen Lokalspei­ cher, der in der Lage ist, nur eine derart große Reihe von MIP-Tabellen auf einmal zu speichern. Wenn ein Wechseln der Textur, die bei der Aufbereitung von Grundelementen verwen­ det ist, vorliegt, muß das System folglich eine neue Reihe von MIP-Tabellen herunterladen. Typischerweise umfaßt der Datenweg, der verwendet ist, um die neuen Texturdaten in den Lokalspeicher der Texturabbildungshardware herunterzuladen, das Durchlaufen der Grundelement-Aufbereitungspipeline des Systems. Wenn eine neue Textur abgebildet werden soll, muß daher ermöglicht sein, daß die Grundelement-Aufbereitungs­ pipeline entleert ist, bevor die neue Reihe von MIP-Tabellen heruntergeladen werden kann. Sobald die Reihe von MIP-Tabel­ len heruntergeladen ist, muß die Pipeline wieder gefüllt werden. Die Notwendigkeit des Spülens der Grundelement-Auf­ bereitungspipeline, jedesmal, wenn eine neue Textur erfor­ derlich ist, reduziert die Bandbreite des Systems.

Fig. 2 ist ein Blockdiagramm, teils Hardware, teils hierar­ chische Software, eines herkömmlichen Computergraphiksy­ stems, das die Softwareschichten zeigt, die auf dem Prozes­ sor des Systemhostcomputers ablaufen, ebenso wie die Hard­ warevorrichtung, mit der der Hostcomputer kommuniziert, um die mit einer Textur versehenen Bilder aufzubereiten. Der Systemspeicher des Hostcomputers kann eine Mehrzahl Benut­ zer-interaktiver Prozesse PR1, PR2, . . ., PRN speichern, die auf dem Systemprozessor laufen können, wie in Fig. 2 gezeigt ist. Jeder Prozeß, PRi, ist ein Hochpegel-Computergraphik-Softwareprogramm oder eine Anwendung, beispielsweise eine Datenbank, eine CAD/CAM-Anwendung, eine Architekturentwurfs­ anwendung, eine Bautechnikanwendung, ein Textverarbeitungs-Datenpaket oder dergleichen.

Innerhalb eines speziellen Prozesses kann ein Benutzer meh­ rere Kontexte erzeugen. Jeder Kontext, der in einem Prozeß erzeugt wird, kann eine unterschiedliche Ansicht des glei­ chen Bilds enthalten. Beispielsweise kann ein Benutzer in einem Bautechnik-Entwurfsanwendungsprozeß unterschiedliche Ansichten der gleichen Struktur, beispielsweise eines Gebäu­ des, erzeugen. Jeder Kontext kann eine Texturabbildung er­ fordern, um das Bild aufzubereiten. Bei diesem Beispiel kön­ nen Texturtabellen erforderlich sein, um die Böden, Wände, Decken und andere Oberflächenattribute des Gebäudes zu zeichnen. Folglich liefert der Benutzer die Textur-Tabelle oder -Tabellen, um das Bild dieses Kontextes aufzubereiten. Da mehrere Kontexte, die in dem gleichen Prozeß erzeugt wer­ den, typischerweise unterschiedliche Ansichten des gleichen Bilds umfassen, benötigen die Kontexte innerhalb eines Pro­ zesses üblicherweise die gleiche Textur oder die gleichen Texturen.

Wenn ein Kontext durch einen Benutzer erzeugt wird, erteilt der Benutzer einen Befehl, der für die Hochpegel-Prozeßpro­ grammiersprache erkennbar ist, um das Bild zu zeichnen. Wenn das Bild eine Texturtabelle erfordert, wird ein Befehl ein­ gegeben, der anzeigt, daß eine Texturtabelle erforderlich ist, wobei die Texturtabelle dann durch den Benutzer von ei­ ner externen Eingabevorrichtung, einer Floppy-Diskette oder dergleichen, geliefert wird. Der Prozeß, oder die Hochpe­ gel-Programmiersprache, übersetzt dann diesen Befehl in ei­ nen Niederpegel-Softwarebefehl und kopiert die Textur, die durch den Benutzer eingegeben wird. Bei bekannten Systemen, beispielsweise dem, das in Fig. 2 gezeigt ist, erfordert je­ der Kontext, der in einem einzelnen Prozeß erzeugt wird, seine eigene Kopie dieser Textur. Jeder Kontext speichert seine Kopie der Textur in einem zugewiesenen Bereich des Sy­ stemspeichers auf dem Hostcomputer. Folglich werden, wenn mehrere Kontexte innerhalb eines Prozesses die Verwendung der gleichen Textur erfordern, mehrere Kopien dieser Textur in dem Systemspeicher gespeichert, wobei eine Kopie jedem Kontext zugeordnet ist.

Der vom Benutzer eingegebene Befehl, um ein Bild unter Ver­ wendung einer speziellen Textur zu zeichnen, wird, sobald er durch den Prozeß übersetzt ist, von dem Prozeß zu einer da­ runterliegenden Graphikanwendungsprogrammier-Schnittstelle ("API"; API = Application Programmer Interface) übertragen. Wie in Fig. 2 gezeigt ist, kommuniziert eine eindeutige Gra­ phik-API mit jedem Prozeß des Systems. Jede Graphik-API ist eine darunterliegende Niederpegel-Softwaresprache, die auf dem Prozessor des Hostcomputers arbeitet, um jeden Hochpe­ gel-Graphikbefehl, der von dem entsprechenden Prozeß empfan­ gen wird, in einen Niederpegel-Softwarecodebefehl zu über­ setzen. Die Graphik-API speichert ferner eine Kopie jeder Textur, die erforderlich ist, um das Bild aufzubereiten, in ihrem eigenen zugewiesenen Ort des Systemspeichers. Die Gra­ phik-API unterteilt das Bild, das aufbereitet werden soll, zusätzlich in Graphikkomponenten, beispielsweise Vierecke oder Polygone. Derartige Informationen werden dann einem entsprechenden Hardwaretreiber geliefert.

Ein eindeutiger Hardwaretreiber kommuniziert mit jeder Gra­ phik-API. Jeder Hardwaretreiber ist eine weitere darunter­ liegende Graphiksoftwaresprache niedrigeren Pegels, die je­ den Niederpegel-Graphikbefehl, der von der API empfangen wird, in Hardwarebefehle übersetzt, die für die Graphikhard­ warevorrichtung, mit der der Hostcomputer verbunden ist, er­ kennbar ist. Diese Befehle werden dann von dem Hardwaretrei­ ber zu der Hardwarevorrichtung übertragen, die als Reaktion das mit der Textur versehene Bild auf einen Anzeigebild­ schirm, der mit der Hardwarevorrichtung verbunden ist, zeichnet. Wie in Fig. 2 gezeigt ist, kommuniziert jedes Bei­ spiel eines Hardwaretreibers HWD1, HWD2, . . ., HWDN mit einer jeweiligen Graphik-API, API1, API2, . . ., APIN.

Bei dem Beispiel, das in Fig. 2 gezeigt ist, sind alle Hard­ waretreiber mit einer einzelnen Graphikhardwarevorrichtung 150 verbunden. Es ist für Fachleute jedoch offensichtlich, daß der Hostcomputer mit einer Mehrzahl unterschiedlicher Graphikhardwarevorrichtungen verbunden sein kann, wobei je­ weils ein unterschiedlicher Hardwaretreiber mit jeder Hard­ warevorrichtung kommuniziert.

Wenn eine Graphik-API einen Niederpegel-Softwarebefehl lie­ fert, um ein mit einer Textur versehenes Polygon unter Ver­ wendung einer speziellen Textur, die ebenfalls geliefert wird, aufzubereiten, übersetzt der Graphikhardwaretreiber den Niederpegelbefehl in Hardwarebefehle, die für die Hard­ warevorrichtung 150 erkennbar sind. Der Graphikhardwaretrei­ ber liefert danach die Befehle, um das Polygon aufzuberei­ ten, zu der Hardwarevorrichtung 150, indem dieselben in ge­ eignete Register und Eingangspuffer in der Hardwarevorrich­ tung geschrieben werden. Zusätzlich liefert der Graphikhard­ waretreiber die Texturdaten für dieses spezielle Polygon zu dem Lokalspeicher 155 der Hardwarevorrichtung 150, wo die­ selben während der Aufbereitung dieses Polygons temporär ge­ speichert werden. Wie hierin beschrieben ist, laden bekannte Computergraphiksysteme die gesamte Reihe von MIP-Tabellen für eine einzelne Textur aus dem Graphikhardwaretreiber in den Lokalspeicher der Hardwarevorrichtung herunter, jedes­ mal, wenn diese Textur erforderlich ist, um ein Bild oder eine Komponente des Bilds aufzubereiten.

Bei herkömmlichen Systemen, beispielsweise dem, das in Fig. 2 gezeigt ist, werden mehrere Kopien einer einzelnen Textur an unterschiedlichen Orten des Systemsoftwarespeichers des Hostcomputers gespeichert. Wenn beispielsweise der Kontext 1A und der Kontext 1B des Prozesses PR1 die gleiche Textur erfordern, um unterschiedliche Ansichten eines speziellen Bilds aufzubereiten, liefert der Benutzer eine erste Kopie dieser Textur, wenn dieselbe anfänglich definiert und in den Prozeß eingeführt wird. Die Graphik-API1 erstellt eine Kopie der Textur für den Kontext 1A (die zweite Kopie) und eine weitere Kopie dieser Textur für den Kontext 1B (die dritte Kopie) und speichert dieselben in einem Speicher, der von der API und der Hardware gemeinsam verwendet wird. Folglich sind drei einzelne Kopien der gleichen Textur an unter­ schiedlichen Orten des Systemsoftwarespeichers gespeichert, um zwei Ansichten des gleichen Bilds unter Verwendung der gleichen Textur aufzubereiten. Zusätzlich werden eine vierte und eine fünfte Kopie der Textur der Hardwarevorrichtung ge­ liefert und in dem Lokalspeicher derselben gespeichert.

Wie offensichtlich wird, kann eine Reihe von Textur-MIP-Ta­ bellen zur Speicherung eine große Systemsoftwarespeichermen­ ge erfordern. Beispielsweise erfordert eine Reihe von MIP-Tabellen für eine Textur mit einer Texturbasistabelle von 1.024×1.024 Texeln mehr als 5 MByte Systemsoftwarespeicher, um eine Kopie der MIP-abgebildeten Textur zu speichern. Folglich verbraucht die Mehrzahl gespeicherter Kopien der MIP-abgebildeten Textur einen signifikanten Systemsoftware­ speicherbetrag.

Obwohl Systemsoftwarespeicher in der Lage sein können, Soft­ waredaten bis zu einigen Gigabyte zu speichern, können typi­ sche, zweckgebundene, lokale Hardwaretexturspeicher einer Texturhardwarevorrichtung viel weniger Daten speichern. Der­ artige lokale Texturhardwarespeicher liegen typischerweise in einem Bereich von vier MByte bis sechzehn MByte. In vie­ len Texturabbildungsanwendungen übersteigt daher der System­ speicherbetrag, der durch Texturen verbraucht wird, den des lokalen Hardwaretexturspeichers weit. Obwohl der Systemspei­ cher typischerweise mehrere MIP-abgebildete Texturen für die Verwendung mit mehreren Kontexten eines Prozesses speichert, kann der lokale Hardwarevorrichtungsspeicher gleichzeitig nur eine Textur einer begrenzten Größe speichern. Daher ist die ordnungsgemäße Verwaltung des Lokaltexturspeichers der Hardwarevorrichtung kritisch, um ein maximales Verhalten des Systems zu erreichen.

Zusätzlich zu dem großen Systemsoftwarespeicherverbrauch aufgrund der Speicherung mehrerer Kopien von Texturen leidet die Systembandbreite allgemein unter herkömmlichen lokalen Hardwaretexturspeicher-Verwaltungsschemata. Herkömmliche lo­ kale Hardwarespeicher-Verwaltungsschemata ersetzen wieder­ holt ganze Reihen von Textur-MIP-Tabellen in dem lokalen Hardwarespeicher. Die Reihe von MIP-Tabellen für eine Textur wird in dem lokalen Speicher jedesmal ersetzt, wenn diese Textur benötigt wird, um ein Polygon aufzubereiten. Derarti­ ge Schemata sind weder in der Lage, die Geschichte der Ver­ wendung dieser Textur zu berücksichtigen, noch die zukünfti­ ge Verwendung dieser Textur vorherzusagen. Durch das wieder­ holte Herunterladen der gesamten Reihe der gleichen Textur von dem Systemspeicher in den lokalen Hardwaretexturspeicher wird die Systembandbreite negativ beeinflußt.

Obwohl herkömmliche Texturhardwarespeicher-Ersetzungsalgo­ rithmen ganze Textur-MIP-Tabellen-Reihen herunterladen, darf jede Textur-MIP-Tabellen-Reihe die physikalischen Speicher­ fähigkeitsgrenzen des lokalen Hardwaretexturspeichers nicht überschreiten. Daher muß der Benutzer des Graphikprozesses, der mit der speziellen Hardwarevorrichtung verbunden ist, die Kapazität des Lokaltexturspeichers kennen, so daß keine Texturen verwendet werden, die größer sind als diese Kapazi­ tät. Obwohl viele Anwendungen (Prozesse) mit mehreren, un­ terschiedlichen, darunterliegenden Hardwarevorrichtungen arbeiten können, von denen jede eindeutige Lokaltexturspei­ cher-Beschränkungen aufweist, fällt die Last dem Benutzer zu, Kenntnis von solchen Beschränkungen zu besitzen und Bil­ der auf eine vorrichtungsabhängige Art und Weise zu erzeu­ gen.

Wie oben angezeigt wurde, ist es möglich, daß für jede gege­ bene Textur eine große Anzahl von Softwarekopien erzeugt werden muß. Jedoch existiert in vielen Fällen niemals ein Bedarf nach all diesen Softwarekopien. In diesen Fällen fragt der Benutzer die Textur niemals wieder ab, wobei wäh­ rend der Lebensdauer der Textur stets Raum benötigt wird, um dieselbe in dem Texel-Cache zu speichern. Frühere Lösungen für dieses Problem richteten sich auf das Reduzieren der An­ zahl von Operationen, die bezüglich der Texturtabelle durch­ geführt wurden, bevor dieselbe in den Graphikkernspeicher kopiert wurde, wobei dieselben jedoch nicht die verschiede­ nen Softwarekopien beseitigten, da davon ausgegangen wurde, daß die Softwarekopien benötigt werden würden, da der Gra­ phikkern zukünftige Funktionen, die auf der Textur durchge­ führt werden könnten (beispielsweise eine Abfrage der Tex­ tur), nicht bestimmen kann.

Entsprechend ist in der U.S.-Patentanmeldung Seriennr. 08/ 486,447, eingereicht am 8. Juni 1995 mit dem Titel TEXEL CACHE INTERRUPT DAEMON FOR VIRTUAL MEMORY MANAGEMENT OF TEX- TURE MAPS, von Ethan W. Gannett, auf die oben Bezug genommen wurde, ein TIM beschrieben, der die gemeinsame Speicherung von Texturen unter dem Verwalter (dem "TIM"), dem Hardware­ treiber und der entsprechenden Graphik-API in dem System­ speicher liefert. Der Verwalter liefert ferner eine gemein­ same Speicherung von Texturen unter mehreren Kontexten eines einzelnen Prozesses. Das Verwaltungsschema, das von Gannett beschrieben ist, ermöglicht ferner, daß der Benutzer der Hochpegel-Graphikprozesse Bilder auf eine vorrichtungsunab­ hängige Art und Weise erzeugt, ohne Kenntnis der Speicherfä­ higkeitsgrenzen der Lokalspeicher der darunterliegenden Hardwarevorrichtungen.

Ein Ausführungsbeispiel der Erfindung von Gannett ist in Blockdiagrammform in Fig. 3 gezeigt, bei der zur Bezeichnung von Elementen, die identisch zu denen von Fig. 2 sind, glei­ che Bezugszeichen verwendet sind. Wie bei dem bekannten Aus­ führungsbeispiel von Fig. 2 (vor Gannett) weist das System mehrere Benutzer-interaktive Prozesse PR1, PR2, . . ., PRN auf, die auf dem Systemprozessor laufen. In jedem Prozeß kann der Benutzer mehrere Kontexte erzeugen, die die glei­ chen Texturtabellen benötigen. Das System weist ferner eine darunterliegende Graphik-API und einen Graphikhardwaretrei­ ber für jeden Prozeß auf.

Die Erfindung von Gannett bezog sich auf ein Texturunterbre­ chungsverwaltungs-Hintergrundprogramm ("TIM"-Daemon) 160, das ein unabhängiger alleinstehender Softwareprozeß ist, der auf dem Prozessor des Hostcomputers ohne Kenntnis des Benut­ zers abläuft. Der TIM 160 der Erfindung von Gannett steht mit jedem der Graphikhardwaretreiber über einen unterschied­ lichen Sockel in Verbindung. Wie für Fachleute offensicht­ lich ist, ist ein Sockel ein Softwarekommunikationsweg, über den zwei Softwareprogramme kommunizieren können. Der TIM kommuniziert mit der Hardwarevorrichtung 150 ferner über ei­ nen Bus 162.

Der TIM der Erfindung von Gannett kann auf herkömmlichen Prozessoren von Computergraphik-Systemhostcomputern, die als Computergraphikworkstations bekannt sind, ablaufen. Ein Bei­ spiel einer derartigen Workstation ist die Hewlett-Packard- 9000-Reihe J200.

Der TIM 160 verwaltet das Speichern von Texturdaten in dem Lokalspeicher 155 der Hardwarevorrichtung 150, wobei der TIM einen vorrichtungsunabhängigen Abschnitt enthielt, der die Softwaretexturspeicher-Verwaltung handhabte und sockelmäßige Verbindungen mit den Graphikhardwaretreibern und einem vor­ richtungsabhängigen Abschnitt, der über den Bus 162 in die Hardwarevorrichtung schreibt und von derselben liest.

Bei einem Ausführungsbeispiel der Erfindung von Gannett ist der Lokalspeicher der Hardwarevorrichtung als ein Cache-Speicher angeordnet, bei dem Abschnitte von Texturen zu je­ der einzelnen Zeit in dem Lokalspeicher der Hardwarevorrich­ tung gespeichert sind. Die vorrichtungsunabhängigen Ab­ schnitte des TIM verfolgen die Verwendung der Abschnitte von Texturdaten, die in dem Cache gespeichert sind und überwa­ chen die Prioritäten der Texturen, um die zukünftige Verwen­ dung dieser Abschnitte vorherzusagen. Ein Cache-Fehlgriff in der Hardware findet statt, wenn von der Hardwarevorrichtung Texturdaten benötigt werden, um ein Bild aufzubereiten, die gegenwärtig nicht in dem Cache gespeichert sind. Wenn ein Cache-Fehlgriff stattfindet, bestimmt der TIM, welcher Block von Texturdaten in dem Cache zu ersetzen ist, indem berück­ sichtigt wird, welcher Block oder welche Blöcke von Textur­ daten in dem Cache zuletzt verwendet wurden, und welche Tex­ turen die geringste Priorität aufweisen.

Bei einem Ausführungsbeispiel der Erfindung von Gannett weist der TIM einen gemeinsam verwendeten Speicherort in dem Systemspeicher auf, an dem eine große Textur oder ein Tex­ turabschnitt gespeichert ist, und zwischen der Graphik-API, dem Graphikhardwaretreiber und dem TIM für einen speziellen Prozeß gemeinsam verwendet wird. Sowohl die Graphik-API als auch der Graphikhardwaretreiber (für einen speziellen Pro­ zeß) als auch der TIM 160 weisen einen Zeiger auf einen Ort in dem gemeinsam verwendeten Systemspeicherbereich auf, um auf die gespeicherte Texturkopie zuzugreifen. Zusätzlich liefert der TIM ein Speicherverwaltungsschema derart, daß alle Kontexte, die in einem einzelnen Prozeß erzeugt werden, die gleiche Kopie jeder Textur, die für diese Kontexte benö­ tigt wird, gemeinsam verwenden. Für bestimmte Anwendungen liefert der TIM der Erfindung von Gannett daher enorme Ein­ sparungen an Systemsoftwarespeicherraum.

Bezüglich des Beispiels, das oben bezugnehmend auf Fig. 2 beschrieben wurde, bei dem der Kontext 1A und der Kontext 1B des Prozesses PR1 die gleiche Textur benötigen, um unter­ schiedliche Ansichten eines speziellen Bilds aufzubereiten, lieferte der TIM der Erfindung von Gannett enorme System­ speicherraumeinsparungen, wenn die Textur groß ist. Im Ge­ gensatz zu dem bekannten beschriebenen System (vor Gannett) kann eine einzelne Kopie der Textur gespeichert werden, die zwischen dem Kontext 1A und dem Kontext 1B gemeinsam verwen­ det wird. Wenn die Textur groß genug war, um zu gewährlei­ sten, daß dieselbe an dem gemeinsam verwendeten Speicherort gespeichert ist, wird zusätzlich nur eine weitere Kopie der Textur an dem gemeinsam verwendeten Systemspeicherort ge­ speichert und zwischen dem TIM, der Graphik-API1 und dem Graphikhardwaretreiber HWD1 gemeinsam verwendet werden. Folglich werden bei diesem Beispiel nur drei einzelne Kopien der gleichen Textur an unterschiedlichen Orten des System­ softwarespeichers gespeichert, um zwei Ansichten des glei­ chen Bilds unter Verwendung der gleichen Textur aufzuberei­ ten. Eine Kopie ist die Benutzerkopie, eine Kopie wird zwi­ schen den zwei Kontexten des Prozesses PR1 gemeinsam verwen­ det, und eine Kopie wird zwischen der Graphik-API, dem Gra­ phikhardwaretreiber und dem TIM gemeinsam verwendet. Bei dem bekannten System von Fig. 2 (vor Gannett), das oben be­ schrieben ist, hätten fünf Kopien dieser gleichen Textur in dem Systemsoftwarespeicher gespeichert werden müssen. Daher müssen bei dem TIM der Erfindung von Gannett zwei Kopien der Textur weniger in dem Systemsoftwarespeicher gespeichert werden, was für eine große Textur große Speicherraumeinspa­ rungen zur Folge hat.

Andererseits erfordert die Verwendung der Vorrichtung der vorliegenden Erfindung, wie hierin nachfolgend erklärt wird, daß nur eine einzelne Kopie der Textur existiert, und daß dieselbe in der Graphikhardware beibehalten wird.

Unter Verwendung der Erfindung von Gannett war es notwendig, mehrere Schritte durchzuführen, um ein mit einer Textur ver­ sehenes Dreieck zu zeichnen. Wie in Fig. 4 gezeigt ist, spe­ zifizierte das Anwendungsprogramm zuerst unter Verwendung eines API-Aufrufs eine Textur 12. Die API-Bibliothek verifi­ zierte, daß der API-Aufruf gültig war 14, woraufhin die API die Textur in einen privaten Bibliothekspuffer kopierte 16, wodurch die erste Kopie der Textur erzeugt wurde.

Als nächstes kopierte das Texturhintergrundprogramm ("TIM") die Textur in den privaten Puffer des Hintergrundprogramms (möglicherweise unformatiert, um Hintergrundprogrammanforde­ rungen zu erfüllen), wobei die zweite Kopie der Textur er­ zeugt wird 18.

Ein Anwendungsprogramm zeichnet ein Dreieck unter Verwendung der Textur, indem die Graphikhardware das Texturhintergrund­ programm auffordert, Abschnitte der Textur, die erforderlich sind, um das Dreieck zu zeichnen, zu liefern. Folglich muß das Texturhintergrundprogramm die erforderlichen Abschnitte der Textur für das Anwendungsprogramm herunterladen, wodurch die dritte Kopie der Textur erstellt wird 24.

In ähnlicher Weise wird entsprechend der Erfindung von Gan­ nett eine zusätzliche Kopie der Textur beibehalten, um die Abfrage durch die Anwendung des momentanen Werts der Textur zu handhaben, oder um die Beseitigung der Textur aus der Graphikhardware zu handhaben, wenn eine neue Textur benötigt wird.

Ausgehend von dem genannten Stand der Technik besteht die Aufgabe der vorliegenden Erfindung darin, ein Verfahren zum schnellen Herunterladen von Texturen in einem Computergra­ phik-Hardwaresystem zu schaffen, das nur eine geringe Anzahl von Kopien der Textur benötigt.

Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 ge­ löst.

Gemäß dem bevorzugten Ausführungsbeispiel der Erfindung wird das Erstellen der Softwarekopie der Textur verzögert, bis dieselbe absolut benötigt wird oder die Textur durch den Be­ nutzer verworfen wird.

Ferner verallgemeinert die vorliegende Erfindung ein Textur­ herunterladen, um stets diesen Mechanismus zu verwenden, was die Softwarearchitektur stark vereinfacht und das Verhalten in Fällen wie z. B. Rahmenpufferkopien in den Textur-Cache verbessert, wobei wiederum keine Softwarekopie benötigt wird, es sei denn, eine solche wird angefordert.

Das schnelle Herunterladen von Texturen zu einer Hardware für beschleunigte Graphiken, das einfach als "schnelles Her­ unterladen" bezeichnet wird, liefert einen Mechanismus, um Texturen direkt in den Hardware-Texel-Cache herunterzuladen, wobei der Bedarf nach einer Softwarekopie der Texel verzö­ gert oder möglicherweise vollständig beseitigt wird. Dies verbessert das Verhalten des Herunterladens von Texturen in die Hardware dramatisch, was ferner das Verhalten von Anwen­ dungen, die sich dynamisch ändernde Texturen aufweisen, stark verbessert.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend bezugnehmend auf die beiliegenden Zeich­ nungen näher erläutert. Es zeigen:

Fig. 1 eine graphische Darstellung eines Satzes von Tex­ tur-MIP-Tabellen;

Fig. 2 ein Blockdiagramm, teils Hardware, teils hierarchi­ sche Software, eines bekannten Computergraphiksy­ stems;

Fig. 3 ein Blockdiagramm, teils Hardware, teils Software, eines Computergraphiksystems gemäß der bekannten Erfindung von Gannett;

Fig. 4 ein Flußdiagramm, das das Verfahren, das durch die bekannte Erfindung von Gannett verwendet wird, dar­ stellt; und

Fig. 5 und 6 Flußdiagramme, die das Verfahren der vorlie­ genden Erfindung zeigen.

Um die zahlreichen Kopien von Texturen zu vermeiden, zusam­ men mit der Zeit, die benötigt wird, um derartige Kopien zu erstellen, ebenso wie die große Menge von Speicherbetriebs­ mitteln, die derartige Kopien besetzen, liefert die vorlie­ gende Erfindung eine Einrichtung zum Plazieren von Texturen aus dem Benutzerpuffer direkt in die Graphikhardware. Die Verwendung der vorliegenden Erfindung verbessert die Tex­ tur-Herunterladungsgeschwindigkeit ebenso wie das Aufberei­ tungsverhalten von Anwendungen, die sich dynamisch ändernde Texturen aufweisen. Dieselbe ermöglicht, daß Benutzer einer Texturabbildung ihre Texturen effizient direkt in den Hard­ ware-Texel-Cache herunterladen.

Die Erfindung verwendet einen Mechanismus, um Texturen, die nur hardwaremäßig gespeichert sind, zu verfolgen, bewahrt jedoch die Fähigkeit, eine softwaremäßige Kopie der Textur zu liefern, wenn eine solche benötigt wird. Wenn folglich ein Benutzer die Textur wieder abfragt, oder wenn sich der Graphikkontext ändert, kann die Textur dem Benutzer wieder geliefert werden.

Wie oben erläutert wurde, speichern gegenwärtige Texturab­ bildungsimplementierungen eine Kopie der Benutzertextur softwaremäßig, um einen Mechanismus für eine Texturabfrage zu liefern, und um eine hardwaremäßige Zwischenspeicherung von Texeln zu ermöglichen, wenn nicht genügend Speicher exi­ stiert, daß alle Texel gleichzeitig in die Graphikhardware passen. In vielen Fällen wird diese Softwarekopie der Textur niemals benötigt. In diesen Fällen fragt der Benutzer die Textur nicht wieder ab, wobei während der Lebensdauer der Textur stets Raum existiert, um dieselbe in dem Texel-Cache zu speichern. Die vorliegende Erfindung optimiert diesen Fall, indem die Softwarekopie der Textur verzögert wird, bis dieselbe absolut benötigt wird, oder bis die Textur durch den Benutzer ausrangiert wird.

Zusätzlich verallgemeinert die vorliegende Erfindung das Texturherunterladen, um stets diesen Mechanismus zu verwen­ den, was die Softwarearchitektur stark vereinfacht und das Verhalten in Fällen wie z. B. Rahmenpufferkopien in den Tex­ tur-Cache erhöht - wobei wiederum keine Softwarekopie benö­ tigt wird, es sei denn, eine solche wird beantragt.

Wie nun in dem Flußdiagramm von Fig. 5 gezeigt ist, spezifi­ ziert gemäß dem vorliegenden erfinderischen Verfahren 50 das Anwendungsprogramm unter Verwendung eines API-Aufrufs 52 ei­ ne Textur, um ein mit einer Textur versehenes Dreieck zu zeichnen. Die API-Bibliothek verifiziert, daß der API-Aufruf gültig ist 54, woraufhin dieselbe unmittelbar die Textur in die Graphikhardware herunterlädt 56. Gemäß der vorliegenden Erfindung ist die Graphikhardwarekopie der Textur die einzi­ ge Kopie, die von der Textur gemacht wird, es sei denn, außergewöhnliche Dinge geschehen.

Gemäß der Erfindung wird eine Buchführung durchgeführt, um sowohl die Bibliothek als auch das Texturhintergrundprogramm zu informieren, daß sich die einzige Kopie der Textur in der Hardware 51 befindet. Diese Softwarekopie wird dann als "dirty" betrachtet, da sich die Textur nur in der Hardware befindet.

Das Anwendungsprogramm zeichnet dann ein Dreieck unter Ver­ wendung der Textur, indem die Graphikhardware dasselbe ein­ fach zeichnet 60, da die Graphikhardware bereits eine gegen­ wärtige Kopie der Textur besitzt.

In dem Fall, in dem eine Textur aus der Graphikhardware wie­ dergewonnen werden muß, wurde gemäß dem alten Algorithmus zum Wiedergewinnen der Textur aus der Graphikhardware (ent­ weder da der Benutzer ihren Wert anfordert, oder da die Gra­ phikhardware eine andere Textur benötigt, die nicht paßt), die Textur entweder zu dem Benutzer zurückkopiert (Abfrage) oder dieselbe wurde in der Graphikhardware einfach über­ schrieben (neue Textur benötigt).

Wie nun in Fig. 6 gezeigt ist, überprüft das Anwendungspro­ gramm gemäß der vorliegenden Erfindung andererseits zuerst den Buchführungseintrag, um zu sehen, ob die Textur "dirty" ist 74, d. h., ob dieselbe bereits in der Graphikhardware ist, wenn das Anwendungsprogramm eine Textur benötigt. Wenn dies der Fall ist, lädt das Texturhintergrundprogramm die Textur von der Hardware herauf 76. Wenn die API-Bibliothek die Textur benötigt, gibt das Texturhintergrundprogramm die­ selbe danach zu der API-Bibliothek 78.

Für Fachleute auf dem Gebiet der Computergraphiken ist es offensichtlich, daß die Verwendung des Verfahrens gemäß der vorliegenden Erfindung das Verhalten für Benutzer von Tex­ turabbildungen stark verbessert, speziell für Benutzer, die Anwendungen mit sich dynamisch ändernden Texturtabellen be­ sitzen. Unter Verwendung dieser Technik sind die Zeit und der Speicher, die benötigt werden, um eine Softwarekopie der Texturtabelle zu erstellen, beseitigt. Schlimmstenfalls sind dieselben beseitigt, bis der Benutzer den Texel-Cache-Raum überschreitet, ohne die Textur auszurangieren, oder bis die Textur aufgrund einer Benutzerabfrage oder einer anderen Software-Anforderung zurückgelesen wird. Im besten Fall sind die Zeit und der Speicher, die benötigt werden, vollständig beseitigt.

Claims (5)

1. Verfahren zum schnellen Herunterladen von Texturen in einem Computergraphik-Hardwaresystem, das ein Textur­ unterbrechungs-Verwaltungshintergrundprogramm ("TIM"-Daemon) verwendet, mit folgenden Schritten:

• (a) Veranlassen der Graphikanwendungs-Programmier­ schnittstelle ("API"), eine Textur als Reaktion auf einen gültigen Anwendungs-Programmierschnitt­ stellenaufruf durch ein Anwendungsprogramm in die Graphikhardware zu laden (56); und
• (b) Durchführen eines Buchführungs-Eintrags (58), um die Existenz und die Gültigkeit der Textur in der Graphiksoftware aufzuzeichnen, so daß die Graphik­ bibliothekssoftware und das Anwendungs-Program­ mierschnittstellenhintergrundprogramm den Buchhal­ tungseintrag überprüfen können (74), um zu bestim­ men, ob die Textur aus der Graphikhardware wieder­ erlangt werden muß oder nicht, sollte die Textur benötigt werden.

2. Verfahren zum schnellen Herunterladen gemäß Anspruch 1, bei dem der Schritt des Veranlassens der Graphik-Anwen­ dungsprogrammierschnittstelle, eine Textur als Reaktion auf einen gültigen Anwendungsprogrammierschnittstel­ len-Aufruf durch ein Anwendungsprogramm in die Graphik­ hardware zu laden, das Laden von Daten, die die Textur darstellen, in die Graphikhardware aufweist.

3. Verfahren zum schnellen Herunterladen gemäß Anspruch 2, bei dem der Schritt des Durchführens eines Buchfüh­ rungseintrags das Setzen einer Flag in einer gemeinsam verwendeten Speicherregion aufweist, wobei die gemein­ sam verwendete Speicherregion sowohl durch das Textur­ unterbrechungsverwaltungs-Hintergrundprogramm als auch die Graphik-Anwendungsprogrammierschnittstelle zugreif­ bar ist.

4. Verfahren zum schnellen Herunterladen gemäß Anspruch 3, bei dem der Schritt des Setzens einer Flag das Setzen einer Variable auf einen Wert aufweist, der anzeigt, ob die Texturdaten, die in der Graphikhardware gehalten sind, sich geändert haben, seit die Texturdatenkopie, die in der Graphik-Anwendungsprogrammierschnittstelle gehalten ist, zuletzt modifiziert wurde, oder nicht.

5. Verfahren zum schnellen Herunterladen gemäß Anspruch 4, das ferner den Schritt des Wiedererlangens der Textur­ daten aus der Graphikhardware aufweist, wenn die Flag einen Wert aufweist, der anzeigt, daß die Texturdaten­ kopie geändert wurde, seit die Texturdatenkopie, die in der Graphik-Anwendungsprogrammierschnittstelle gehalten ist, zuletzt modifiziert wurde.