DE69817926T2

DE69817926T2 - Beleuchtungsberechnungseinheit und Verfahren für dreidimensionalen Graphikbeschleuniger

Info

Publication number: DE69817926T2
Application number: DE69817926T
Authority: DE
Inventors: Michael F. Los Altos Deering; Wayne Fremont Morse; Scott R. Pleasanton Nelson; Kevin San Jose Rushforth
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1997-06-30
Filing date: 1998-06-29
Publication date: 2004-07-22
Anticipated expiration: 2018-06-30
Also published as: JPH11102443A; EP0889441A2; EP0889441A3; DE69817926D1; US5914724A; EP0889441B1

Description

Technisches Gebiet der Erfindung
Die vorliegende Erfindung betrifft einen 3D-Grafikbeschleuniger und insbesondere eine Belichtungs- bzw. Beleuchtungseinheit für einen 3D-Grafikbeschleuniger, der eine verbesserte Leistung für die Handhabung von ankommenden Farbwerten zeigt.
Beschreibung des relevanten Standes der Technik
Ein dreidimensionaler (3D-) Grafikbeschleuniger ist ein spezialisiertes Grafikdarstellungsuntersystem für ein Computersystem, das konstruiert ist, um den Host-Prozessor von den 3D-Darstellungsfunktionen zu entlasten, wodurch somit eine verbesserte Systemleistung bereitgestellt wird. In einem System mit einem 3D-Grafikbeschleuniger erzeugt ein Anwendungsprogramm, das auf dem Host-Prozessor des Computersystems ausgeführt wird, dreidimensionale Geometriedaten, die dreidimensionale Grafikelemente für die Ausgabe auf einer Anzeigeeinrichtung definieren. Das Anwendungsprogramm veranlaßt den Host-Prozessor, die Geometriedaten zu dem Grafikbeschleuniger zu übertragen. Der Grafikbeschleuniger empfängt die Geometriedaten und stellt die entsprechenden Grafikelemente auf der Anzeigevorrichtung dar.
Die Designarchitektur eines dreidimensionalen Hochleistungsgrafiksystems verkörpert historisch gesehen eine Balance zwischen einer ansteigenden Systemleistung und der Minimierung der Systemkosten. Grafiksysteme des Standes der Technik leiden jedoch üblicherweise entweder an einer begrenzten Leistung oder an hohen Kosten aufgrund einer Vielzahl von Systembeschränkungen. Beispielsweise lehrt die US-A-4,001,064 die Verwendung eines normalen Vektorshaderchips, der eine Anzahl von extern beladbaren Registerbänken beinhaltet, einschließlich 127 unterschiedlichen 42-Bit-Oberflächenmaterialregistern, die unter anderem die Farbwerte, die in dem Belichtungsmodell eingesetzt werden, und die spiegelnden Intensitätssteuerwerte speichern. Jeder Chip einer Pipeline von 16 Chips führt eine Shading- bzw. Schattierungsberechnung auf einem einzelnen Ausgangspixel durch.
Anwendungen, die dreidimensionale Grafiken darstellen, erfordern eine beachtliche Menge der Verarbeitungsfähigkeiten. Um ein glattes 3D-Bewegungsvideo zu erzeugen, ist es für ein Computersystem beispielsweise erforderlich, eine Einzelbildrate oder eine Aktualisierungsrate von zwischen 20 bis 30 Einzelbildern pro Sekunde beizubehalten. Dies erfordert einen 3D-Computergrafikbeschleuniger, der in der Lage ist, über eine Million Dreiecke pro Sekunde zu verarbeiten.
Ein Architekturansatz, um die Leistung von 3D-Grafiksystemen zu erzeugen, erfolgt durch die Verwendung von algorithmenspezifischen Schaltkreisen, die speziell für nur eine Stufe einer Grafikpipeline vorgesehen sind. Dieser Trend begann vor vielen Jahren am unteren Ende der Grafikpipeline mit pixelverarbeitenden Funktionen und bewegte sich graduell bis zur Spaninterpolation, der Kanteninterpolation und kürzlich bis zu den Einstellfunktionen. Andere Funktionen, die früher in der Pipeline durchgeführt werden (wie z. B. Transformationen, das Clipping und das Beleuchten), wurden im allgemeinen von teureren Allzweckgleitkommaprozessoren, wie z. B. DSP-Chips oder speziell mikrocodierter Gleitkommahardware durchgeführt.
In zunehmendem Maße beginnen jedoch Operationen, wie z. B. das Beleuchten, die Berechnungszeit zu dominieren, insbesondere bei der Verwendung von komplexeren Belichtungsmodellen. Um einen größeren visuellen Realismus zu erreichen, benutzen Benutzer der Grafiksprachen, wie z. B. XGL und OpenGL, routinemäßig mehrere Lichtquellen mit spiegelnden Highlights, und nicht nur ein einzelnes diffuses Licht. Solche Anforderungen legen großen Wert auf die Erzielung höherer Leistung innerhalb der Beleuchtungseinheiten.
Beleuchtungsberechnungen werden typischerweise auf geometrischen Grundelementen durchgeführt nach Operationen wie z. B. der Transformation, der Abschneideüberprüfung und der Flächenbestimmung. Diese Berechnungen verwenden Eingangsfarbwerte, transformierte Positionsdaten, Lichtquellenattribute und optionale Normalendaten, um die Ausgangsfarbwerte zu erzeugen. Die Ausgangsfarbwerte werden zusammen mit den transformierten Grundelementen zu nachfolgenden Stufen der Grafikpipeline für die Darstellung weitergeleitet.
Standardgrafiksprachen unterstützen eine Vielzahl von Farbmoden für die geometrischen Grundelemente. Beispielsweise kann eine globale Farbe für die vordere Fläche eines gegebenen Objekts und in gleicher Weise für eine hintere Fläche definiert werden. Bestimmte Polygone, die die Fläche bilden, können jedoch Eingangsfarben haben, die auf einer per-Vertex-Basis (für eine oder beide Oberflächen) spezifiziert werden, wodurch die globale Farbeinstellung überschrieben wird. Eine Modeneinstellung kann ebenso anzeigen, daß die Farben nur für die Berechnung des einen Typs der Lichtkomponente für das Grundelement zu verwenden sind (beispielsweise nur die spiegelnde Komponente). Eine alpha-Komponente, die für die Transparenzmischungsberechnungen verwendet wird, kann zusätzlich für die vordere und hintere Fläche spezifiziert sein. Der Overhead bzw. die Kopfzeile, die von der Anzahl der Farbmoden, die von den Grafikstandards unterstützt werden müssen, erfordert wird, ist ein Hauptnadelöhr, um die Leistung in Beleuchtungseinheiten des Standes der Technik zu erhöhen.
Aufgrund solcher Komplikationen ist die Übertragung der Farbdaten in die Beleuchtungseinheit (und die nachfolgende Farbauswahl während der Beleuchtungsoperationen) typischerweise sehr komplex. Diese Komplexität erfordert typischerweise eine große Anzahl von Mikrocoderoutinen, um alle möglichen Typen der ankommenden Daten zu behandeln. Dies führt zu einem erhöhten Speicher für Mikrocodebefehle sowie zu einer ineffizienten Ausführung der Mikrocoderoutinen selbst, da es schwierig ist, die Leistung für eine große Anzahl von Routinen zu optimieren.
Eine Beleuchtungseinheit ist daher wünschenswert, die eine erhöhte Leistung für die Behandlung von ankommenden Farbwerten zur Verfügung stellt.
Zusammenfassung der Erfindung
Die Erfindung wird durch die begleitenden unabhängigen und abhängigen Ansprüche definiert.
Die vorliegende Erfindung weist einen Grafikbeschleuniger auf für das Durchführen von Beleuchtungsoperationen, um ein 3D-Objekt darzustellen, das ein oder mehrere Polygone, einschließlich der Vorder- und Rückseite, aufweist. In einer Ausführungsform wird ein Grafikbeschleuniger zur Verfügung gestellt, der eine verbesserte Handhabung von ankommenden Farbwerten zu einer Beleuchtungseinheit zeigt. Der Grafikbeschleuniger weist eine Beleuchtungseinheit auf, die derart konfiguriert ist, daß sie die Beleuchtungsberechnungen auf dem Polygon durchführt. Die Beleuchtungseinheit beinhaltet einen Eingangspufferspeicher für das Speichern einer Mehrzahl von Farbwerten, ein Modenregister einschließlich eines Farbmodusfeldes, das spezifiziert, ob die Mehrzahl von Farbwerten zu der Vorder- oder Rückseite des Polygons korrespondiert. Das Modusregister beinhaltet weiterhin ein Flächenrichtungsfeld, das spezifiziert, ob die Belichtungsoperationen entsprechend der Vorder- oder der Rückseite des Polygons durchgeführt werden. Weiterhin beinhaltet die Belichtungseinheit eine Registerdatei für das Speichern der Farbinformation. Die Registerdatei beinhaltet eine erste Mehrzahl von Registern für das Speichern der Farbinformation der Vorderseite und eine zweite Mehrzahl von Registern für das Speichern der Farbinformation der Rückseite. Die Belichtungseinheit beinhaltet noch weiterhin eine Eingangs-/Ausgangslogik, die derart konfiguriert ist, daß sie einen Farbübertragungsbefehl durchführt.
Das Ausführen des Farbübertragungsbefehls weist das Zugreifen auf das Modusregister auf, um einen Wert des Farbmodusfeldes zu erhalten, und dann die Mehrzahl von Farbwerten von dem Eingangspuffer zu einem oder mehreren Registern innerhalb der Registerdatei zu transferieren. Das eine oder die mehreren Register sind innerhalb der ersten Mehrzahl von Registern lokalisiert, wenn der Wert des Farbmodusfeldes anzeigt, daß die Mehrzahl von Farbwerten zu der Vorderseitenfarbinformation korrespondiert. Umgekehrt sind das eine oder die mehreren Register innerhalb der zweiten Mehrzahl von Registern lokalisiert, wenn der Wert des Farbmodusfeldes anzeigt, daß die Mehrzahl von Farbwerten der Rückseitenfarbinformation entspricht. Das eine oder die mehreren Register sind innerhalb der ersten Mehrzahl von Registern und der zweiten Mehrzahl von Registern lokalisiert, wenn der Wert des Farbmodusfeldes anzeigt, daß die Mehrzahl der Farbwerte zu sowohl der Vorder- als auch Rückseitenfarbinformation korrespondiert. Schließlich beinhaltet die Belichtungseinheit eine Belichtungsberechnungseinheit, die derart konfiguriert ist, daß sie auf das Modusregister zugreift, um einen Wert des Flächenrichtungsfeldes zu erhalten. Die Beleuchtungseinheit ist weiterhin derart konfiguriert, daß sie Beleuchtungsberechnungen durchführt unter Verwendung von einem oder mehreren der Mehrzahl von Farbwerten, die in Übereinstimmung mit dem Wert des Oberflächenrichtungsfeldes ausgewählt wurden.
Durch Verwendung des Modenregisters, um den Farbübertragungsbefehl und die Beleuchtungsoperationen zu bewirken, kann eine Mikrocoderoutine verwendet werden für das Handhaben der Vorder- und Rückseitenmaterialfarben. Mikrocodespeicher kann somit reduziert werden und die Beleuchtungsleistung kann erhöht werden durch Optimieren auf die einzelne Routine.
Kurze Beschreibung der Figuren
Beispielhafte Ausführungsformen der Erfindung werden im folgenden lediglich beispielhaft unter Bezug auf die begleitenden Zeichnungen beschrieben, in denen:
1 ein Computersystem darstellt, das einen dreidimensionalen (3D-) Grafikbeschleuniger gemäß der vorliegenden Erfindung beinhaltet,
2 ein vereinfachtes Blockdiagramm des Computersystems von 1 ist,
3 ein Blockdiagramm ist, das den 3D-Grafikbeschleuniger entsprechend der bevorzugten Ausführungsform der vorliegenden Erfindung darstellt,
4 ein Blockdiagramm ist, das einen der Gleitkommaprozessoren in dem 3D-Grafikbeschleuniger entsprechend der bevorzugten Ausführungsform der vorliegenden Erfindung zeigt,
5 ein Blockdiagramm ist, das den L-Kernblock in der bevorzugten Ausführungsform der vorliegenden Erfindung zeigt,
6 ein Flußdiagramm ist, das ein Verfahren zum Durchführen der automatischen Auswahl der Vorder-/Rückseitenmaterialfarben in einer Ausführungsform der vorliegenden Erfindung zeigt,
7A–B Zustandsmaschinendiagramme sind, die den Betrieb der Farbübertragungsinstruktion in zwei unterschiedlichen Ausführungsformen der vorliegenden Erfindung zeigen, und
8A–B Blockdiagramme sind, die die Farbwertregisterdatei in zwei unterschiedlichen Ausführungsformen der vorliegenden Erfindung darstellen.
Detaillierte Beschreibung der Ausführungsformen
1 – Computersystem
In 1 ist ein Computersystem 80 gezeigt, das einen dreidimensionalen (3D-) Grafikbeschleuniger gemäß der vorliegenden Erfindung beinhaltet. Wie gezeigt, weist das Computersystem 80 eine Systemeinheit 82 und einen Videomonitor oder eine Anzeigevorrichtung 84, die mit der Systemeinheit 82 verbunden ist, auf. Die Anzeigeeinrichtung 84 kann irgendeine von verschiedenen Typen von Anzeigemonitoren oder -einrichtungen sein. Verschiedene Eingabevorrichtungen können mit dem Computersystem verbunden sein, einschließlich einer Tastatur 86 und/oder einer Maus 88 oder einer anderen Eingabeeinrichtung. Anwendungssoftware kann auf dem Computer 80 ausgeführt werden, um die 3D-Grafikobjekte auf dem Videomonitor 84 anzuzeigen. Wie weiter unten beschrieben wird, beinhaltet der 3D-Grafikbeschleuniger in dem Computersystem 80 eine Beleuchtungseinheit, die eine erhöhte Leistung für die Behandlung von ankommenden Farbwerten von Polygonen zeigt, die verwendet werden, um dreidimensionale Grafikobjekte auf der Anzeigeeinrichtung 84 darzustellen.
2 – Computersystemblockdiagramm
In 2 ist ein vereinfachtes Blockdiagramm gezeigt, das das Computersystem von 1 illustriert. Elemente des Computersystems, die für ein Verständnis der vorliegenden Erfindung nicht notwendig sind, sind der Einfachheit halber nicht gezeigt. Wie gezeigt, beinhaltet das Compu tersystem 80 eine Hauptverarbeitungseinheit (CPU) 102, die mit einem Hochgeschwindigkeitsbus oder Systembus 104 verbunden ist. Ein Systemspeicher 106 ist ebenso vorzugsweise mit dem Hochgeschwindigkeitsbus 104 verbunden.
Der Hostprozessor 102 kann von irgendeinem von verschiedenen Typen von Computerprozessoren, Multiprozessoren und CPUs sein. Der Systemspeicher 106 kann von irgendeinem von verschiedenen Typen von Speicheruntersystemen sein, einschließlich Speichern mit wahlfreiem Zugriff und Massenspeichereinrichtungen. Der Systembus oder Hostbus 104 kann von irgendeinem von verschiedenen Typen von Kommunikations- oder Hostcomputerbussen sein für die Kommunikation zwischen den Hostprozessoren, CPUs und Speicheruntersystemen sowie auch aus spezialisierten Subsystemen bestehen. In bevorzugten Ausführungsformen ist der Hostbus 104 der UPA-Bus, was ein 64-Bit-Bus ist, der mit 83 MHz arbeitet.
Ein 3D-Grafikbeschleuniger 112 entsprechend der vorliegenden Erfindung ist mit dem Hochgeschwindigkeitsspeicherbus 104 verbunden. Der 3D-Grafikbeschleuniger 112 kann mit dem Bus 104 beispielsweise mit einem Kreuzschienenschalter oder mit einer anderen Busverbindungslogik verbunden sein. Es wird angenommen, daß verschiedene andere externe Vorrichtungen oder andere Busse mit dem Hochgeschwindigkeitsspeicherbus 104 verbunden sein können, wie im Stand der Technik gut bekannt ist. Es sei bemerkt, daß der 3D-Grafikbeschleuniger mit irgendeinem von verschiedenen Bussen, wie es gewünscht ist, verbunden sein kann. Wie gezeigt, ist der Videomonitor oder die Anzeigeeinrichtung 84 mit dem 3D-Grafikbeschleuniger 112 verbunden.
Der Hostprozessor 102 kann Information zu und von dem Grafikbeschleuniger 112 übertragen gemäß einem programmierten Eingabe-/Ausgabe-(I/O-) Protokoll über den Host 104. Alternativ dazu greift der Grafikbeschleuniger 112 entsprechend einem direkten Speicherzugriffsprotokoll (DMA) oder über ein intelligentes Busmastering auf das Speichersubsystem 106 zu.
Ein Grafikanwendungsprogramm, das zu einem Anwendungsprogrammierinterface (API), wie z. B. OpenGL, konform ist, erzeugt Befehle und Daten, die ein geometrisches Grundelement, wie z. B. ein Polygon, für die Ausgabe auf der Anzeigeeinrichtung 84 definieren. Wie von dem bestimmten verwendeten Grafikinterface definiert, können diese Grundelemente getrennte Farbeigenschaften für die Vorder- und Rückseitenflächen haben. Der Hostprozessor 102 überträgt diese Befehle und die Daten zu dem Speichersubsystem 106. Danach arbeitet der Hostprozessor 102 derart, daß er die Daten zu dem Grafikbeschleuniger 112 über den Hostbus 104 überträgt. Alternativ liest der Grafikbeschleuniger 112 die geometrischen Datenanordnungen unter Verwendung von DMA-Zugriffszyklen über den Hostbus 104 ein. In einer anderen Ausführungsform ist der Grafikbeschleuniger 112 mit dem Systemspeicher 106 durch einen direkten Anschluß, wie z. B. den Advanced Graphics Port (AGP), der von Intel Corporation entwickelt wurde, verbunden. Wie unten beschrieben wird, ist der Grafikbeschleuniger 112 mit Vorteil derart konfiguriert, daß er eine effizientere Mikrocodesteuerung erlaubt, was zu einer erhöhten Leistung für die Handhabung von ankommenden Farbwerten entsprechend den von dem Hostprozessor 112 erzeugten Polygonen führt.
3 – Grafikbeschleuniger
In 3 ist ein Blockdiagramm gezeigt, das den Grafikbeschleuniger 112 gemäß der bevorzugten Ausführungsform der vorliegenden Endung zeigt. Wie gezeigt, besteht der Grafikbeschleuniger 112 prinzipiell aus einem Befehlsblock 142, einem Satz von Gleitkommaprozessoren 152A–152F, einem Satz von Zeichenprozessoren 172A und 172B, einem Einzelbildpufferspeicher 100, der aus 3DRAM besteht, und einem Direktzugriffspeicher/Digital-zu-Analog-Wandler (RAM-DAC) 196.
Wie gezeigt ist, beinhaltet der Grafikbeschleuniger 112 einen Befehlsblock 142, der eine Schnittstelle mit dem Speicherbus 104 hat. Der Befehlsblock 142 stellt eine Schnittstelle zwischen dem Grafikbeschleuniger 112 und dem Hostbus 104 zur Verfügung und steuert den Datentransfer zwischen anderen Blöcken oder Chips in dem Grafikbeschleuniger 112. Der Befehlsblock 142 führt ebenso die Vorverarbeitung von Dreiecken und Vektordaten durch und führt die geometrische Datendekomprimierung durch.
Der Befehlsblock 142 stellt eine Schnittstelle zu einer Mehrzahl von Gleitkommablöcken 152 zur Verfügung. Der Grafikbeschleuniger 112 beinhaltet vorzugsweise bis zu sechs Gleitkommaprozessoren, die, wie gezeigt, mit 152A–152F bezeichnet sind. Die Gleitkommaprozessoren 152A–152F empfangen Highlevel-Zeichenbefehle und erzeugen graphische Grundelemente, wie z. B. Dreiecke, Linien usw. für das Darstellen dreidimensionaler Objekte auf dem Schirm. Die Gleitkommaprozessoren 152A–152F führen die Transformation, die Abschneidung bzw. das Clipping, die Oberflächenbestimmung, die Belichtung und die Einstelloperationen auf den empfangenen geometrischen Daten durch. Jeder der Gleitkommaprozessoren 152A–152F ist mit einem entsprechenden Speicher 153A– 153F verbunden. Die Speicher 153A–153F sind vorzugsweise 32k × 36-Bit SRAM und werden für die Mikrocodierung und die Datenspeicherung verwendet.
Jeder der Gleitkommablöcke 152A–F ist mit jedem der beiden Zeichenprozessoren 172A und 172B verbunden. Der Grafikbeschleuniger 112 beinhaltet vorzugsweise zwei Zeichenprozessoren 172A und 172B, obgleich eine größere oder geringere Anzahl verwendet werden kann. Die Zeichenprozessoren 172A und 172B führen die Schirmraumdarstellung der verschiedenen graphischen Grundelemente durch und arbeiten derart, daß sie die vervollständigten Pixel in der 3DRAM-Anordnung sequenzieren oder auffüllen. Die Zeichenprozessoren 172A und 172B fungieren ebenso als 3DRAM-Steuerchips für den Einzelbildpufferspeicher 100. Die Zeichenprozessoren 172A und 172B stellen gleichzeitig ein Bild in dem Einzelbildpufferspeicher 100 dar entsprechend einem Zeichenpaket, das von einem der Gleitkommaprozessoren 152A–152F empfangen wurde oder entsprechend einem Direktanschlußpaket, das von dem Befehlsprozessor 142 empfangen wurde. Jeder der Gleitkommablöcke 152A–F arbeitet vorzugsweise derart, daß er die gleichen Daten zu den beiden Zeichenblöcken 172A und 172B sendet. Mit anderen Worten sind auf beiden Sätzen von Datenleitungen, die von jedem Gleitkommablock 152 kommen, immer dieselben Daten vorhanden. Wenn somit der Gleitkommablock 152A Daten transferiert, transferiert der Gleitkommablock 152 dieselben Daten über beide Teile des FD-Busses zu den Zeichenprozessoren 172A und 172B.
Jeder der entsprechenden Zeichenblöcke 172A und 172B ist mit dem Einzelbildpufferspeicher 100 verbunden, wobei der Einzelbildpufferspeicher 100 vier Bänke von 3DRAM-Speicher 192A– B und 194A–B aufweist. Der Zeichenprozessor 172A ist mit den beiden 3DRAM-Bänken 192A und 192B verbunden und der Zeichenprozessor 172B ist mit den beiden 3DRAM-Bänken 194A bzw. 194B verbunden. Jede Bank weist drei 3DRAM-Chips auf, wie gezeigt ist. Die 3DRAM-Speicher oder -Bänke 192A–B und 194A–B bilden zusammen den Einzelbildpufferspeicher 100, der 1280 × 1024 × 96 Bits tief ist. Der Einzelbildpufferspeicher speichert die Pixel entsprechend den 3D-Objekten, die von den Zeichenprozessoren 172A und 172B dargestellt werden.
Jeder der 3DRAM-Speicher 192A–B und 194A–B ist mit einem RAMDAC (wahlfreier Zugriffsspeicher/Digital-/Analog-Wandler) 196 verbunden. Der RAMDAC 196 weist einen programmierbaren Videotakterzeuger und einen programmierbaren Pixeltaktsynthesizer zusammen mit Kreuzschienenschalterfunktion sowie auch traditionelle Farbnachschlagtabellen und dreifach-Video-DAC-Schaltkreise auf. Der RAMDAC ist wiederum mit dem Videomonitor 84 verbunden.
Der Befehlsblock wird vorzugsweise als ein Einzelchip implementiert. Jeder der Gleitkommaprozessoren 152 ist vorzugsweise als getrennter Chip implementiert. In der bevorzugten Ausführungsform können bis zu sechs Gleitkommablöcke oder Chips 152A–F beinhaltet sein. Jeder der Zeichenblöcke oder Prozessoren 172A und 172B weist ebenso vorzugsweise getrennte Chips auf. Für mehr Information über verschiedene Aspekte der Grafikbeschleunigerarchitektur der bevorzugten Ausführungsform schlage man bitte US-Patentdokument US-A-5,821,949 nach, mit dem Titel "Three-Dimensional Graphics Accelerator With Direct Data Channels for Improved Pertormance", und das im Zusammenhang stehende US-Patentdokument US-A-5,874,969 mit dem Titel "Three-Dimensional Graphics Accelerator Which Implements Multiple Logic Buses Using Common Data Lines for Improved Bus Communication", die beide am 1. Juli 1996 eingereicht wurden.
Wie oben beschrieben wurde, stellt der Befehlsblock 142 eine Schnittstelle mit dem Hostbus 104 zur Verfügung, um Grafikbefehle und Daten von der Host-CPU 102 zu empfangen. Diese Befehle und Daten (einschließlich Polygone mit sowohl Vorder- als auch Rückseitenflächeneigenschaften) werden wiederum zu den Gleitkommaprozessoren 152 für die Transformation, die Belichtung und die Einstellberechnungen weitergeleitet. Der allgemeine Betrieb dieser Gleitkommaprozessoren 152, die mit Vorteil für das verbesserte Handling von ankommenden Farbwerten konfiguriert sind, wird mit Bezug auf 4 beschrieben. Der L-Kernblock innerhalb der Gleitkommaprozessoren 152, der diese verbesserte Handhabungsfähigkeit bereitstellt, wird genauer unter Bezug auf die 5–8 beschrieben.
4 – Gleitkommagrozessorblockdiagramm
In 4 ist ein Blockdiagramm gezeigt, das einen der Gleitkommaprozessoren 152 entsprechend der bevorzugten Ausführungsform der vorliegenden Erfindung zeigt. Alle jeweiligen Gleitkommaprozessoren 152A–152F sind identisch und somit wird der Einfachheit halber hier nur einer beschrieben. Wie gezeigt, beinhaltet jeder der Gleitkommablöcke 152 drei funktionale Haupteinheiten oder Kernprozessoren; diese sind der F-Core 353, der L-Core 354 und der S-Core 356. Der F-Core-Block 353 ist derart angeschlossen, daß er Daten von dem CF-Bus, die von dem Befehlsblock 142 übertragen werden, empfängt. Der F-Core-Block 352 stellt Ausgangsdaten zu dem L-Core- Block 354 und dem S-Core 356 zur Verfügung. Der L-Core-Block 354 stellt ebenso Daten zu dem S-Core-Block 356 bereit. Der S-Core-Block 356 stellt Ausgangsdaten zu dem FD-Bus bereit.
Der F-Core-Block 352 führt alle gleitkommaintensiven Operationen durch einschließlich der Geometrietransformation, der Abschneideüberprüfung, der Seitenbestimmung, der perspektivischen Teilung und der Schirmraumumwandlung. Der F-Core-Block 352 führt ebenso das Clipping bzw. das Abschneiden durch, wenn dies erforderlich ist. In der bevorzugten Ausführungsform ist der F-Core-Block 352 vollständig programmierbar unter Verwendung eines 36-Bit-Mikrobefehlswortes, das in einem 32k-Wort-SRAM gespeichert ist.
Der L-Core-Block 354 führt die meisten Belichtungsberechnungen unter Verwendung eines auf dem Chip-RAM-basierten Mikrocodes durch. Der L-Core-Block 354 beinhaltet ebenso eine effiziente Dreifachwortkonstruktion für effizientere Beleuchtungsberechnungen. Diese Dreifachwortkonzentration arbeitet mit einem 48-Bit-Datenwort, das 16-Bit-Festkommawerte aufweist. Somit kann ein Befehl dieselbe Funktion auf allen drei Farbkomponenten (RGB) oder auf allen drei Komponenten einer Normalen (N_x, N_y und N_z) in einem Zyklus durchführen. Die Mathematikeinheiten, die in dem L-Core-Block 354 vorhanden sind, klemmen die Werte automatisch in die erlaubten Bereiche, was keine zusätzlichen Verzweigungen erfordert.
Der S-Core-Block führt die Einstellberechnungen für alle Grundelemente durch. Diese Einstellberechnungen beinhalten die Berechnungen der Abstände in mehreren Dimensionen von einem Vertex zu einem anderen und die Berechnungen der Steigungen entlang dieser Kante. Für Dreiecke werden die Steigung der Z-Tiefe, der Farbe und des UV (für Texturen) ebenso in Richtung einer Abtastzeile berechnet.
Wie gezeigt, beinhaltet jeder der Gleitkommablöcke 152 eine CF-Businterfacelogik 362, die mit dem CF-Bus verbunden ist. Jeder der Gleitkommablöcke 152 beinhaltet eine FD-Busintertacelogik 366, die eine Verbindung zu dem FD-Bus herstellt. Jeder Gleitkommablock 152 beinhaltet einen Bypassbus oder Datenpfad 364, der als Datentransferpfad durch einen entsprechenden Gleitkommablock 152 für den CD-Bus dient. Daten, die über den CD-Bus gesendet werden, d. h. die direkt zu dem FD-Bus gesendet werden, wandern auf dem Datentransferbus 364, was somit die Gleitkommalogik, die in dem Gleitkommablock 152 enthalten ist, umgeht.
Im allgemeinen können Daten, die dem Gleitkommablock 152 zur Verfügung gestellt werden, eines von drei Zielen haben; diese sind der F-Core-Block 352, der L-Core-Block 354 oder direkt aus dem FD-Bus, d. h. ein CD-Bustransfer. In der bevorzugten Ausführungsform weisen die Daten, die für den F-Core-Block 352 bestimmt sind 32-Bit-Worte einschließlich 32-Bit-IEEE-Gleitkommazahlen und anderer 32-Bit-Daten auf. Daten, die für den L-Core-Block 354 bestimmt sind, weisen 48-Bit-Worte auf, die 3-Bit-Festkommazahlen aufweisen.
Wie gezeigt, beinhaltet der Gleitkommablock 152 einen Gleitkomma-Eingangspufferspeicher (FI-Pufferspeicher) 372, der Daten von dem CF-Bus empfängt, die von dem Befehlsblock 142 bereitgestellt wurden. Der FI-Pufferspeicher 372 ist doppelt puffergespeichert und hält 32 32-Bit-Einträge in jedem Pufferspeicher. Das erste Wort, Wort Null, das in dem FI-Pufferspeicher 372 gespeichert ist, weist einen Opcode bzw. Befehlscode auf, der den F-Core-Block 352 darüber infor miert, welche Mikrocoderoutine für die empfangenen geometrischen Grundelemente eingeplant ist. Nur der Header bzw. die Kopfzeile und die X-, Y- und Z-Koordinaten werden diesem Pufferspeicher zur Verfügung gestellt, wenn die geometrischen Grundelemente transformiert und belichtet werden.
Der Gleitkommablock 152 beinhaltet ebenso einen F-Core-zu-L-Core-Pufferspeicher (FL-Pufferspeicher) 374. Der FL-Pufferspeicher 374 ist doppelt puffergespeichert und hält 16 16-Bit-Einträge in jedem Pufferspeicher. Der F-Core-Block 352 arbeitet derart, daß er drei F-Core-Worte in ein L-Core-Wort schreibt oder kombiniert, das dem FL-Pufferspeicher 374 zur Verfügung gestellt wird. Von der L-Core-Perspektive aus erscheint jeder Pufferspeicher in dem FL-Pufferspeicher 374 als fünf 48-Bit-Einträge. Während der Belichtungsoperationen werden drei X-, Y-, Z-Koordinaten von dem F-Core-Block 372 durch den FL-Pufferspeicher 374 zu dem L-Core-Block 354 gesendet. Diese drei X-, Y-, Z-Koordinaten werden verwendet, um die Augenrichtung zu berechnen.
Der Gleitkommablock 152 beinhaltet einen L-Core-Eingangsspeicher (LI-Pufferspeicher) 376, der Daten empfängt, die über den CF-Bus gesendet werden, die von dem Befehlsblock 142 bereitgestellt wurden, und stellt diese Daten dem L-Core-Block 354 zur Verfügung. Der LI-Pufferspeicher 376 weist fünf Pufferspeicher auf; jeder hiervon hält sieben 48-Bit-Einträge. Diese sieben 48-Bit-Einträge weisen drei Vertexnormalen, drei Vertexfarben und ein Wort mit drei alpha-Werten auf. Der FI-Pufferspeicher 372 und der LI-Pufferspeicher 376 bilden zusammen den Gleitkommablockeingangspufferspeicher.
Der Gleitkommablock 152 beinhaltet ebenso einen FLL-Pufferspeicher 378, der zwischen den F-Core-Block 352 und den L-Core-Block 354 geschaltet ist. Der FLL-Pufferspeicher 378 ist ein FIFO, der für das Übertragen der Belichtungs- und Abschwächungsfaktoren von dem F-Core-Block 352 zu dem L-Core-Block 354 verwendet wird. Diese Abschwächungsfaktoren weisen drei X-, Y-, Z-Positionswerte, drei Abschwächungswerte, drei Umgebungslichtwerte und ein Abschwächungsverschiebewort, das drei gepackte Werte enthält, auf. Ein FLF-Pufferspeicher 380 wird ebenso zwischen dem F-Core-Block 352 und dem L-Core-Block 354 bereitgestellt. Der FLF-Pufferspeicher ist ein bidirektionaler Pufferspeicher, der für das Übertragen von Daten zwischen dem F-Core-Block 352 und dem L-Core-Block 354 unter der Steuerung des F-Cores verwendet wird.
Ein L-Core-zu-S-Core-Pufferspeicher (LS-Pufferspeicher) 386 ist zwischen den L-Core-Block 354 und den S-Core-Block 356 geschaltet. Der LS-Pufferspeicher 386 ist doppelt puffergespeichert, wobei jeder Pufferspeicher vier 48-Bit-Worte hält.
Der Gleitkommablock 152 beinhaltet ebenso einen F-Core-zu-S-Core-Pufferspeicher (FS-Pufferspeicher) 384, der verwendet wird für das Übertragen von Daten von dem F-Core-Block 352 zu dem S-Core-Block 356. Der FS-Pufferspeicher weist fünf Pufferspeicher auf, die jeweils 32 32-Bit-Werte enthalten. Diese fünf Pufferspeicher sind derart konstruiert, daß sie zu den Pipelinestufen des L-Core-Blocks 354 passen, wobei diese die beiden FL-Pufferspeicher, die beiden LS-Pufferspeicher plus ein Grundelement sind, das in dem L-Core-Block 354 gespeichert werden kann. Daten, die von dem F-Core-Block 354 durch diesen Pufferspeicher zu dem S-Core-Block 356 übertragen werden, beinhalten einen Dispatchcode bzw. einen Zuteilungscode, der anzeigt, welche Mikrocodeprozedur in dem S-Core-Block 356 abläuft.
Schließlich beinhaltet der Gleitkommablock 152 einen S-Core-Ausgangspufferspeicher (SO-Pufferspeicher) 158, der zwischen S-Core-Block 356 und das FD-Businterface 366 geschaltet ist. Der SO-Pufferspeicher 158 sammelt Daten, die über den FD-Bus zu den entsprechenden Zeichenprozessoren 172A–172B zu senden sind. Der SO-Pufferspeicher 158 ist doppelt puffergespeichert und hält 32 32-Bit-Worte in jedem Pufferspeicher. Der SO-Pufferspeicher 158 hält bis zu zwei Grundelemente, die Festkommadaten in der Ordnung, die von den entsprechenden Zeichenprozessoren 172A–172B benötigt wird, aufweisen. Der S-Core-Block 356 leitet zusätzliche Statusinformation zusammen mit den Festkommadaten zu den Zeichenprozessoren 172. Beispielsweise wird ein Statusbit mit jedem Eintrag weitergeleitet, das anzeigt, ob oder ob nicht ein gegebenes Grundelemente das letzte einer Gruppe von in Beziehung stehenden Grundelementen ist. Der SO-Pufferspeicher 158 beinhaltet ebenso ein getrenntes Statusregister, das anzeigt, wie viele Worte gültig sind, so daß die minimale Anzahl von Zyklen verwendet wird, um die Daten über den Bus zu übertragen. Der SO-Pufferspeicher 158 weist den Gleitkommablockausgangspufferspeicher 158 auf.
5 – L-Core-Blockdiagramm
In 5 ist ein Blockdiagramm gezeigt, das den L-Core-Block 354 in jedem der Gleitkommaprozessoren 152 illustriert. Der L-Core-Block 354 weist eine Festkommaberechnungseinheit für das Durchführen von Belichtungsberechnungen auf. Wie dargestellt, beinhaltet der L-Core-Block 354 ein Modenregister 400, das derart angeschlossen ist, daß es Eingangsdaten von dem F-Core-Block 352 empfängt. Das Modenregister 400 beinhaltet ein Farbmodusfeld 402, ein Flächenbit 404 und ein "verwende unterschiedliche Vorder-/Rückseitenmaterialien"-Bit 406. Die Inhalte des Modenregisters 400 werden zu einer Belichtungssteuereinheit 460 geleitet, die ebenso Daten von dem LI-Pufferspeicher 376 sowie auch Steuersignale von einem Befehlssteuerlogikblock 470 empfängt. Die Belichtungssteuereinheit 460 ist derart konfiguriert, daß sie Farbdaten von dem LI-Pufferspeicher 376 zu einem LCC-Registerfile 420 leitet.
Zusätzliche Information wird zu dem L-Core-Block 354 über den FL-Pufferspeicher 374, den FLL-Pufferspeicher 378 und den FLF-Pufferspeicher 380 geleitet. Zusätzlich zu dem LCC-Registerfile 420 beinhaltet der L-Core-Block 354 ein LL- (Licht-) Registerfile 410 und ein LR-(Allzweck-) Registerfile 430. Operanden werden von den Registerfiles 410, 420 und 430 zu einem LA-Bus, einem LB-Bus und einem LC-Bus zu einem mehrfach akkumulierten Block 450 für die Beleuchtungsberechnungen geleitet. Diese Berechnungen werden unter der Steuerung des Befehlssteuerlogikblockes 470, der Mikrocode ausführt, der in einem SRAM 472 gespeichert ist, durchgeführt. Zusätzliche Beleuchtungsberechnungen werden in einem inversen Quadratwurzelblock (ISQRT) 462 und einer Leistungsfunktionseinheit 464 durchgeführt. Die Belichtungsergebnisse werden zu einem LD-Bus weitergeleitet und zu einem S-Core-Block 356 über den LS-Pufferspeicher 386 weitergeleitet.
Der L-Core-Prozessor 354 ist speziell konstruiert, um Belichtungsberechnungen durchzuführen. In der bevorzugten Ausführungsform führt der L-Core-Block 354 die meisten Belichtungsoperationen durch. Der F-Core-Block 354 führt Belichtungsberechnungen für komplexere Lichtquellen durch, was die Verwendung eines Allzweckgleitkommaprozessors erfordert, wie z. B. Punkt- und Spotlichtquellen.
In der bevorzugten Ausführungsform werden alle Berechnungen in dem L-Core-Block 354 unter Verwendung einer 16-Bit-Festkommamathematik, dreimal je Zeitpunkt durchgeführt. Die drei Werte in einem 48-Bit-Wort können entweder ein Triple, wie z. B. XYZ, Normale oder RGB, darstellen oder können einen Wert (z. B. einen alpha-Wert) für jeden der drei unterschiedlichen Vertices eines Dreiecks darstellen. Die Beleuchtungsberechnung, die vom L-Core 354 durchgeführt wird, verwendet keine vorvervielfältigten Materialfarbwerten mit anderen cachegespeicherten Beleuchtungsattributwerten. Dies erlaubt es dem Grafikbeschleuniger, Dreiecksnetze mit RGB-Farben je Vertex als eine hochqualitative Alternative zu der Textur- und Erhöhungsabbildung zu unterstützen. Im allgemeinen wird von den meisten Belichtungsoperationen erwartet, daß sie eine Farbveränderung per Vertex beinhalten. Während dies eine etwas gesteigerte Berechnung in dem L-Core 354 erfordert, wird diese vollständig von anderen Einheiten überdeckt (d. h. der L-Core ist immer noch schneller als sowohl F-Core als auch S-Core). Diese Veränderung macht es viel einfacher, die Semantik von OpenGL zu unterstützen, in der Farben sich bei jedem Vertex ohne Warnung und ohne irgendeinen effektiven Weg der Cachespeicherung ändern können.
Der L-Core 354 hat effiziente 16-Bit-Funktionseinheiten und führt ebenso die Modellraum-zu-Weltraum-Transformation auf Vertexnormalen durch. Der Befehlsblock 142 liefert Normalendaten zu dem Gleitkommaprozessor 152 als 48-Bit-Werte (drei 16-Bit-Komponenten), die bereits normalisiert sind. Die L-Core-Register beinhalten zwei 3 × 3-Normalentransformationsmatrizen, die jeweils als drei 48-Bit-Werte gespeichert sind. Die beiden Transformationsmatrizen werden verwendet, um linke und rechte Augentransformationen im Stereomodus durchzuführen.
Farben und Normalen werden von dem Befehlsblock 142 mittels des LI-Pufferspeicher 376 zu dem L-Core 354 übertragen. Die Beleuchtungsberechnungen werden in Antwort auf Mikrocodebefehle, die in dem SRAM 472 residieren, und unter der Steuerung der Befehlssteuerlogik 470 aufgrund eines Zuteilerwortes, das von dem F-Core-Block 352 eingeleitet wird, ausgeführt. Der L-Core-Befehlssatz beinhaltet keine Verzweigungsbefehle, so daß jeder Schritt der Beleuchtungsberechnungen zuende läuft, dann wird der nächste Schritt basierend auf den Inhalten des nächsten Zuteilerwortes gestartet.
Der L-Core 354 beinhaltet drei unterschiedliche Registerfiles zusätzlich zu den Eingangs- und Ausgangspufferspeichern. Die L-Register 410 enthalten die Werte für jedes von bis zu 32 Lichtern. Die LT-Register 440 spezifizieren, auf welches Licht zugegriffen wird, da nur auf ein Licht zu einem Zeitpunkt zugegriffen werden kann. Die Lichtwerte werden von dem F-Core 352 geladen und werden von dem L-Core 354 nicht modifiziert. Die LR-Register 430 werden als Allzweckregister für das Speichern von Zwischenwerten von den Belichtungsberechnungen verwendet. Die LCC-Register 420, die unter der Steuerung der Beleuchtungssteuereinheit 460 geladen wurden, halten die Materialeigenschaften oder die "gegenwärtigen Farb-" Werte für die Vertices des Grundelements und werden unten weiter erörtert.
Der L-Core-Block 354 beinhaltet einen Multiplizier-Summier-Block 450, einschließlich einer Einheit für jeden der drei 16-Bit-Werte in dem 48-Bit-Wort. Die Standardoperation von jeder der Multiplizier-Summier-Einheiten ist 48 Bits Eingabe und 48 Bits Ausgabe. Für die Skalarproduktberechnung gibt es nur ein 16-Bit-Ergebnis, so daß dieses Ergebnis in jedem der drei 16-Bit-Felder repliziert wird.
Der inverse Quadratwurzelblock (ISQRT) 462 wird bei der Normalisierung des Sichtpunktvektors verwendet. Der ISQRT-Block 462 empfängt 16 Bits von einer Skalarproduktberechnung und erzeugt ein 16-Bit-Ergebnis, das auf drei Werte in dem 48-Bit-Wort repliziert wird. Weiterhin beinhaltet der L-Core 354 ebenso eine Leistungsfunktionseinheit 464, die für die Berechnung von spiegelnden Stellen verwendet wird. Die Leistungsfunktionseinheit 464 nimmt ebenso 16 Bits von einer Skalarproduktberechnung auf und erzeugt ein 16-Bit-Ergebnis, das in drei Werte in dem 48-Bit-Wort repliziert wird. Die Leistungsfunktionseinheit 464 führt zwei Tabellennachschlagvorgänge durch und führt andere Berechnungen durch, um einen genauen Wert zu erzeugen. Das Ergebnis ist auf 0,5% genau oder auf ein am wenigsten signifikantes Bit einer 8-Bit-Farbe genau.
L-Core-Kommunikationspufferspeicher
Der L-Core 354 beinhaltet fünf unterschiedliche Pufferspeicher für die Kommunikation mit anderen Teilen des Chips. Der LI-Pufferspeicher 376 entspricht dem FI-Pufferspeicher 372 im F-Core-Block 354. Der LI-Pufferspeicher 376 wird verwendet für das Zugreifen auf ankommende Daten von dem Befehlsblock 142, die über den CF-Bus kommen. Der LI-Pufferspeicher 376 erscheint als sieben 48-Bit-Register und enthält drei Farben, drei Normalen und ein Wort, das die drei alpha-Werte enthält. Wie die FS-Register 384 im F-Core 352 weist der LI-Pufferspeicher 376 fünf Pufferspeicher auf, um mit den beiden FI-Pufferspeichern 372, den beiden FL-Pufferspeichern 374 plus dem einen Grundelement, das in dem F-Core 352 verarbeitet wird, zusammenzupassen.
Der FL-Pufferspeicher 374 wird verwendet, um die XYZ-Betrachtungspunktvektoren von dem F-Core 352 zu empfangen. Der FL-Pufferspeicher 374 wird ebenso verwendet, um abgeschnittene RGB-Farb- und alpha-Werte zu speichern, wenn dies notwendig ist. Der FLL FIFO 378 wird verwendet, um die Abschwächwerte für lokale Lichter weiterzuleiten. Diese Werte erfordern Gleitkommaberechnungen, die nur in dem F-Core 352 durchgeführt werden können. Wenn die Belichtungsberechnungen zu dem Punkt gelangen, wo der Abschwächungsfaktor für ein Licht benötigt wird, pausiert der L-Core 354, bis die Daten in dem FLL FIFO 378 verfügbar sind.
Der FLF-Pufferspeicher 380 ist für die Kommunikation zwischen dem L-Core und dem F-Core und nicht für den normalen Betrieb vorgesehen. Eine Laufzeitverwendung des FLF-Pufferspeichers 380 ist es, Belichtungswerte zurück zu dem L-Core 354 während des Clippings zu senden und für den F-Core, um sich die Leistungsfunktionslogik von dem L-Core 354 für die Verwendung mit Spotlichtern zu "leihen". Um dies zu tun, schreibt der F-Core die zwei Leistungsfunktionsparameter in den FLF-Pufferspeicher 380, unterbricht dann den L-Core und fordert an, daß die Berechnung durchgeführt wird. Wenn die Berechnungen vollständig sind, wird das Ergebnis zurück in den FLF-Pufferspeicher 380 plaziert und dem L-Core 354 wird erlaubt, fortzusetzen. Der F-Core 352 liest dann das Ergebnis aus seiner Seite des FLF-Pufferspeichers 380 aus. Der FLF-Pufferspeicher 380 wird ebenso für diagnostische Zwecke verwendet.
Der LS-Pufferspeicher 386 weist die Nur-Schreibe-Ausgangsregister auf, die verwendet werden, um Daten zu dem S-Core 356 für Einstellberechnungen zu senden. Nur Farb- und alpha-Werte werden über diese Schnittstelle gesendet. Für Standarddreiecke werden drei Farben und ein alpha-Wort (das drei Werte enthält) zu dem S-Core 356 gesendet. In der bevorzugten Ausführungsform weist der LS-Pufferspeicher 386 vier doppelt gepufferte Einträge auf.
6 – Handhabung von ankommenden Farbwerten
In 6 ist ein Flußdiagramm gezeigt, das ein Verfahren 500 für das Durchführen der verbesserten Handhabung von eingehenden Farbwerten darstellt gemäß einer Ausführungsform der vorliegenden Erfindung. Das Verfahren 500 beinhaltet zuerst einen Schritt 510, in dem eine Mehrzahl von Farbwerten in dem LI-Pufferspeicher 376 gespeichert werden. Jeder Eintrag in dem LI-Pufferspeicher 376 beinhaltet sieben 48-Bit-Einträge. Drei dieser Einträge spezifizieren die Rot-Blau-Grün-Farbkomponenten für jeden Vertex eines Dreiecks, das durch den Grafikbeschleuniger 112 darzustellen ist. Ein vierter Eintrag wird verwendet, um alpha-Werte zu speichern. Die Rot-Blau-Grün-Farben können entweder zu der vorderen oder zu der hinteren Fläche des Dreiecks oder zu beiden korrespondieren. Weiterhin können diese Farben spezifiziert sein, um für die Emissionslichtberechnungen, die Umgebungslichtberechnungen, die diffusen Lichtberechnungen, die spiegelnden Lichtberechnungen oder die Umgebungs-/diffusen Berechnungen bei Kompatibilität mit dem OpenGL-Standard zu verwenden.
In Schritt 520 wird ein Wert in das Modusregister 400 durch den F-Core-Block 352 geschrieben, der anzeigt, wie die Farbwerte in dem LI-Pufferspeicher 376 auf die Oberflächen eines ankommenden Dreiecks abgebildet werden. Wie unten beschrieben wird, werden die Farben in dem LI-Pufferspeicher 376 zu den LCC-Registern 420 in Übereinstimmung mit diesem Wert übertragen. Wie in 5 gezeigt ist, beinhaltet das Modusregister 400 ein Farbmodusfeld 402, ein Flächenbit 404 und ein verwende-unterschiedliche-Vorder-/Rückseitenmatertalien-Bit 406. Das Farbmodusfeld 402 wird verwendet, um zu bestimmen, ob die Farben in dem LI-Pufferspeicher 376 zu dem Abschnitt des LCC-Registerfiles 420 zu übertragen sind, das Vorderseitenmaterialfarben, Rückseitenmaterialfarben oder beides enthält. Zusätzlich kann das Modusfeld 402 ebenso anzeigen, daß die Farben in dem LI-Pufferspeicher 376 für ein gegebenes Dreieck nicht zu dem Registerfile 420 zu übertragen sind. In diesem Fall hat das Dreieck keine Farbwerte per Vertex und kann stattdessen einen globalen Farbwert verwenden, der für die Vorder- oder Rückseitenfläche spezifiziert ist. In einer anderen Ausführungsform kann ein Grundelement, das keine per-Vertex-spezifizierten Farben hat, eine Vorderseiten-/Rückseitenfarbe haben, die in einer vorherigen Stufe der Grafikpipeline des Beschleunigers 112 eingestellt wurde. Eine mögliche Abbildung des Farbmodusfeldes 402 ist unten in Tabelle 1 gezeigt:
Tabelle 1
Wenn somit Farbwerte für jeden Vertex eines Dreiecks im LI-Pufferspeicher 376 zu den LCC-Registern 420 übertragen werden sollen, schreibt die Steuerlogik in dem F-Core-Block 352 den geeigneten Farbmoduswert in das Farbmodusfeld 402 des Modusregisters 400 in Schritt 520.
In einem Schritt 524 stellt der F-Core-Block 352 die "faced-ness" bzw. die Flächenausrichtung des ankommenden Dreiecks ein, da typische Grafikstandards erlauben, daß Grundelemente entweder front-facing bzw. mit der Vorderseite nach vorne zeigend oder back-facing bzw. mit der Rückseite nach vorne zeigend sind. In einer Ausführungsform wird eine Flächenrichtung in das Flächenbit 404 codiert und verwendet unterschiedliche Vorder-/Rückseitenmatertalbits 406. Eine mögliche Codierung der beiden Bits ist in Tabelle 2 gezeigt:
Verwende unterschiedliche Vorder-/Rückseite Tabelle 2
Wie oben gezeigt ist, wird ein Dreieck als mit der Vorderseite nach vorne zeigend bestimmt, es sei denn, daß das Flächenbit 404 und das verwende-unterschiedliche-Vorder-/Rückseitenmaterial-Bit 406 beide gesetzt sind (in diesem Fall wird das Dreieck als nach hinten zeigend benannt). Ein Bit 406, das gelöscht ist, veranlaßt, daß die vorderen Farbwerte verwendet werden, ungeachtet des Flächenbitwertes 404, der für ein bestimmtes Dreieck gesetzt ist. Andere Mittel zum Codieren der Flächenrichtung sind in anderen Ausführungsformen des L-Core-Blockes 354 möglich.
Mit dem eingestellten Farbmodus und der eingestellten Flächenrichtung führt der L-Core-Block 354 einen übertrage-Farbbefehl in einem Schritt 530 durch. Wie in 6 gezeigt ist, weist der Schritt 530 Unterschritte 530A und 530B auf. In der bevorzugten Ausführungsform wird der übertrage-Farbe-Befehl in dem SRAM 472 als Mikrocode gespeichert und unter der Steuerung der Befehlssteuertogik 470 ausgeführt. Der übertrage-Farbe-Befehl setzt den Wert des Farbmodusfeldes 402 (auf den im Unterschritt 530A zugegriffen wird) ein, um die Farbwerte von dem LI-Pufferspeicher 376 zu dem LCC-Registerfile 420 in einem Unterschritt 530A über einen speziell angepaßten Datenpfad über die Beleuchtungssteuereinheit 460 zu bewirken.
In einer Ausführungsform (die in den 7A und 8A gezeigt ist) kann der übertrage-Farbe-Befehl 0, 3, 6 oder 12 LCC-Register speichern abhängig von dem Wert des Farbmodusfeldes 402. Wenn das Farbmodusfeld 402 anzeigt, daß keine Farben zu übertragen sind, werden die übertrage-Farbe-Befehle als noop-Befehl bzw. Null-Operations-Befehl ausgeführt und keine per-Vertex-Farben werden in das LCC-Registerfile 420 geladen. Wenn das Farbmodusfeld 402 derart eingestellt ist, daß entweder die vordere oder die hintere Fläche spezifiziert wird (jedoch nicht beide), werden drei LCC-Register geschrieben beginnend bei dem Offset, der in Tabelle 1 spezifiziert ist, es sei denn, daß der Umgebungs- und Diffusmodus ausgewählt wird. Jedes der drei 48-Bit-Felder, das die Rot-Blau-Grün-Farbe innerhalb des "Boden"-Eintrags im LI-Pufferspeicher 376 spezifiziert, wird in eine entsprechende Gruppe aus drei LCC-Registern geschrieben (wie in 8 gezeigt ist). Wenn der Umgebungs- und Diffusmodus aktiviert ist, werden die drei 48-Bit-Farbwertfelder in dem LI-Pufferspeicher 376 in sowohl die Umgebungs- als auch die Diffusgruppe aus Registern geschrieben. Wenn das Farbmodusfeld 402 spezifiziert, daß die Farben im LI-Pufferspeicher 376 zu der Vorderseite und der Rückseite eines Dreiecks korrespondieren, werden sechs LCC-Register geschrieben. Wenn beispielsweise der vordere und hintere Diffusmodus ausgewählt wird, werden die LCC-Register 6–8 für die Vorderseite geschrieben, während die Register 18–20 für die Rückseite mit denselben Werten geschrieben werden. Falls schließlich das Farbmodusfeld 402 den vorderen und hinteren Umgebungs- und Diffusmodus spezifiziert, werden 12 LCC-Register (3–8, 15–20) geschrieben. Jede Gruppe aus drei LCC-Registern, die Umgebungs- oder Diffusfarbwerte speichert, empfängt die Inhalte der drei Vertexfarbwerte in dem LI-Pufferspeicher 376. Der Schritt 530 wird detaillierter unter Bezug auf 7A beschrieben.
In einer anderen Ausführungsform der vorliegenden Erfindung (gezeigt in den 7B und 8B) ist das LCC-Registerfile 421 zusätzlich derart konfiguriert, daß es alpha-Blendingwerte für die Vorder- und Rückseitenflächen beinhaltet. Das Speichern der Emissions-, der Umgebungs-, Dif fus- und der Spiegelfarben arbeitet ähnlich der oben beschriebenen Ausführungsform. Die vorderen und/oder hinteren alpha-Werte werden gespeichert, wenn die diffuse Beleuchtung ausgewählt wird.
In einem Schritt 540 werden Belichtungsoperationen durch den L-Core-Block 354 durchgeführt unter Verwendung der Farbwerte, die von dem LCC-Registerfile 420 übertragen werden. Im Unterschritt 540 wird auf ein Modusregister 400 zugegriffen, um die Flächenrichtung des gegenwärtigen Grundelements zu bestimmen. Wie oben beschrieben wurde, wird der Flächenrichtungswert durch das Flächenbit 404 und das benutze-unterschiedliche-Vorderseiten-/Rückseitenmaterialien-Bit 406 in einer Ausführungsform codiert.
In dem Unterschritt 540B werden die Belichtungsoperationen für das Eingangsdreieck unter Verwendung der Farbwerte für die Oberfläche, die durch die Flächenrichtung spezifiziert ist, die im Modenregister 400 eingestellt ist, durchgeführt. In einer Ausführungsform ist nur ein Teil der Werte in dem LCC-Registerfile 420 für die Belichtungsberechnungseinheit während eines gegebenen Zyklus verfügbar. In dieser Ausführungsform bestimmt die Flächenrichtung des Eingangsdreiecks, welche Hälfte des Registers 420 ansprechbar ist. Wenn beispielsweise ein Dreieck als nach hinten zeigend spezifiziert wird, werden die Werte in der oberen Hälfte des LCC-Registerfiles 420 als Eingangsfarbwerte für das Bewirken der Belichtungsberechnungen verwendet.
Da das Farbmodusfeld 402 (das den Farbübertragungsbefehl leitet) typischerweise eingestellt wird, bevor ein Eingangsdreieck von dem L-Core-Block 354 empfangen wird, können die Farbwerte, die von dem Farbübertragungsbefehl gespeichert werden, nicht tatsächlich verwendet werden bei der Durchführung der Belichtungsberechnungen. Man nehme beispielsweise an, daß das Farbmodusfeld 402 eingestellt wird, um anzuzeigen, daß die Farbwerte in dem LI-Pufferspeicher 376 zu den Vorderseiteneigenschaften korrespondieren. Die Farbwerte (und üblicherweise der alpha-Wert) werden dann zu einem Abschnitt des LCC-Registerfiles 420 übertragen, der die Vorderseitenfarbeigenschaften speichert. Wenn das Eingangsdreieck empfangen wird, können jedoch die Bits 404 und 406 eine nach hinten zeigende Richtung spezifizieren. Die Vorderseiteneigenschaften, die übertragen wurden, werden somit nicht für die gegenwärtige Belichtungsberechnung verwendet. Während diese Entkopplung des Farbübertragungsbefehls von der Bestimmung der Flächenrichtung einige nicht notwendige Übertragungen zu den Registern 420 verursachen kann, führt die Implementierung insgesamt zu einer effizienteren Handhabung von ankommenden Farbwerten.
Da der Farbübertragungsbefehl eine Referenz auf das Modusregister 400 beinhaltet (das den Zieloffsetwert in dem LCC-Registerfile 420 bestimmt), kann eine Mikrocoderoutine für alle Variationen von ankommenden Farbeigenschaften verwendet werden. Das Speichern im SRAM 472 wird somit eingespart und die Leistung wird mit Vorteil erhöht, da die Steuerhardware nicht auf viele unterschiedliche Übertragungsroutinen optimiert werden muß.
Es sei erwähnt, daß in einer Ausführungsform eine Anzahl von LR-Registern 430 ebenso für entweder Vorderseiten- oder Rückseiteneigenschaften bestimmt sein kann. Beispielsweise können in dem XGL API ein Spiegelexponent und Umgebungs-, Diffus- und Spiegelfarben für sowohl die Vorder- als auch Rückseiten eines Polygons spezifiziert werden. Vier LR-Register 430 können dafür bestimmt sein, diese Vorderseiteneigenschaften während der Belichtungsberechnungen zu speichern, wobei andere vier Register dafür bestimmt sind, die entsprechenden Rückseiteneigenschaften zu speichern. Wie bei dem LCC-Registerfile 420 können diese vordere und hintere Registergruppe automatisch ausgewählt werden entsprechend der Werte des Flächenbits 404 und des verwende-unterschiedliche-Vorder-/Rückseitenmaterialien-Bit 406.
7A und 7B – Farbübertragungsbefehl
In 7A ist eine Zustandsmaschine 600 gezeigt, die den Betrieb einer Ausführungsform des Farbübertragungskommandos darstellt, das in Schritt 530 des Verfahrens 500 ausgeführt wird. Die Zustandsmaschine 600 zeigt einen Übergang zwischen verschiedenen Zuständen in Antwort auf den Empfang eines Taktsignals und geeignete Eingangssignale. Die Steuerlogik im L-Core-Block 394 verbleibt im Leerlaufzustand 604, bis auf das Farbübertragungskommando getroffen wird. In Antwort auf den Wert des Farbmodusfeldes 402 geht die Zustandsmaschine 600 entweder in den Zustand 608 (speichere Vorderseite oder Vorderseite/Rückseite) oder in den Zustand 632 (speichere Rückseite). Der vordere oder hintere Abschnitt des LCC-Registerfiles 420 wird ebenso in Übereinstimmung mit dem Farbmodusfeld 402 ausgewählt.
Wenn das Farbmodusfeld 402 einen Frontfarbmodus spezifiziert, speichert der L-Core-Block 354 die Farbwerte von dem LI-Pufferspeicher 376 für die Vertices 1, 2 und 3 in den Zuständen 608, 612 und 616. Im Zustand 660 geht die Zustandsmaschine 600, wenn das Farbmodusfeld 404 einen Umgebungs-/Diffusmodus anzeigt, in den Zustand 620 und speichert diffuse Farbwerte für die drei Vertices in den Zuständen 620, 624 und 628. Die Zustandsmaschine kehrt dann in den Leerlaufzustand 604 zurück.
Wenn das Feld 402 einen Vorder-/Rückseitenfarbmodus spezifiziert, geht die Zustandsmaschine durch die Zustände 608, 612 und 616. In Zustand 616 werden, wenn das Farbmodusfeld 402 einen Umgebungs-/Diffusmodus anzeigt, die Diffusfarbwerte für jeden Vertex in den Zuständen 620, 624 und 628 gespeichert. Da der Vorderseiten-/Rückseitenmodus spezifiziert wird, geht die Zustandsmaschine 600 dann in die Zustände 632, 636 und 640 und speichert die Rückseitenfarbwerte. Die Zustandsmaschine 600 geht direkt von dem Zustand 616 in die Zustände 632, 636 und 640 über, wenn der Umgebungs-/Diffusmodus nicht spezifiziert ist. Von dem Zustand 640 geht die Zustandsmaschine 600 in den Zustand 604 oder 644, abhängig davon, ob der Umgebungs-/Diffusmodus angezeigt ist. Sobald sie im Zustand 644 ist, werden die Rückseitendiffusfarbwerte für jedes Vertex in den Zuständen 644, 648 und 652 gespeichert. Von dem Zustand 620 geht die Zustandsmaschine 600 erneut in den Leerlaufzustand 604 über.
Wenn das Farbmodusfeld 402 einen Rückseitenfarbmodus spezifiziert, tritt die Zustandsmaschine 600 nacheinander in die Zustände 632, 636 und 640 ein und speichert die Rückseitenfarbwerte für die Vertices 1, 2 und 3. Von dem Zustand 640 geht die Zustandsmaschine 600 in den Leerlaufzustand 604, es sei denn, der Umgebungs-/Diffusmodus wird spezifiziert. In diesem Fall zykelt die Zustandsmaschine 600 durch die Zustände 644, 648 und 652 und speichert die Rücksei tendiffusfarbwerte. Von dem Zustand 652 tritt die Zustandsmaschine 600 zurück in den Leerlaufzustand 604.
In 7B wird eine Zustandsmaschine 700 gezeigt, die den Betrieb des Farbübertragungskommandos in einer alternativen Ausführungsform der vorliegenden Erfindung zeigt, in der alpha-Werte für sowohl die vorderen als auch hinteren Oberflächen unterstützt werden. Die Zustandsmaschine 700 arbeitet ähnlich wie die Zustandsmaschine 600 mit den zusätzlichen Zuständen 630 und 656. Die Zustandsmaschine 700 beinhaltet ebenso einen anderen Übergang von dem Zustand 616. Wie gezeigt, geht, wenn der Diffusmodus spezifiziert wird, die Zustandsmaschine 700 von dem Zustand 616 in den Zustand 630 über, in dem die alpha-Komponente der Vorderseite gespeichert wird. Von dem Zustand 630 aus setzt der Betrieb entweder zu dem Leerlaufzustand 604 oder zu dem Zustand 632 fort, abhängig davon, ob der Vorder-/Rückseitenmodus spezifiziert ist. In ähnlicher Weise beinhaltet der Zustand 640 in der Zustandsmaschine 700 ebenso einen neuen Übergang. In Zustand 640, falls der Diffusmodus eingestellt ist, geht die Zustandsmaschine 700 in den Zustand 646 über, in dem der Rückseiten-alpha-Wert in dem LCC-Registerfile 421 gespeichert wird. Von dem Zustand 646 kehrt die Zustandsmaschine 700 in den Leerlaufzustand 604 zur Vorbereitung des nächsten Farbübertragungskommandos zurück.
8A und 8B – LCC-Registerfile
In 8A ist eine Ausführungsform eines Farbregisterfiles, das LCC-Registerfile 420, gezeigt. Wie dargestellt, ist das LCC-Registerfile 420 in zwei Registersätze organisiert: LCCO-LCC11 (vorne) und LCC12-LCC23 (hinten). Jeder Registersatz ist in vier Gruppen aus drei Registern unterteilt. Die vier Gruppen entsprechen den Belichtungsmodi, die im OpenGL-Standard unterstützt werden: Emission, Umgebung, diffus und spiegelnd. Die drei Register innerhalb jeder Gruppe entsprechen den Farbwerten bei jedem der drei Vertices des zu verarbeitenden Dreiecks. Wie oben beschrieben wurde, werden die Farbwerte in dem LCC-Registerfile 420 durch das Farbübertragungskommando gespeichert, wie durch die Werte des Farbmodusfeldes 402 im Modusregister 400 spezifiziert ist. Auf die Register 420 wird dann von der Belichtungseinheitshardware in Übereinstimmung mit der Flächenrichtung des Eingangsdreiecks (wie es durch die Bits 404 und 406 bestimmt wird) zugegriffen. Die Unterstützung von unterschiedlichen Vertexfarben für ein Dreieck und unterschiedlichen Farben für jeden Belichtungsmodus auf einer per-Vertex-Basis erlaubt, daß eine anspruchsvollere Belichtung durchgeführt wird, was zu einem größeren visuellen Realismus führt.
In 8B ist eine andere Ausführungsform des Farbregisterfiles, LCC-Register 421, gezeigt. Wie dargestellt, ist das LCC-Registerfile 421 ähnlich wie das LCC-Registerfile 420 organisiert mit der Hinzufügung eines Registers für einen Vorderseiten-alpha-Wert (LCC12) und für einen Rückseiten-alpha-Wert (LCC25). Das Registerfile 420 ist in eine vordere Hälfte und eine hintere Hälfte organisiert, wobei jede Hälfte in vier Gruppen aus drei Registern plus das alpha-Wert-Register unterteilt ist. Die Hinzufügung der alpha-Komponente in dieser Ausführungsform erlaubt eine noch realistischere Darstellung eines Objekts durch Transparenzbelichtungsberechnungen.

Claims

Verfahren zum Betreiben einer Beleuchtungseinheit eines 3D-Grafikbeschleunigers (112) für das Durchführen von Beleuchtungsoperationen auf einem Polygon, wobei das Verfahren aufweist: Empfangen (510) einer Mehrzahl von Eingangsfarbwerten, die dem Polygon entsprechen, Empfangen (520) eines Farbmoduswertes, der eine Art und Weise anzeigt, in der die Mehrzahl von Eingangsfarbwerten bei der Durchführung der Beleuchtungsoperationen auf dem Polygon, benutzt wird, Übertragen (530) der Mehrzahl von Eingangsfarbwerten in ein Farbwertregisterfile der Beleuchtungseinheit (354), wobei die Mehrzahl von Eingangsfarbwerten an geeigneten Orten innerhalb des Farbwertregisterfiles gemäß dem Farbmoduswert abgelegt werden, und Erzeugen (540) von Ausgangsfarbwerten für das Polygon unter Verwendung eines oder mehrerer der Mehrzahl von Farbeingangswerten, die in dem Farbwertregisterfile in Übereinstimmung mit dem Moduswert abgelegt sind.
Verfahren nach Anspruch 1, wobei der Farbmoduswert anzeigt, ob die Mehrzahl von Eingangsfarbwerten zu einer Vorderseite des Polygons, einer Rückseite des Polygons oder zu beiden Seiten des Polygons korrespondiert.
Verfahren nach Anspruch 1 oder Anspruch 2, wobei das Farbwertregisterfile eine erste Mehrzahl von Speicherorten für das Ablegen von Farbwerten einer Vorderseite des Polygons und eine zweite Mehrzahl von Speicherorten für das Ablegen von Farbwerten einer Hinterseite des Polygons beinhaltet.
Verfahren nach einem der vorherigen Ansprüche, wobei der Farbmoduswert einen der Mehrzahl von Beleuchtungsmodi anzeigt für das Durchführen der Beleuchtungsoperationen.
Verfahren nach Anspruch 4, wobei die Mehrzahl von Beleuchtungsmodi aus der Gruppe ausgewählt werden, die besteht aus: (i) Emissionsmodus, (ii) Umgebungsmodus, (iii) unscharfer Modus, (iv) Spiegelmodus und (v) Umgebungs-/Diffusmodus.
Verfahren nach Anspruch 4, wobei das Farbwertregisterfile eine Mehrzahl von Speicherplätzen für jeden der Mehrzahl von Beleuchtungsmodi aufweist.
Verfahren nach einem der vorherigen Ansprüche, wobei jeder der Mehrzahl von Eingangsfarbwerten zu einem einer Mehrzahl von Vertices des Polygons korrespondiert.
Verfahren nach einem der vorherigen Ansprüche, wobei jeder der Mehrzahl von Eingangsfarbwerten einen oder mehrere Farbkomponentenwerte beinhaltet.
Verfahren nach einem der vorherigen Ansprüche, das weiterhin aufweist das Ablegen des Farbmoduswertes in einem Modusregister.
Verfahren nach Anspruch 9, wobei das Übertragen das Durchführen einer Abfolge von Programmbefehlen beinhaltet, wobei die Abfolge von Programmbefehlen ausführbar ist, um auf den Farbmoduswert innerhalb des Modusregisters zuzugreifen, um zu bestimmen, wo die Mehrzahl von Farbeingangswerten innerhalb des Farbwertregisterfiles abzulegen ist.
Verfahren nach einem der vorherigen Ansprüche, das weiterhin aufweist das Ablegen eines Flächenmoduswertes in einem Modusregister, wobei der Flächenmoduswert anzeigt, wie die Mehrzahl von Farbeingangswerten bei der Erzeugung der Ausgangsfarbwerte benutzt wird.
Verfahren nach Anspruch 11, wobei das Erzeugen der Ausgangsfarbwerte das Zugreifen auf den Flächemoduswert in dem Modusregister beinhaltet, um zu bestimmen, ob die Mehrzahl von Farbeingangswerten mit einer Vorderseite des Polygons, einer Rückseite des Polygons oder beiden Seiten des Polygons verknüpft sind.
Verfahren nach einem der vorherigen Ansprüche, wobei das Polygon in einer Mehrzahl von Polygonen beinhaltet ist, die ein 3D-Grafikobjekt darstellen.
3D-Grafikbeschleuniger (112) für das Durchführen von Beleuchtungsoperationen auf einem Polygon, der aufweist: eine Beleuchtungseinheit (354), die aufweist: einen Eingangspufferspeicher (376), der derart verbunden ist, daß er eine Mehrzahl von Eingangsfarbwerten, die dem Polygon entsprechen, empfängt, ein Modusregister (400), das derart angeschlossen ist, daß es einen Farbmoduswert empfängt, der anzeigt, wie die Mehrzahl von Eingangsfarbwerten bei dem Durchführen der Beleuchtungsoperationen auf dem Polygon verwendet werden soll, wobei das Modusregister derart konfiguriert ist, daß es den Farbmoduswert in einem Farbmoduswertfeld ablegt, ein Farbwertregisterfile (420), das mit dem Eingangspufferspeicher gekoppelt ist, wobei das Farbwertregisterfile derart konfiguriert ist, daß es Farbinformation entsprechend dem Polygon ablegt, eine Übertragungseinheit, die mit dem Eingangspufferspeicher und dem Modusregister verbunden ist, wobei die Steuereinheit derart konfiguriert ist, daß sie auf den Farbmoduswert in dem Modusregister zugreift, und wobei die Steuereinheit derart konfiguriert ist, daß sie die Mehrzahl von Eingangsfarbwerten zu geeigneten Speicherstellen innerhalb des Farbwertregisterfiles gemäß dem Farbmoduswert überträgt, und wobei die Beleuchtungseinheit derart konfiguriert ist, daß sie Beleuchtungsberechnungen auf dem Polygon durch Verwendung von einem oder mehreren der Mehrzahl von Eingangsfarbwerten, die in dem Farbwertregisterfile abgelegt sind, durchführt.
Grafikbeschleuniger nach Anspruch 14, wobei der Farbmoduswert anzeigt, ob die Mehrzahl von Eingangsfarbwerten einer Vorderseite des Polygons, einer Rückseite des Polygons oder beiden Seiten des Polygons entspricht.
Grafikbeschleuniger nach Anspruch 14 oder Anspruch 15, wobei das Farbwertregisterfile eine erste Mehrzahl von Speicherstellen für das Ablegen von Farbwerten einer Vorderseite des Polygons und eine zweite Mehrzahl von Speicherstellen für das Ablegen von Farbwerten einer Rückseite des Polygons aufweist.
Grafikbeschleuniger nach einem der Ansprüche 14 bis 16, wobei der Farbmoduswert einen Modus einer Mehrzahl von Beleuchtungsmodi für das Durchführen der Beleuchtungsoperationen anzeigt.
Grafikbeschleuniger nach Anspruch 17, wobei die Mehrzahl von Beleuchtungsmodi aus der Gruppe ausgewählt wird, die besteht aus: (i) Emissionsmodus, (ii) Umgebungsmodus, (iii) Diffusmodus, (iv) Spiegelmodus und (v) Umgebungs-/Diffusmodus.
Grafikbeschleuniger nach Anspruch 17 oder Anspruch 18, wobei das Farbwertregisterfile eine Mehrzahl von Speicherplätzen für jeden der Mehrzahl von Beleuchtungsmodi beinhaltet.
Grafikbeschleuniger nach einem der Ansprüche 14 bis 19, wobei jeder der Mehrzahl von Eingangsfarbwerten zu einem einer Mehrzahl von Vertices des Polygons korrespondiert.
Grafikbeschleuniger nach einem der Ansprüche 14 bis 20, wobei jeder der Mehrzahl von Eingangsfarbwerten einen oder mehrere Farbkomponentenwerte beinhaltet.
Grafikbeschleuniger nach einem der Ansprüche 14 bis 21, wobei das Übertragen das Durchführen einer Abfolge von Programmbefehlen beinhaltet, wobei die Abfolge von Programmbefehlen ausführbar ist, um auf den Farbmoduswert innerhalb des Modusregisters zuzugreifen, um zu bestimmen, wo die Mehrzahl von Farbeingangswerten innerhalb des Farbwertregisterfiles abgelegt wird.
Grafikbeschleuniger nach einem der Ansprüche 14 bis 22, der weiterhin aufweist das Ablegen eines Flächenmoduswertes in dem Modusregister, wobei der Flächenmoduswert anzeigt, wie die Mehrzahl von Farbeingangswerten bei der Erzeugung der Ausgangsfarbwerte verwendet wird.
Grafikbeschleuniger nach Anspruch 23, wobei die Beleuchtungseinheit derart konfiguriert ist, daß sie auf den Flächenmoduswert in dem Modusregister zugreift, um zu bestimmen, ob die Mehrzahl von Farbeingangswerten mit einer Vorderseite des Polygons, einer Rückseite des Polygons oder mit beiden Seiten des Polygons verknüpft ist.
Grafikbeschleuniger nach einem der Ansprüche 15 bis 24, wobei das Polygon in einer Mehrzahl von Polygonen aufgenommen ist, die ein 3D-Grafikobjekt darstellen.
Grafisches Untersystem, das eine Beleuchtungseinheit eines 3D-Grafikbeschleunigers (112) beinhaltet, das derart konfiguriert ist, daß es Beleuchtungsoperationen auf einem Polygon durchzuführen, wobei die Beleuchtungseinheit (354) aufweist: eine Farbwerte empfangende Einrichtung für das Empfangen einer Mehrzahl von Eingangsfarbwerten entsprechend dem Polygon, eine Farbmodusempfangseinrichtung für das Empfangen eines Farbmoduswertes, der eine Art und Weise anzeigt, in der die Mehrzahl von Eingangsfarbwerten bei der Durchführung der Beleuchtungsoperationen auf dem Polygon verwendet wird, eine Übertragungseinrichtung für das Übertragen der Mehrzahl von Eingangsfarbwerten in einen Farbwertregisterfile der Beleuchtungseinheit (354), wobei die Mehrzahl von Eingangsfarbwerten in geeigneten Speicherstellen innerhalb des Farbwertregisterfiles abgelegt werden gemäß dem Farbmoduswert und eine Farbausgangserzeugungseinrichtung für das Erzeugen von Ausgangsfarbwerten für das Polygon unter Verwendung von einem oder mehreren der Mehrzahl von Eingangsfarbwerten, die in dem Farbwertregisterfile in Übereinstimmung mit dem Moduswert abgelegt sind.