Aktuelle Grafikleistungen

Transkript

1 Aktuelle Grafikleistungen Alexander Hötzendorfer 3. Juli

2 Inhaltsverzeichnis 1 Einleitung 3 2 Aktuelle Techniken HDR-Lighting Tessellation Aufbau der Rendering-Pipeline 7 4 Shader Vertex-Shader Geometry-Shader Pixel-Shader Unified Shader ATIs R600 & nvidias G Stream-Processing-Units Latenzminimierung durch Thread-Aufschub Hierarchical-Z + Re-Z MSAA und Tent-Filter bzw. CSAA Ausblick 18 2

3 1 Einleitung Die Leistungen heutiger Grafikkarten sind sehr eindrucksvoll, bedenkt man dass Grafikkarten an sich noch gar nicht so sehr alt sind. Ursprünglich dafür eingesetzt den Prozessor bei Spielen zu entlasten haben sie mittlerweile auch schon im Betriebssystem selbst Aufgaben in Form von 3D-Effekten erhalten. Was heutige Grafikkarten jedoch in Spielen zu leisten im Stande sind übertrifft selbst aktuelle CPUs. Angefangen von 3D-Transformation über Floating-Point-Berechnungen bis hin zu beeindruckenden Lichteffekten aller Art. Im Folgenden sollen sowohl einige Techniken vorgestellt werden, als auch gezeigt werden, welche Neuerungen in den aktuellen Grafikkarten zu finden sind. 2 Aktuelle Techniken 2.1 HDR-Lighting Die Bilder, die man standardmäßig auf Monitoren sieht, besitzen nur eine Low Dynamic Range (LDR). D. h. dass der Helligkeitsbereich nicht die gleiche Anzahl Abstufungen aufweist, die das menschliche Auge wahrnehmen kann. Was die Anzahl der Farben angeht, sind heutige Monitore dem menschlichen Auge zwar überlegen, aber bei Helligkeitsabstufungen erreicht das menschliche Auge ein Verhältnis von bis zu :1. Demgegenüber steht ein maximales Verhältnis von 1.000:1 bei heutigen Monitoren. Das aber bei weitem noch größere Problem liegt hierbei in der Berechnung der Helligkeitsstufen, die bei LDR mittels Integer-Werten durchgeführt werden, also maximal 256 Werte annehmen kann (pro Farbkanal). Hier setzt nun das High Dynamic Range Lighting an, indem pro Farbkanal eine 16-bit floating-point Zahl benutzt wird. Um die resultierenden Abstufungen besser vergleichen zu können nimmt man die sog. Dynamik zuhilfe; diese berechnet sich indem man den größtmöglichen durch den kleinstmöglichen Wert teilt. Der Anschaulichkeit wegen nimmt man hiervon dann noch den 10er Logarithmus. Im Falle von 8-bit (Integer-)Zahlen ergibt sich dann: log = log = 24 db Dieser Wert erscheint sehr klein, da das menschliche Auge eine Dynamik von rund 140 db bietet. Benutzt man nun 16-bit floating-point Zahlen ist der Bereich immerhin schon größer: 1 Bit wird für das Vorzeichen benutzt; der Exponent erhält 5 Bit, kann also 2 5 = 32 Werte darstellen, wovon aber noch 2 Spezialfälle abgezogen werden müssen (Null und Not A Number), somit ergibt sich ein minimaler Exponent von 2 0 = 1 und ein maximaler von 2 3 0; für die Mantisse bleiben noch 10 Bit übrig, die einen Wert zwischen 1,000 und 1,999 darstellen können. 3

4 Damit ergibt sich die Dynamik zu: log = log = 93 db Man sieht dass dieser Wert bereits deutlich über dem Dynamikwert von Integer-Zahlen liegt, jedoch erreicht auch dieser Wert noch nicht die von der DirectX-Spezifikation geforderten 96 db. Dies lässt sich aber durch die Hinzunahme von Denorm-Support erreichen. Dabei ist der kleinste Wert der Mantisse um = 1024 mal kleiner, wodurch die Dynamik entsprechend anwächst: log = log = 123 db Dieser Wert kommt der Dynamik des Auges schon deutlich näher und ist für heutige Monitore somit sehr gut akzeptierbar. Das größere Problem ist hier wie bereits erwähnt, das geringe Kontrastverhältnis der Monitore, das z. B. über Tone-Mapping gelöst wird, indem man versucht die Werte relativ zueinander auf die möglichen Werte des Montiors zu übertragen. Dadurch ergibt sich für die Szene eine objektivere Darstellung, die nicht länger von dem aufnehmendem Gerät abhängig ist. Abbildung 1: Sichtbarkeit aller Helligkeitsbereiche 4

5 Eine weitere Mo glichkeit zur Erstellung von HDR-Bildern aus LDR-Bildern ist die, bei der man mehrere Bilder der gleichen Szene mit verschiedenen Belichtungen aufnimmt. Dadurch erreicht man eine bessere Verteilung u ber das gesamte Farbspektrum hinweg. [1] Abbildung 2: LDR im Vergleich zu HDR 2.2 Tessellation Mit Tessellation bezeichnet man die Unterteilung eines Polygons in mehrere, kleinere Polygone. Diese Technik wurde zuerst in der Xbox 360 eingefu ht und kam mit der letzten Grafikkartengeneration nun auch auf den PC. Tessellation wird verwendet, um aus Low-Polygon-Modellen detailreiche Polygonmodelle zu erstellen, indem die gewu nschten Bereiche mehrere Male hintereinander unterteilt werden; bei heutigen Grafikkarten ist dies bis zu 15 mal mo glich. Dabei kann auch ein Modell verschieden stark unterteilt werden. Mo chte man sehr feine Gesichtszu ge, so wa hlt man hier eine ho here Anzahl an Bearbeitungen als an flacheren Partien, wie beispielsweise den Armen. Nachdem die Unterteilung dann abgeschlossen ist wendet man gewo hnlich noch eine Displacement-Map auf das fertige Modell an, um anschließend dann die Texturen aufzulegen. Ein weiterer Vorteil fu r den Grafik-Programmierer ist die einfachere Handhabung der Objekte, da diese in der Rohform weniger komplex sind, als High-PolygonModelle. Auch auf Seiten der Geschwindigkeit gibt es Vorteile, da es eine spezielle Hardware-Einheit gibt, die die Unterteilung vornimmt und somit den Geometry-Shader entlastet. 5

6 Abbildung 3: Tessellation eines Low-Polygon-Modells Bei großen Landschaftszenen kann die Technik ihre Flexibilität dann richtig ausspielen: Die Objekte in unmittelbarer Nähe werden stärker unterteilt um realer auszusehen, die Objekte die sich näher am Horizont befinden werden nur ganz leicht verfeinert, da diese deutlich kleiner sind und es kaum auffällt, wenn diese weniger Details besitzen. [2][8] Abbildung 4: Stärkere Unterteilung der Lippen, als des Kinns 6

7 3 Aufbau der Rendering-Pipeline Das untenstehende Bild zeigt von oben nach unten den Ablauf von den Rohdaten bis zum fertigen Bild. Im Input Assembler liegen die Rohdaten, wie etwa Vertices, Tiefeninformationen und Texturen. Diese gelangen als Erstes in den Vertex-Shader, in dem aus den einzelnen Punkten die verschiedenen Polygone zusammengesetzt werden. Hier lassen sich gezielt einzelne Vertices verändern um grafische Effekte wie Linsenoptik zu erzielen. Der Vertex-Shader erlaubt hingegen kein Löschen oder Hinzufügen neuer Vertices. Anschließend gelangen die Daten direkt in den Geometry-Shader, in dem nun das Neuanlegen und Entfernen von Objekten möglich ist. Auch dieser arbeitet noch auf den Dreiecksdaten. Erst im Anschluß erfolgt die Rasterisierung im Rasterizer, wodurch jedem Pixel, das später auf dem Bildschirm auftaucht der entsprechende Farbwert zugewiesen wird und danach an den Pixel-Shader weitergereicht wird. Als letzter Shader kann der Pixel-Shader dann noch gezielt Farb- oder Tiefenwerte einzelner Pixel verändern um durch Effekte wie Glanz die Oberflächen noch realistischer wirken zu lassen. Abschließend wird das fertige Bild dann zum Monitor geliefert. Input Assembler Vertex Shader Geometry Shader Rasterizer Video Memory Buffer, Texture, Constant Buffer Pixel Shader Output Merger Abbildung 5: Rendering-Pipeline Zukünftig wird sich dieser Aufbau wohl verändern, da ab der DirectX-Version 11 diese Shader durch die neuen Unified-Shader abgelöst werden müssen. Dies wird bereits heute auf aktuellen Grafikkarten erfüllt, wodurch von der aktuellen Rendering Pipeline prinzipiell nur noch der Rasterizer als Verarbeitungsinstanz übrig bleibt. [2][8][9][10] 7

8 4 Shader 4.1 Vertex-Shader Meist sind mehrere Vertex-Shader Einheiten auf einer Grafikkarte verbaut. Diese ersetzen die ältere und vorallem unflexiblere Technik des Transform & Lighting. Was sie von den Geometry-Shadern unterscheidet, ist die Tatsache, dass sie nur vorhandene Vertices bearbeiten können, nicht aber bereits vorhandene löschen oder neue hinzufügen. Durch diese Bearbeitung lassen sich Effekte wie etwa Terraindeformationen und Wasserwellen erzeugen, aber auch Fischaugenoptiken und ähnliche Effekte: Abbildung 6: Beispiel eines Vertex-Shaders Um Brechungen des Lichts an und vor allem durch Glasoberflächen darzustellen ist das Verändern von Vertices beim Rendern die beste Möglichkeit. Am Rand des Hasen lässt sich dies schön erkennen, wie gezielt Vertices verschoben wurden, um den Linseneffekt der gebogenen Glaßoberfläche stärker hervorzuheben. Auf Systemen, bei denen die Grafikkarte noch keine Vertex-Shader besitzt, lassen sich diese auch mittels Software berechnen. [5][6][8] 8

9 4.2 Geometry-Shader Der Geometry-Shader ist ein relativ junger Teil der Rendering-Pipeline; er wurde erst mit DirectX 10 verpflichtend eingeführt. Seine prinzipielle Aufgabe ist eine Ebene über dem Vertex-Shader, d. h. er ist dafür zuständig mit ganzen Objekten umzugehen. Im Vergleich zum Vertex-Shader kann er auch neue Primitive erzeugen oder löschen. Man muss also nicht mit einzelnen Knoten arbeiten, sondern kann mit ganzen Knotenverbänden arbeiten. Abbildung 7: Geometry-Shader In obigem Bild sieht man sehr schön, wie der Geometry-Shader die CPU entlasten kann. Bislang war die CPU dafür zuständig zu prüfen, wo sich die Wasserpartikel befinden und ab welchem Punkt sie gelöscht werden können (beim Aufprallen auf den Stein). Der Geometry-Shader übernimmt nun diese Aufgabe komplett und löscht die betreffenden Polygone. Ebenso verhält es sich bei der Erstellung neuer Wassertropfen. Befindet sich in einer Mulde so viel Wasser, dass sie überläuft, werden neue Wassertropfen durch den Shader erstellt und unter realen physikalischen Bedingungen (Physikengine) zu Boden fallen gelassen. Diese gesamte Kollisionsabfrage inklusive Erstellen und Löschen ist meist sehr rechenintensiv, wodurch die Geometry-Shader klar im Vorteil gegenüber der CPU sind, die nicht so speziell für derartige Rechnungen ausgelegt ist. [5][6][8] 9

10 4.3 Pixel-Shader Pixel-Shader schließlich bilden die letzte Shader-Stufe in der Rendering-Pipeline. Sie sind im Gegensatz zu Vertex-Shadern stark an die zugrundeliegende Hardware gebunden, was sich auch daran zeigt, dass einige CPU-Berechnungen durch Pixel-Shader schneller ausgeführt werden können als auf dem Prozessor selbst. Der große Vorteil zum Vorgänger, der fixed-function pipeline, ist die viel flexiblere Programmierbarkeit. Dadurch lassen sich viel feinere Effekte erzielen. Beispielsweise bei der Beleuchtung eines rundlichen Objekts durch eine Punktlichtquelle wirkt das Resultat der fixed-function pipeline viel verwaschener, als das des Pixel-Shaders: Abbildung 8: Fixed-Function Pipeline im Vergleich zu Pixel-Shader In diesem Beispiel wird dem Shader ein dreidimensionaler Vektor übergeben, anhand dessen für jeden Pixel entschieden wird, ob der Farbwert verändert werden soll oder nicht. Im Folgenden ist dieses Kriterium der Winkel zwischen Normaler und Einfallswinkel des Lichtstrahls. Die übergebenen Parameter sind die Normale, die Koordinaten der Lichtquelle als auch der Pixel, der berechnet wird. void main() { vec3 n, lightdir; float NdotL, NdotHV; vec4 color = ambientglobal; n = normalize(normal); NdotL = max(dot(n,normalize(lightdir)),0.0); if (NdotL > 0.0) { // Addition des hier noch zu berechnenden Helligkeitswerts } } Mit Pixel-Shadern lassen sich aber nicht nur Helligkeitswerte verändern; auch einzelne Farben können beeinflusst werden, aber auch Eigenschaften wie der Z-Buffer bestimmter Pixel. 10

11 Der Schwerpunkt des Einsatzfeldes liegt ganz klar in der Beleuchtung, Spiegelungen, Schattierungen, sowie Lens-Flare-Effekten und auch das anfangs beschriebene HDR- Lighting wird zum größten Teil durch Pixel-Shader erledigt. [5][6][7][8] Abbildung 9: Reflexionen und Schattierungen mittels Pixel-Shader 11

12 4.4 Unified Shader Die Grundidee hinter den Unified Shadern ist die Vereinigung aller drei zuvor genannten Shadertypen zu einem, der universell eingesetzt werden kann. Bislang gab es zum Teil große Leerlaufphasen einzelner Shader-Einheiten, da nicht zu jedem Zeitpunkt die Pixel-Shader voll ausgelastet werden konnten, falls diese Daten der Vertex- oder Geometry-Shader benötigten. Ebenso gab es Phasen, in denen eine Einheit mehr berechnen sollte, als überhaupt möglich war. Durch die Unified-Shader soll dies nicht mehr vorkommen. Sobald Berechnungen anstehen, wird versucht diese bedarfsgerecht auszuführen, d.h. so dass möglichst alle Bilder zur Verfügung stehen, sobald diese angezeigt werden sollen und somit kein Ruckeln auftritt. Dadurch sollen im Idealfall sämtliche Shader-Einheiten stets ausgelastet sein. Für den Programmierer ergeben sich auch Vorteile, da die Berechnungen nicht speziell für eine Shader-Art angepasst werden müssen, sondern es eine einheitliche Schnittstelle gibt, die genutzt werden kann. Die Berechnung der Physikeffekte, die durch die Geometry-Shader schon ansatzweise erreicht wurde, wird nun durch die Unified-Shader komplett unterstützt. Es lässt sich neben den herkömmlichen Shadern also auch eine komplette Physikengine durch das Unified-Konzept simulieren. [2][5][6][11] Geometry Vertex Floating Point Processor Physics Pixel Rasterizer Abbildung 10: Konzept der Unified-Shader 12

13 5 ATIs R600 & nvidias G Stream-Processing-Units Im Bild sieht man den Aufbau des neuesten Grafikchips von ATI. Im Bereich der Setup Engine findet die Verarbeitung des Codes und Verteilung auf die verschiedenen Einheiten statt. Einerseits sind das die verschiedenen Shadervarianten, sowie die Tessellation- Einheit und der Tiefentest, der an dieser Stelle zum ersten Mal durchlaufen wird. Abbildung 11: Stream-Processing-Units im Grafikprozessor Die Verteilung der Anweisungen findet durch den Ultra-Threaded-Dispatch Processor statt, der versucht die Arrays aus Stream-Processing-Units (SPU) möglichst komplett auszulasten, so dass kein Leerlauf entsteht. Dabei werden die wichtigen Daten durch die verbundenen Caches geliefert (z. B. Texturdaten mittels der Texture Units). Anschließend werden die Daten an den Shader Export weitergereicht, wo die Daten 13

14 zurück in die Setup Engine übertragen werden können, um dort einen zusätzlichen Shader-Zyklus zu durchlaufen. Alternativ werden die Daten an die Render-Back-Ends geleitet, wo bei Bedarf ein zweiter Tiefentest durchgeführt werden kann oder zum Monitor übertragen werden. Die Stream-Processing-Units bestehen aus jeweils 5 Shader-Einheiten, die nach dem Single-Instruction-Multiple-Data-Prinzip zusammenarbeiten, also auf verschiedenen Objekte die gleiche Anweisung ausführen. Im Detail sieht das so aus, dass eine dieser fünf Einheiten für mathematische Sonderaufgaben wie beispielsweise Sinusberechnungen zuständig ist, während die anderen vier in der Regel je einen Pixel bearbeiten. Dabei werden die Pixel nicht wie früher üblich horizontal in die Prozessoren geladen, sondern jeder Prozessor berechnet nacheinander die verschiedenen Farbkanäle für seinen Pixel. So ist es dann auch möglich, dass die fünfte Shader-Einheit für alle 4 Pixel jeweils eine mathematische Operation berechnet, ohne in Zeitverzug zu geraten. Branch Execution Unit General Purpose Registers Abbildung 12: Unterteilung der Stream-Processing-Units Gerade für die Benutzung der GPU als Rechenwerk für Simulationen sehr schön, ist die Möglichkeit die 5 Shader-Einheiten auch flexibel zu unterteilen, d. h. nicht nur einen Prozessor für mathematische Operationen abzustellen, sondern die Prozessoren in jedem beliebgen Verhältnis zwischen Pixel- und Mathematik-Berechnungen aufteilen zu können. Dadurch erhält man letztendlich 5 (vertikal) arbeitende Skalarprozessoren. Zusätzliche Geschwindigkeitsvorteile bringt eine Branch-Execution-Unit, die zu jeder Stream-Processing-Unit gehört. [2][8][9][10] 14

15 5.2 Latenzminimierung durch Thread-Aufschub Das Dynamic Branching wird durch die oben genannten Branch-Execution-Units bewerkstelligt, durch die nicht alle Anweisungen starr durchlaufen werden müssen, sondern dem Programmierer die Möglichkeit gegeben wird, einzelne Abschnitte zu überspringen falls entsprechende Kriterien vorliegen. Im Speziellen sind dies if-abfragen, sowie for- und while-schleifen, die hier zur Verfügung stehen. Dadurch lassen sich bei entsprechenden Szenen deutliche Geschwindigkeitsvorteile erzielen, die aber auch in Abhängigkeit der Größe der zu überspringenden Bereiche liegen. Wählt man die Bereiche zu groß, ergibt sich nur sehr selten ein Abbruchkriterium und man erhält keinerlei Geschwindigkeitszuwachs. Wird hingegen die Anzahl der Bereiche zu groß, verliert man ebenfalls Zeit, da die Vergleiche und Abfragen auch Rechenzeit kosten und daher nur an den Stellen eingesetzt werden sollten, an denen sie auch unbedingt notwendig sind. Abbildung 13: Dynamic Branching mit verschieden großen Bereichen Auch nicht zu vernachlässigen ist die Tatsache, dass zwischen Vertex- und Pixel-Shadern teils deutliche Geschwindigkeitsunterschiede vorliegen, die auch bedacht werden sollten, falls man Dynamic Branching effizient und sinnvoll einsetzen möchte. [2][8] 15

16 5.3 Hierarchical-Z + Re-Z Das Hierarchical-Z-Verfahren führt Tiefentests in hierarchisch abgestuften Schritten durch. Abbildung 14: Schrittweise Verfeinerung der Sichtbarkeitsprüfung Von dem blauen Dreieck soll ein Teil entfernt werden, da es sich hinter dem roten befindet. Dafür überdeckt man das blaue Dreieck zuerst mit 8x8 Pixel großen Quadraten. Liegt in einem dieser Quadrate der Teil des blauen Dreiecks komplett hinter dem roten, so wird in diesem Quadrat der blaue Teil gelöscht. Die Berechnung dieses Quadrats ist somit abgeschlossen und muss nicht weiter unterteilt werden. Für die Quadrate in denen kein Teil des roten Dreiecks liegt, wird der blaue Teil komplett gelassen und auch dieses Quadrat muss nicht weiter untersucht werden. Für die übrigen Bereiche wird die Kantenlänge der Quadrate halbiert und das Verfahren mit dieser Quadratgröße weiter angewendet, bis schließlich die Quadratgröße nur noch ein Pixel beträgt und somit der gesamte Bereich getestet wurde. Durch dieses hierarchische Durchlaufen, sowie durch eine höhere Z-Kompression sind sowohl Schattenberechnungen schneller möglich, als auch Tiefentests bei Auflösungen größer als 2560x1600 möglich geworden. Hierzu trägt auch eine Technik des Löschens des Z-Buffers bei, die nicht einfach den kompletten Buffer mit Nullen überschreibt, sondern diesen über einen speziell implementierten Befehl direkt zurücksetzt; dadurch entsteht annähernd kein Bandbreitenverlust. Ein weiteres Verfahren für den Z-Buffer ist das sogenannte Re-Z, bei dem der Sichtbarkeitstest nicht nur vor dem Pixel-Shader geschieht, sondern ein zweites mal, nachdem 16

17 sämtliche Shader-Berechnungen abgeschlossen sind. Dies verbessert das resultierende Bild zusätzlich. [8] 5.4 MSAA und Tent-Filter bzw. CSAA Das Coverage-Sample-Anti-Aliasing von nvidia war bislang tendenziell dem Multi- Sampling-Anti-Aliasing von ATI überlegen; nun wird das relativ alte MSAA durch das sogenannte Custom-Filter-Anti-Aliasing ersetzt. Dieses bietet wie der Name bereits andeutet einen wählbaren Filter, der zusätzlich noch Subpixel der angrenzenden Pixel mitgewichtet und somit unter Umständen harmonischer wirkt. Abbildung 15: 8x MSAA, 12x CFAA mit Narrow Tent, 16x CFAA mit Wide Tent Prinzipiell ist das Einbeziehen der Nachbarpixel ähnlich dem Quincunx-Verfahren, jedoch wird durch eine geringere Gewichtung der Pixel am Rand kein derart verschmiertes Bild generiert. Der beste Effekt, sowohl aus Geschwindigkeitsgründen, als auch vom fertigen Bild, wird mit dem 12x CFAA zusammen mit dem Narrow-Tent-Filter erzielt. Das CFAA-Verfahren lässt sich auch bei Stencil-Schatten, also Schattenrändern, anwenden, im Gegensatz zum CSAA-Verfahren. Was das Bild zusätzlich noch aufwerten kann, ist der Edge-Detection-Filter, der versucht in einer Szene die Kanten zu erkennen und diese Stellen stärker glättet, als den Rest der Szene. Das Verfahren ist natürlich vom betrachteten Objekt abhängt, erzielt aber bei Standardbildern deutlich bessere Effekte, als ein nicht nachbearbeitetes Bild. [2][10][11][12] 17

18 6 Ausblick Die zu Beginn erwähnte Tessellation-Einheit wird zukünftig eine Standardeinheit auf Grafikkarten sein; bei High-End-Karten ist dies bereits heute oft zu finden. Dieses Verfahren zusammen mit Unified-Shadern verspricht sehr flexible Programmiermöglichkeiten. Eine sehr interessante Anwendung von Grafikkarten stellt nvidia in Form ihres Tesla vor. Dies ist eine Art Supercomputer, der mittels PCI-Express-Slot an einen normalen Computer angeschlossen wird und dann für rechenintensive Anwendungen wie meteorologische, biologische oder ähnliche Simulationen verwendet werden kann. Bei einer Rechenleistung von über 500 Gigaflops pro Grafikkarte klingt dies sehr vielversprechend. [3] Abbildung 16: Tesla-System von nvidia Auch im Hinblick auf Echtzeit-Raytracing ist diese Hardwarekombination ein Schritt nach vorne. Denn ab einer gewissen Anzahl Polygonen wird Raytracing performanter als aktuelle Verfahren. Dies ist vor allem damit zu begründen, dass man beim Raytracing einen gewissen Grundaufwand für Licht und andere Grundlagen benötigt, die aber auch bei einer großen Anzahl Polygone nur logarithmisch wächst. [4] 18

19 Literatur [1] Der lange Weg zum HDR-Rendering: [2] ATI Radeon HD 2900 XT Review: [3] CUDA ermöglicht Berechnungen auf nvidia-gpus: /november/cuda_berechnungen_nvidia-gpus/ [4] Echtzeit-Raytracing der Universität des Saarlandes: [5] Die Entwicklung der Shader zu 4.0: [6] Shader-Konzept: tutorials-t-7-77.html#shader [7] OpenGL Shading Language - GLSL Tutorial: [8] Test: ATi Radeon HD 2900 XT: /test_ati_radeon_hd_2900_xt/ [9] ATI Radeon HD2000-Serie Preview: index2.php [10] AMD R600 Architecture and GPU Analysis: [11] Test: nvidia GeForce 8800 GTX: /test_nvidia_geforce_8800_gtx/1 [12] Multisampling Anti-Aliasing unter der Lupe: index7.php 19

20 Abbildungsverzeichnis 1 Old saint pauls 1.jpg ldr.png Rendering-Pipeline magazin/storage/images/media/ linux magazin/ausgabe/2004/02/gla nzende effekte/ab jpg/ ger- DE/ab jpg.jpg archive.html Konzept der Unified-Shader Unterteilung der Stream-Processing-Units nvidia 600x600.jpg