-
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 (Nx, Ny und Nz) 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:
-
-
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.