Leistungsanalyse Von Graphiksystemen

Leistungsanalyse von Graphiksystemen

Semesterarbeit

Winter 1998/1999

Stephan Würmlin Pascal Kurtansky

ETH Zürich Departement Informatik Institut für Wissenschaftliches Rechnen Forschungsgruppe Graphische Datenverarbeitung

Prof. Dr. Markus Gross

Betreuer: Daniel Bielser Reto Lütolf 1Inhaltsverzeichnis

Zusammenfassung v Abstract vii Aufgabenstellung ix 1 Einleitung 1 1.1 Benchmarks ...... 1 1.2 Graphikleistung ...... 1 1.2.1 3D Anwendungsleistung ...... 2 1.2.2 Leistung von OpenGL Graphikoperationen ...... 2 1.3 Systemleistung ...... 3 1.4 Die getesteten Computersysteme ...... 3 1.5 Überblick ...... 4

BESCHREIBUNG DER SYSTEME 7 2 Indigo2 XZ/Extreme und Maximum Impact von SGI 9 2.1 Systemarchitektur der Indigo2 mit XZ/Extreme ...... 10 2.2 Systemarchitektur der Indigo2 Maximum Impact ...... 12 2.3 XZ und Extreme Graphiksystem ...... 12 2.3.1 Die Standard Rendering-Pipeline ...... 13 2.3.2 Das CPU-Interface ...... 14 2.3.3 Das Geometry-Subsystem ...... 14 2.3.4 Das Raster-Subsystem ...... 15 2.3.5 Das Display-Subsystem ...... 16 2.3.6 Die XZ und Extreme Graphic-Features ...... 17 2.4 Das Maximum Impact Graphiksystem ...... 19 3 Die O2 von SGI 21 3.1 Systemarchitektur ...... 22 3.1.1 Systemplatine ...... 22 3.1.2 Die Prozessoren: MIPS R5000 und R10000 ...... 23 3.1.3 Der R10000 in der O2 ...... 26 3.1.4 Der Speicher (UMA) ...... 27 3.2 Graphikleistung ...... 30 3.2.1 Allgemeine Bemerkungen ...... 30 3.2.2 Vergleich mit Indigo2 Systemen ...... 31 4 Die Octane von SGI 33 4.1 Die Octane Modelle ...... 34 4.2 Systemarchitektur ...... 35 4.2.1 Systemplatine ...... 35 4.2.2 Die Crossbar-Switch Technologie ...... 38 4.3 Graphiksystem ...... 39

i ii Inhaltsverzeichnis

5 Die Onyx2 von SGI 41 5.1 Systemarchitektur ...... 42 5.1.1 Übersicht ...... 42 5.1.2 Multi-Pipe Rendering Mode ...... 46 5.1.3 Aufbau der Onyx2 ...... 47 5.1.4 Hypercube Architektur ...... 48 5.1.5 Node-Boards und I/O Subsystem ...... 51 5.1.6 Die Prozessoren: MIPS R10000 ...... 54 5.2 Graphiksystem ...... 55 5.2.1 Verarbeitungsschritte in der Visualisierungs-Pipeline ...... 55 5.2.2 Graphic-Features und weitere Spezialitäten ...... 56 6 Ultra 1 von SUN 59 6.1 Systemarchitektur der Ultra1 ...... 61 6.1.1 Der UPA Crossbar-Switch ...... 62 6.1.2 Der Prozessor: UltraSPARC I Version 9 ...... 63 6.2 Graphiksysteme ...... 65 6.2.1 SUN Ultra 1 mit Creator 3D ...... 65 6.2.2 Elite 3D m3/m6 ...... 68 7 Zwei PC Systeme 69 7.1 Systemarchitektur ...... 69 7.1.1 AGP von Intel ...... 69 7.1.2 Die Prozessoren ...... 72 7.2 Graphiksystem ...... 74

LEISTUNGSANALYSE UND BENCHMARKING 77 8 Der Viewperf Benchmark 79 8.1 Einführung ...... 79 8.1.1 Charakteristiken von Viewperf ...... 80 8.1.2 Das geometrische Mittel ...... 81 8.2 Die Viewsets ...... 81 8.2.1 ProCDRS - Pro/DESIGNER ...... 84 8.2.2 DX - Data Explorer ...... 85 8.2.3 DRV - Design Review ...... 86 8.2.4 AWadvs - Advanced Visualizer ...... 87 8.2.5 Light - Lightscape ...... 88 8.2.6 CDRS - Conceptual Design Rendering Software ...... 89 8.3 Benchmarking mit Viewperf ...... 89 8.3.1 Beispielaufruf von Viewperf ...... 90 8.4 Kompilieren von Viewperf ...... 90 8.4.1 Sun unter Solaris ...... 90 8.4.2 SGI unter IRIX ...... 91 8.4.3 Pentium Pro/Pentium II unter Windows NT ...... 91 8.5 Zusammenfassung ...... 91 Inhaltsverzeichnis iii

9 Der GLperf Benchmark 93 9.1 Einführung ...... 93 9.1.1 Charakteristiken von GLperf ...... 95 9.1.2 Unterschiede zwischen Viewperf und GLperf ...... 97 9.2 Die OPC Skripte ...... 98 9.2.1 BgnEnd.rgb ...... 98 9.2.2 CopyPixl.rgb ...... 99 9.2.3 DrawPixl.ndx ...... 100 9.2.4 DrawPixl.rgb ...... 100 9.2.5 FillRate.rgb ...... 101 9.2.6 Light.rgb ...... 101 9.2.7 LineFill.rgb ...... 102 9.2.8 OPClist.ndx ...... 102 9.2.9 OPClist.rgb ...... 103 9.2.10 ReadPixl.ndx ...... 104 9.2.11 ReadPixl.rgb ...... 104 9.2.12 TexImage.rgb ...... 105 9.2.13 TriFill.rgb ...... 105 9.3 Benchmarking mit GLperf ...... 106 9.3.1 Beispielaufruf von GLperf ...... 106 9.4 Compilieren von GLperf ...... 107 9.4.1 Sun unter Solaris ...... 107 9.4.2 SGI unter IRIX ...... 107 9.4.3 Pentium Pro/Pentium II unter Windows NT ...... 107 9.5 Zusammenfassung ...... 107 10 Der SPEC CPU95 Benchmark 109 10.1 Einführung ...... 109 10.1.1 Charakteristiken von CPU95 ...... 109 10.2 Die Integer Programme ...... 111 10.3 Die Floating-Point Programme ...... 112 10.4 Benchmarking mit CPU95 ...... 112 10.4.1 Beispielaufruf von CPU95 ...... 113 10.5 Compilieren von CPU95 ...... 113 10.5.1 Sun unter Solaris ...... 113 10.5.2 SGI unter IRIX ...... 114 10.5.3 Pentium Pro/Pentium II unter Linux ...... 114 10.6 Zusammenfassung ...... 114 11 Resultate und Analyse 117 11.1 Viewperf ...... 117 11.1.1 Bedingungen beim Ausführen von Viewperf ...... 117 11.1.2 Die Resultate ...... 118 11.1.3 Der Test ohne Netzwerk ...... 119 11.1.4 Application Binary Interfaces ...... 119 11.1.5 Auflösungen ...... 120 11.1.6 Entkopplung des Bufferaustauschs vom vertikalen Refresh des Bildes . . 120 11.1.7 Analyse ...... 122 11.2 GLperf ...... 126 11.2.1 Bedingungen beim Ausführen von GLperf ...... 126 iv Inhaltsverzeichnis

11.2.2 Die Resultate ...... 126 11.2.3 TexImage - Texture Download/Switching ...... 127 11.2.4 Light - Lichtquellen ...... 133 11.2.5 FillRate - Pixelfüllraten ...... 135 11.2.6 TriFill - Dreieckfüllraten ...... 136 11.3 SPEC CPU95 ...... 138 11.3.1 Bedingungen beim Ausführen von CPU95 ...... 138 11.3.2 Die Resultate ...... 138 11.4 Schlussbemerkungen ...... 143 12 Schlussworte 145 12.1 Zusammenfassung ...... 145 12.2 Fazit und Schlussbemerkungen ...... 145 12.3 Dank ...... 145 13 Referenzen 147

A Anhang 149 A.1 Die Open Graphics Library ...... 149 A.1.1 Computergraphik Tutorial ...... 149 A.1.2 Die OpenGL Primitiven ...... 150 A.1.3 Die OpenGL Pipeline ...... 150 A.2 Viewperf ...... 151 A.2.1 Die Viewperf Kommandozeilen Parameter ...... 151 A.3 GLperf ...... 154 A.3.1 Die Grammatik der Eingabedateien ...... 154 A.3.2 Die fehlenden OpenGL Kommandos auf den SUN’s ...... 155 B Weitere Tests 157 B.1 Das Dell Computersystem mit drei verschiedenen Graphikkarten ...... 157 B.1.1 Diamond FireGL 1000 PRO (AGP) ...... 157 B.1.2 Evans & Sutherland AccelGalaxy 52 ...... 158 B.1.3 Intergraph Intense 3D Wildcat 4000 ...... 158 B.2 Die sgi Visual Workstation 320 ...... 159 B.3 Resultate und Analyse ...... 161 B.3.1 Viewperf ...... 161 B.3.2 GLperf ...... 163 B.4 Schlussbemerkungen ...... 165 Zusammenfassung

In dieser Semesterarbeit wird die Graphikleistung von verschiedenen Computersystemen mit Hilfe von Standard Benchmark Programmen verglichen. In einem ersten Teil werden die getesteten Systeme beschrieben. Es werden dabei die Prozes- soren und ihr Einfluss auf die Graphikleistung, die Systemarchitektur und die Graphiksubsy- steme analysiert. Es interessieren dabei speziell die implementierten Graphikfunktionen, welche die Graphiksubsyteme in Hardware durchführen können. In einem zweiten Teil werden Leistungsmessungen durchgeführt und deren Resultate analysiert. Zur Leistungsmessung werden Standard-Benchmarks verwendet, welche von der Stan- dard Performance Evaluation Corporation SPEC entwickelt werden. Für Graphikleistungsmessungen werden die Benchmarks Viewperf und GLperf verwendet, welche einerseits die 3D-Anwendungsleistung und andererseits die rohe Graphikleistung messen. Für die Messung der gesamten Systemleistung wird SPEC CPU95 verwendet. Der Vergleich umfasst neun verschiedene Computersysteme, die von Silicon Graphics’ Onyx2 mit Infinite Reality2 Graphikhardware zu Arbeitsstationen von Sun und SGI bis zu Standard PC Arbeitsstationen mit OpenGL Graphikbeschleunigern reichen.

v vi . Abstract

This semester thesis compares the graphics performance of a number of different computer systems using standard benchmarking software. The first part gives a comprehensive Overview of the tested computer systems. We will analyse the processor and its impact on graphics performance, the system architecture and the graphics subsystem. It is specially concerned with the implemented graphics functions that are perfor- med in hardware by the graphics subsystem. In the second part we will make performance evaluations and analyse the results. The evaluations will be realized with standard benchmarks which are implemented and supported by the Standard Performance Evaluation Corportion SPEC. We will measure graphics performance with Viewperf for 3D application performance and GLperf for optimal performance. To measure system-level performance we will use SPEC CPU95. The comparison involves nine different computer systems, ranging from SGI’s powerful Onyx 2 with Infinite Reality graphic hardware to scientific workstations from Sun and Silicon Gra- phics and standard PC workstations.

vii viii . Eidgenössische Ecole polytechnique fédérale de Zurich Technische Hochschule Politecnico federale di Zurigo Zürich Swiss Federal Institute of Technology Zurich

Institut für Wissenschaftliches Rechnen Forschungsgruppe Graphische Datenverarbeitung Prof. M. Gross Aufgabenstellung

Semesterarbeit von Stephan Würmlin und Pascal Kurtansky Graphikleistungsanalyse von Computersystemen

Einleitung Bis vor kurzem waren hohe Graphikleistungen nur auf Workstations oder auf entsprechend aus- gerüsteten Grossystemen verfügbar Ð natürlich zu entsprechend hohen Preisen. Inzwischen wird jeder normale PC mit Beschleuniger-Chips, eventuell sogar mit 3D-Fähigkeiten, und speziellen Bussystemen im Graphiksubsystem ausgerüstet. Betrachtet man die eindrücklichen Demoprogramme oder spezielle Graphikanwendungen auf gängigen PC-Systemen, drängt sich die Frage nach einem Leistungsvergleich mit teuren, optimierten Graphikworkstations gera- dezu auf. Insbesondere wäre ein Leistungsvergleich mit den verschiedenen, nach wie vor im Highend-Bereich angesiedelten SGI-Rechnern von besonderem Interesse. Natürlich muss bei einem plattformübergreifenden Vergleich auch anderen wichtigen System- komponenten wie Prozessor, Busarchitektur oder Massenspeicher Rechnung getragen werden.

Aufgabenstellung Für den Vergleich sollen aussagekräftige Benchmark-Programme gesucht und bezüglich ihrer Bewertungsverfahren kritisch betrachtet werden. Hauptsächlich soll das Benchmark-Programm Viewperf zur Anwendung kommen und dementsprechend genau untersucht werden. Nach Möglichkeit soll durch Performance-Tests mit üblichen Graphik-Applikationen wie zum Beispiel AVS/Express aufgezeigt werden, in wie weit die Benchmark-Programme im Vergleich zu den Anforderungen realer Anwendungsprogramme eher synthetische Testergebnisse liefern. Die folgenden Graphiksysteme sollen untersucht werden: ¥ SGI: Indigo2 mit Maximum Impact ¥ SGI: Indigo2 mit XZ ¥ SGI: Indigo2 mit Extreme ¥ SGI: O2 mit Standard Graphikhardware ¥ SGI: Onyx2 mit Inﬁnite Reality2 ¥ SUN: Ultra Sparc mit Creator3D ¥ PC: PentiumPro mit Diamond FireGL 1000 ¥ evtl. Mac-Plattform

Die normierten Testergebnisse sollen tabellarisch dargestellt werden. Die getesteten Rechnersysteme inklusive ihrer Graphikhardware sowie die benutzen Bench- mark-Programme sind detailliert zu vergleichen und zu beschreiben.

v vi .

Die Semesterarbeit steht unter der Obhut von Prof. Dr. Markus Gross und wird von Reto Lütolf und Daniel Bielser betreut.

Ausgabe: 20. Oktober 1998 Abgabe: 3. Juli 1999

(Prof. Dr. M. Gross) 1 1Einleitung

Mit der Einführung von immer leistungsfähigeren und kostengünstigeren Graphikkarten für Windows PC’s scheint es, dass Silicon Graphics mit ihren Hochleistungsworkstations bald einmal die 3D Graphikkrone abgeben muss. Doch scheint es auch, dass die PC Arbeitsstationen für komplexes 3D Modelling von Firmen wie zum Beispiel Pixar nicht genutzt werden. In dieser Arbeit soll die Graphikleistung von verschiedenen Arbeitsstationen gemessen und verglichen werden. Es wurden sowohl High-End Systeme wie eine Onyx2 Konfiguration für 200’000 Franken gemessen als auch PC Arbeitsstationen für ein paar Tausend Franken. Zur Messung von Leistung in der Computer Technologie wird in der Regel ein Benchmark verwendet. Ein Benchmark lässt sich wie folgt umschreiben:

1.1 Benchmarks Ein Benchmark ist eine Referenz, wie etwas gemessen werden kann. In der Computer und Inter- net Technologie kann das Wort Benchmark folgende Bedeutungen haben: (i) Konditionen, unter welchen ein Produkt oder System gemessen werden kann. (ii) Ein Programm, das speziell entwickelt wurde, um gewisse Komponenten, Systeme oder Anwendungen zu messen. (iii) Leistungskriterien, die ein Produkt erreichen kann. Benchmarks, die in einem Labor entwickelt werden, schaffen es machmal nicht, reale Produkte oder Umgebungen zu reflektieren. Aus diesem Grund definiert Eric Raymond ein Benchmark als “eine falsche Leistungsmessung” und zitiert ein altes Hackersprichwort: “In the Computer Industry, there are three kinds of lies: Lies, Damn Lies, and Benchmarks.”

1.2 Graphikleistung Viele Graphikkartenhersteller geben zur Beschreibung der Leistung ihrer Graphik-Hardware Zahlen wie zum Beispiel “3.4 Millionen Polygone pro Sekunde” an. Werden diese Polygone beleuchtet? Wie gross sind die Polygone? Sind diese Polygone schat- tiert, oder handelt es sich um ein Drahtgittermodell?

1 2 1 Einleitung

Das Problem ist, dass niemand wirklich genaue Spezifikationen über die Art der Messungen angibt. Ein weiteres Problem ist die Interpretation dieser Zahlen. Was nützt eine Angabe in “Millionen Polygone in der Sekunde”, wenn man einfach wissen will, wie schnell eine gegebene Animation laufen würde. Deshalb kann man auch richtige Anwendungen zur Hand nehmen, um Vergleiche anzustellen.

Grob gesagt gibt es zwei Wege die Graphikleistung eines Computersystems zu messen: 3D Anwendungsleistung und Leistung von OpenGL Graphikoperationen.

1.2.1 3D Anwendungsleistung

In dieser Arbeit wird ein standardisierter und von der Industrie akzeptierter 3D Anwendungs- benchmark, der Viewperf Benchmark, dazu verwendet, die Graphikleistung realer 3D Anwen- dungen zu messen. Viewperf verwendet fünf sogenannte Viewsets, welche verschiedene Anwendungsgebiete repräsentieren. Bezeichnung repräsentative Anwendungsgebiete DX wissenschaftliche Datenvisualisierung und -analyse ProCDRS Modellierung und Rendering im Bereich der computerunterstützten Konstruktion DRV 3D Computermodellbetrachtung AWadvs 3D Animation, Rendering, Modellierung und Bildaufbau Light Radiosity Visualisierung Tabelle 1.1: Die Viewsets von Viewperf

Jedes Viewset besteht aus einer Vielzahl von Einzeltests, welche alle ein Resultat in Bildern pro Sekunde ausgeben. Für jedes Viewset wird eine Zahl als gewichtetes Resultat der Einzeltests angegeben; grössere Zahlen geben dann grössere Leistung an.

1.2.2 Leistung von OpenGL Graphikoperationen

Eine der grössten Schwierigkeiten beim Vergleichen der 3D Graphikleistung ist, wie schon erwähnt, die Spezifikation der Resultate. Die gemessenen Werte varieren mit verschiedenen Parametern, zum Beispiel Grösse, Farbtiefe, Schattierungsmodus, Beleuchtung, etc. Um die Parameter zu standardisieren, wurde von der SPEC ein Benchmark Programm mit dem Namen GLperf entwickelt, welches in dieser Arbeit verwendet wird, um die Leistung von OpenGL Graphikoperationen zwischen verschiedenen Computersystemen zu vergleichen. GLperf variert dabei in dreizehn Skripten die benutzten Primitiven1 in verschiedenen Modi und Grös- sen. Die Resultate werden in “Objekte pro Sekunde” angegeben, also zum Beispiel in “Dreiecke pro Sekunde”. Unser Interesse galt den Pixel- und Dreieckfüllraten, Texturierungsraten und Leistungen in

1. Eine Primitive ist ein Grundelement eines Graphikprogramms. In 2D sind dies u.a. Kreis, Linie; bei 3D sind dies analog Kugel, Fläche, etc. Eine kleine Beschreibung der in OpenGL vorkommenden Pri- mitiven sind im Anhang A.1.2 wiedergegeben. 1.3 Systemleistung 3

Abhängigkeit der Lichtquellenanzahl. Aus diesem Grund benutzten wir nur vier der dreizehn Skripte: Skript Beschreibung TexImage.rgb misst die Leistung der glTexImage2D RGB Operationen. glTexImage2D spezifiziert ein zweidimensionales Texturbild, welches auf eine Graphikprimitive gelegt wird FillRate.rgb misst wieviele Pixel pro Sekunde gezeichnet werden können Light.rgb misst den Einfluss der Anzahl eingeschalteter Lichtquellen für das Zeichnen einer bestimmten Primitive TriFill.rgb misst den Einfluss der Vergrösserung der Primitive auf das Zeichnen von Polygonen Tabelle 1.2: Die 4 verwendeten Skripte von GLperf

Meistens kann der Systemprozessor, der die Bilddaten berechnet, diese nicht genügend schnell an das Graphiksubsystem weitergeben. Dabei erweisen sich die Prozessorleistung, die Spei- chergeschwindigkeit und die Busbandbreite als Flaschenhals zwischen Prozessor und Graphik- subsystem. Somit sind die von Viewperf und GLperf ermittelten Werte auch von diesen Systemkomponenten abhängig. Aus diesem Grund wurde mit einem weiteren Benchmark Pro- gramm auch noch die Systemleistung gemessen.

1.3 Systemleistung Zur Messung der Systemleistung wurde ein Benchmark Programm verwendet, welches ebenfalls von der SPEC [18] entwickelt wurde. SPEC CPU95, misst die Leistung des Prozessors, des Speichers und des Compilers. CPU95 benutzt die CINT95 Tests mit acht Programmen um die Festkommaeinheit und die CFP95 Tests mit zehn Programmen um die Gleitkommaeinheit zu testen. Das CPU95 Programm testet keine weiteren Komponenten, wie zum Beispiel I/O, die Graphikleistung oder das Netzwerk, weshalb es sich gut eignet, um den Einfluss steigender Systemleistung auf die Graphikleistung des Computersystems zu betrachten. Dieser Benchmark wird in dieser Arbeit nicht so detailliert beschrieben, wie die Graphikbench- mark-Programme. Die mit CPU95 ermittelten Werte dienen jedoch der Analyse der Graphik- leistung.

1.4 Die getesteten Computersysteme Wir konnten eine grosse Anzahl von Computersystemen der Computer Graphik-Gruppe und des Departements Informatik der ETH Zürich testen. So schufen wir eine Momentaufnahme der Graphikleistung. Jedem System wurde eine ID vergeben, welche dazu dient, das System ohen langen Namen zu identifizieren. Diese ID gibt in der Regel die DNS Adresse in der ethz.ch Domain wieder (gogh entspricht zum Beispiel gogh.ethz.ch). Bei den Windows NT-Computern entsprechen die ID’s nicht den DNS Namen, diese sind matisse für den ppro und capilla für den ptwo 4 1 Einleitung

Tabelle 1.3 gibt einen Überblick über die getesteten Computersysteme. ID Vendor System OS Window CPU Graphic System Name Vers. Env. gogh SGI Indigo2 IRIX X MIPS R10000 Maximum 6.5 195 MHz Impact 10000 caroll SGI Indigo2 IRIX X MIPS R4400 XZ 6.5 200 MHz escher SGI Indigo2 IRIX X MIPS R4400 Extreme 6.5 150 MHz mondrian SGI O2 IRIX X MIPS R5000 CRM 6.5 200 MHz birs SGI Octane IRIX X MIPS R10000 MXE 6.5 250 MHz luxo SGI Onyx2 IRIX X MIPS R10000 Infinite Reality2 6.4 8× 195 MHz ppro Dell Optiplex WinNT Win Intel Pentium Diamond FireGL Pro 4 SP3 Pro 180 MHz 1000 PRO PCI ptwo Dell Precision WinNT Win Intel Pentium II Diamond FireGL 410 4 SP3 2× 400 MHz 1000 PRO AGP antimon Sun Ultra1 Solaris X UltraSPARC I Creator 3D Model 170 2.5 167 MHz Tabelle 1.3: Überblick über die Computer Systeme

Leider konnten wir weder eine neue Sun Arbeitsstation (wie zum Beispiel die Sun Ultra60 mit Elite3D-m6 Graphiksystem) noch ein leistungsfähiges OpenGL System unter Windows NT (wie zum Beispiel die Intergraph TDZ2000D GX1 450 MHz mit der Intense3D Wildcat 4000 Graphikkarte) bis zur Abgabe dieser Arbeit testen. Im Anhang B befinden sich jedoch die Resultate einer Dell Precision 410 mit Intel Pentium III Prozessor (500 MHz), 256 MByte RAM mit folgenden Graphikkarten: ¥ Diamond FireGL 1000 Pro ¥ Evans & Sutherland AccelGalaxy 52 ¥ Intergraph Intense3D Wildcat 4000 Ausserdem konnten wir noch eine Visual Workstation 320 von SGI testen. Diese war mit einem Intel Pentium II Prozessor (400 MHz) und ebenfalls 256 MByte RAM ausgestattet. Eine Sun Ultra60 wurde uns von Sun (Schweiz) trotz frühzeitiger Anmeldung nicht zur Verfü- gung gestellt.

1.5 Überblick

Die an diese Einleitung anschliessenden Kapitel 2 bis 7 haben die Beschreibung der getesteten Systeme zum Inhalt, insbesondere eine genaue Betrachtung der Graphikengine. 1.5 Überblick 5

Kapitel 8 beschreibt Viewperf, den ersten der zwei verwendeten Graphik-Benchmarks, dabei werden speziell die Viewsets genau untersucht. Kaptiel 9 beschäftigt sich mit GLperf, dem zweiten Graphik-Benchmark, und betrachtet neben dem Benchmark auch die 13 Skripte. Kapitel 10 erklärt kurz, was SPEC CPU95 ist und gibt einen Überblick über die zugrundeliegenden Tests. Kapitel 11 zeigt die erhaltenen Resultate und analysiert diese. Kapitel 12 beschliesst diesen Bericht mit einer Zusammenfassung und Schlussbemerkungen. Einen kurzen Überblick über die OpenGL, die Kommandozeilenoptionen von Viewperf sowie die Grammatik von GLperf Skripten bilden den Anhang A. Die weiteren Tests mit den neuen Windows NT-Computern und der Visual Workstation befinden sich im Anhang B. 6 1 Einleitung Erster Teil

BESCHREIBUNG DER SYSTEME

7 8 . 2 2Indigo2 XZ/Extreme und Maximum Impact von SGI

Bild SGI

Bereits 1993 wurden die Indigo Rechner durch die Indigo2 Systeme mit XZ oder Extreme Gra- phiksystemen abgelöst. Damit stellen diese SGI Rechner die ältesten im Rahmen dieser Arbeit getesteten Maschinen dar.

1 Ausgestattet wird die Indigo2 mit einem MIPS R4400 Prozessor, einem 64 Bit breiten GIO64 Bus und wahlweise mit XZ oder Extreme Graphikkarten (Siehe Abschnitt 2.3), wobei in der Extreme Ausführung die doppelte Anzahl von Geometrie- und Raster-Engines zum Einsatz kommen.

Drei Jahre später (1996), hat SGI die verbesserte und leistungsstärkere Indigo2 Maximum Impact auf den Markt gebracht. Die Systemarchitektur wurde bis auf einige Details eins zu eins von den anderen Indigo2 Modellen übernommen. Bezüglich des Graphiksystems ist SGI aber neue Wege gegangen und konnte dadurch die Graphikleistung massiv steigern (Siehe Abschnitt 2.4).

1. Der Vergleich mit den neueren MIPS R5000 und R10000 Prozessoren wird unter 3.1.2 behandelt.

9 10 2 Indigo2 XZ/Extreme und Maximum Impact von SGI

Um Konfusionen zu vermeiden, werden die älteren Indigo und die neueren Indigo2 Rechner oftmals durch ihre Gehäusefarbe identifiziert, besonders in älteren Dokumentationen und White- papers. ¥ Violett (purple) für Indigo mit XZ 1oder Elan2 Graphik ¥ Grün (green) für Indigo2 mit XL3, XZ oder Extreme Graphik

2.1 Systemarchitektur der Indigo2 mit XZ/Extreme

Die Indigo2 Systeme verwenden eine klassische Busarchitektur. Vom Prozessor-Modul ausge- hend, stellt der Systembus die Verbindung zum Hauptspeicher-Kontroller her. Direkt daran angeschlossen sind zum einen der Hauptspeicher und zum anderen der GIO64-Bus. Diese Systemarchitektur wird als Non-Unified-Memory Architektur (NUMA) bezeichnet. Das Memory, bestehend aus Hauptspeicher und lokalen Speichern auf den Erweiterungskarten, ist physikalisch betrachtet über das gesamte System verteilt. Als Alternative zur NUMA existiert auch die Unified-Memory Architektur (UMA), wie sie etwa in der O2 von SGI (Siehe Abschnitt 3) verwendet wird. Die zentrale Verbindung der einzelnen Subsysteme bilden die beiden Systembusse:

¥ Zwischen dem Memory/DMA Controller und der I/O Einheit kommt ein 64 Bit breiter Bus zum Einsatz. Daran werden mit einer Busbreite von 32 Bit die vier EISA Slots und mit 64 Bit die drei GIO64 Slots angeschlossen. ¥ Der Memory Bus bildet die Verbindung zwischen dem Prozessor Modul und dem Hauptspeicher, ebenfalls in 64 Bit breiter Ausführung.

An der I/O Einheit werden nebst den beiden SCSI Kanälen die peripheren Einheiten, wie etwa parallele/serielle Schnittstellen oder ein Ethernet Adapter angeschlossen. Auf der nächsten Seite ist der Aufbau eines Indigo2 Rechners schematisch dargestellt. Der Prozessor: MIPS R4400 Der R4400 mit MIPS III Instruktionsatz ist ein echter 64 Bit Prozessor mit einer Super-Pipeline Architektur. Im Gegensatz zum neueren R5000 oder R10000 fehlt dem R4400 jedoch die Unter- stützung für Graphikanwendungen, d.h. es sind keine sogenannte MADD4 Instruktionen vorhanden. Aus diesem Grunde soll hier nicht weiter auf das Design und den MIPS III Instruktionssatz des Prozessors eingegangen werden5. Für einen Vergleich des R4400 mit dem R5000 und R10000 wird auf die Tabelle 3.1 verwiesen.

1. Die Indigo XZ Graphikhardware verwendet lediglich zwei Graphics-Engines (GE). 2. Bei der Indigo Elan Graphikhardware kamen vier Graphics-Engines zum Einsatz. Da SGI die Graphikhardware weiterentwickelte, gilt es zu beachten, dass eine Indigo Elan nicht identisch ist mit einer Indigo2 XZ, welche ebenfalls vier GE verwendet. 3. Diese Variante hatte keine GE, d.h. alle Graphik-Berechnungen mussten in Software durchgeführt werden. 4. MADD = Multiply-Add. Für eine ausführliche Beschreibung der MADD Instruktionen siehe 3.1.2. 5. Details unter www.mips.com 2.1 Systemarchitektur der Indigo2 mit XZ/Extreme 11

Abbildung 2.1: Die Indigo2 XZ/Extreme Systemplatine 12 2 Indigo2 XZ/Extreme und Maximum Impact von SGI

2.2 Systemarchitektur der Indigo2 Maximum Impact

Zwischen einer Indigo2 mit XZ oder Extreme und Indigo2 Maximum Impact bestehen nur geringe Unterschiede. Beide Systeme haben grundsätzlich dieselbe NUMA-Systemarchitektur, somit kann Abbildung 2.1 auch für eine schematische Übersicht des Maximum Impact Systems verwendet werden. In der nachfolgenden Tabelle werden die wichtigsten Unterschiede der beiden Systeme dargestellt. Für eine ausführliche Beschreibung der Graphiksysteme wird auf die Abschnitte 2.3 und 2.4 verwiesen. Indigo2 XZ/Extreme Indigo2 Maximum Impact Prozessor MIPS R4400 MIPS R10000 Max. Hauptspeicher 384 MB 640 MB

GIO64 Slots 3 2 EISA Slots 4 3 Tabelle 2.1: Vergleich zwischen Indigo2 XZ/Extreme und Indigo2 Maximum Impact

Es ist klar, dass in der Maximum Impact Ausführung auch bessere und leistungsstärkere Sub- systeme, wie etwa der SCSI Controller, verwendet werden. Von besonderer Bedeutung ist aber das Graphiksystem der Maximum Impact, welches nur schon aufgrund der Rechenleistung der Graphics Engines (GE) bedeutend schneller als die XZ/Extreme Ausführung ist. Eine Gegenüberstellung der Rechenleistung befindet sich in Tabelle 3.2.

2.3 XZ und Extreme Graphiksystem

Da die XZ und Extreme Graphiksysteme grundsätzlich die gleiche Hardware verwenden, werden sie in diesem Abschnitt auch zusammen beschrieben. Die einzigen Unterschiede sind in der Tabelle 2.2 zusammengefasst. Da im weiteren Verlauf dieses Abschnittes immer wieder neue Begriffe eingeführt werden, ist es empfehlenswert, die Abbildung 2.2 zur Hand zu haben. Die einzelnen Graphik-Verarbei- tungsstufen werden von “oben nach unten” erklärt, d.h. es wird schrittweise die Verarbeitung eines Graphikbefehls verfolgt - vom Empfang über den Bus bis hin zur Darstellung auf dem Monitor.

Indigo2 mit XZ Indigo2 mit Extreme Geometry Engines 48 (GE7 Prozessor) Raster Engines 12 (Typ 3) Tabelle 2.2: Hardware Komponenten der Graphiksysteme. 2.3 XZ und Extreme Graphiksystem 13

Das Herz des XZ und Extreme Graphiksystems sind die Geometry Engines (GE7). Das Design weist eine spezielle mirkoprogrammierte Architektur1 auf, die eine Implementation von verschiedenen Algorithmen ermöglicht. Zum eigentlichen Kern des allgemeinen Floating Point Instruktionssatzes wurden weitere Instruktionen hinzugefügt, sodass vor allem Algorithmen mit Graphikberechnungen effizient ausgeführt werden können.

Das Geometry Subsystem2 besteht aus vier bzw. acht solcher Geometry Engines. Diese Pro- zessoren sind in einer SIMD (Single instruction stream, multiple data stream) Struktur angeordnet. Dabei wird dieselbe Instruktion in mehreren Prozessoren auf verschieden Daten ausgeführt. Jeder Prozessor hat demnach seinen eigenen Datenspeicher. Es gibt jedoch nur einen Instruktionsspeicher und nur einen Kontroll-Prozessor, der die Instruktionen holt und an die anderen Prozessoren weiterleitet. Im Geometry Subsystem übernimmt der Geometry Sequencer die Aufgabe des Kontroll-Prozessors. Die Daten für die einzelnen GE7 Prozessoren werden von der Command Engine verteilt.

2.3.1 Die Standard Rendering-Pipeline Eine wichtige Rolle in der Verarbeitung von Graphikbefehlen übernimmt die Standard-3D- Graphik-Pipeline (Rendering-Pipeline) von SGI. Deren Aufgabe ist es, die erforderlichen Berechnungen durchzuführen, um von einem dreidimensionalen Objekt ein Rasterbild zu erzeugen. Das Ziel wird mittels folgender vier Stufen erreicht: 1. Das darzustellende 3D-Modell wird traversiert und die sichtbaren Teile des nächsten darzustellenden Bildes bestimmt. Typischerweise übernimmt die CPU diese Aufgabe. 2. Im Geometry Subsystem werden ¥ die Transformationen, ¥ die Beleuchtungsberechnungen und ¥ die Transformation von 3D-Welt- in 2D-Bildschirmkoordinaten vorgenommen. 3. In der Rasterverarbeitung laufen folgende Teilschritte ab: ¥ Zuerst wird die sogenannte Scan-Conversion durchgeführt Die in Bildschirmkoordinaten vorliegenden Graphikprimitiven werden in zusam- menhängende Gruppen von Pixeln aufgeteilt. ¥ Anschliessend wird für jedes einzelne Pixel einer Graphikprimitive mittels Z-Buf- fer-Algorithmus geprüft, ob der Bildpunkt sichtbar ist oder nicht (Hidden- Line/Surface). ¥ Danach erfolgt die Schattierung der gerasterten Graphikprimitive: Auf Basis der Ergebnisse der Beleuchtungsberechnung und in Abhängigkeit vom gewählten Schatteriungsverfahren (konstant oder Gouraud) gilt es dabei, die Farb- werte für jedes einzelne Pixel einer Graphikprimitive zu bestimmen.

1. Genau genommen handelt es sich um eine “general purpose microprogrammed floating point datapath architecture.” 2. Eine detaillierte Beschreibung befindet sich in 2.3.3. 14 2 Indigo2 XZ/Extreme und Maximum Impact von SGI

Gegegebenenfalls kommen noch weitere Operationen auf Pixelbasis hinzu wie etwa: ¥ Texture-Mapping1 ¥ Anti-Aliasing ¥ Nebeleffekte ¥ Stenciling ¥ Alpha-Blending etc. 4. Im letzten Schritt werden die Resultate aus der dritten Stufe in den Frame-Buffer geschrieben und schliesslich im RAM-DAC in analoge Signale umgewandelt.

2.3.2 Das CPU-Interface 2 Als Verbindung zur CPU dient der 64 Bit breite GIO64 Bus. Mit dem Burst Mode wird die maximale (theoretische) Busbandbreite beinahe erreicht. Um die CPU zu entlasten verwenden XZ und Extreme die DMA (Direct Memory Access) Technologie. Über die DMA Kanäle kann die Graphikkarte direkt mit dem Speicher kommunizieren (lesen und schreiben), ohne dass dabei die CPU belastet wird. Es kann pro Raster Engine Clock-Zyklus ein 32 Bit Wort übertra- gen werden, was eine sehr hohe Transferrate vom und zum Frame Buffer beziehungsweise Z- Buffer zur Folge hat. Dies kommt vor allem bei graphik-orientierten Applikationen zum Tra- gen, d.h. wenn grössere Datenmengen übertragen werden müssen.

Die Graphikbefehle werden mit ihren Daten im Weltkoordinaten Format über den GIO64 Bus übertragen und in den FIFO3 Speicher des Graphiksystems geschrieben. Dieser FIFO Buffer kompensiert Schwankungen der Latenz zwischen einer Applikation, welche Graphikbefehle generiert und des Graphiksystems, das die Befehle abarbeitet. Der erhaltene Strom von Gra- phikbefehlen wird analysiert und die Graphikprimitiven4 bestimmt, welche dann an die Geo- metry Engines (GE7) Prozessoren verteilt werden.

2.3.3 Das Geometry-Subsystem Wie bereits erwähnt, werden die GE7 Prozessoren in einer SIMD Struktur angeordnet. Dabei übernimmt der Geometry Sequencer die Aufgabe des Kontroll-Prozessors. Jeder GE7 Prozes- sor bearbeitet somit eine andere Graphikprimitive, welche aber alle zur selben Graphikinstruk- tion gehören. Dadurch können die Graphikinstruktionen in einem Clock-Zyklus abgearbeitet werden. Die Daten für die GE7 Prozessoren werden von der Command Engine verteilt. Jeder GE7 Prozessor besteht aus zwei separaten arithmetischen Blöcken, einer für Multiplika- tionen der andere für Additionen. Dank der kurzen Latenz der Mikro-Instruktionen erreicht jeder GE7 Prozessor eine Leistung von 32 MFLOPS.

1. Nur bei Indigo2 Maximum Impact in Hardware. 2. Die Datenwörter werden nicht einzeln, sondern zu grossen Blöcken zusammengefasst übertragen. 3. FIFO = First In First Out Speicherverwaltung. 4. Jedes Graphische Objekt lässt sich in seine Graphikprimitiven - Punkte, Linien, Dreiecke und Polygone - aufteilen. 2.3 XZ und Extreme Graphiksystem 15

Jeder Geometry Engine Prozessor erhält einen Strom von einfach-genauen FP-Wörtern, welche Punkte im 3D-Welt-Koordinatensystem (world coordinate system) repräsentieren. Mit Matri- zenoperationen werden Transformationen, Rotationen und Skalierungen berechnet. Im nächsten Schritt werden die einzelnen Punkte beleuchtet. Dazu stehen maximal acht Spot- lights zur Verfügung. Die Materialspezifikationen beeinhalten ambient, diffuse und specular reflectance Parameter und Informationen des Lichtmodels. Als Resultat dieser Beleuchtungs- berechnungen entsteht pro Punkt entweder eine Menge von acht Bit Red -, Green-, Blue- und Alpha-Werten (RGBα) oder ein einziger 12 Bit Farb-Index. Anschliessend findet die Transformation von 3D-Welt- in 2D-Bildschirmkoordinaten statt. Nachfolgend wird das Clipping berechnet, wobei der Cohen-Sutherland Algorithmus zum Ein- satz kommt. Im nächsten Schritt werden Triangle Meshes und Independant Quads aufgeteilt, da das Geome- try-System sie nicht direkt weiter verarbeiten kann. Als Resultat entstehen Dreiecke, die alle auf die gleiche Art und Weise von den restlichen Graphik-Pipelines behandelt werden können.

Für die Linien1 entfällt natürlich die Aufteilung in Dreiecke. Im letzten Schritt werden noch weitere Parameter der Linien oder Dreiecke bestimmt: ¥ Steigungen für die Linien ¥ Steigungen für Dreieckskanten und die Dreiecksﬂäche (in X und Y-Richtung) Die resultierenden Parameter werden von den GE7 Prozessoren ans Raster Subsystem weiter- geleitet.

2.3.4 Das Raster-Subsystem Die Raster Engine ist dafür verantwortlich, dass die Linien und Dreiecke zu individuellen Punkten aufgespalten werden, damit sie schliesslich in den Frame-Buffer geschrieben werden können. Dieser Vorgang wird als Scan-Konvertierung bezeichnet. Es wird über die Linien und Dreieckskanten iteriert, sodass Felder (Arrays) von Pixelwerten entstehen, die dann zum näch- sten Verarbeitungs-Block weitergeschickt werden können. Die Raster Engine hat eine Pipeline variabler Länge, welche je nach Operationsmodus zwischen 25 und 40 Stufen verwenden kann. Die Pipeline wird mit den Werten2 aus dem Geometry Sub- system geladen. Der Iterationsblock (Line and triangle iteration) traversiert die Linien oder Dreiecke und berechnet die Scan-Konvertierung.

1. In einigen Dokumentationen wird anstelle von Linien auch von Vektoren gesprochen. 2. Damit sind Pixel, Linien und Dreiecke mit ihren Parameter gemeint. 16 2 Indigo2 XZ/Extreme und Maximum Impact von SGI

Der Pixel Operation Block stellt den nächsten Verarbeitungsschritt dar und hat verschiedene Funktionen. ¥ Für die Pixel-blending-Operation und die Pixel-Raster-Operation, werden folgende Schritte durchgeführt: Für jeden erhaltenen Pixelwert1 aus dem vorangehenden Iterationsblock, wird die Adresse im Frame-Buffer bestimmt und der entsprechende Wert ausgelesen. Die beiden Pixelwerte - erhaltener und ausgelesener Wert - werden mittels der entsprechenden arithmetischen oder logischen Operation miteinander kombiniert. ¥ Für farbindizierte Linien mit Anti-Aliasing wird der Farbvergleich berechnet. ¥ Dunst- oder Nebel-Abschwächungen werden berechnet.

Der nächste Schritt findet im Pixel Test Block statt: Mittels eines vierfachen Tests (screen mask, clipping, z compare und stencil value check) wird hier effektiv bestimmt, ob ein Pixel auch wirklich in den Frame- oder Z-Buffer geschrieben werden soll. Jedes Pixel wird nun mit einem 56 Bit Wert gespeichert, welcher folgendermassen zusammengesetzt ist: ¥ 24 Bit Farbinformationen ¥ 24 Bit vorzeichenbehaftete Z-Bufferdaten. Für nicht Z-Buffer unterstützende Applika- tionen kann dieses Feld für ein zweites 24-Bit Farbfeld verwendet werden. ¥ 4 Bit für Over- oder Underlay Operationen, z.B. für Pop-Up Menüs ¥ 4 Bit für die Fenstergrenzen. Jedes geöffnete Fenster erhält eine 4 Bit Clipping ID (CID). Jeder nicht verdeckte Punkt eines Fensters hat dieselbe CID. Für jeden erhaltenen Punkt, aus dem vorangehenden Pixel Operation Block, wird die gespeicherte CID mit der erhaltenen verglichen. Nur bei einer Übereinstimmung wird der Pixelwert auch in den Frame-Buffer geschrieben. Die Z-Komponenten werden in einem separaten Z-Buffer abgespeichert. Damit nun die gleiche Fill Rate für z-Buffer unterstützte wie auch für nicht z-Buffer unterstützte Applikationen zur Verfügung steht, hat der Z-Buffer die doppelte Memory-Bandbreite wie der herkömmliche Frame-Buffer.

2.3.5 Das Display-Subsystem Das Display Subsystem erhält die Pixeldaten aus dem Frame-Buffer und sendet sie an den RAM-DAC weiter. Dabei wird jedem Pixel die sogenannte Display ID (DID) zugeordnet, welche den Farbformat-Modus bestimmt. Diese DID wird dem Multimode Graphics Proces- sor (MGP) übergeben, der die Bild-Informationen gemäss der DID entsprechend interpretiert und dem DA-Konverter weitergibt.

1. Der Pixelwert liegt in 2D Bildschirmkoordinaten vor und hat zusätzliche Parameter, welche z.B. die Farbe festlegen. 2.3 XZ und Extreme Graphiksystem 17

2.3.6 Die XZ und Extreme Graphic-Features Die XZ und Extreme Graphiksysteme bieten viele “Graphic-Features” an, die hier aber aus Platzgründen nicht alle erläutert werden können1.Die wichtigsten Features seien aber dennoch genannt: ¥ Punkt2 und Linien Anti-Aliasing ¥ Slope Correction: Sobald die Steigung einer Linie gegen 45 Grad geht, sollten die Pixel der Linie heller werden. Um diesen Effekt zu verstehen, stelle man sich zwei gleich lange Linien vor, wobei eine steil und die andere flach ist. Werden diese Linien nun gerastert, so benötigt die steile Linie weniger Rasterpunkte als die flache. In der Folge erscheint die steilere Linie heller als die flache. Um diese Helligkeitsunterschiede zu korrigieren, verwenden die Graphiksysteme eine Hardware-Lookup-Table, welche die Werte für die Steigung und Gewichte für die Überblendung der Subpixels enthält. Die Werte sind demnach grösser für steile Linien und kleiner für flache. ¥ Lighting Features, wie mehrere Lichtquellen, Beleuchtung von zwei Seiten, etc. ¥ Texture-Mapping mit Texturen die 8, 16, 24 oder 32 Bits Tiefe haben Bei den XZ und Extreme Graphiksystemen ist keine Hardware Unterstützung für Texture-Mapping vorhanden und alle Berechnungen müssen in Software durchgeführt werden und benötigen somit CPU-Rechenleistung. ¥ Stencil planes ¥ Pixel Read, Write und Copy: Das Graphiksystem hat einen 32 Bit DMA Kanal, der grosse Übertragungsraten zwischen dem Host, Frame-Buffer und Z-Buffer ermöglicht. Falls der Benutzer keinen Z-Buffer verwendet, so kann ein 24 Bit Bild im Z-Buffer gezeichnet werden und anschliessend als Frame in den Frame-Buffer kopiert werden. Wird das Kopieren mit dem Refresh des Bildschirms synchronisiert, so kann man den Effekt eines echten 24 Bit Double-Buffering erreichen.

In der Abbildung 2.2 ist schematisch der Aufbau der XZ und Extreme Graphikhardware dargestellt.

1. Informationen unter www.sgi.com 2. Ein Punkt mit Anti-Aliasing wird mittels einem 2*2 Gitter dargestellt, wobei jedes der vier Subpixels ein bestimmtes Gewicht zur Überblendung erhält. 18 2 Indigo2 XZ/Extreme und Maximum Impact von SGI

Abbildung 2.2: Das XZ und Extreme Graphiksystem in der Indigo2 2.4 Das Maximum Impact Graphiksystem 19

2.4 Das Maximum Impact Graphiksystem

In diesem Abschnitt ist das Schwergewicht auf die Unterschiede zum älteren Graphiksystem mit XZ/Extreme gelegt. Es sei auf die Abbildung 2.3 verwiesen, welche den schematischen Aufbau eines Maximum Impact Graphiksystems darstellt. Im Gegensatz zur XZ und Extreme Graphik ist die Maximum Impact Graphikhardware auf drei Boards verteilt worden (Siehe Abbildung 2.3): ¥ Auf dem ersten Board beﬁndet sich der HQ3 Chip, eine Weiterentwicklung des HQ2, sowie das Geometry- Subsystem. ¥ Die beiden anderen Boards sind weitgehend gleich aufgebaut, sie enthalten die beiden Rastersysteme mit der Texture Engine inklusive Texturspeicher, Z-Buffer und natür- lich dem Frame-Buffer. Ein Rastersystem (System B in Abbildung 2.3) enthält noch den RAM DAC. Standardmässig stehen den beiden Rastersystemen total 1 MB Texturspeicher zur Verfügung, mit der Texture-Option-Card lässt sich dieser jedoch auf gesamthaft 4 MB aufrüsten. Dieses Graphiksystem bietet zudem Hardware-Unterstützung für: ¥ Texture-Mapping ¥ Environment-Mapping ¥ Anti-Aliasing ¥ Alpha-Blending ¥ Nebeleffekte 20 2 Indigo2 XZ/Extreme und Maximum Impact von SGI

Abbildung 2.3: Das Indigo2 Maximum Impact Graphiksystem 3 3Die O2 von SGI

Bild SGI

Die O2 ist das Einstiegsmodell der heutigen SGI Reihe. Sie ist nicht nur äusserlich einiges kom- pakter als die nächst grösseren Indigo2 Systeme, sondern auch preislich attraktiver. Ausgestat- tet entweder mit einem MIPS R5000 oder MIPS R10000 Prozessor stellt sie aber dennoch eine leistungsfähige Desktop Workstation dar. Die O2 verwendet die Unified Memory Architecture (UMA) Technologie. Dieses Konzept konzentriert Z-Buffer, Frame-Buffer, Textur- und Videospeicher, sowie System- und User- memory in einem Speicherpool, von dem jede System-Komponente je nach Bedarf Segmente anfordern kann. Ausserdem bietet die O2 weitere Spezialkomponenten, die auf professionelles Audio-, Video- sowie Graphik- und 3D-Image-Processing in Echtzeit ausgelegt sind. Eine herausragende Graphikleistung wird vor allem dank direkt in Hardware implementierten Graphic-Features erreicht. So werden etwa das Texture-Mapping und OpenGL Befehle durch spezielle Hardware unterstützt. Auch das Video-processing wird durch spezielle Hardware beschleunigt. Dadurch ist Motion-JPEG und MPEG Kompression und Dekompression in Echt- zeit für die O2 kein Problem.

21 22 3 Die O2 von SGI

3.1 Systemarchitektur

In diesem Abschnitt soll die besondere Systemarchitektur der O2 und deren Einfluss auf die Graphikleistung erläutert werden.

3.1.1 Systemplatine

Die nachfolgende Abbildung zeigt den schematischen Aufbau der Systemplatine einer O2.

Abbildung 3.1: Die O2 Systemplatine mit einem R5000 Prozessor 3.1 Systemarchitektur 23

Die zentrale Einheit der O2 ist die Memory Engine (MRE). In ihr werden Informationen verwaltet, welche die CPU zur Bearbeitung der Prozesse benötigt. In der Image und Compression Engine (ICE) befinden sich Hardwareunterstützungen für folgende Features: ¥ z-Buffer ¥ triangle rasterization ¥ texture-mapping ¥ image mapping ¥ stencil planes ¥ anti-aliasing ¥ source plus destination alpha ¥ Video Kompressionshardware: Motion-JPEG mit 30 respektive 25 Bildern pro Sekunde in NTSC oder PAL Qualität. Der letzte Punkt hat zur Folge, dass der SpecInt95 JPEG Compression Test natürlich durch die Hardware massiv beschleunigt wird (Siehe auch 11.3). Obwohl die O2 spezielle Hardware für Graphikunterstützung hat, müssen alle Geometrie- und Beleuchtungsberechnungen im Hauptprozessor verarbeitet werden. Dies sieht zuerst wie ein Nachteil aus. Die Rechenleistung lässt sich jedoch sehr einfach durch einen Austausch des Pro- zessors erhöhen - es kann sozusagen mit “einem Handgriff” der R5000 durch einen R10000 oder R12000 ersetzt werden. Es gilt jedoch zu beachten, dass der R10000 Prozessor seine volle Leistungsfähigkeit in einem O2-System nicht entfalten kann (Siehe hierzu 3.1.3).

3.1.2 Die Prozessoren: MIPS R5000 und R10000 Die O2 kann wahlweise mit dem R5000 oder mit dem leistunsstärkeren R10000 bestückt werden. Das Ziel dieses Abschnittes soll nicht die detaillierte Beschreibung der beiden Prozessor- architekturen sein, sondern es werden die MADD Instruktionen des MIPS IV Instruktionssatzes und das Verhalten des R10000 in einer O2 erläutert (Siehe Abschnitt 3.1.3). Der MIPS R5000 ist ein klassischer Reduced Instruction Set (RISC) Prozessor, der 1996 auf den Markt kam. Er stellt sozusagen den kleineren Bruder des teureren und leistungsstärkeren R10000 dar. Damit die Kosten in der Produktion gesenkt werden konnten, mussten einige Fea- tures des R10000 weggelassen werden, denn das Ziel war ganz klar einen Prozessor mit sehr gutem Preis-Leistungsverhältnis zu produzieren. In der Tabelle 3.1 werden die wichtigsten Ausstattungsmerkmale der beiden Prozessoren sowie dem R4400 einander gegenübergestellt. Für die Tests der Integer und Floatingpoint Rechenleistung der Prozessoren, sei auf das Kapitel 11.3 verwiesen. Die sogenannten MADD Instruktionen und einige Besonderheiten der Prozessorarchitektur, welche bezüglich der Graphikleistung relevant sind, sollen hier näher beleuchtet werden. 24 3 Die O2 von SGI b bietet noch R4400 MC R4400 SC, PC, MC (nur R4400 MC) ja Nein 128 Bit Data Bus, Min KB Max. 4 MB (max.) 128 byte cache line refill a Ausführung hat nur den primary cache. Der R5000 SC, PC PC (nicht in der ersten Version) Ausführung hat nur den primary cache. PC Dual Issue: FP Load/Store und ALU In- struktionen geladen im selben Zy- klus 64 Bit Data Bus, Min 512 KB Max. 2 MB (max.) 32 byte cache line refill R10000 ANDES (Advanced Superscalar Architec- ture) mit 4 Instruktionen pro Zyklus: 2 INT und FP execute 1 Load/Store pro Zyklus 128 bit Data Bus, Min. 512 KB Max. 16 MB (max.) 128 byte cache line refill Variante ist sowohl ein primary und secondary cache vorhanden, die ein primary und secondary cache vorhanden, ist sowohl Variante MC und Variante ist sowohl ein primary und secondary cache vorhanden, die ein primary und secondary cache vorhanden, ist sowohl Variante Vergleich zwischen den MIPS Prozessoren R10000, R5000 und R4400 SC SC zusätzlichen Support für Multiprozessor Systeme. a. Bei der Bei der b. Superskalare Architektur MADD Instruktionen ja ja nein PipelineInstruktionssatzPrimary Data CachePrimary Instruction CacheSecondary Cache Unterstüt- 32 KBytes MIPS-IV 32 KByteszung 5-fach 32 KBytes 32 KBytes MIPS-IV 5-fach 16 KBytes 16 KBytes MIPS-III 8-fach Branch PredictionDaten AbhängigkeitenTranslation look aside buffer 64 Einträge ja Register renaming/out of order exec.Multiprozessor unterstützt nein ja 96 Einträge nein nein nein 96 Einträge nein Tabelle 3.1: 3.1 Systemarchitektur 25

Die MADD-Instruktionen

Der MIPS IV Instruktionssatz unterstützt gegenüber dem MIPS III Instruktionssatz, wie er in einem R4440 verwendet wird, vier zusätzliche Floating Point (FP) Instruktionen mit einfacher und doppelter Genauigkeit, die in einem Zyklus zwei separate FP Berechnungen durchführen können. Die vier genannten Instruktionen umfassen:

¥ MADD: Multiply-add; bzw. NMADD Negatives MADD

¥ MSUB: Multiply-subtract; bzw. NMSUB Negatives MSUB

In den nachfolgenden Beispielen stehen die Variablen (A-D) stellvertretend für Registernamen des Prozessors. Betrachten wir zunächst das Beispiel für eine MADD Instruktion:

AB× + C = D

Dies sollte aber nicht mit dem bekannten MAC (multiply-accumulate) verwechselt werden, das lediglich

AB× + C = C berechnet.

In der dreidimensionalen Geometrie wird typischerweise jeder Knoten eines 3D-Objekts durch einen Vektor repräsentiert. Die meisten 3D-Verarbeitungsschritte multiplizieren nun diesen Vektor mit einer Transformationsmatrix. Als Resultat entsteht wiederum ein Vektor, welcher entweder zu einem anderen Knoten(-vektor), oder wie bei Filteroperationen üblich zum ursprünglichen Wert desselben Knotens addiert wird. Man spricht bei diesen Filteroperationen von Faltung.

Der eigentliche Clou dieser MADD Instruktionen liegt darin, dass die Implementation so gewählt wurde, dass diese Instruktionen eine Wiederholrate von einem und eine Latenz von vier Zyklen haben. Dank sub-pipelining kann die Fliesskomma-Einheit (FPU) die Multiplikation und Addition der Komponenten des oben beschriebenen Matrizenproblems parallel lösen. In herkömmlichen Prozessoren wie etwa dem R4400, wird das MULTIPLY ausgeführt und das Resultat ins Register geschrieben um nachher vom ADD gelesen, berechnet und schliesslich wieder zurückgeschrieben zu werden.

Dual-Issue

Ein weiterer Vorteil dieser Prozessorarchitektur betrifft das Pipelining. In jede der fünf Pipeli- nestufen kann je eine MADD-Instruktion nacheinander geladen werden, sodass der Prozessor in jedem Zyklus eine neue MADD-Instruktion und gleichzeitig noch eine Integer oder FP Load/Store Instruktion ausführen kann. Allgemein kann dank diesem Dual-Issue Mechanis- mus neben einer FP ALU Instruktion simultan ein anderer Instruktionstyp ausgeführt werden. 26 3 Die O2 von SGI

Kombination von MADD-Instruktionen und Dual-Issue Das Zusammenspiel von MADD Instruktionen und Dual-Issue Mechanismus wird vor allem deutlich, wenn man beachtet, dass die meisten Applikationen, welche Geometrie Berechnungen beinhalten, nach einem FP Load/Store eine MADD Instruktion ausführen: Die Load/Store Instruktionen werden in der Pipeline verarbeitet, die währenddessen noch genug Kapazität auf- weist, um eine neue MADD Instruktion in jedem Clock-Zyklus auszuführen. Gut strukturierter Code, wie etwa der von OpenGL Befehlsbibliotheken, können diese Pipeline Struktur voll aus- nutzen.

3.1.3 Der R10000 in der O2 Die Floatingpoint Rechenleistung steigert sich durch den Einsatz eines R10000 in einer O2 anstelle des R5000 nicht in dem Ausmass, wie es zu erwarten wäre. Insbesondere wenn der Ver- gleich mit einem R10000 in der Octane gemacht wird, kann man feststellen, dass die SpecFP95 Werte deutlich tiefer ausfallen (Siehe 11.3). Die Integer Rechenleistung lässt sich hingegen massiv erhöhen. Die wichtigsten Gründe, weshalb der R10000 in der O2 nicht seine volle Floa- tingpoint Rechenleistung ausspielen kann, sind nachfolgend erwähnt: ¥ Das Prozessor Modul enthält Schaltkreise, die für den R5000 entwickelt wurden und bei einem Austausch des Prozessors unverändert bleiben. Insbesondere ist das Second Level Cache nur für 32 Byte Refills dimensioniert, der R10000 erlaubt aber 128 Byte Refills. Dies hat zur Folge, dass ein 128 Byte Refill des R10000 in vier 32 Byte Refills konvertiert werden muss, was die Cache Miss Strafe massiv erhöht. Deshalb liefert der SpecFP95 der O2 schlechtere Resultate als in vergleichbaren SGI Systemen (Siehe auch 11.3).

¥ Der R10000 bringt nicht viel zusätzliche Leistung für 3D-Graphik Aufgaben, wenn diese nicht 64 Bit Verarbeitung brauchen. Die meisten 3D-Berechnungen brauchen nur einfach genaue Floating Point Arithmetik (32 Bit), besonders bei Geometrie- und Beleuchtungsberechnungen. Demnach kann ein R5000 mit 180 MHz schneller als ein R10000 mit 150 MHz sein. Der R10000 ist jedoch bei gleicher Taktfrequenz für gewisse Graphik Aufgaben um ca. 25% schneller, vor allem wenn sie 64 Bit Verarbei- tung brauchen, wie zum Beispiel das Gouraud Shading.

¥ Der R10000 war nie für Speichersysteme mit Uniﬁed Memory Architecture (UMA) entwickelt worden. Er wurde für viel schnellere Speichersysteme wie etwa das der Octane oder Onyx entwickelt. Das Speichersystem einer O2 läuft mit einer tieferen Taktrate und hat grössere Speicher Latenzen1. Ausserdem beträgt der Durchsatz des

1. Speicher Latenzen werden durch zwei Messwerte charakterisiert - die access time und cycle time. Erstere misst die Zeit, die vergeht bis nach einem READ Request das entsprechende Speicherwort zu- rückgeliefert wird. Die cycle time definiert die minimale Zeit, welche zwischen zwei aufeinanderfol- genden READ Requests zu vergehen hat. Der Ausdruck “grössere Speicher Latenz” impliziert also eine längere Zugriffszeit und eine grössere cycle time. Die cycle time ist bei DRAMs grösser als die access time. Der Hauptgrund liegt darin, dass die Adressleitungen zwischen zwei Speicherzugriffen stabil sein müssen. Bei SRAMs hingegen ist, aufgrund der anderen Bauweise, die access time mit der cycle time identisch und etwa 8 bis 16 mal schneller als die entsprechenden Werte der DRAMs. 3.1 Systemarchitektur 27

Busses vom Prozessor-Modul zum Hauptspeicher bei einer O2 rund 800 Mbyte/sec in einer Richtung (simplex). Die Octane erreicht mit der Crossbar Technologie, welche den Bus ersetzt, 1.6 GByte/sec in beiden Richtungen, (Siehe Abschnitt 4.2.2).

Um eine grössere Leistungssteigerung für den R5000 sowie für den R10000 zu erzielen, kann das Second Level Cache auf seine maximale Kapazität vergrössert werden, siehe hierzu auch Tabelle 3.1.

3.1.4 Der Speicher (UMA)

Die O2 verwendet als einzige der getesteten Maschinen die Unified Memory Architecture (UMA). Die Grundidee besteht darin, nur einen zentralen physikalischen Speicher zu verwenden, dessen Zugriffszeit aus Sicht des Prozessors uniform ist. Im Gegensatz dazu steht der her- kömmliche Aufbau, die sogenannte Non-Unified Memory Architecture (NUMA). Das Memory erscheint zwar aus logischer Sicht auch nur als ein Block, doch physikalisch ist der Speicher über die verschiedenen Subsysteme verteilt. So befindet sich zum Beispiel das Video RAM auf der Videokarte. Dadurch entstehen aus der Sicht des Prozessors unterschiedliche, nicht uniforme Zugriffszeiten. Es dauert somit länger das Video RAM anstelle des Hauptspei- chers anzusprechen. Im Weiteren kann der Speicher mit UMA effizienter verwaltet werden als mit NUMA. Um dies zu illustrieren werde angenommen, dass sich auf einer Graphikkarte 16 MB und auf einer Videokarte1 2 MB RAM befinden. Falls zu einem Zeitpunkt auf der Graphikkarte lediglich 4 MB alloziiert sind, so gehen die restlichen 12 MB sozusagen verloren und können nicht von Videokarte als zusätzlichen Buffer angesprochen werden. Die UMA kennt diese Art von Pro- blemen nicht, da die Subsysteme dynamisch die Speichermenge beanspruchen, die sie gerade brauchen. Dazu kommt noch, dass Speicherbausteine für den lokalen Speicher (Video RAM, Texture-Memory etc.) einiges teurer als herkömmliches Memory sind.

Durch UMA werden auch Datentransferzeiten reduziert. Oftmals werden Daten vom Haupt- speicher zu den peripheren Geräten, die am Bus hängen, gesendet beziehungsweise empfangen. Da aber nur noch ein physikalischer Speicher vorhanden ist, können solche Transfers entfallen. Zudem stellt der Bus in herkömmlichen Systemen, insbesondere für Graphikverarbeitung, oftmals den Flaschenhals dar. So reichen die maximalen Transferraten auf einem PCI Bus für gewisse Anwendungen nicht aus, um die Daten zwischen einer Graphikkarte und dem Haupt- speicher mit der geforderten Leistung zu übertragen. Als Ausweg haben sich die Hardware Her- steller, allen voran Intel, daran gemacht sogenannte private Busse zwischen den einzelnen Subsystemen einzuführen, wie dies auch in Abbildung 3.3 dargestellt ist. Das eigentliche Pro- blem wird dadurch nur lokal zwischen diesen am privaten Bus angeschlossenen Komponenten gelöst. Es kann leicht vorkommen, dass auf irgend einem anderen Bus (zum Beispiel PCI Bus) wieder ein Engpass entsteht. Der sicherste Ausweg ist die Crossbar Technologie, wie sie in grösseren und leistungsfähigeren Systemen wie etwa in der Octane verwendet wird (Siehe Abschnitt 4.2.2).

1. Z.B. eine Frame-Grabber Karte für VHS Videosignalverarbeitung. 28 3 Die O2 von SGI

Abbildung 3.2 zeigt schematisch zusammengefasst die Architektur der O2, die sich aber leicht für ein beliebiges UMA System verallgemeinern lässt. In SGI’s neuester Rechnerreihe, den Visual Workstations mit Windows NT, wird die UMA Technologie so realisiert, dass Gra- phik- und Hauptspeicher einen gemeinsamen physikalischen Speicher bilden. In der Sprache des SGI Marketings nennt sich das Ganze schliesslich Integrated Visual Computing Archi- tecture (IVC). Es standen zu Testzwecken jedoch noch keine derartigen Maschinen zur Verfü- gung, weshalb in dieser Arbeit auch nicht weiter darauf eingegangen werden soll1. Wie schon erwähnt verwenden alle anderen PC-Systeme die NUMA Technologie. Von besonderer Bedeutung ist hier Intel's Accelerated Graphics Port (AGP), der die Rolle eines privaten Busses zwischen CPU und Graphikkarte übernimmt (Siehe Abschnitt 7.1.1).

Die besonderen Vorteile der UMA Technologie bezüglich Graphikperformanz werden im nachfolgenden Abschnitt 3.2 genauer beschrieben.

1. Eine nähere Beschreibung findet man unter www.sgi.com. 3.1 Systemarchitektur 29

Abbildung 3.2: Unified Memory Architecture (UMA) in der O2

Abbildung 3.3: Non-Unified-Memory-Architecture (NUMA) 30 3 Die O2 von SGI

3.2 Graphikleistung

In diesem Abschnitt werden die Vorteile der UMA Technologie hervorgehoben, sowie ein Ver- gleich mit den SGI-Rechnern der nächst höheren Preisklasse vorgenommen. Es muss hier noch bemerkt werden, dass die Indigo2 Systeme mit XZ und Extreme Graphikhardware schon einige Jahre vor der O2 auf den Markt gekommen sind und sich deshalb ein direkter Vergleich dieser beiden Systeme (Siehe Abschnitt 3.2.2) aus technischer Sicht als etwas unfair gestaltet. Es ist nicht weiter verwunderlich, dass die um einige Faktoren teurere Indigo2 mit Maximum Impact gegenüber der O2 noch einige Leistungsreserven hat, was vor allem auf die aufwendige Gra- phikverarbeitung zurückzuführen ist.

3.2.1 Allgemeine Bemerkungen

Wie schon erwähnt führt die O2 alle Geometrie- und Beleuchtungsberechnungen im Hauptpro- zessor aus. Da der R5000 und insbesondere der R10000 eine hohe Rechenleistung haben, konnte die Leistung der Systeme mit speziellen Graphik-Beschleunigerboards erreicht und einigen Fällen sogar übertroffen werden. Vor allem können die Graphics Engines (GE) der Indigo2 Modelle mit XZ und Extreme Graphikhardware mit der Rechenleistung einer O2 nicht mehr mithalten (Tabelle 3.2). Die GE’s stellen somit den eigentlichen Engpass dar.

Dank der UMA Technologie kann die O2 im gleichen physikalischen Speicher Texturen, 3D- Szenen etc. verwalten. Braucht nun eine Anwendung plötzlich mehr Textur Speicher, so kann dieser ohne Einschränkung alloziiert werden. Die einzige Limite stellt die aktuelle im System installierbare Speichermenge dar, die zur Zeit bei 1 GByte liegt. Bei den Beschleunigerboards hingegen kommt irgendwann der Punkt, wo der lokale Speicher erschöpft ist und zeitaufwen- dige Transfers zwischen dem Hauptspeicher und den Graphikboards notwendig werden. Eben- falls entfallen kann zum Beispiel auch das sogenannte Textur Uploading, d.h. das Kopieren der Texturdaten vom Hauptspeicher in den lokalen Speicher des Graphiksystems.

Ein weiterer Vorteil der UMA Technologie liegt darin, dass jedes Subsystem immer genug Memory-Bandbreite zur Verfügung hat. Das O2 System hat mehr als 2.1 GByte/sec Memory- Bandbreite (Siehe Abbildung 3.1). Herkömmliche Systeme mit einem PCI Bus, stossen dann sehr bald an ihre Kapapizitätsgrenzen.

Auch für Echtzeit-Applikationen ergeben sich Vorteile aus der UMA Technologie. Es gibt zum einen keinen Engpass auf dem Bus und zum anderen ist ein UMA System flexibler, da die Daten schon dort sind, wo sie eigentlich gebraucht werden. Der Prozessor kann sozusagen in Echtzeit auf allen Daten arbeiten, da das zeitraubende Kopieren entfällt. Das nachfolgende Beispiel zeigt sehr deutlich, dass die eigentlichen Stärken einer O2 vor allem in der Echtzeit-Verarbeitung lie- gen1. In einer virtuellen militärischen Trainingsumgebung ist es notwendig, dass Videodaten eines Infrarot-Sensors in Echtzeit importiert und gewisse Bildberechnungen und Manipulationen vorgenommen werden. So wird unter anderem die Charakteristik des Bild-Rauschens verändert. Dieser bearbeitete Videostream wird dann als realtime Textur für eine 3D-Szene verwendet. In

1. Quelle SGI. 3.2 Graphikleistung 31 der letzten Stufe wird - ebenfalls in Echtzeit - die gesamte Trainingssession mit Hilfe der ICE mittels Motion JPEG komprimiert und schliesslich als Film abgespeichert.

3.2.2 Vergleich mit Indigo2 Systemen

Wie bereits im vorangehenden Abschnitt erläutert wurde, braucht die preislich sehr attraktive O2 einen Vergleich mit den Indigo2 Graphics Engines (GE) nicht zu scheuen, wie die folgende Tabelle illustriert1. Bei den Indigo2 Systemen bezieht sich die angegebene Leistung auf die Graphic-Engines im Geometry-Subsystem, wohingegen bei der O2 der Prozessor die Graphik- Berechnungen übernehmen muss.

Systeme Totale MFLOPS Indigo2 XZ 128 Indigo2 Extreme 256 Indigo2 Solid IMPACT 480 Indigo2 High IMPACT 480 Indigo2 Maximum IMPACT 960 O2 mit R5000 @ 150 MHz ca. 300 O2 mit R10000 @ 250 MHz ca. 500

Tabelle 3.2: Übersicht der Graphikleistung

Der hauptsächliche Unterschied in der Leistung zwischen einem Indigo2 XZ/Extreme und einer O2 beruht auf dem Umstand, dass ersteres System keine Texture Hardware hat. So kann die O2 bei gewissen Graphikbefehlen bis zu 100 mal schneller sein.

Andere wichtige Hauptunterschiede seien summarisch aufgezählt:

¥ O2 hat Hardware Anti-Aliasing

¥ O2 hat einen 32 Bit Z-Buffer

¥ O2 hat einen unlimitierten Textur Speicher (nur begrenzt durch Hauptspeichergrösse, dank UMA)

¥ O2 bietet viel Hardwareunterstützung im Bereich Video Verarbeitung

1. Quelle SGI. 32 3 Die O2 von SGI

Sobald komplexere Geometrie und Beleuchtungsberechnungen, wie zum Beispiel mehrere Spotlights und komplexere Szenen vorliegen, reicht die Hardware-Unterstützung der Indigo2 Systeme nicht mehr aus und der Prozessor muss die Arbeit übernehmen1. Zusätzlich müssen die ganzen Daten auch noch über den Bus geschickt werden, was nochmals viel Zeit kosten kann. Insbesondere dann, wenn der begrenzte Textur Speicher bei Indigo2 Maximum Impact Syste- men2 nicht mehr ausreicht und deshalb auch Texturdaten über den Systembus geschickt werden müssen. Daraus kann man ableiten, dass Graphikarbeiten, welche komplexe Beleuchtungen und dynamische 3D-Szenen enthalten, oftmals dazuführen, dass die FIFO’s3 der Graphikkarten aufge- füllt und zeitraubende Context-switches notwendig werden. Ein weiterer Vorteil der O2 gegenüber den älteren Indigo2 Modellen mit XZ/Extreme Graphik, ergibt sich aus der Verwendung des neueren und leistungsfähigeren Prozessors R10000 4. Ins- besondere beinhaltet der MIPS IV Instruktionssatz die MADD Instruktionen, die beim R4400 nicht vorhanden sind.

1. Es gibt grundsätzlich zwei Arten von Überlast: Zum einen die zeitliche Überlast, d.h. zuviele Graphikprimitiven/sec werden dem Graphiksystem übergeben. Zum anderen eine Überlast im Sinne der unterstützten Hardware-Features der Graphiksy- steme. Werden zum Beispiel drei Spotlights benötigt und das Graphiksystem unterstützt lediglich zwei in Hardware, so muss die Berechnung ebenfalls auf die CPU ausgelagert werden. 2. Indigo2 XZ und Extreme haben keinen Texturspeicher. 3. FIFO-Queues für die Graphikbefehle in den Command Engines der Graphiksysteme. 4. Nur in den Modellen Indigo2 Maximum Impact. 4 4Die Octane von SGI

Bild SGI

Mit den Octane Systemen, welche 1997 auf dem Markt eingeführt wurden, hat SGI ihre Rech- nerreihe vervollständigt. Die Octane ist zwischen der verhältnismässig günstigen O2 und der äusserst leistungsfähigen Onyx2 positioniert. Die Indigo2 Maximum Impact Systeme gehören eigentlich nicht in diese Reihe, sie können aber für einen Vergleich oberhalb der O2 angesiedelt werden. Eine solcher Vergleich ist allerdings etwas heikel, da die O2 hat einerseits eine geringere Graphikleistung1, aber hat andererseits zusätzliche Hardware für Videobearbeitung und kann deshalb die Leistung einer Indigo2 Maxi- mum Impact bei weitem übertreffen.

Das Kernstück der Octane-Systemarchitektur bildet ein Crossbar-Switch, welcher alle Kom- ponenten im Rechner miteinander verbindet. Dank dieser Technologie kann eine durchschnitt- liche Übertragungsrate von 1.2 GByte/sec beziehungsweise bis zu 1.6 GByte/sec bei kleinen

1. Siehe Resultate mit Viewperf unter 11.1

33 34 4 Die Octane von SGI

Peak-Transfers erreicht werden. Damit lassen sich im Vergleich zu Vorgängern wie Indigo2 Systemen - bei gleicher CPU-Ausstattung1 - spürbare Leistungsgewinne erzielen.

Ausgestattet wird die Octane mit maximal zwei MIPS R10000 Prozessoren. Damit verfügt das System über genügend Leistungsreserven für die Berechnung komplexer 2D- und 3D-Modelle.

4.1 Die Octane Modelle

Die ursprünglichen Modelle aus dem Jahre 1997 basieren auf der I-Serie und werden als SI, SSI und MXI bezeichnet. Als Grundlage dient für alle drei Modelle zum einen die Geometry- Engine, mit einer Rechenleistung von 960 MFLOPS und zum anderen die Raster-Engine mit 120 Mpixel/sec. Die interne Architektur des Graphiksystems entspricht dem der Indigo2 Maxi- mum Impact (Siehe Abschnitt 2.4). Das Indigo2 Graphiksystem lässt sich aber nicht direkt in der Octane weiterverwenden beziehungsweise einbauen. Das Octane-Graphiksubsystem steht direkt mit dem Crossbar-Switch in Verbindung, wohingegen bei der Indigo2 die Graphikkarten über einen konventionellen Bus mit dem System verbunden sind.

Im Gegensatz zur Octane SI, enthalten die SSI und MXI Ausführungen die doppelte Anzahl Graphic-Engines, nämlich zwei Geometry- und Raster-Engines. Die Octane SI Modelle besitzen eine und die SSI und MXI zwei Texture-Engines, welche jedoch nur in Zusammenhang mit dem entsprechenden Texturspeicher funktionsfähig sind (Vrgl. Abbildung 4.2).

Da SI und SSI standardmässig ohne Texturspeicher ausgerüstet sind, muss zuerst die Texture- Cache-Option installiert werden, um von der Texture-Engine Gebrauch zu machen. Pro Texture-Engine muss je eine solche Option, welche 4 MB Texturspeicher umfasst, installiert werden. Somit braucht die SI Variante ein Texture-Cache-Option mit 1 x 4 MB und die Octane SSI 2 x 4 MB. Es sei nochmals erwähnt, dass die SSI Ausführung zwei Graphic-Engines mit je einer Texture-Engine hat und deshalb auch je einen Texturspeicher pro Graphic-Engine benö- tigt. Eine Octane SSI mit Texturspeicher ist somit gleichwertig wie die MXI Ausführung, welche bereits standardmässig mit 2 x 4 MB Texturspeicher ausgerüstet ist. Folglich kann eine Octane MXI auch keinen zusätzlichen Texturspeicher mehr aufnehmen. Die Abbildung 4.2 illustriert den Aufbau der Octane Graphiksysteme der I und E Serie.

Seit 1998 sind die drei neueren Octane Basismodelle der E-Serie erhältlich. Sie basieren alle auf SGI’s Geometry Engines, die 1344 MFLOPS erreichen und der Raster Engine, welche 138 Millionen Gouraud-schattierte und texturierte 3D-Pixel/sec verarbeiten kann.

1. MIPS R10000 in Indigo2 Maximum Impact. 4.2 Systemarchitektur 35

Nachfolgend werden die drei Modelle kurz vorgestellt: ¥ Octane SE: Einfachste Ausführung: Die Graphikhardware besteht aus einer Geome- trie- und Rasterengine und belegt einen XIO-Port. Ein solches System soll laut Herstel- ler für Aufgaben wie Solid Modelling verwendet werden. Gegen einen grösseren Aufpreis lässt sich der Texturspeicher auf 4 MB aufrüsten (Texture-Cache-Option) ¥ Octane SSE: Sie verfügt über zwei Geometrie- und Rasterengines, die somit zwei XIO-Ports belegen und soll gemäss SGI beim Solid Modelling die doppelte Leistung der Octane SE erbringen. Auch hier gibt es die Texture-Cache-Option: Das System ist dann äquivalent zu einer Octane MXE. ¥ Octane MXE: Das High-End System mit ebenfalls zwei Geometrie- und Rasterengi- nes und zusätzlichem Texturspeicher von 2 x 4 MB. Bemerkenswert ist, dass sich der Kunde, bezogen auf die preisgünstige O2 mit R5000 Prozessor, etwa die vierfache CPU- und Graphikleistung zum circa zehnfach höheren Preis erkauft.

4.2 Systemarchitektur

Wie schon in der Einleitung erwähnt, bildet der Crossbar-Switch das Kernstück der Octane Systeme (Siehe Abschnitt 4.2.2). Wie bei den meisten SGI Systemen, fehlen auch der Octane interne Wechselmedien wie etwa CD-ROM- oder Zip/Jaz-Laufwerke.

4.2.1 Systemplatine Zur besseren Orientierung ist in der Abbildung 4.1 der Aufbau der Octane-Systemplatine abge- bildet. Auf dem CPU Board, das für die Aufnahme von maximal zwei R10000 ausgelegt ist, befinden sich neben den Second Level Caches der Prozessoren auch noch die SDRAM-Spei- chermodule. Gegenüber der älteren I Serie (SI, SSI. MXI) werden die Prozessoren mit maximal 250 MHz getaktet: Dadurch, erklärt SGI, wird bei gleichen Cache1 Grössen die Rechenleistung um ca. 25% erhöht. Leider stand zu Testzwecken kein System der I-Serie zur Verfügung, um dies auch selber nachvollziehen zu können. Zu Bemerken gilt auch, dass der R10000 in der Octane eine bedeutend bessere Fliesskommalei- stung erbringt als in einem Indigo2 Maximum Impact System. Die beiden wichtigsten Gründe für diesen Leistungsunterschied sind einerseits der 128 Bit breite Datenpfad2 von der CPU zum Second level cache und andererseits kommen in der Octane - wie auch in der O2 - eine schnellere und synchrone Variante von DRAM Speicherbausteinen zum Einsatz.

1. Primary und secondary cache. 2. Indigo2 verwendet 64 Bit. 36 4 Die Octane von SGI

Standardmässig sind die Octane Systeme mit einem 24-Bit Audio-Subsystem, 10/100Base-TX- Ethernet und Dual-Host-SCSI Schnittstellen ausgestattet. Ebenfalls zur Basisausstattung zählen zwei serielle und ein bidirektionaler paralleler Port.

Neben drei Standard PCI Slots befinden sich auf dem Mainboard auch vier XIO Ports, in denen die XIO Options Karten eingesetzt werden können. Diese XIO-Ports bilden eine direkte Ver- bindung mit dem Crossbar-Switch. Zur Zeit sind diverse Optionskarten erhältlich, wie etwa Netzwerkkarten und SCSI-Optionskarten. Besonders interessant sind jedoch die drei Video Optionskarten, deren Möglichkeiten hier kurz dargestellt werden.

¥ Digital Video: Es können zwei separate und unkomprimierte Videoströme im 4:2:2 Format in Echtzeit verarbeitet werden. Beide Ströme können in realtime direkt in den Hauptspeicher oder auf eine Harddisk1 geschrieben werden. Neben diversen genormten Ein- und Ausgängen2, bietet diese Karte auch spezielle Hardware Unterstützung für:

¥ Farbumsetzung des Videosignals von YUV 3 nach RGB in 24 Bit Auﬂösung

¥ Real-time Video-Texturen

¥ Personal Video: Dies ist die kleinere Variante der Digital Video Option, wobei aus Preisgründen einige Features weggelassen werden mussten, wie etwa die Video-Textur Unterstützung.

¥ Compression: Das Compression-Board erlaubt die Echtzeit-Komprimierung von zwei unabhängigen Videoströmen im Motion-JPEG Format, mit einer minimalen Kompressionsrate von lediglich 2:1. Dieses Board besitzt zwei Ein- und Ausgänge im S-Video Format. Dank einer direkten Verbindung zur Digital Video Option, können jedoch auch zwei unabhängige CCIR- 601 Videoströme in Echtzeit mit Motion-JPEG komprimiert und dekomprimiert werden.

1. Nur mit externem Ultra SCSI oder Fibre Channel Interface möglich. 2. Zwei Ein- und Ausgänge für SMPTE 259M und CCIR-601 serial digital video. 3. YUV-Farbraum, Europäische Fernsehnorm. 4.2 Systemarchitektur 37

Abbildung 4.1: Die Octane Systemplatine 38 4 Die Octane von SGI

4.2.2 Die Crossbar-Switch Technologie

Die Leistungsfähigkeit der Subsysteme in den Computern hat in den letzten Jahren eine rasante Entwicklung durchlaufen. Eine massive Steigerung des Daten-Durchsatzes war die Folge. Damit erhöhten sich aber auch laufend die Anforderungen an den Systembus: Immer grössere Datenmengen sollen in immer kleiner werdenden Zeiteinheiten übertragen werden können. Schlussendlich müssen alle Daten von einem Subsystem zum anderen über den Bus übertragen werden. Damit ist die Grundvoraussetzung gegeben, dass der Systembus vor allem in leistungs- fähigen Systemen zum Flaschenhals werden kann. Besonders deutlich wird diese Entwicklung, wenn man bedenkt, dass sich etwa alle fünf Jahre die Prozessorleistung verzehnfacht und dass sich die Bandbreite der Systembusse lediglich alle vier Jahre verdoppelt. So entsteht eine immer grösser werdende Lücke zwischen der Prozessor- leistung und der Bandbreite der Systeme.

Die Folge war, dass sich einige Hersteller dazu entschlossen haben, sogenannte private Busse zwischen einzelnen besonders leistungshungrigen Subsystemen zu schalten, um so den Engpass auf dem Systembus zu umgehen. Dieser Ausweg fällt aber eher in den Bereich der Symptom- bekämpfung, denn obwohl der eine Engpass behoben wurde, kann leicht ein neuer entstehen, wie folgendes Beispiel aufzeigt. Zwischen der Graphikkarte und der Bridge zum Prozessor-Memory-Bus sei ein privater Bus eingesetzt, wie etwa Intel’s AGP (Siehe Abschnitt 7.1.1). Weil dieser Bus1 nur einen Port hat, der bereits durch die Graphikkarte belegt ist, muss eine Video Frame-Grabber Karte im her- kömmlichen PCI Bus installiert werden. Möchte man den Vidoestream als 3D-Textur verwenden, müssen in der Folge wieder grosse Datenmengen über den langsamen PCI Bus zur Graphikkarte hin transportiert werden. Falls der Videostream auch noch in real-time auf der Harddisk gesichert werden soll, müssten die Daten abermals über den PCI Bus von der Graphik- karte zum SCSI Controller übertragen werden. Dies ist aber gar nicht möglich, da gleichzeitig nur ein Subsystem den PCI-Bus belegen kann.

Aus diesen Gründen wurde in der Octane der traditionelle Systembus durch einen Crossbar- Switch ersetzt. Mit dieser Technologie brauchen sich die Subsysteme nicht mehr um einen gemeinsamen Bus zu bewerben, um Daten zu übertragen. Stattdessen kann jede Komponente mittels einer privaten Verbindung mit einer anderen kommunizieren. Die Funktionsweise entspricht der eines Vermittlungsknotens in einem Telefonnetz, wo die einzelnen Gesprächsteil- nehmer miteinander verbunden werden können. Falls - wie beim Telefonnetz - gleichzeitig und unabhängig voneinander, mehrere Verbindungen geschaltet werden können, spricht man auch von einem non-blocking Switch. In der Octane wird ein Sieben-Port non-blocking Switch eingesetzt, der eine Punkt zu Punkt Verbindung zwischen den einzelnen Komponenten möglich macht. Das bedeutet, dass z.B. eine Videokarte ihren Datenstrom direkt zum Harddisk-Interface schicken kann und somit keine Speicher-Bandbreite verbraucht.

1. Der AGP ist eigentlich kein Bus, sondern ein unabhängiger Steckplatz für eine Punkt-zu-Punkt-Ver- bindung zwischen einer Graphikkarte und der Bridge zum Prozessor-Memory-Bus. 4.3 Graphiksystem 39

4.3 Graphiksystem

Um höchste Transferraten zu erreichen, ist das Graphiksystem direkt durch einen oder zwei XIO Ports mit dem Octane Crossbar-Switch verbunden. Wie aus Abbildung 4.1 ersichtlich, belegen die Varianten Octane SSE und MXE zwei der insgesamt vier XIO Ports. Alle Varianten enthalten: ¥ ein doppelt gepuffertes 32 Bit RGBA Video Memory für eine Auﬂösung bis zu 1280 x 1024 Bildpunkten. ¥ 24 Bit Z-Buffer ¥ doppelte gepufferte Color-Index-Frames (12 Bit) und 8 Bit Overlay Frames1

Bei SSE und MXE Varianten sind auch Auflösungen bis zu 1900 x 1035 Bildpunkten2 realisierbar. Um Darstellungen in ansprechender Realitätsnähe zu ermöglichen, empfiehlt es sich bei Octane SE und SSE 3den Texturspeicher auf 4 MB aufzurüsten. Auffallend ist jedoch, dass der Texturspeicher bewusst knapp gehalten ist, damit sich SGI nicht selber mit dem Einsteigermo- dell der Onyx2 Modellreihe konkurrieren. Zur Illustration ist auf der nächsten Seite das Graphiksystem der Octane dargestellt.

1. Over- und Underlay Planes werden vom Window Manager oder von Applikationen verwendet, um unter anderem Pop-Up Menüs darzustellen. 2. Entspricht HDTV Auflösung. 3. Gilt auch für SI und SSI. 40 4 Die Octane von SGI

Octane Crossbar Switch

XIO XIO

Interface Interface

zusätzliches Geometry GE GE Subsytem von Octane Geometry SS und MX Subsytem zusätzliches Raster Subsytem von Raster Octane SS und MX Subsytem

Raster Engine Raster Engine

Z Buffer Texture Engine Texture Engine Z Buffer (nur mit installiertem (nur mit installiertem Texturspeicher Texturspeicher funktionsfähig) funktionsfähig)

VRAM VRAM

Texture Memory Texture Memory (Texture-Cache-Option) (Texture-Cache-Option)

RAM DAC

Monitor

Abbildung 4.2: Das Octane Graphiksystem 5 5Die Onyx2 von SGI

Bild SGI “To build the world’s most powerful visualization engine, Silicon Graphics combined the ulti- mate in supercomuting and visualization technologies and then designed a way to simultane- ously process 3D graphics, imaging, and video data in real time.”1

Dieses Zitat scheint der geeigneteste Einstieg für dieses Kapitel zu sein. Es geht ja letztendlich darum, den leistungsfähigsten Rechner aus der Gruppe von Testmaschinen zu beschreiben. Diesen Grossrechner für einmal detailliert zu beschreiben und ihm mit den entsprechenden Benchmarking-Programmen auf die Zähne zu fühlen, war ein Kernpunkt der Motivation für diese Arbeit.

1. Aus der SGI Website, www.sgi.com

41 42 5 Die Onyx2 von SGI

5.1 Systemarchitektur

Um eine Übersicht zu erlangen, werden im ersten Teil dieses Abschnittes die verschiedenen Onyx2 Systeme beschrieben. Anschliessend wird auf die spezielle Architektur dieses Gross- rechners eingegangen. Eine komplette Beschreibung der Onyx2 Systeme würde aber den Rahmen dieser Arbeit sprengen. Für eine vollständige Dokumentation - insbesondere auch der unzähligen Graphic-Features - sei auf die Whitepapers von SGI verwiesen1. In diesem Abschnitt werden nur die neueren Onyx2 InfinteReality2 Systeme beschrieben, denn die älteren Onyx2 InfiniteReality beinhalten ähnliche Hardware und haben vor allem die gleiche Architektur.

5.1.1 Übersicht In den Illustrationen zu den einzelnen Onyx2 Modellen (Abbildungen 5.2 bis 5.4), lässt sich immer die Visualisierungs-Pipeline2 wiedererkennen. In der Abbildung 5.1 ist deren Aufbau schematisch dargestellt, wobei Form und Farbgebung der einzelnen Komponenten in allen Illu- strationen dieselben sind. Das Onyx2 InfinteReality2 Visualisierungs-Subsystem besteht aus drei Komponenten: Geometry Engine, Raster Manager und Display Generator. Die Geome- try Engine bildet die Schnittstelle zum restlichen Computersystem und ist für geometrische Transformationen3 und Beleuchtungsberechnungen verantwortlich. Auf 2D-Bildern wird das sogenannte “image processing” durchgeführt, welches unter anderem Konvolutionen berechnet. Im Raster Manager werden die Resultate der Geometry Engine weiterverarbeitet. Die wichtigste Aufgabe ist die Scan-Konvertierung. Im weiteren werden verschiedene Pixel-Operationen, wie etwa Z-Buffer Tests, Blending, Texture-Mapping und das Anti-Aliasing berechnet. In allen Raster Managern erlaubt der Framebuffer eine schnelle Bilddatenverarbeitung, währenddessen der Texturspeicher ein effizientes Texture-Mapping ermöglicht. Die letzte Stufe bildet der Display Generator, welcher das digitale Bild in analoge Signale konvertiert, die dann auf dem Bildschirm dargestellt werden können. Eine genauere Beschreibung der Aufgaben der einzelnen Graphic-Engines befindet sich im Abschnitt 5.2.

Abbildung 5.1:Die Visualisierungs-Pipeline

1. Zu beziehen unter www.sgi.com 2. Die Begriffe Graphik-Pipeline und Visualisierungs-Pipeline sind identisch. 3. Translationen, Rotationen und Skalierung. 5.1 Systemarchitektur 43

Onyx2 InfiniteReality2 Deskside System

Dieses System ist das Einstiegsmodell der Onyx2 Familie und ist deshalb auch am einfachsten aufgebaut. Die Systemarchitektur ist in Abbildung 5.2 dargestellt. Deutlich zu erkennen ist, dass lediglich eine Graphik-Pipeline eingesetzt wird. Zusammenfassend besteht dieses Modell aus:

¥ zwei oder vier R10000 Prozessoren mit je 4 MB Cache

¥ 128 MB bis zu 8 GB Hauptspeicher

¥ eine Graphik-Pipeline mit einem oder zwei Raster Manager

¥ Bis zu 64 MB Textur-Speicher und bis zu 80 MB Frame Buffer.

Abbildung 5.2: Onyx2 InfiniteReality2 Deskside System

Onyx2 InfiniteReality2 Single-Rack System

¥ zwei oder acht R10000 Prozessoren mit je 4 MB Cache

¥ 128 MB bis zu 16 GB Hauptspeicher

¥ eine erste Graphik-Pipeline mit 1/2/4 Raster Manager, die je 80 MB Framebuffer und insgesamt 64 MB Texturspeicher aufnehmen können

¥ eine zweite Graphik-Pipeline mit 1/2 Raster Manager, die je 80 MB Framebuffer und insgesamt 64 MB Texturspeicher aufnehmen können.

In Abbildung 5.3 ist ein System mit vier Prozessoren und zwei Graphik-Pipelines dargestellt. 44 5 Die Onyx2 von SGI

Abbildung 5.3: Onyx2 InfiniteReality2 Single-Rack System

Onyx2 InfiniteReality2 Multi-Rack System Dank der Verwendung von Multiracks kann das Onyx2 System zu einem sehr leistungsfähigen Grossrechner ausgebaut werden. ¥ bis zu 128 R10000 Prozessoren mit je 4 MB Cache, ¥ maximal 256 GB Hauptspeicher, ¥ maximal 16 Visualisierungs-Pipelines ¥ die beiden Racks des Systems können je nach Bedarf mit diversen CPU- oder Graphics Boards bestückt werden.

In der Abbildung 5.4 wird eine Beispiel-Konfiguration mit acht Prozessoren und vier Graphik- Pipelines dargestellt. Der weitaus grösste Vorteil der Rack-Systeme ergibt sich aus der modularen und skalierbaren Architektur. Falls mehr Rechenleistung gebraucht wird, so kann das System problemlos und beinahe beliebig erweitert werden. 5.1 Systemarchitektur 45

Abbildung 5.4: Onyx2 InfiniteReality2 Multi-Rack System 46 5 Die Onyx2 von SGI

5.1.2 Multi-Pipe Rendering Mode Die Graphik-Pipelines eines Onyx2 Systems können derart konfiguriert werden, dass sie alle Berechnungen für nur ein Fenster auf dem Bildschirm durchführen. Das gesamte Graphiksy- stem arbeitet demnach mit seiner vollen Leistung für die Darstellung auf nur einem Bildschirm- fenster. Mit dieser geballten Ladung an Graphikleistung lassen sich absolut realitätsnahe virtuelle 3D-Welten darstellen. Es bestehen grundsätzlich zwei Möglichkeiten um dieses Prin- zip des Multi-Pipe Rendering Mode umzusetzen: ¥ Digitales Multiplexing (DPLEX): Dies ist eine Hardware Option, welche folgendes einfaches Prinzip ausnutzt: Die Gra- phik-Pipelines arbeiten parallel auf der Sequenz von Frames. Anschliessend werden die berechneten Frames mit einem digitalen Multiplexer in der richtigen zeitlichen Reihen- folge aneinandergereiht. Die Abbildung 5.5 zeigt ein System mit vier Graphik-Pipelines. Für die Berechnung eines Frames braucht eine Pipeline maximal 1/15 Sec. Da jedoch vier Pipelines parallel arbeiten, kann eine Frame-Rate von 60 Hz garantiert werden.

Abbildung 5.5: DPLEX Multi-Pipe Rendering Mode

¥ Monster Mode: Hinter diesem Begriff versteckt sich eine Menge von Software-basierten Methoden. Sie sind dafür verantwortlich, dass die Daten zur Abarbeitung auf mehrere Pipelines verteilt werden um dann auf einem Bildschirm dargestellt zu werden. Der Monster Mode beinhaltet Unterstützung für die Dekomposition von 2D- und 3D-Objekten. Ein System kann im Monster 3D-Mode mit n Graphik-Pipelines die n-fache Leistung in der Texturverarbeitung gegenüber einer einzelnen Pipeline erreichen. Ein System mit 16 Graphik-Pipelines kann über maximal 1 GB Texturspeicher verfügen und theore- tisch eine Textur-Download Rate von 5 GB/Sec erzielen! 5.1 Systemarchitektur 47

5.1.3 Aufbau der Onyx2 Damit grosse Datenmengen effizient übertagen werden können, setzt SGI auch bei der Onyx2 die Crossbar-Switch Technologie ein. Der Crossbar-Switch, welcher in der Onyx2 Terminolo- gie Crossbow genannt wird, verbindet zwei Node-Boards mit bis zu sechs I/O Einheiten (Siehe Abbildung 5.10). Über einen Router werden die Node-Boards miteinander verbunden. Die Motivation zur Verwendung eines Crossbar-Switches anstelle eines konventionellen Busses liegt zum einen in der höheren Übertragungsrate und zum anderen in der Möglichkeit der Übertragung mehrerer Datenströme, ohne dass diese sich gegenseitig beeinträchtigen oder gar lahm legen1. Statt auf einem gemeinsamen Systembus konkurrierenden Datentransfer zu betreiben, verbindet der Crossbar-Switch jede Komponente direkt über eine separate Verbin- dung miteinander. Vor allem in einem Mehrprozessorsystem würde ein gemeinsamer System- bus rasch an seine Kapazitätsgrenzen stossen. Die Onyx2 ist aber auch ein skalierbares und modulares System, da zusätzliche Node-Boards zu einem späteren Zeitpunkt einfach hinzuge- fügt werden können. Der physikalische Speicher einer Onyx2 ist auf die verschiedenen Node-Boards verteilt. Es können jedoch alle Prozessoren auf den gesamten Speicher zugreifen. Man bezeichnet eine solches System deshalb als Scalable Shared Memory Multiprocessor (S2MP) System. Da der Speicher verteilt ist, entstehen aus der Sicht eines Prozessors unterschiedliche Zugriffszeiten auf den Speicher, wobei näherliegendes Memory schneller als entferntes angesprochen werden kann. Damit die Konsistenz des Speichers garantiert werden kann, wird ein directory based cache coherence protocol eingesetzt. Informell ausgedrückt bedeutet Cache Kohärenz, dass alle Lesezugriffe auf ein und dieselbe Speicherzelle auch den zuletzt geschriebenen Wert dieser Zelle zurückliefern. Oder mit anderen Worten ausgedrückt, sehen alle Prozessoren nur eine Instanz des Speichers. Diese Speicherarchitektur wird deshalb als Cache Coherent Non Uni- form Memory Access Architektur (ccNUMA)2 bezeichnet. Die klassische S2MP Architektur hat SGI dahingehend erweitert, dass immer mindestens zwei separate Verbindungen zwischen den Systemkomponenten existieren. Somit lassen sich parallel verschiedene Aufgaben ausführen, ohne dass sich der Datentransfer gegenseitig beeinflusst. Abbildung 5.6 illustriert die zwei unabhängigen Datenpfade zwischen den Knoten R1 und R6. Aus dieser Systemarchitektur resultieren grundsätzlich zwei Vorteile. Erstens kann R1 seine Daten auf zwei unabhängigen Pfaden nach R1 schicken und somit die Übertragunslast verteilen. Zweitens ist ein solches System äusserst robust gegenüber Ausfällen von Knoten und dazwi- schenliegenden Pfaden.

1. Man spricht in diesem Falle auch von einem Non-blocking Crossbar-switch. In der Onyx2 sind sowohl der Crossbow, wie auch der Hub als non-blocking Crossbar-Switch implementiert worden. 2. Eine gute Beschreibung der Cache Protokolle und Systemarchitekturen befindet sich in [1] 48 5 Die Onyx2 von SGI

Abbildung 5.6:Separate Datenpfade zwischen R1 und R6

Dank dieser Systemarchitektur kann auch die Anzahl der benötigten direkten Verbindungen für Kommunikationszwecke eingeschränkt werden. Die Abbildung 5.7 zeigt, dass R1 nur eine einzige direkte Verbindung zu R0 braucht, um simultan mit einer Reihe von Knoten zu kommunizieren. Im linken Würfel der Abbildung 5.7 kommuniziert R1 simultan mit R0, R4, R6 und im rechten mit R0, R2, R3, R6 und R7. Die Anzahl von direkten Verbindungen lässt sich also auf ein Minimum reduzieren.

Abbildung 5.7:Simultane Kommunikation zwischen Knoten

5.1.4 Hypercube Architektur

Es gibt verschiedene Konzepte, um die Knoten eines Multiprozessorsystems miteinander zu verbinden. Die einfachsten Möglichkeiten stellen der Shared Bus und die Ringstruktur dar, welche jedoch beide einen entscheidenden Mangel haben. Je mehr Knoten ein System hat, umso kleiner wird die verfügbare Bandbreite. Die komplizierteste Möglichkeit ist schliesslich ein komplett vermaschtes System, wo alle Knoten miteinander verbunden sind. Ein non-blocking Crossbar-Switch repräsentiert eine solche Architektur. Den Preis der hohen Bandbreite muss jedoch mit einem enormen Aufwand an Hardware bezahlt werden. Deswegen lässt sich ein solches System auch nicht auf eine beliebige Anzahl Knoten ausdehnen. Ein weiterer Nachteil besteht darin, dass ein System mit Crossbar-Switch-Technologie, sobald alle Ports belegt sind, nicht mehr skalierbar ist. 5.1 Systemarchitektur 49

Das Ziel ist also, die Realisierung eines skalierbaren Systems mit einer hohen Bandbreite und mit einem möglichst geringen Aufwand an Hardware. Diese Forderungen stehen einander dia- metral gegenüber. Ein möglicher Ausweg aus diesem Dilemma stellt die Hypercube Architektur dar. Bevor diese genauer erläutert wird, soll zunächst das Mass der bisection bandwith eingeführt werden. Um die verfügbare Bandbreite in einem Mehrprozessorsystem zu charakterisieren, wird dieses zunächst gedanklich in zwei gleiche Teile - beide mit der halben Anzahl Knoten- aufgetrennt. Danach werden entlang dieses imaginären Schnittes, die Bandbreiten der bestehenden Verbin- dungen zwischen den beiden abgetrennten Teilen aufsummiert. Diese Summe wird als bisection bandwith bezeichnet. Da einige Architekturen unsymmetrisch verbunden sind, entstehen je nach Wahl des Schnittes unterschiedliche Werte. Per Definition wird nun der kleinste Wert unter allen möglichen Schnitten ausgewählt. Das Mass der bisection bandwith stellt demnach den worst case dar. Bei der Hypercube Architektur werden die Knoten in einem Würfel angeordnet. Die Kanten dieses Würfels stellen die Verbindungen zwischen den Knoten dar. Allgemein besteht ein System aus 2n Knoten, welche n direkte Nachbarn haben. Aus diesem Grunde wird ein solches System auch als n-cube bezeichnet. Nun kommt der eigentliche Clou der Sache. Die bisection bandwith nimmt mit zunehmender Anzahl Knoten linear zu und die Bandbreite pro Knoten bleibt konstant. Hingegegen bleibt bei der eingangs erwähnten Bus- oder Ringstruktur die bisection bandwith konstant und die verfügbare Bandbreite pro Knoten wird immer kleiner!

Bisection Bandwith Anzahl Knoten Shared Bus Hypercube Komplett verbunden 2111 4124 81416 16 1 8 64 32 1 16 256 Tabelle 5.1: Bisection bandwith verschiedener Architekturen.

In der Onyx2 besteht nun jeder Knoten aus einem Router, welcher maximal mit vier weiteren Routers verbunden werden kann. Jeder Router hat zudem zwei weitere Verbindungen zu den Node-Boards mit den Prozessoren. In der Abbildung 5.10 ist das Zusammenspiel von Router und Node-Boards dargestellt. Wie aus Tabelle 5.1 zu entnehmen ist, wächst mit der Anzahl Knoten auch die Anzahl der Ver- bindungen der Knoten zu ihren direkten Nachbarn. Beispielsweise braucht ein Hypercube mit acht Knoten drei direkte Verbindungen pro Knoten (3-cube). Der Router der Onyx2 hat jedoch vier mögliche Verbindungen. Dieser freie Port pro Router kann für zusätzliche direkte Verbin- dungen zwischen Knoten gebraucht werden. In der Abbildung 5.8 sind diese zusätzlichen Ver- bindungen gestrichelt eingezeichnet. Dadurch lässt sich die bisection bandwith eines Systems mit acht Knoten gegenüber der herkömmlichen 3-cube Anordnung auf acht anstelle von vier steigern. 50 5 Die Onyx2 von SGI

Wenn in der Hypercube-Terminologie von Knoten gesprochen wird, so ist zu beachten, dass ein Knoten in einem Onyx2 System immer aus

¥ einem Router und

¥ zwei Node-Boards besteht.

Jedes Node-Board kann mit maximal zwei MIPS R10000 Prozessoren bestückt werden. Somit hat ein Onyx2 System mit total n Knoten maximal 4*n Prozessoren (Siehe Abbildung 5.8).

Abbildung 5.8:Ein System mit 8 Knoten1

Betrachtet man nun einen Hypercube mit 32 Knoten, so sind fünf direkte Verbindungen pro Knoten (5-cube) notwendig. Der Onyx2 Router hat jedoch nur vier Verbindungen. Wie kann ein solcher Hypercube dennoch realisiert werden?

Die Lösung liegt in der Verwendung sogenannter Meta-Router. Die Abbildung 5.9 zeigt den Aufbau eines solchen Verbindungsnetzes. Man könnte nun meinen, dass die bisection bandwith Werte eines solchen Systems kleiner sind als die einer “echten” Hypercube-Architektur. Man kann sich dies folgendermassen vorstellen. In der Abbildung 5.9 besteht jeder schwarze Würfel aus einer Deck- und Bodenplatte mit je vier Knoten. Alle grünen Verbindungen aller Deckplatten der vier schwarzen Würfel führen zur Deckplatte des Meta-Routers. Das Analoge gilt für die Bodenplatten. Falls alle fünf Würfel in der gleichen horizontalen Ebene liegen und die Schnittebene zwischen den Boden- und Deckplatten gelegt wird, so durchstossen genau die vertikalen Kanten der Würfel die Schnittebene. Zählt man nun diese vertikalen Kanten der schwarzen Würfel, so erhält man eine bisection bandwith von 16. Die vertikalen Kanten des Meta-Routers stellen keine zusätzlichen direkten Verbindungen zwischen den Knoten dar und dürfen deshalb auch nicht mitgezählt werden. Die bisection bandwith eines Systems mit Meta-Routern ist dieselbe wie die einer Hypercube- Architektur! 2

1. Ein solches System kann maximal mit 32 Prozessoren ausgestattet werden. 2. Beweis in Hypercube Connectivity within ccNUMA Architecture; Part 6: Bandwith of metaroutered systems. Erhältlich unter www.sgi.com/tech/whitepapers. 5.1 Systemarchitektur 51

Abbildung 5.9:Verwendung von Meta-Routern

5.1.5 Node-Boards und I/O Subsystem Das Node-Board ist das wichtigste Element eines Onyx2 Systems. Jedes Board kann zwei R10000 Prozessoren mit maximal je 4 MB Second Level Cache aufnehmen. Wie bereits im Abschnitt 5.1.3 erwähnt, befindet sich auf jedem Node-Board auch ein Teil des gesamten Spei- chers und das Directory Memory. Letzteres wird zur Aufrechterhaltung der Cache Kohärenz verwendet. Die zentrale Einheit eines Node-Boards bildet ein Hub1, dessen vier Ports ¥ die Prozessoren, ¥ den Speicher, ¥ den Router und ¥ den Crossbow1 verbinden. Die Ports sind für voll-duplex Übertragung mit bis zu 1.6 GByte/sec2 ausgelegt. Aufgabe des Hub ist es, die Zugriffszeiten auf den Speicher zu minimieren. Der Hub sorgt dafür, dass die Speicherbereiche in Richtung desjenigen Prozessors verschoben werden, der auf sie am häufig- sten zugreift (Page Migration). Auf jedem Node-Board kontrolliert der Hub über ein zusätzli-

1. Als Non-blocking Crossbar Switch implementiert. 2. Peak Transfer Rate. 52 5 Die Onyx2 von SGI ches Speicherelement (Directory-Memory) die Speicherzugriffe, um die Datenbereiche beim Kopieren in den Second-Level-Cache und beim Verschieben von einem Node-Board zum anderen eindeutig zu halten. SGI hat also die Crossbar-Switch Technologie gleich doppelt angewendet, zum einen im Hub auf den Node-Boards und zum anderen im Crossbow. Letzterer verbindet zwei Node-Boards mit bis zu sechs I/O Einheiten. Als Sonderform eines Ein-/Ausgabegerät lässt sich die Graphik- hardware über den Crossbow anschliessen. Dies lässt sich besonders gut in den Abbildungen 5.2 bis 5.4 erkennen. 5.1 Systemarchitektur 53

Abbildung 5.10: Zusammenspiel von Node-Board, Router und Crossbow (Crossbar- Switch) 54 5 Die Onyx2 von SGI

5.1.6 Die Prozessoren: MIPS R10000

In den Onyx2 Systemen kommen ausschliesslich R10000 Prozessoren zum Einsatz. Von besonderer Bedeutung für die Graphikleistung sind bei diesem Prozessor die MADD-Instruktionen des MIPS IV Instruktionssets. Die Auswirkung auf die Graphikleistungen dieser speziellen Instruktionen, wurde bereits im Abschnitt 3.1.2 ausführlich behandelt.

An dieser Stelle soll das Design dieses Prozessors etwas näher dargestellt werden. Die Abbil- dung 5.11 zeigt den grundsätzlichen Aufbau des MIPS R10000 Prozessors. Es gilt zu beachten, dass über den speziellen Systembus bis zu vier Prozessoren direkt verbunden werden können, wobei jeder Prozessor sein eigenes Second level cache hat1.

Abbildung 5.11: Aufbau eines MIPS R10000 Prozessors

1. Weitere Spezifikationen zum R10000 unter www.mips.com. 5.2 Graphiksystem 55

5.2 Graphiksystem In diesem Abschnitt wird zuerst die Verarbeitungsschritte der Visualisierungs-Pipeline näher erläutert. Anschliessend werden die wichtigsten Graphic-Features eines Onyx2 Systems dargestellt.

5.2.1 Verarbeitungsschritte in der Visualisierungs-Pipeline Als dreistufige Pipeline aufgebaut, besteht die InfiniteReality2 Graphikhardware aus dem ¥ Geometry subsystem mit den Geometry Engines (GE), ¥ Raster subsytem mit den Raster Managers (RM), ¥ Display subsystem mit dem Display Generator (DG). Die Hauptaufgabe des Geometry subsystem bestehen darin, die Datentransfers vom und zum Hostrechner zu gewährleisten und OpenGL Befehle zu analysieren und auszuführen. Für 3D- Daten sind dies Transformationen1 der Eckpunkte im Raum, das Beleuchten und das Clipping. Im weiteren ﬁndet die Projektion der 3D-Weltkoordinaten auf eine zweidimensionale Bildebene statt. Damit immer genug OpenGL Befehle aufgenommen werden können, verwendet das System grosse FIFO Warteschlangen. Dadurch kann die Pipeline ununterbrochen arbeiten und Stalls werden weitgehend vermieden. In der zweiten Stufe - dem Raster subsystem - werden die vom Geometry subsystem geliefer- ten Linien und Dreiecke mittels Scan-Konvertierung in Pixeldaten umgewandelt. Diese können dann in den Framebuffer geschrieben und vom Display subsystem in analoge Videosignale umgewandelt werden. Die Pipelinestufen innerhalb des Raster subsystems erlauben die parallele Verarbeitung von Anti-Aliasing, Texture-Mapping und weiteren Bildverarbeitungs-Funk- tionen. Das System unterstützt neben dem Anti-Aliasing für Graphikprimitiven auch das sogenannte full-screen Anti-Aliasing mit der Multisampling-Technologie. Dabei werden die Bilder mit einer höheren effektiven Auflösung gerendert, als zur Darstellung auf dem Bildschirm notwendig wäre. Es wird also jedem Pixel eine gewisse konstante Anzahl Subsamples zugeordnet, die schliesslich den Vergrösserungsfaktor der Bildauflösung bestimmt. Werden beispielsweise jedem Pixel acht Subsamples zugeordnet, so ist die effektive Auflösung achtmal grösser als die darzustellende. Dieses Subsampling wird für alle Pixel des Bildes durchgeführt. Anschliessend wird für jedes Pixel mittels überblenden aller seiner Subsamples dessen Farbe bestimmt. Durch Interleaving des Bildspeichers arbeiten auf aneinandergrenzende Pixels immer verschiedene Prozessoren. Somit können mehrere Prozessoren parallel an einem Polygon arbeiten. Die Scan-Konvertierung produziert für jedes Pixel die Texturkoordinaten. Die Texturverarbeitende Einheit berechnet die Korrekturen der Perspektive auf den Texturkoordinaten. Die Texturdaten2 werden schliesslich im entsprechenden Format abgespeichert und im sogenannten Pixel Pro- cessing weiterverarbeitet.

Im Display Subsystem werden die gerenderten Bilder aus der vorangehenden Stufe in analoge Videosignale umgewandelt. Das Standard-System der Onyx2 InfiniteReality2 beinhaltet zwei

1. Translationen, Rotationen und Skalierungen. 2. Auch Texel genannt. 56 5 Die Onyx2 von SGI unabhängige Video Kanäle, als Option sind aber auch acht erhältlich. Der Display Generator lässt sich je nach Verwendung mit verschiedenen Refresh-Raten und Videosignalcharakteristi- ken (beispielsweise interlaced/non-interlaced) programmieren.

5.2.2 Graphic-Features und weitere Spezialitäten Gegen Überlastung der Graphikhardware bei zu komplexen Bildern hat sich SGI einiges einfal- len lassen. Damit die vorgegebene Frame-Rate eingehalten werden kann, spielt die Flexibilität der Display Generators eine grosse Rolle. Echtzeitapplikationen für Simulationen tolerieren so gut wie nie ein Abfallen der Frame-Rate. So zerstört schon ein durch Auslassen eines Frames verursachtes Rucken die Illusion der kontinuierlichen Bewegung in einer virtuellen Szene. Um Echtzeitverlust zu verhindern, ist es wichtig, eine drohende Überlastung der Graphikhardware im Voraus festzustellen. Nur so kann das System noch rechtzeitig entsprechende Gegenmass- nahmen einleiten. Typischerweise resultiert eine Überlastung der Graphikhardware aus dem Versuch, zu viele Polygone zu rendern oder zu viele Bildpunkte in den Bildspeicher zu schreiben (Pixel Fill). Die erste Art von Überlastung - zu viele Polygone - lässt sich mittels SGI’s IRIS Performer Soft- ware eliminieren. Dabei wird der Detaillierungsgrad einer Szene so weit reduziert, bis die vorgegebene Framerate sichergestellt werden kann. Hingegen ist eine Überlastung durch Pixel Fill schwieriger zu handhaben. Als Lösung verwendet die InfiniteReality2 das Verfahren der dyna- mischen Auflösung, die ein dynamisches Auslesen des Bildspeichers vornimmt. So lässt sich die Auflösung für jeden einzelnen Videokanal unabhängig von den anderen variieren. Die Anzahl der Pixelschreiboperationen nimmt dann entsprechend ab. Der Display Generator zoomt den Ausschnitt im Bildspeicher auf das Format des Videosignals, wobei die Berechnung der fehlenden Bildpunkte für das analoge Videosignal mittels bilinearer Interpolation erfolgt. Die leichte Unschärfe des Videobildes ist für den Betrachter kaum wahrnehmbar. Die Onyx Systeme sind aber auch für die realistische Darstellung komplexer texturierter Szenen in Echtzeit ausgelegt. Die Hardware gestattet das simultane Laden und Verwenden von Textu- ren1, was das Aktualisieren von Texturen während einer Echtzeitanwendung erlaubt. Ein spezieller Synchronisationsalgorithmus verwaltet dabei das Nachladen und Freigeben der Texturen. Dieser stellt sicher, dass Texturen erst für das Rendering verwendet werden, wenn sie komplett in den Raster Manager geladen sind. Auch die Freigabe erfolgt erst, wenn die entsprechende Textur nicht mehr verwendet wird. Die hohen Textur-Download-Raten2 sollen den ungestörten Betrieb der Anwendung während des Texture Paging gewährleisten. Ein weiteres Feature ist das global Texturing. Es wird hauptsächlich bei Flug- oder Fahrsimu- latoren verwendet. Damit lassen sich etwa Satelliten- oder Luftaufnahmen als Textur auf die 3D-Modellgeometrie des zugehörigen geographischen Terrains aufbringen. Zu beachten ist, dass die Textur dabei grösser als der vorhandene Speicher im Raster Manager sein kann. Darum wird nur der aktuell für das Rendering benötigte Texturausschnitt in den Texturspeicher geladen. Der Rest befindet sich im Hauptspeicher oder auf der Harddisk. Während der Betrachter sich in der virtuellen Szene bewegt, lädt das System immer den momentan sichtbaren Teil der Textur nach. Neben den standardisierten OpenGL Befehlen liefert SGI etwa 30 weitere Erweiterungsfunk- tionen, mit denen sich spezielle Graphic-Features realisieren lassen. In der folgenden, unvoll-

1. Texture Paging. 2. 176 MB/Sec aus dem Hauptspeicher. 5.2 Graphiksystem 57 ständigen Auflistung werden die wichtigsten Gruppen dieser Graphic-Features aufgezeigt. In diversen Whitepapers1 werden diese Features detailliert beschrieben und erklärt, wie sie vom Programmierer benutzt werden müssen.

¥ Resolution: Es stehen eine Vielzahl von verschiedenen Auflösungen zur Verfügung. ¥ Immediate Mode und Display Lists: OpenGL unterstützt diese beiden Operations- modi. Im Immediate Mode ruft die Applikation direkt OpenGL Befehle auf. Alternativ können die immediate Kommandos zu Display Lists kompiliert werden. Die Applika- tion kann somit immer diese Display Lists anstelle von immediate Kommandos ausfüh- ren. ¥ Farbe (Color): In dieser Gruppe werden Befehle zum Schattieren, Color Blending und zum Beleuchten zur Verfügung gestellt. Einige Beleuchtungsmöglichkeiten sind: ¥ Advanced lighting Model mit folgenden Komponenten: Specular, Diffuse, Ambient und Emissive. ¥ Oberflächen Eigenschaften (Surface Properties) ¥ Unendlich weit entfernte Lichtquellen (Infinite Light Sources) ¥ Lokale Lichtquellen (local) ¥ Transparenz (Transparency) ¥ Hidden Surface Removal ¥ Anti-Aliasing ¥ Texture-Mapping. Diese Gruppe beinhaltet: ¥ Eine Vielzahl von Texturformaten in 16, 32 oder 48 Bit Tiefe. ¥ Textur Filterung ¥ Globale Texturen ¥ Verschiedene Möglichkeiten zur Bearbeitung einer Textur, wie Add, Replace, Blend usw. ¥ Korrektur der Perspektive (Perspective Correction) ¥ Video to Texture ¥ 3D-Texturen ¥ Bild Operationen (Image Operations): Zu dieser Gruppe gehören Konvolutionen, Histogramme und andere Funktionen.

¥ Atmospheric Effects wie Dunst- und Nebelfunktionen ¥ Offscreen Rendering

1. Whitepapers auf www.sgi.com und sgi.webguide.nl Hinweise zur Programmierung unter techpubs.sgi.com 58 5 Die Onyx2 von SGI

¥ Weitere Features zur Darstellung des Bildes, wie: ¥ Multi-Channel Display Generator ¥ Stereoskopische Bilder ¥ Digital Video Multiplexer - DPLEX1 ¥ Digital Video Option ¥ Graphics to Video Option

1. Siehe auch Abschnitt 5.1.2. 6 6Ultra 1 von SUN

Bereits 1995 stellte SUN Microsystems die neue Ultra-Produktelinie vor, welche aus den drei Modellen Ultra 1 140/170 und Ultra 2 besteht. Die Rechner werden mit UltraSPARC-I1 Prozes- sor ausgestattet, wobei die Ultra 1 nur einen und die Ultra 2 maximal zwei Prozessoren aufnehmen kann. Diese SPARC-Prozessorfamilie markiert den Übergang von der Welt der 32 Bit Applikationen in die 64 Bit Ära. Ein zentrales Ziel von SUN war die Aufrechterhaltung der Binärkompatibilität zur alten V8 Generation mit 32 Bit. Die neueren Prozessoren der V9 Gene- ration beeinhalten zusätzliche 25 Single-Cycle-Instruktionen, welche besonders für die Abar- beitung von Multimedia-Datenströmen - wie etwa Echtzeit MPEG-Dekodierung - und Bildverarbeitung eingesetzt werden können. Diese Instruktionen werden unter dem Begriff Visual Instruction Set (VIS) zusammengefasst. Eine weitere UltraSPARC-Neuerung betrifft die Ablösung des MBus2 durch den UPA3 Cross- bar-Switch, welcher die wichtigsten Systemkomponenten miteinander verbindet. Dank dieser High-Speed Verbindung sind Transferraten von durchschnittlich 600 MB/Sec und 1.3 GB/Sec

1. Die Architektur wird durch die SPARC Definition V9 beschrieben. 2. Multi-Bus 3. UPA = UltraSPARC Port Architecture.

59 60 6 Ultra 1 von SUN für Peak-Transfers realisierbar. Die Creator3D Graphikhardware ist direkt mit einem Port des UPA verbunden. Die restlichen Anschlüsse verbinden das Prozessormodul, den Hauptspeicher und die I/O Bridge mit dem Crossbar-Switch.

Wie bereits erwähnt, wurden die Ultra Rechner 1995 auf dem Markt eingeführt. In den vergan- genen Jahren hat SUN diese Reihe laufend ergänzt und so umfasst sie heute sieben Ultra Modelle. Leider standen zu Testzwecken nur die Ultra 1 Maschinen zur Verfügung (Obwohl uns von SUN zuerst noch eine stärkere Ultra 60 versprochen wurde). Die nachfolgende Tabelle listet die verschiedenen Ultra-Modelle auf.

Prozessoren Unterstützte Graphiksysteme

System Max. Architektur Anzahl PGX24, on board Creator Creator 3D Elite3D m3 Elite3D m6 Ultra 1 UltraSPARC I, V9 1 ✔✔ Ultra 2 UltraSPARC I, V9 2 ✔✔✔✔ Ultra 5 UltraSPARC IIi, V9 1 ✔ Ultra 10 UltraSPARC IIi, V9 1 ✔✔✔✔ Ultra 30 UltraSPARC II, V9 1 ✔✔✔✔ Ultra 60 UltraSPARC II, V9 2 ✔✔✔✔ Ultra 450 UltraSPARC II, V9 4 ✔ Tabelle 6.1: Die Ultra-Modelle in einer Übersicht. 6.1 Systemarchitektur der Ultra1 61

6.1 Systemarchitektur der Ultra1

In diesem Abschnitt wird auf den UPA Crossbar-Switch und die speziellen VIS Instruktionen des UltraSPARC Prozessors eingegangen. Die grundsätzliche Erklärung der Funktionsweise eines Crossbar-Switches wurde bereits im Abschnitt 4.2.2 vorgenommen.

Abbildung 6.1: Der Aufbau der SUN Ultra 1 62 6 Ultra 1 von SUN

6.1.1 Der UPA Crossbar-Switch Als Einstieg soll hier noch einmal die Motivation zur Verwendung eines Crossbar-Switches am konkreten Beispiel des SUN Rechners aufgezeigt werden. Superskalare Prozessoren - wie der UltraSPARC I - erfordern einen schnellen Datenaustausch mit dem Speicher, insbesondere weil sie mehrere Befehle pro Takt verarbeiten können. Ein weiterer Engpass entsteht bei symmetrischen Multiprozessorsystemen (SMP), da alle Prozessoren gleichzeitig auf den Speicher zugreifen können. So war bei den älteren SPARC Rechnern der MBus als zentraler Systembus die Basis für symmetrisches Multiprocessing. Der MBus wurde deshalb von der Ultra Port Architecture (UPA) abgelöst. Die SMP-Technologie basiert auf einem gemeinsam benutzten Speicher. Bei acht Prozessoren bedeutet dies, dass der Speicher die achtfache Datenmenge pro Sekunde verkraften muss wie ein gleichstarker Einprozessorrechner. Die Übertragung der Daten vom Prozessor zum Speicher sollte demnach so effizient wie nur möglich ausgeführt werden können. Allgemein betrachtet stösst man mit der Bus-Technologie auf zwei Probleme. Erstens ergibt sich das Problem der konstanten Ausbreitungs-Geschwindigkeit der Bussignale, dadurch wird mit zunehmender Buslänge die Signallaufzeit immer grösser. Innerhalb einer Bus-Taktperiode müssen die Signale den gesamten Bus traversieren, damit alle Bus-Komponenten am Ende der Taktperiode auch das gleiche Datum sehen. Man kann demnach einen langen Bus nicht beliebig hoch takten. Aus diesem Grunde ist der Systembus, welcher die CPU mit dem Hauptspeicher verbindet, typischerweise ein kurzer und hoch getakteter Bus1. Zweitens wird der Bus viel länger belegt, als es für die effektive Datenübertragung notwendig wäre. Konkret spielt sich die Übertragung eines 32 Byte Datenblockes folgendermassen ab:

¥ Phase 1: Zuerst ﬁndet die Bus Arbitrierung statt, das heisst es wird geregelt welcher Teilnehmer den Bus für seine Kommunikation beanspruchen kann. Dauer: mind. 3 Takte ¥ Phase 2: Hier wird die Daten-Blockanfangsadresse gesendet und anschliessend auf den Datenübertragunsmodus umgeschaltet. Dauer: 2 Takte ¥ Phase 3: Die Systemsteuerung liest die angeforderten Daten aus dem Hauptspeicher. Das erste Datenwort (64 Bit) benötigt 7 Takte, alle weiteren folgen unmittelbar mit der Phase 4. ¥ Phase 4: Die gelesenen Daten werden vom Speicher zum Prozessor übertragen. Dauer: 6 Takte.

Von den insgesamt 18 Takten fand auf dem MBus nur während 8 Takten - entspricht 44% - tatsächlich eine Datenübertragung statt. Die restliche Zeit ist der Bus belegt und steht nicht für die Kommunikation der anderen Komponenten zur Verfügung.

1. Es gibt noch weitere Möglichkeiten, um den Datentransfer über den Bus effizienter zu machen, dazu zählen unter anderem: Vergrösserung der Busbreite, Burst-Modes, Split-Transactions, ein oder mehrere Busmaster. Diese Thematik wird ausführlich im Manuskript zur Vorlesung Digitaltechnik und Rechnerstrukturen bahandelt. Zu beziehen unter http://www.tik.ee.ethz.ch/tik/education/lectures/DRS/DRS.html 6.1 Systemarchitektur der Ultra1 63

Genau hier setzt nun das Konzept der UPA an, um eine bessere Ausnutzung zu erreichen. Der Bus sollte effektiver arbeiten, also die eigentliche Datenübertragung leisten und nicht durch Wartezeiten das System blockieren. Über die vier Ports sind folgende Komponenten mit dem Crossbar-Switch verbunden: ¥ Das Prozessor-Modul ¥ Der Hauptspeicher ¥ Das Graphiksubsystem und ¥ Die I/O Bridge, welche die Verbindung zum SBus und anderen peripheren Komponen- ten herstellt. Bei den Ports spielt die Unterscheidung in Master und Slave eine wichtige Rolle. Nur erstere können eine Übertragung anstossen, während letztere lediglich darauf reagieren können. Der Prozessor kann beides, hingegen sind beispielsweise die Graphiksubsysteme reine Slaves. Da beim MBus die Übertragung der Adressen deutlich weniger Takte beansprucht als die Daten- übertragung, gruppiert die UPA jeweils einige Signalleitungen zu einem kurzen Adressbus, der hoch getaktet werden kann1. Der Hauptspeicher und das Prozessor-Modul sind mit getrennten Daten- und Adressleitungen mit dem UPA Crossbar-Switch verbunden (Siehe Abbildung 6.1). Diese Aufteilung in unabhängige Daten- und Adresspfade, stellt einer der wesentlichsten Vor- teile der UPA genüber dem MBus dar. Ein weiteres wichtiges Merkmal der UPA-Technologie ist die Verwendung von grossen Blöcken bei der Datenübertragung. Ebenso wie bei den Octane und Onyx2 Crossbar-Switches kann der UPA parallel mehrere Ver- bindungen aufrecht erhalten. An dieser Stelle sei auf die hohen technischen Anforderungen hin- gewiesen, denn nur schon beim Einprozessorsystem der Ultra 1, müssen 504 Pins2 geschaltet werden. Ausserdem sollte die Durchlaufverzögerung unter 10 ns liegen und die Zeit für den Verbindungsaufbau (Switching) nur geringfügig darüber!

6.1.2 Der Prozessor: UltraSPARC I Version 9 Wie bereits in der Einleitung zu diesem Abschnitt erwähnt, sollen hier vor allem die VIS Instruktionen beschrieben werden. Für eine ausführliche Dokumentation der SPARC Architektur wird auf die Referenz von SUN verwiesen3. Nachfolgend werden einige Highlights der UltraSPARC I Architektur aufgelistet: ¥ 64 Bit Architektur ¥ 9-stuﬁge Pipeline, welche maximal 4 Instruktionen pro Clock-Zyklus ausführen kann ¥ Je 16 KB Daten- und Intruktionscache ¥ Second Level cache mit minimal 512 KB und maximal 4 MB ¥ Eingebaute Multiprozessorunterstützung ¥ Graphikunterstützung durch VIS

1. In der Regel die halbe Prozessor-Taktfrequenz. 2. 256 + 32 Bit für die Speicher Verbindung, 128 + 16 Bits zum Prozessor und 64 + 8 Bit zur I/O Bridge. 3. Gute Dokumentationen unter www.sun.com. 64 6 Ultra 1 von SUN

Im Unterschied zum UltraSPARC I Prozessor, kann der UltraSPARC II wesentlich höher getaktet werden.

Das Visual Instruction Set (VIS) umfasst insgesamt eine Menge von 25 Instruktionen, welche innerhalb eines Prozessortaktes ausgeführt werden können. Eines der Designziele war die Dekodierung eines MPEG2-Datenstromes mit 30 Bildern pro Sekunde. Zur Dekomprimierung sind ziemlich aufwendige Pixeloperationen notwendig, welche dank der VIS Unterstützung massiv beschleunigt werden. Die Register des Prozessors werden so aufgeteilt, dass die Integer-Register die Bildadressen enthalten und die Floatingpoint-Register für die Manipulation der Daten zur Verfügung stehen. Somit kann der Prozessor alle verfügbaren Register einsetzen und den Durchsatz maximieren.

Die VIS Instruktionen lassen sich wie folgt in vier Kategorien einteilen:

¥ Pixel Format/Conversion Zu dieser Gruppe von Instruktionen gehören Pixel Formatierungs- und Konvertierungs- Instruktionen. Durch die speziellen Pixel Expand, Pack und Merge Instruktionen lassen sich typische Pixelmanipulationen mit nur einer Instruktion ausführen.

¥ Image Processing Die Instruktionen in dieser Kategorie beschleunigen folgende Berechnungen:

¥ Skalierung und Rotation von Bildern

¥ Pixel Interpolationen

¥ Filterberechnungen

¥ Alpha blending

¥ Volumetric rendering

¥ Real-time Video Kompression Mit der Verwendung dieser Instruktionen ist die Echtzeit Kompression und Dekom- pression von Bildatenströmen möglich. Folgende Standards werden unterstützt:

¥ H.261

¥ JPEG

¥ MPEG1 und MPEG2

¥ Beschleunigung des Datentransfers und Beschleunigung von Animationen Die VIS Instruktionen können von den Block Load/Store Features der UltraSPARC Architektur proﬁtieren. Diese gestatten direkte 64 Bytes Load und Stores vom Prozes- sor in den Hauptspeicher und vom Hauptspeicher in den Framebuffer des Graphiksy- stems. 6.2 Graphiksysteme 65

6.2 Graphiksysteme In diesem Abschnitt wird das Graphiksystem der SUN Ultra 1 beschrieben. Unter 6.2.2 wird zur Übersicht noch das Nachfolgemodell - die Elite3D- vorgestellt1. Die beiden Abbildungen 6.2 und 6.3 stellen Graphiksysteme in einer Übersicht dar.

6.2.1 SUN Ultra 1 mit Creator 3D Das Creator3D Graphiksystem wird direkt mit dem UPA Crossbar-Switch verbunden, wobei die Datenbreite 64 Bit bis hin zum Framebuffer umfasst. Die Kernkomponenten der Creator3D sind nachfolgend aufgelistet und werden anschliessend in den weiteren Abschnitten näher erläutert. ¥ Framebuffer Controller: Dieser ist einerseits für die Verbindung mit dem UPA und zum anderen für die Beschleunigung des Rendering verantwortlich. ¥ 3D-RAM ¥ Pixel Processing

Der Framebuffer Controller stellt die erste Stufe der 3D-Graphik Rendering-Pipeline dar. Es werden verschiedene Berechnungen durchgeführt, welche nachfolgend genauer beschrieben werden. Die Pipeline unterstützt eine Menge von Graphikprimitiven, welche in der Tabelle 6.2 zusammengefasst sind2.

Graphikprimitive Attribute Punkt Anti-Aliasing, Alpha blending Bresenham Linien Pattern Bresenham Polygone Pattern DDA Linien Pattern, Anti-Aliasing, Depth Cue, Alpha Blending DDA Dreiecke Shade, Z-Buffer, Pattern, Depth Cue, Alpha Blending Tabelle 6.2: Graphikprimitiven der Rendering-Pipeline2

Als Alternative zur Rendering-Pipeline existiert auch ein direkter Port, welcher eine schnelle Zwei-Weg Schnittstelle zur Verfügung stellt. Auf diesem Weg können reine Pixeldaten (ohne Geometrie) direkt in den Framebuffer geschrieben werden, was besonders für DMA Übertra- gungen sehr nützlich und effizient ist. Die Pixel aus der Rendering-Pipeline müssen dagegen zuerst noch den Pixel Processing Block passieren. In der Pixel Processing Stufe, innerhalb des Framebuffer-Controllers, können verschieden Operationen ausgeführt werden. Nachfolgend seien einige Beispiele genannt:

1. Whitepapers unter www.sun.com. 2. Quelle: Creator Graphics Technology, Technical Whitepaper; www.sun.com. 66 6 Ultra 1 von SUN

¥ Depth Cueing ¥ Alpha Blending ¥ Transparenz ¥ Anti-Aliasing ¥ Z-Buffering (Hidden Surface Removal) ¥ Raster Operationen ¥ Viewport, Window ID, Stencil, Alpha Clipping Das 3D-RAM1 stellt eine Besonderheit unter den Framebuffer-Technologien dar. Typischer- weise liegt der Flaschenhals von 3D-Graphikhardware bei der Rate, mit welcher die Pixel in Frame- und Z-Buffer geschrieben werden können. Die Pixelfillrate war bei vielen Graphik- Algorithmen der limitierende Leistungsfaktor. In diesem 3D-RAM Chip wurde das günstige, aber langsamere DRAM mit einem schnellen SRAM Cache kombiniert. Als Resultat entstand ein Chip, welcher 3D-Operationen etwa zehnmal schneller ausführen kann als dies mit konventionellem Video-RAM möglich ist. Neben dem eigentlichen Speicher befindet sich auch noch eine ALU innerhalb dieses 3D- RAM’s. Die ALU Funktionen lassen sich in drei Hauptgruppen aufteilen: ¥ Depth-Unit: Z-Buffer Vergleiche ¥ Alpha-Unit: Alpha-Blending, Anti-Aliasing, Raster Operationen ¥ Stencil-Unit: Berechnet OpenGL Stencil Funktionen. Die Creator Graphiksysteme haben keine spezielle Hardwareunterstützung für das Texture- Mapping und auch keinen separaten Texturspeicher. Die gesamten Texturen werden stattdessen im konventionellen Hauptspeicher abgelegt. Der Verzicht auf diese Hardwareunterstützung hat natürlich einen Leistungsrückgang zur Folge. Dennoch müssen die Berechnungen nicht zu hun- dert Prozent in Software ausgeführt werden. Die Creator Graphiksysteme unterstützen das Rastern der Bilder mit der Verwendung der speziellen VIS Instruktionen. Besonders nützlich sind die VIS Instruktionen beispielsweise für bilineare Interpolation und die Berechnung von Texturoperationen.

1. Gemeinsame Entwicklung von SUN Microsystems und Mitsubishi Electronics. Vorgestellt an der SIGGRAPH 1994 als FBRAM. 6.2 Graphiksysteme 67

Abbildung 6.2: SUN Creator3D Graphiksystem 68 6 Ultra 1 von SUN

6.2.2 Elite 3D m3/m6 In der nachfolgenden Abbildung ist der schematische Aufbau der Elite3D Graphiksubsysteme

dargestellt, wie sie in den neueren SUN Ultra Modellen zum Einsatz kommen. UPA

UPA Interface

AFB Command

Nur Elite3D m6

AFB AFB AFB AFB AFB AFB Float Float Float Float Float Float

AFB AFB Draw Draw

3D RAM 3D RAM 3D RAM 3D RAM

RAM DAC

Monitor

Abbildung 6.3: SUN Elite3D Graphiksystem 7 7Zwei PC Systeme

In diesem letzten Abschnitt werden den SGI und SUN Maschinen zwei handelsübliche PC- Systeme für einen Vergleich gegenübergestellt. Es drängt sich natürlich sofort die Frage auf, ob die beiden PC an die Leistung der Graphikrechner herankommen. Um diese Frage beantworten zu können, standen zu Testzwecken zwei Dell Computer - einer mit Intel PentiumPro, der andere mit PentiumII Prozessor - zur Verfügung. Beide Systeme sind mit der FireGL1000 Pro von Diamond ausgestattet und arbeiten unter WindowsNT 4, Service Pack 3.

7.1 Systemarchitektur Die Systemarchitektur dieser Maschinen entspricht der klassischen Bauweise eines PC: Um einen zentralen (PCI-)Bus sind die einzelnen Komponenten angeschlossen und der Systembus verbindet den Prozessor mit dem Hauptspeicher. Ausser der Verwendung des Accelerated Graphics Port (AGP) im PentiumII-System sind keine weiteren Besonderheiten der System- architektur zu nennen.

7.1.1 AGP von Intel Bereits 1996 veröffentlichte Intel einen detaillierten Entwurf für den Accelerated Graphics Port (AGP). Diverse Firmen - sowohl aus der Hardware- und als auch der Softwarebranche - unterstützen mittlerweile die Weiterentwicklung des AGP. Hinter dem AGP verbirgt sich ein Boardsteckplatz, welcher in erster Linie für Graphikerweiterungen bestimmt ist und die Lei- stung des heute eingesetzten PCI-Bus um den Faktor vier übertrifft. Der AGP ist demnach kein neues Bussystem, sondern ein zusätzlicher Port für eine Punkt-zu-Punkt-Verbindung zu einer Graphikkarte. Der AGP ist weder als Nachfolger noch als Ersatz für den PCI-Bus konzipiert. Die Hauptmotivation für die Entwicklung des AGP war die Knappheit an Ressourcen auf dem PCI-Bus, insbesondere erreichen leistungsstarke 3D-Graphikboards die Kapazitätsgrenze des Busses. Gleichzeitig mit der Einführung des PentiumII Prozessors, kamen auch die ersten AGP- Systeme auf den Markt1.

1. Die älteren PentiumPro Systeme können nicht mit dem AGP zusammen betrieben werden.

69 70 7 Zwei PC Systeme

In praktisch allen Graphikanwendungen werden Darstellungen mit texturierten Oberflächen benutzt. Die Verwendung solch hochwertiger Texturen stellt allerdings enorme Anforderungen an die Graphikhardware. Um texturierte Szenarien in akzeptabler Zeit aufbauen zu können, müssen bei den meisten Systemen alle Oberflächeninformationen auf dem Graphikboard abgespeichert werden. Bessere Graphikboards verwenden deshalb einen eigenen Texturspeicher. Der entscheidende Nachteil solcher Graphikboards liegt in deren Preis, da der Texturspeicher einen grossen Anteil an den Produktionskosten und somit auch am Verkaufspreis hat. Ver- schafft man nun der Graphikkarte einen schnellen Zugriff zum Hauptspeicher, so müssen diese Texturen nicht mehr lokal gehalten werden. Vor allem für den Consumer-Markt sind kosten- sparende Versionen der Graphikboards äusserst interessant.

Die Technik des AGP Die PCI-Spezifikation1 wird beim AGP um neue Protokolle und neue Transfermodi ergänzt. Die Datenübertragung erfolgt nach wie vor über einen 32-Bit breiten Bus, welcher mit 66 MHz arbeitet. Im Speziellen x2-Mode finden Datenübertragungen auf beiden Flanken des 66-MHz- Taktes statt, demnach mit einer Rate von 133 MHz. Es ergibt sich daraus eine theoretische Übertragungsrate von 533 MBytes/sec. Bei allen AGP-Systemen ist die Graphikkomponente grundsätzlich der Busmaster, das heisst nur sie kann Lese- und Schreiboperationen initiieren. Die Core-Logic beziehungsweise der AGP-Chipsatz ist der Slave. Seine Aufgabe ist es, in den Lesezyklen Daten aus dem Hauptspei- cher abzurufen und über den AGP bereitzustellen. Während eines Schreibzyklus liefert dagegen die Graphikkomponente die Daten an den Chipsatz, welcher sie anschliessend in den Haupt- speicher schreibt. Entscheidend ist, dass die Datenströme auf dem AGP weder unterbrochen noch wiederholt werden können. Aufeinanderfolgende Daten werden gesendet, ohne dass der Empfang der vorangehenden bestätigt wurde. Dank dieser Pipeline-Mechanismen, liegt die tat- sächlich erzielte Übertragungsrate nahe an der theoretischen. Ein AGP Transfer hat eine Länge zwischen 8 und 256 Bytes und wird entweder aus den sogenannten read/write data queues in der Core-Logic, oder aus einem der AGP Devices bedient. Die Anforderung von Transaktionen und ihre eigentliche Ausführung sind zeitlich getrennt. Für die Verwaltung der Anforderungen gibt es Warteschlangen im AGP-Chip, welche als read/write request queues bezeichnet werden. Für die Bearbeitung der High-Priority Anfor- derungen stehen eigene Warteschlangen zur Verfügung, sodass die maximal tolerierte Latenz eingehalten werden kann. Wie bereits erwähnt, hat Intel den AGP auf der PCI-Spezifikation aufgebaut und somit ist das PCI-Protokoll in den AGP-Spezifikationen enthalten. Für die Übertragung der AGP-Signale wurde die Anzahl der PCI-Steuerleitungen erweitert. Zu den neuen Leitungen gehört ein eigener Bus für Kommandos und Adressen, welcher in der AGP-Terminologie SBA-Bus2 genannt wird. Er soll verhindern, dass der Datenbus während der Kommandophase blockiert wird - ein Effekt, der sich beim PCI-Bus oft nachteilig auf die Effizienz auswirkt. Über den SBA-Bus kann die AGP Core-Logic während laufender Datentransfers neue Transaktionen anmelden und in die Warteschlangen einfügen lassen. Die Nutzung des SBA ist allerdings nicht verbindlich, denn ein AGP-Device kann Kommandos auch über den Datenbus schicken. Ein Kompromiss zwischen Effizienz und Aufwand ist der Verzicht auf die Cache-Kohärenz der AGP-Daten. Da der grösste Anteil der AGP-Aktionen aus Lesezugriffen besteht, sind aufwen-

1. Revision 2.1 2. 8 Bit breiter Bus, welcher auch als Side Band Port bezeichnet wird. 7.1 Systemarchitektur 71 dige Mechanismen für ein Cache-Snooping1 nicht implementiert worden. Sollte bei Schrei- boperationen dennoch Cache-Kohärenz erforderlich sein, kann man auf bewährte Softwaretechniken oder PCI-Transaktionen zurückgreifen. Mit dem AGP steigen auch die Anforderungen an den Hauptspeicher. Nach der CPU und den PCI-Mastern2 ist der AGP die dritte Quelle für Speicherzugriffe! In der Abbildung 7.1 ist der schematische Aufbau des AGP dargestellt.

Abbildung 7.1: Der AGP von Intel.

1. Es gibt zwei grundlegende Cache-Kohärenz-Protokolle: Directory-Based und Snooping. Ersteres wird z.B. in der Onyx2 eingesetzt. Eine Erklärung dieser beiden Protokolle befindet sich in [1, Kapitel 8]. 2. Ein PCI-System kann mehrere Bus-Master haben. Details im Manuskript zur Vorlesung Digitaltech- nik und Rechnerstrukturen. Zu beziehen unter http://www.tik.ee.ethz.ch/tik/education/lectures/DRS/DRS.html 72 7 Zwei PC Systeme

7.1.2 Die Prozessoren In den Dell Systemen kommen zum einen der PentiumPro und zum anderen ein PentiumII zum Einsatz. Letzterer ist mit der neueren Multimedia Extensions (MMX) Technologie ausgestattet, welche einen direkten Einfluss auf die Graphikleistung hat. Wie bereits in den vorangehenden Kapiteln wird die Prozessorarchitektur nicht weiter erläu- tert1.

Der PentiumPro Da dieser Prozessor noch keine Unterstützung für die MMX Technologie hat, wird an dieser Stelle nur eine kurze Zusammenfassung der Features des PentiumPro aufgelistet. ¥ Superskalare Mikro-Architektur. Es können pro Clock-Zyklus zwei Instruktionen aus- geführt werden. ¥ 64 Bit breiter externer Bus ¥ 5-stuﬁge Pipeline ¥ Multiprozessor Unterstützung für bis zu vier Prozessoren ¥ Separates Daten- und Instruktionscache, je 8 KB ¥ Bis zu 1 MB Second Level Cache

Der PentiumII mit MMX Als Weiterentwicklung des Pentium Prozessors realisierte Intel den PentiumII. Das wichtigste neue Feature dieses Prozessors ist - zumindest aus der Sicht der Graphikanwendungen - die MMX Technologie. Dank MMX kann eine Anwendung auf folgende zusätzliche Ressourcen zugreifen: ¥ 8 MMX Register, 64 Bit breit ¥ 4 MMX Datentypen ¥ Eigener MMX Instruktionssatz

Die MMX Instruktionen können direkt mit den MMX Registern arbeiten. Der eigentliche Trick der MMX Register liegt darin, dass physikalisch gesehen die Floating Point Register des Pro- zessors verwendet werden. Es wird also einfach ein Alias von den MMX auf die FP Register gemacht. Dies gilt aber nicht für die General Purpose Register, welche gewissermassen “parallel” zu den MMX Registern verwendet werden können2. In den Applikationen, welche Gra- phikberechnungen durchführen, wird in den meisten Fällen nur mit Ganzzahlarithmetik gearbeitet, sodass dank der MMX Technologie eine Leistungssteigerung erreicht werden kann. Die MMX Datentypen beinhalten zum einen das 64 Bit quadword und zum anderen die soge-

1. Informationen unter www.intel.com 2. Die FP Register können natürlich trotzdem angesprochen werden, nur ist im Prinzip ein Context- Switch zwischen der MMX- zur FP-Verarbeitung notwendig. 7.1 Systemarchitektur 73 nannten packed data types. Letztere erlauben die parallele Verarbeitung auf mehreren Bytes oder Wörtern. Die MMX Datentypen werden immer als 64 Bit Block vom und zum Hauptspei- cher transportiert. Der MMX Instruktionssatz umfasst insgesamt 57 Instruktionen, welche sich in folgende Grup- pen einteilen lassen: ¥ Datentransfer ¥ Arithmetik ¥ Vergleiche ¥ Konvertierung ¥ Logik ¥ Shift Instructions ¥ Empty MMX State (EMMS) Instruction Hinter allen Instruktionen steckt die Idee, dass auf mehreren Bytes innerhalb eines packed data type parallel gearbeitet werden kann.

Die MMX Technologie verwendet die SIMD1 Technik, um arithmetische und logische Opera- tionen auf den Datentypen auszuführen. Diese Technik erlaubt es, die gleiche Instruktion auf verschiedenen Datenelementen parallel arbeiten zu lassen. Im Geometry Subsystem der Indigo2-Graphikhardware kommt dieselbe SIMD-Technik zum Einsatz, siehe hierzu Abschnitt 2.3.3. Dank der MMX Technologie können verschiedene Algorithmen aus der Multimediawelt direkt implementiert werden2.

1. Single Instruction stream, multiple data streams. 2. Eine Sammlung befindet sich unter: www.intel.com/design/pentiumii/manuals 74 7 Zwei PC Systeme

7.2 Graphiksystem

Wie bereits erwähnt, handelt es sich bei der eingesetzten Graphikkarte um die FireGL1000 Pro der Firma Diamond1. Das Kernstück der Karte bildet der Permedia 2 Chip der Firma 3Dlabs2. Es handelt sich hier um einen hochwertigen 2D/3D-Graphikprozessor. Die öffentlich zugänglichen Informationen zur FireGL1000pro beschränken sich leider auf reines Marketing und enthalten sehr wenig technische Details. Aus diesem Grunde kann hier weder ein schematischer Aufbau der Karte, noch ein logisches Datenflussdiagramm dargestellt werden.

Der Permedia 2 Graphikchip Der Permedia 2 Graphikchip wird von Texas Instruments gefertigt und trägt die Bezeichnung TVP4020. Dieser Chip hat einen integrierten Geometry-Setup-Prozessor zur Entlastung der Haupt-CPU. In der Abbildung 7.2 ist das Blockdiagramm des TVP4020 dargestellt. Dieser Chip unterstützt eine vielzahl von Graphic-Features; einige wichtige werden kurz genannt: ¥ MPEG-2 Dekodierung ¥ Farbraumkonvertierungen YUV in RGB ¥ Video Strom Bus für simultanes externes Video I/O ¥ Hardwareunterstützung für ¥ Texture-Mapping ¥ Double Buffering ¥ 16 Bit Z-Buffering in ¥ Bilineare Filterung ¥ Dithering ¥ Anti-Aliasing ¥ Alpha-Blending ¥ Gouraud- und Flat Shading ¥ Beschleunigt alle OpenGL-, Direct3D- und Heidi- Applikationen ¥ Integrierter Geometrie Pipeline Setup Prozessor ¥ True Color (24 Bit) bis 1600x1200

1. Informationen unter: www.diamondmm.com und firegl.diamondmm.com 2. Informationen unter: www.3dlabs.com/products 7.2 Graphiksystem 75

Abbildung 7.2: Blockdiagramm des Texas Instruments TVP4020 76 7 Zwei PC Systeme Zweiter Teil

LEISTUNGSANALYSE UND BENCHMARKING

77 78 . 8 8Der Viewperf Benchmark

Viewperf [17] ist ein portables OpenGL1 Performance Benchmark Programm, welches in C geschrieben wurde. Zurzeit, im Januar 1999, ist die Version 6.1 aktuell. Ursprünglich wurde es von IBM entwickelt, erweitert wurde es dann von SGI, Digital und anderen. Viewperf ist sehr flexibel zum Evaluieren der OpenGL Performance von Computer Systemen. Derzeit gibt es Implementationen für diverse Plattformen, zum Beispiel für UNIX, Linux, Win- dows NT, Windows 95 und OS/2. Viewperf wurde 1994 in die Standard Performance Evaluation Corporation (SPEC) eingeglie- dert, welche sich zur Aufgabe macht, Benchmarks für Computer zu unterhalten. Die OpenGL Performance Characterization (OPC) Projektgruppe der SPEC publizierte Viewperf als ersten OpenGL Benchmark der Graphics Performance Characterization (GPC) Gruppe. Erste Mes- sungen wurden Ende 1994 im The GPC Quarterly publiziert. Die OPC Gruppe unterhält den Quellcode von Viewperf, der für alle über Internet erhältlich ist.

8.1 Einführung

Wichtig bei jedem Benchmark ist zu wissen, für welche Zwecke er gemacht wurde. Die Gefahr ist gross, dass der Benutzer mit einem Benchmark Programm etwas machen will, für das es nicht entwickelt wurde. Das ist mit Viewperf nicht anders. Darum wird hier ein näherer Blick auf Viewperf geworfen.

1. Open GL = Open Graphics Library, ein von Silicon Graphics Inc. entwickelter Graphik Standard

79 80 8 Der Viewperf Benchmark

Viewperf misst die 3D Rendering Performance eines Systems. Dazu wird das OpenGL API1 benutzt. Die OPC Gruppe arbeitet mit unabhängigen Software-Entwicklern (ISV: engl. Inde- pendent Software Vendors) zusammen, um Tests, Datensätze und Gewichte zusammenzustel- len, welche Viewsets genannt werden. Jedes Viewset repräsentiert den Graphik Rendering Mix einer realen 3D Anwendung. Die ISVs, welche die Viewsets entwickelt haben, bestimmen für jeden Test, der im Bericht aufgeführt wird, ein Gewicht, das die Wichtigkeit des Tests in der ganzen Anwendung wiedergibt.

8.1.1 Charakteristiken von Viewperf Viewperf liegt auf der Homepage der OpenGL Performance Characterization Group zum Download bereit. Der Quellcode ist dazu da, Leistungsvergleiche diverser Hardware Plattfor- men anzustellen. Viewperf ist unter vielen Betriebssystemen lauffähig, unter anderem unter Windows NT, UNIX und OS/2. Ebenfalls werden die gängigsten Prozessoren unterstützt, so zum Beispiel Alpha, Intel, MIPS und PowerPC. Als Window Umgebungen werden sowohl X als auch Windows unterstützt. Die Datensätze, die in Viewperf und in den OPC Viewsets verwendet werden, wurden für reale Anwendungen entwickelt. Die Auswahl der Modelle und Parameter wird von unabhängigen Software-Entwicklern und von Graphiksoftware-Benutzern bestimmt. Die Zahlen, welche die Performance angeben, werden in der Einheit “frames per second”2 angegeben, was für den Benutzer einfach nachzuvollziehen ist. Für jeden Rendering Test in einem Viewset wird eine Zahl ausgegeben. Viewperf bewertet eine grosse Anzahl von OpenGL Befehlen, Operationen und Modi. Unter anderem kann Texture Mapping, Alpha Blending, Fogging, Anti-Aliasing, Depth Buffering und Lighting bewertet werden. Das Zeichnen der folgenden OpenGL Primitiven kann gemessen werden: points, lines, line_strips, line_loops, triangles, triangle_strips, triangle_fans, qauds und polygons. Im Anhang werden diese Primitiven beschrieben. In Viewperf können Bildschirmschnappschüsse aufgenommen werden. Diese werden im PNG3 oder PPM4 Format abgespeichert. Die Schnappschüsse dienen der Qualitätsanalyse und der Verifikation des Benchmarks. In den Tests von Viewperf werden folgende Faktoren nicht miteinbezogen. ¥ Effekte, die durch das Wechseln der Primitiven hervorgerufen werden. ¥ Eingabe Effekte in der Event Loop. ¥ Benutzerschnittstellen Rendering und Management. ¥ Komplexe Bewegungen bei verschiedenen Modellen. ¥ Betriebssystemeffekte, wie zum Beispiel Interrupts. ¥ Multi-Context, Multi-Window Effekte.

1. API = Application Programming Interface, Programmierungsschnittstelle 2. dt. Bilder pro Sekunde. Es wird hier die englische Schreibweise beibehalten (Abkürzung fps), da sie sehr verbreitet ist. 3. Abkürzung für Portable Network Graphics (PNG, pronounced “ping”). 4. Abkürzung für Portable PixMap (PPM). Dieses Format ist ein Teil der Extended Portable Bitmap Uti- lities (PBMPLUS). 8.2 Die Viewsets 81

Viewperf ist nicht systemunabhängig. Wenn der Prozessor oder der Bus an seine Leistungs- grenzen stösst, was bei einem herkömmlichen PC System schnell der Fall ist, wird nicht mehr nur die Performance des Graphiksubsystems berechnet, sondern auch die des ganzen Systems.

8.1.2 Das geometrische Mittel In Viewperf wird das gewichtete geometrische Mittel dazu verwendet, um pro Viewset eine Zahl zu erhalten, welche eine Aussage über die Gesamtbewertung der darin enthaltenen Tests macht. Folgende Formel zeigt die Berechnung des Mittels: n w ()()frames⁄ sec ond i ∏ i i = 1

Dabei ist n die Anzahl Tests und w das jeweilige Gewicht des Tests, als Zahl zwischen 0.0 und 1.0 dargestellt: 25% entspricht 0.25 Das gewichtete geometrische Mittel für CDRS-05 ist zum Beispiel:

0.50 0.20 0.15 0.08 0.05 0.02 0.00 WgmÐ05 CDRS Ð = test1 ⋅⋅⋅⋅⋅⋅test2 test3 test4 test5 test6 test7

Die Tests in einem Viewset repräsentieren die häufigsten Operationen in einem Programm. Die Gewichte geben an, in welcher Häufigkeit diese Operationen vorkommen. Das geometrische Mittel hat die wünschenswerte Eigenschaft: "bigger is better" (grösser ist besser); d.h. je grösser die Zahl, desto besser die Performance. Als Alternativen zum geometrischen Mittel gibt es das arithmetische Mittel oder das harmoni- sche Mittel. Das arithmetische Mittel gäbe keine repräsentative “frames per second” Angabe. Das normalisierte gewichtete geometrische Mittel wird oft dazu verwendet (SPECint92, Xmark93) die Resultate gegenüber einem Referenzsystem zu vergleichen. Da wir hier aber nicht von einem Referenzsystem ausgehen, ist es ungünstig. Es gibt aber auch beim geometrischen Mittel Nachteile: Es kann als "Filter" fungieren. Die stär- ker gewichteten Tests können unter Umständen die weniger gewichteten völlig überdecken. Dies kann zur Folge haben, dass ein ausserordentlich schlechtes Resultat in einem wenig gewichteten Test nicht auffällt. Aus diesem Grund ist es unerlässlich, dass man auch die individuellen Resultate der einzelnen Tests betrachtet.

8.2 Die Viewsets Die OPC Gruppe anerkennt die Wichtigkeit von Benchmarks, welche die Leistung von Syste- men mit realen Programmen bewerten; man wollte keinen synthetischen Benchmark. Von Anfang an versuchte die Gruppe Viewperf repräsentativ für den OpenGL Rendering Mix von wichtigen Industrieanwendungen zu machen. Somit kam die Idee von sogenannten Viewsets auf. Ein Viewset ist eine Gruppe von individuellen Abläufen von Viewperf, die versuchen, den Gra- phik Rendering Mix einer richtigen Anwendung zu simulieren. Viewsets kann jeder entwickeln. Da Viewperf anwendungsorientiert ist, muss man zuerst die vorhandene Anwendung analysieren. Daraus muss man Datensätze zusammenstellen, die reprä- 82 8 Der Viewperf Benchmark sentativ für die Anwendung sind und eine ähnliche Komplexität aufweisen. Für publizierbare Resultate ist man aber beschränkt auf die Standard Viewsets. Diese werden nicht von der OPC Gruppe entwickelt; sie werden von Firmen entwickelt, welche in der Gra- phiksoftwarebranche tätig sind. In der Version 6.1 von Viewperf gibt es fünf Standard OPC Viewsets mit folgenden Abkürzungen: ProCDRS, DX, DRV, AWadvs und Light. Die im folgenden Abschnitt beschriebenen Tests wurden auch noch mit dem älteren CDRS Viewset durchgeführt. Die CDRS-Resultate werden immer noch publiziert, sollten aber in den kommenden Monaten verschwinden. CDRS besitzt eine zu geringe Komplexität, welche heute nicht mehr marktgerecht ist. Tabelle 8.1 gibt einen Überblick über die Viewsets und ihren zugrundeliegenden Anwendun- gen.

Name Vendor Description Based on # of Tests Pro Parametric Technology Modeling und Rendering Pro/DESIGNER 7 CDRS (PTC) Application for Computer- Aided Industrial Design (CAID) DX Industrial Business Ma- Scientific Data Visualiza- Visualization Data 10 chines (IBM) tion and Analysis Package Explorer DRV Intergraph 3D Computer Model Re- Design Review 10 view Package for plant design models consisting of piping, equipment and structural elements such as I-beams, HVAC ducting, and electrical raceways AWadvs Alias/Wavefront Integrated workstation-ba- Advanced Visualizer 10 sed 3D animation system that offers a comprehensive set of tools for 3D modeling, animation, rendering, image composi- tion, and video output Light Lightscape Technology Radiosity Visualization Lightscape Visuali- 4 Inc. Application with a physi- zation System cally based lighting interface Tabelle 8.1: Überblick über die Viewperf 6.1 Viewsets 8.2 Die Viewsets 83

Tabelle 8.2 zeigt die Grösse und die Schwerpunkte der einzelnen Viewsets. Dabei ist Light mit Abstand das komplexeste Viewset. In ProCDRS werden alle Tests im Display List-Modus durchgeführt. Name Grösse Schwerpunkte Pro 200’000 3D-Punkte Wireframe-Darstellung mit geglätteten Linien CDRS Alle Tests im Display List-Modus texturiert DX 93’000 3D-Punkte Dreiecks-Mesh Wireframe, mit Z-Buffer DRV 150’000 3D-Punkte Dreiecks-Mesh gouraud- und flat-shaded AWadvs 62’000 3D-Punkte texturiert (trilinear gefiltert) Wireframe, unbeleuchtet, ohne Z-Buffer Light 1’100’000 3D-Punkte bzw. farbige Wireframes 1’800’000 3D-Punkte gouraud-shaded keine Texturen Tabelle 8.2: Grösse und Schwerpunkte der Viewsets 84 8 Der Viewperf Benchmark

8.2.1 ProCDRS - Pro/DESIGNER Das ProCDRS Viewset ist eine aktuelli- sierte Version des CDRS1 Viewsets und steht in der Version 1 zur Verfügung. Es modelliert die Graphikoperationen von Pro/ DESIGNER, der Industrial Design Soft- ware von Parametric Technology. Das Viewset besteht aus zehn Tests; jeder repräsentiert einen anderen Operationsmo- dus von Pro/DESIGNER. Zwei Tests benutzen ein Wireframe (Draht- gitter) Modell, alle anderen verwenden ein Shaded (schattiertes) Modell. Das schattierte Modell ist eine Mixtur von Triangle Strips und Independant Triangles, mit unge- fähr 281’000 Eckpunkten in 4’700 OpenGL Primitiven, was ein Total von 131’000 Dreiecke ergibt. Die ungefähre Grösse eines Dreiecks auf dem Bildschirm ist 4 bis 5 Pixel. Das Wireframe Modell besteht nur aus Linienstreifen mit ungefähr 202’000 Ecken in 19’000 Streifen, was ein Total von 184’000 Linien ergibt. Alle Tests laufen im Display List Modus ab. Die Wireframe Tests benutzen Anti-Aliased Linien, da diese in Pro/DESIGNER standardmässig vorkommen. Die schattierten Tests benutzen ein Lichtquelle und zweiseitige Beleuchtung. Die Textur ist ein512× 512 Pixel grosses Bild mit 24-bit Farbtiefe, was zu einer Speichergrösse von 800 KByte führt. Test Weight Description 1 25 Wireframe Test 2 25 Wireframe Test, walkthrough 3 10 Shaded Test 4 10 Shaded Test, walkthrough 5 5 Shaded Test with Texture 6 5 Shaded Test with Texture, walkthrough 7 3 Shaded Test with Texture, eye linear texgen (dynamic reflections) 8 3 Shaded Test with Texture, eye linear texgen, walkthrough 9 7 Shaded Test with Color per Vertex 10 7 Shaded Test with Color per Vertex, walkthrough Tabelle 8.3: ProCDRS Tests

Weitere Informationen siehe [9].

1. Conceptual Design Rendering Software 8.2 Die Viewsets 85

8.2.2 DX - Data Explorer Das DX Viewset basiert auf dem IBM Visualization Data Explorer, welches ein General-Purpose Software Packet ist, das der Visualisierung und Analyse von wis- senschaftlichen Daten dient. DX steht in der Version 4 zur Verfügung. Es unterhält ein datenflussorientiertes Client-Server Ausführungsmodell und ist zurzeit für UNIX Worksta- tions von Digital Equipment, IBM, Sun, Hewlett-Pack- ard und Silicon Graphics erhältlich. Die Tests visualisieren ein Set von Partikelverfolgun- gen durch ein als Röhren dargestelltes Vektorflussfeld. Die Breite jeder Röhre repräsentiert die Länge des Geschwindigkeitsvektors an diesem Ort. Solche Daten können aus Flüssigkeits-Durchfluss Simulationen durch eine Verbeugung resultieren. Das repräsentierte Objekt besitzt 1’000 Triangle Meshes mit je ungefähr 100 Eckpunkten. Dies ist ein mittelgrosser Datensatz für den Data Explorer. Alle Tests benutzen Z-Buffering mit einer Lichtquelle zusätzlich zur Spezifikation von einer Farbe zu jedem Eckpunkt. Triangle Meshes sind die primären Primitive für dieses Viewset.

Test Weight Description 1 40 Triangle Mesh, immediate mode 2 20 Line, immediate mode 3 10 Triangle Mesh, display list 4 8 Point, immediate mode 5 5 Line, display list 6 5 Triangle Mesh, list with facet normals 7 5 Triangle Mesh, with polygon stippling 8 2.5 Triangle Mesh, with two sided ligh‘ting 9 2.5 Triangle Mesh, clipped 10 2 Point, direct rendering, display list Tabelle 8.4: DX Tests

Weitere Informationen siehe [4]. 86 8 Der Viewperf Benchmark

8.2.3 DRV - Design Review Das DRV Viewset basiert auf Intergraph’s Design Review Programm zum Betrachten von 3D Modellen. Speziell werden Betriebsdesignmodelle von Ölplattfor- men oder Hochhäusern damit visualisiert. Es erlaubt flexible Betrachtung und Manipulation der Modelle, hilft dem Design Team visuell den Fortschritt zu überwachen, Störungen zu identifizieren, Komponen- ten zu finden und Projektzustimmungen zu erleichtern, indem die Arbeit so präsentiert wird, dass auch ein nicht technisches Publikum sie verstehen kann. DRV steht zum Zeitpunkt dieser Arbeit in der Version 5 zur Verfügung. Das Modell in diesem Viewset ist ein Subset vom 3D Betriebsmodell, welches für die GYDA Ölproduktionsplattform in der Nordsee an der Südwestküste von Norwegen gemacht wurde. Design Review geht von einer Repräsentation des Modells aus, welche aus verschiedenen Objekten, wie zum Beispiel Röhren, Winkelstückventilen und elektrischen Kanälen, besteht. Während eines Walkthroughs wird jede Ansicht durch Transformation dieser Objekte zu Tri- angle Strips oder Line strips gerendert. Viele Design Review Modelle sind grösser als 50 Megabytes und werden als 3D Objekte gespeichert. Wegen der Grösse der Modelle und der Benutzung von face-culling, werden keine Display Lists verwendet. Es gibt sechs Tests, welche die häufigsten Operationen in Design Review repräsentieren.

Test Weight Description 1 45 Walkthrough rendering of curved surfaces; each curved object is rendered as a triangle mesh, depth-buffered, smooth-shaded, with one light and a different color per primitive 2 30 Walkthrough rendering of flat surfaces; flat shade model 3 8 Walkthrough rendering of curved surfaces; textured with linear blending and mipmaps 4 5 Walkthrough rendering of flat surfaces; also textured 5 4 Walkthrough rendering of flat surfaces; with "screen door" transparency applied (addition of polygon stippling) 6 4 Objects to be identified are rendered as solid and the rest of the view is rendered as a wireframe (line strips). The line strips are depth-buffered, flat- shaded and unlit. Colors are sent per primitive 7 4 A wireframe, orthographic projection of the model is used. Depth buffering is not used, so multithreading cannot be used; this preserves draw order Tabelle 8.5: DRV Tests

Weitere Informationen siehe [5]. 8.2 Die Viewsets 87

8.2.4 AWadvs - Advanced Visualizer AWadvs basiert auf Advanced Visualizer von Alias/ Wavefront. Es ist ein integriertes, workstation-basiertes 3D Animationssystem, welches als komplettes Hilfsmittel für 3D Modelling, Animation, Rendering und Video Output dient. AWadvs steht in der Version 2 zur Verfügung. Der Advanced Visualizer stellt folgendes zur Verfügung: interaktives Testrendering und hochqualitatives, freiform Oberflächen-Rendering, Software Rotoscoping1 für Com- puteranimation, realistische Bildeffekte, Bewegungen für eine unlimitierte Anzahl von Objekten, Kameras und Lichtquellen. Alle Operationen im Advanced Visualizer werden im Bildspeicherbereich mit doppelt gepuf- ferten Windows ausgeführt. Es gibt zehn Tests, welche die häufigsten Operationen im Advanced Visualizer repräsentieren.

Test Weight Description 1 41.8 Material shading of polygonal animation model with highest interactive image fidelity and perspective projection 2 10.45 Wireframe rendering of polygonal animation model with perspective projection 3 2.2 Material shading of polygonal animation model with lowest interactive image fidelity and perspective projection 4 0.55 Smooth shading of polygonal animation model with perspective projection 5 28.5 Flat shading of polygonal animation model with perspective projection 6 1.5 Material shading of polygonal animation model with highest interactive image fidelity and orthogonal projection 7 9.5 Wireframe rendering of polygonal animation model with orthogonal projection 8 0.5 Material shading of polygonal animation model with lowest interactive image fidelity and orthogonal projection 9 4.75 Smooth shading of polygonal animation model with orthogonal projection 10 0.25 Flat shading of polygonal animation model with orthogonal projection Tabelle 8.6: AWadvs Tests

Weitere Informationen siehe [13].

1. Rotoscopers erstellen Ebenen mit bewegten Elementen im Vordergrund (Menschen und Objekte), so dass Computer Graphik-Elemente in den Hintergrung plaziert werden können. Sie erstellen ebenso Ebenen, so dass ungewollte Objekte, wie z.B. Drähte, entfernt werden. 88 8 Der Viewperf Benchmark

8.2.5 Light - Lightscape Das Lightscape Visualisierungssystem von Lightscape Technologies, Inc. repräsentiert eine neue Generation der Computer Graphik Technologie, die Radiosity Algorithmen mit physikalisch basierten Beleuchtungsschnittstellen kombiniert. Light steht in der Version 2 zur Verfü- gung. Beleuchtung Die wichtigste Eigenschaft von Lights- cape, ist die Fähigkeit, globale Beleuch- tungseffekte zu simulieren. Das System beinhaltet zwei integrierte Visualisie- rungskomponenten. Die erste benutzt die progressive Radiosity Technik und generiert sichtunabhängige Simulatio- nen der diffusen Lichtausbreitung in einer Umgebung. Subtile aber bedeutende Effekte werden erfasst, eingeschlossen indirekte Beleuchtung, weiche Schatten und Farbverläufe zwischen Flä- chen. Der zweite Prozess, der Ray-Tracing Techniken benutzt, addiert spekulare Glanzpunkte, Reflektionen und Tranzparenzeffekte zu speziellen Ansichten der Radiosity Lösung. Progressive Verfeinerung Lightscape benutzt einen Radiosity Algorithmus mit progressiver Verfeinerung, welcher brauchbare visuelle Resultate während der Verarbeitung produziert. Die Qualität der Visuali- sierung verbessert sich, wenn der Prozess fortläuft. So hat der Benutzer die totale Kontrolle über die gewünschte Qualität. Diese Flexibilität erlaubt es dem Benutzer, schnell mehrere Beleuch- tungs- und Materialkombinationen zu testen, um genau den richtigen visuellen Effekt zu erhalten. Es gibt vier Tests, welche die häufigsten Operationen in Lightscape repräsentieren.

Test Weight Description 1 25 Walkthrough wireframe rendering of "Cornell Box" model using line loops with colors supplied per vertex 2 25 Full-screen walkthrough solid rendering of "Cornell Box" model using smooth-shaded z-buffered quads with colors supplied per vertex 3 25 Walkthrough wireframe rendering of 750K-quad Parliament Building model using line loops with colors supplied per vertex 4 25 Full-screen walkthrough solid rendering of 750K-quad Parliament Buil- ding model using smooth-shaded z-buffered quads with colors supplied per vertex Tabelle 8.7: Light Tests

Weitere Informationen siehe [7]. 8.3 Benchmarking mit Viewperf 89

8.2.6 CDRS - Conceptual Design Rendering Software Der Vollständigkeit halber wird hier noch das CDRS Viewset beschrieben. CDRS steht für Conceptual Design Rendering Software und ist die Modellierungs- und Rendering-Software von Parametric Technology für Computer Aided Industrial Design. CDRS steht in der Version 4 zur Verfügung. Sie wird benutzt, um Konzeptmodelle von Automobilen oder anderen Fahrzeugen, Konsumentenelektronik, Geräten und anderen Produkten zu erstellen, welche schwierige Freiform- konturen besitzen. CDRS ist der Vorgänger von ProCDRS. Es wurde aus ver- schiedensten Gründen von der OPC Gruppe durch ProCDRS ersetzt. Die kleine Modellgrösse in CDRS ist nicht mehr repräsentativ für die zu Grunde liegende Anwendung. Ein weiterer Ersetzungsgrund sind die einfachen Optimierungsmöglichkeiten, mit welchen die Werte ver- fälscht werden können. Es gibt sieben Tests, die verschiedene Operationstypen in CDRS repräsentieren. Fünf benutzen Triangle Strips-Datensätze von einem Rasenmähermodell, welches mit CDRS erstellt wurde. Die zwei anderen Tests zeigen die Repräsentation des Rasenmähers.

Test Weight Description 1 50 Vectors used in designing the model. Represents most of the design work done in CDRS. Antialiasing turned on to allow the designer to see a cleaner version of the model 2 20 Surfaces shown as polygons, but all with a single surface color 3 15 Surfaces grouped with different colors per group 4 8 Textures added to groups of polygons 5 5 Texture used to evaluate surface quality 6 2 Color added per vertex to show the curvature of the surface 7 0 (!) Same as test #1, but without the antialiasing Tabelle 8.8: CDRS Tests

Weitere Informationen siehe [9].

8.3 Benchmarking mit Viewperf Viewperf verwendet die Kommandozeile zum Setzen der OpenGL Zustände und zur Eingabe von Textur- und Modelldaten. Viewperf setzt Rendering-Zustände und konvertiert Datensätze in ein Format, welches unter Benutzung von OpenGL Rendering Calls abgearbeitet werden 90 8 Der Viewperf Benchmark kann. Viewperf rendert den Datensatz für eine vorgegebene Zeit oder für eine bestimmte Anzahl Frames und misst die Anzahl der Bilder pro Sekunde. Viewperf gibt die Testresultate in “frames per second” an. Andere Informationen über das System - alle Rendering Zustände, die Zeit um Display Lists aufzubauen und den benutzten Datensatz - werden ebenfalls ausgegeben. Ein Benchmark mit Viewperf ist ein einzelner Aufruf von Viewperf mit Kommandozeilenop- tionen, welche dem Programm gewisse Parameter mitgeteilt werden. Dazu gehört welcher Datensatz eingelesen werden soll, welche Texturdatei benutzt werden soll, welche OpenGL Pri- mitiven benutzt werden sollen, um den Datensatz zu rendern, welche Attribute benutzt werden sollen und wie oft, wenn überhaupt, Display Lists gebraucht werden sollen. Somit gibt es eine riesige Auswahl an Viewperf Benchmarks.

8.3.1 Beispielaufruf von Viewperf Viewperf könnte wie folgt aufgerufen werden:

viewperf-mh newtruck-shade -dl -zb -vz -nil 1 -l2s -xws 1260 -yws 980 -newview -mp 20 -grab grab3.scr

Die Parameter haben folgende Bedeutung: viewperf startet das Viewperf Programm -mh spezifiziert das Format des Datensatzes, in diesem Fall ist es mesh (binär) newtruck-shade ist der Name des Datensatzes, hier der schattierte Truck -dl gibt an, dass der Test im display list Modus ausgeführt wird -zb aktiviert den Z-Buffer -vz erlaubt dem Benutzer, die Visualisierung zu definieren, in diesem Fall wird der Z-Buffer aktiviert -nil 1 gibt an, wieviele Lichtquellen benutzt werden, in diesem Fall ist es eine -l2s beleuchtet beide Seiten des Modells -xws 1260 gibt die x-Koordinaten-Grösse des Testfensters an, hier 1260 Pixel -yws 980 gibt die y-Koordinaten-Grösse des Testfensters an, hier 980 Pixel -newview aktiviert die Berechnung des “New View Frustum” -mp 20 gibt die minimale Periode des Tests an, in diesem Fall 20 Sekun- den -grab grab3.scr Bildschirmschnappschuss in die Datei grab3.scr

8.4 Kompilieren von Viewperf Das Kompilieren des Viewperf Benchmarks zeigte sich als sehr schwierig. Dies ist auf die vielen UNIX Versionen die es gibt zurückzuführen . Hier werden nur die Veränderungen an den Makefiles angegeben, die vorgenommen werden mussten, um Viewperf zu starten.

8.4.1 Sun unter Solaris Bei der Sun Workstation musste das Modul “lang” hinzugefügt werden (module add lang). Dieser Fehler trat auf, da dieses Modul den C Compiler zur Verfügung stellt. 8.5 Zusammenfassung 91

8.4.2 SGI unter IRIX Es gab Probleme mit den Libraries. Die Reihenfolge der Anbindung der Libraries durch das vorhandene Makefile ist nicht korrekt. Somit muss man im Makefile (makefile.sgi) unter “LIB =” die Reihenfolge dahingehend ändern, dass -laux vor -lX11 zu stehen kommt. Dies hat den einfachen Grund, dass die “X11” Library die “aux” Library benutzt. Im Makefile vom vpaux Directory (/vpaux/Makefile) musste folgende Zeile unter “INCLUDE” hinzugefügt werden: /usr/openwin/share/include (dies ist vermutlich nicht auf einen Fehler zurückzuführen, sondern auf unterschiedliche Path-Strukturen). Ausserdem musste unter “CCFLAGS” folgendes hinzugefügt werden: $(INCLUDES) ABI. Bei den SGI Maschinen ist zu beachten, dass je nach Prozessor vor dem Kompilieren die SGI_ABI Variable gesetzt werden muss. ABI steht für Application Binary Interface. Ein ABI definiert eine Systemschnittstelle, um kompilierte Programme zu starten. Es definiert die Pro- zeduraufrufregeln, welche Instruktionssatz-Architektur (ISA) unterstützt wird und welche For- mate die Objektdateien besitzen. IRIX unterstützt folgende ABI’s: ¥ O32 ist das alte 32-bit ABI, welches unter IRIX 5 den Standard bezeichnete. Die MIPS 1 und 2 Architekturen werden unterstützt, wobei letztere der Standard ist. Das Format der Objektdateien ist ELF32, die Anzahl der Gleitkommaregister mit doppelter Genauigkeit ist 16. Es werden ältere Prozeduraufrufregeln vewendet. ¥ N64 ist das 64-bit ABI, welches in IRIX 6.0 eingeführt wurde. Es werden die MIPS 3 und 4 Architekturen unterstützt, wobei letztere der Standard ist. Das Format der Objektdateien ist ELF64, die Anzahl der Gleitkommaregister mit doppelter Genau- igkeit ist 32 und es werden die neuen Prozeduraufrufregeln verwendet. ¥ N32 ist die 32-bit ABI mit hoher Performance welche mit IRIX 6.2 eingeführt wurde.Es werden die MIPS 3 und 4 Architekturen unterstützt, wobei MIPS 3 der Standard ist. Das Format der Objektdateien ist ELF32, die Anzahl der Gleitkommaregister mit doppelter Genauigkeit ist 32 und es werden die neuen Prozeduraufrufregeln verwendet. In dieser Arbeit wurde für alle Maschinen das ABI auf “N32” gesetzt. In der Kommandozeile gibt man dazu folgendes ein: setenv SGI_ABI -n32. Weitere Informationen über das ABI findet man in den Manpages (man abi) und auf der MIPS ABI Webpage unter [15].

8.4.3 Pentium Pro/Pentium II unter Windows NT Für Windows wird ein InstallShield zur Verfügung gestellt, welches problemlos ablief. Nur die Batchfiles erfüllten nicht ihren Zweck. Diese konnten aber schnell auf unsere Bedürfnisse abge- stimmt werden.

8.5 Zusammenfassung

Viewperf ist ein standardisierter und von der Industrie akzeptierter 3D Anwendungsbenchmark, der die Graphikleistung realer 3D Anwendungen misst. Viewperf verwendet dazu fünf sogenannte Viewsets, welche verschiedene Anwendungsgebiete repräsentieren. Jedes Viewset besteht aus einer Vielzahl von Einzeltests, welche alle ein Resultat in Bildern pro Sekunde ausgeben. Für jedes Viewset wird eine Zahl als gewichtetes Resultat der Einzeltests angegeben; grössere Zahlen geben dann grössere Leistung an. 92 8 Der Viewperf Benchmark

Viewperf eignet sich, um einen Überblick über die 3D Graphikleistung eines Systems zu erhalten. Um genaue Leistungsangaben oder die maximale Leistung zu messen, eignet er sich nicht. 9 9Der GLperf Benchmark

GLperf [16] ist ein Programm, welches die Leistung von OpenGL Graphikoperationen misst. Diese Operationen werden auf “Low-Level” Primitiven, wie Punkte, Linien, Polygone, Pixel etc. angewandt. GLperf beinhaltet keine ganzen geometrischen Modelle wie das in Viewperf der Fall ist. Mit GLperf versucht man einerseits die Methode zu standardisieren, mit welcher Computerver- käufer die Leistung von OpenGL Graphikoperationen auf ihren Systemen angeben, andererseits ermöglicht GLperf einen umfassenden Einblick in die Graphikleistung eines Systems. GLperf wurde hauptsächlich von John Spitzer1 von Silicon Graphics entwickelt und ist wie Viewperf in die OpenGL Performance Characterization Gruppe der SPEC integriert worden.

9.1 Einführung

GLperf ermöglicht die explizite Eingabe der OpenGL Zustände und der Datenart, die das Gra- phiksystem bewältigen soll. Das Ziel von GLperf ist es, möglichst grosse Flexibilität in der Lei- stungsmessung über einen grossen Bereich von Szenarien und Modi zu erreichen. GLperf dient als Serviceprogramm. Die vom Benutzer gewünschten Zustände und Tests werden in einer Eingabedatei gespeichert, die dann von GLperf analysiert und ausgeführt werden.

Eingabedateien/Skripte. GLperf verwendet diese Eingabedateien oder Skripts, um ein flexi- bles Format zum Spezifizieren der OpenGL Primitiven vorzugeben, die es dem Benutzer ermöglicht, auf einfache Art anzugeben, was er testen will. Das Format erlaubt es, die GLperf

1. E-Mail: [email protected]

93 94 9 Der GLperf Benchmark

Objekte (zum Beispiel Line Strip) mit verschiedenen Attributen (zum Beispiel Linienbreite) zu definieren. Grammatik der Eingabedateien. Die Eingabedateien müssen einer Grammatik entsprechen. Diese ist im Anhang A.3.1 beschrieben. Mehr dazu auch in [16]. GLperf Eingabedateien können sowohl C als auch C++ Kommentare enthalten. Um die Ent- wicklung einfach zu machen, führt GLperf nur einfachste syntaktische und semantische Über- prüfungen durch. Zusätzlich zur flexiblen Spezifikation der Tests werden auch Optionen für die Generation von Testberichten zur Verfügung gestellt (siehe Kapitel 9.3.1). Art Beispiel einer Zuweisung Erklärung Wert (TexMagFilter GL_LINEAR) Die Zuweisung setzt den Texture Magnifi- cation Filter zu GL_LINEAR. Liste (TexMinFilter GL_NEAREST Zwei Tests werden gestartet. Der erste mit GL_LINEAR_MIPMAP_LINEAR) dem Texture Minification Filter GL_NEAREST, der zweite mit GL_LINEAR_MIPMAP_LINEAR. Werden mehrere Listen zusammenverwen- det, kann das schnell zu sehr vielen Tests führen. Bereich (ObjsPerBeginEnd Die Zuweisung setzt einen Bereich für die from 100 to 10 step -10) Anzahl Objekte, die pro Begin/End Paar gezeichnet werden. Dieser wird von 100 bis 10 variiert, in abnehmenden Zehnerschrit- ten. Die Schrittweite ist standardmässig auf 1 eingestellt. Man kann auch in Prozent- schritten gehen. (Beispiel: ... from 1 to 256 step 100%: führt zu 1, 2, 4, 8, 16, ...) Wildcard (Fog *) * und ALL sind Wildcards. Sie führen zu ei- (Fog ALL) ner Reihe von Tests, mit jedem möglichen- Attribut. Im angegebenen Fall werden Tests produziert, in denen der FogMode Pa- rameter zu folgenden Werten gesetzt wird: Off, GL_LINEAR, GL_EXP, GL_EXP2. Wild- cards für numerische Attribute, wie zum Beispiel Size, sind illegal. printf TriangleStripTest { Die printf Anweisung ist nur für die User- (UserString printf String Eigenschaft zulässig. Die printf An- (“Triangle Strip: %.0f pixels”, Size)) weisung erlaubt die Ausgabe von Daten, (Size from 20 to 100 step 20) ähnlich wie in der Programmiersprache C. } Mehr- DrawPixelsTest { Mehrfache Zuweisungen ein und desselben fachzu- ([ImageWidth ImageHeight] Wertes zu mehreren Eigenschaften sind zuweisung 16 32 64) lässig. } Tabelle 9.1: Beispiele für GLperf Attributzuweisungen 9.1 Einführung 95

Attribute. Attribute werden dazu verwendet, einem Objekt Zustände zuzuweisen. Die Attribute können sowohl lokal als auch global definiert werden. Lokal definierte Attribute werden nur von einer Objektdefinition benutzt, während global definierte Attribute von allen folgenden Definitionen in der Eingabedatei benutzt werden. Dies ermöglicht zum Beispiel das Setzen des RGB Farbmodus für alle Tests, ohne ihn jeweils für jeden Test erneut setzen zu müssen. Attribute können gesetzt werden, indem man ihnen einen Wert, eine Liste von Werten, einen Bereich, eine Wildcard oder ein printf-Anweisung zuweist. Wenn man mehrere Listen verwendet wird das kartesische Produkt darauf angewendet. Tabelle 9.1 zeigt Beispiele dieser verschiedenen Zuweisungen.

9.1.1 Charakteristiken von GLperf Die Skripts erlauben dem Benutzer die Veränderung der meisten Attribute, welche die Graphi- kleistung verändern können. Dies beinhaltet die meisten OpenGL Zustandsvariablen (e.g. Depth Functions, Alpha Functions, Fogging Functions, Texture Options, Polygon Mode, Number Of Lights, etc.). Zusätzlich kann man folgendes spezifizieren: ¥ den Ablaufmodus (immediate oder in einer Display List (compile, execute, compile_and_execute, list deletion)1) ¥ den Farbmodus (RGBα oder Index in einer Look-Up Table) ¥ die Grösse der Primitive (e.g. point, line, polygon) in Anzahl Pixel ¥ die Form der Primitive ¥ die Orientierung der Primitive (horizontal, vertikal oder zufällig) ¥ den Prozentsatz der Front-Facing beziehungsweise der Back-Facing Primitiven ¥ den Prozentsatz der trivial akzeptierten, geclippten und zurückgewiesenen Primitiven ¥ den Typ der Projektionsmatrix (perspektivisch oder parallel) ¥ die Datenmenge, die für jede Primitive zur Verfügung gestellt wird (color data (none, per facet, per vertex), normal data (none, per facet, per vertex), texture data (none, per vertex)) ¥ und viele weitere Parameter Erweiterbarkeit. GLperf wurde mit objektorientierten Konstrukten geschrieben, um die beträchtliche Menge an Zustandsinformationen unter Kontrolle zu halten und die Codereplika- tion durch Vererbung möglichst klein zu halten. Die aktuelle Version 3.12 wurde in C geschrieben und benutzt lex und yacc zur Analyse der Eingabe. Da die Daten in einer Objekthierarchie eingebunden sind, ist die ganze Verarbeitung auf eine Klasse eingeschränkt, welche einfach erweitert werden kann, um mehr oder andere Informationen zu behandeln.

1. compile: (glNewList) die Kommandos in der Display List werden vorcompiliert. execute: (glCallList) die Kommandos in der Display List werden ausgeführt. compile_and_execute: (glNewList) die Kom- mandos in der Display List werden ausgeführt, während sie compiliert werden. list deletion: (glDele- teLists) die Display List wird gelöscht. 96 9 Der GLperf Benchmark

Klassenhierarchie und Datenorganisation. Wenn eine Eingabedatei analysiert wird, generiert GLperf ein Objekt. Dieses besteht aus einem Satz von Testobjekten. Die Testklassenhier- archie wird in Abbildung 9.1 wiedergegeben. Klassen, die in Klammern angegeben werden, sind weitere, vererbte Klassen.

Test Drawn Primitive Vertex Points

Linear Lines

Line Strip

Line Loop

Polygonal Triangles

Triangle Strip

Triangle Fan

Quads

Quad Strip

Polygon

Raster Pos Bitmap (Image)

Text

Draw Pixels (Image, Trans. Map, Zoom)

Copy Pixels (Image, Trans. Map, Zoom)

Clear

Transform

Read Pixels (Image, Trans. Map)

Tex Image (Image, Trans. Map)

Abbildung 9.1: Testklassenhierarchie (Trans.Map steht für Transfer Map)

Die Daten, die in jeder Klasse gespeichert sind, können hier nicht alle angegeben werden. Sie sind sind unter [16] abrufbar. Das kleine Beispiel in Tabelle 9.2 beschreibt die Eigenschaften der DrawPixels Klasse. 9.1 Einführung 97

Property/String Description Type Possible Default Settable Printed Names Values Value DrawPixelsWidth Width of DrawPi- Ranged [1, 2048] -1 Yes Yes Width of Draw Pi- xels Call (width de- Integer xels faults to ImageWidth unless DrawPixelsWidthist set, in which case it sets the subimage width DrawPixelsHeight Height of DrawPi- Ranged [1, 2048] -1 Yes Yes Heigth of Draw Pi- xels Call (height de- Integer xels faults to ImageHeight unless DrawPixelsHeight ist set, in which case it sets the subimage height Tabelle 9.2: Datenorganisation: ein Beispiel (Eigenschaften der Draw Pixels Klasse)

Nun ein kleines Beispielskript, welches den Effekt der Anzahl Lichtquellen auf das Zeichnen von Dreiecken misst. TrianglesTest { (InfiniteLights *) // 0-8 Lichtquellen (NormalData PerVertex) // Eine Normale pro Eckpunkt }

9.1.2 Unterschiede zwischen Viewperf und GLperf Obwohl sowohl Viewperf als auch GLperf Graphikleistung messen, wurden sie mit zwei verschiedenen Zielen entwickelt. Während Viewperf ein ganzes Modell mit unterschiedlichen Primitivengrössen zeichnet, welche den typischen Grössen in richtigen Anwendungen entsprechen, weist GLperf künstlich jeder Primitive eine spezielle Grösse zu. Während Viewperf den Rendering Mix einer Anwen- dung simuliert und die Leistung misst, offeriert GLperf die Möglichkeit viel spezifischere Angaben zum Messen der maximalen Leistung eines Systems für das Ausführen einer bestimmten Zeichnungsfunktion. Hierzu eine Analogie aus der Automobilwelt: GLperf entspricht dem Geschwindigkeitsmess- gerät, welches die höchste Geschwindigkeit misst und Viewperf der Stoppuhr, welche die Durchschnittsgeschwindigkeit in einem Slalom misst. Ein weiterer Unterschied besteht in der Ausgabe der Resultate. Viewperf Tests resultieren in einer Angabe in Bildern pro Sekunde, während GLperf Tests eine Messung in Anzahl gezeichneter Primitiven pro Sekunde ergeben. 98 9 Der GLperf Benchmark

9.2 Die OPC Skripte Um repräsentative Resultate von GLperf zu erhalten, hat die OPC Gruppe 13 Skripte geschrieben, welche die interessantesten Leistungsbereiche testen. Sie sind aufgeteilt in 10 Skripte im RGB-Farbraum und 3 Skripte im indexierten Farbraum. Das Postfix des Skriptnamens gibt die jeweilige Zugehörigkeit an. In den Kapiteln 9.2.1 bis 9.2.13 wird ein kleiner Überblick über die Funktionalität dieser Skripte gegeben.

9.2.1 BgnEnd.rgb Das BgnEnd.rgb Skript testet die Leistung in Abhängigkeit der Anzahl der Primitiven zwischen dem glBegin Kommando und dem glEnd Kommando. Zwischen einem glBegin und einem glEnd Kommando können geometrische Konstrukte definiert werden. Es können Eckpunkte, Normalen, Farbe, Texturkoordinaten, etc. spezifiziert werden. Die Ergebnisse geben wider, ob sich die Maschine auch für grosse Szenen oder Konstrukte eignet. In jedem der folgenden Tests wird der “Objekte pro glBegin/ glEnd Paar”- Parameter von 1 bis 541 in 10% Schritten erhöht. Dies ergibt die folgende Liste von 48 Zahlen:1 2345678 9101113151719212427303337414651576370778594104115127140154170 187 206 227 250 275 303 334 368 405 446 491 541. Folgende Einzeltests sind mit diesem Skript möglich: ¥ 10 pixel Lines (RGB, 3D, flat) - Immediate Mode ¥ 10 pixel Lines (RGB, 3D, flat) - Display List Mode ¥ 10 pixel Line Strip (RGB, 3D, flat) - Immediate Mode ¥ 10 pixel Line Strip (RGB, 3D, flat) - Display List Mode ¥ 25 pixel Triangle Strip (RGB, Z, 3D, smooth, 1 inf light) - Immediate Mode ¥ 25 pixel Triangle Strip (RGB, Z, 3D, smooth, 1 inf light) - Display List Mode ¥ 50 pixel Quads (RGB, Z, 3D, smooth, 1 inf light) - Immediate Mode ¥ 50 pixel Quads (RGB, Z, 3D, smooth, 1 inf light) - Display List Mode 9.2 Die OPC Skripte 99

9.2.2 CopyPixl.rgb CopyPixl.rgb misst die Leistung der glCopyPixels RGB Ope- rationen. glCopyPixels kopiert einen rechteckigen Bereich von Pixeln von einem Bereich des Frame Buffers in einen anderen. Dieser Befehl beinhaltet eigentlich ein glReadPixels gefolgt von einem glDrawPixels, ohne aber in den Speicherbereich geschrieben zu werden. Dieser Test misst die Raster-Operationen (Fogging, Textu- ring) und die Per-Fragment-Operationen. Abbildung 9.2 hilft, die verschiedenen Pixelbefehle zu verstehen. Mit glCopyPixels werden Pixels aus dem Frame Buffer über die Raster- und Per-Fragment-Operationen wieder in den Frame Buffer geschrieben. glDrawPixels schreibt Pixels aus dem Speicher in den Frame Buffer, glReadPixels führt die inverse Funktion aus: das Lesen von Pixels aus dem Frame Buffer in den Speicher. Der Test läuft im “Immediate” Modus ab. Die Breite und Höhe der CopyPixels Bilder (CopyPixelsWidth, CopyPixelsHeight) werden von 16 bis 512 erhöht, in 2er Potenz-Schritten. (16, 32, 64, 128, 256, 512). Dieses Skript führt nur einen einzigen Test aus: ¥ CopyPixels (RGB)

Per Vertex glRasterPos* Operations & Primitive Assembly

Rasterization Per- Frame glDrawPixels (fog, texture) Fragment Buffer Processor Operations Memory glReadPixels glCopyPixels Abbildung 9.2: Pixel Datenfluss (glRasterPos* spezifiziert die Position für ein Pixel) 100 9 Der GLperf Benchmark

9.2.3 DrawPixl.ndx DrawPixl.ndx misst die Leistung der glDrawPixels Color Index Operationen. glDrawPixels liest einen rechteckigen Bereich von Pixeln aus dem Speicher und schreibt ihn in den Frame Buffer. Der Test misst nicht nur die Rasterisierung, sondern auch den Zugriff auf den Speicher. Die Tests laufen beide im indexierten Farbraummodus, das heisst die vorkommenden Farbwerte werden in einer Look- Up Table gespeichert. Die Breite und Höhe der DrawPixels Bilder (ImageWidth, ImageHeight) werden von 16 bis 512 erhöht, in 2er Potenz- Schritten. (16, 32, 64, 128, 256, 512). Zwei Tests können mit diesem Skript durchgeführt werden: ¥ DrawPixels (color index, ubyte) - Immediate Mode ¥ DrawPixels (color index, ubyte) - Display List Mode

9.2.4 DrawPixl.rgb DrawPixl.rgb misst die Leistung der glDrawPixels RGB Operationen. Es werden die gleichen Tests wie im DrawPixl.ndx durchge- führt, mit dem Unterschied, dass sie im RGB Farbraum aus- geführt werden. Die Breite und Höhe der DrawPixels Bilder (ImageWidth, ImageHeight) werden von 16 bis 512 erhöht, in 2er Potenz- Schritten. (16, 32, 64, 128, 256, 512)

Diese Skript beinhaltet die folgenden Einzeltests: ¥ DrawPixels (RGB, ubyte) - Immediate Mode ¥ DrawPixels (RGB, ubyte) - Display List Mode ¥ DrawPixels (RGBA, ubyte) - Immediate Mode ¥ DrawPixels (RGBA, ubyte) - Display List Mode ¥ DrawPixels (RGBA, zoom 2x, ubyte) - Immediate Mode ¥ DrawPixels (RGBA, zoom 2x, ubyte) - Display List Mode ¥ DrawPixels (RGBA, zoom .5x, ubyte) - Immediate Mode ¥ DrawPixels (RGBA, zoom .5x, ubyte) - Display List Mode 9.2 Die OPC Skripte 101

9.2.5 FillRate.rgb FillRate.rgb misst, wieviele Pixel pro Sekunde gezeichnet werden können. Diese Tests messen, wie gut die Rasterization Engine des Graphiksubsystems ist. Bei allen Tests werden im “Display List” Modus 500× 500 Pixel grossen Quadrate gezeichnet.

Dieses Skript führt die folgenden Einzeltests aus:

¥ Quads (RGB, 3D, ﬂat) ¥ Quads (RGB, Z, 3D, ﬂat) ¥ Quads (RGB, 3D, smooth) ¥ Quads (RGB, Z, 3D, smooth) ¥ Quads (RGB, Z, 3D, 64x64 RGB nearest modulated texture, smooth) ¥ Quads (RGB, Z, 3D, 64x64 RGB linear modulated texture, smooth) ¥ Quads (RGB, Z, 3D, 64x64 RGB trilinear modulated texture, smooth)

9.2.6 Light.rgb Light.rgb misst den Einfluss der Anzahl eingeschalteter Lichtquellen auf das Zeichnen einer bestimmten Primitive. Die Berechnnungen, die hier ausgeführt werden, sind Per- Vertex Operationen, also eckpunktbezogene Operationen. Diese Operationen werden in der Geometry Engine bearbeitet, wenn diese vorhanden ist, andernfalls werden die Berech- nungen vom Hauptprozessor durchgeführt. In jedem Test wird die Anzahl Lichtquellen (InfiniteLights) von 0 bis 8 jeweils um Eins inkrementiert. Light testet folgende Modi und Primitiven: ¥ Triangle Strip (RGB, Z, 3D, smooth, n inf lights) - Immediate Mode ¥ Triangle Strip (RGB, Z, 3D, smooth, n inf lights) - Display List Mode ¥ Quads (RGB, Z, 3D, smooth, n inf lights) - Immediate Mode ¥ Quads (RGB, Z, 3D, smooth, n inf lights) - Display List Mode 102 9 Der GLperf Benchmark

9.2.7 LineFill.rgb LineFill.rgb misst den Einfluss der Linienlänge auf die Ren- deringleistung von Linien. In jedem Test wird der Grössenparameter (Size in Pixel) von 1 bis 541 in 10% Schritten erhöht. Dies gibt die folgeden Liste von 48 Zahlen:1 2 3456789 10 11 13 15 17 19 21 24 27 30 33 37 41 46 51 57 63 70 77 85 94 104 115 127 140 154 170 187 206 227 250 275 303 334 368 405 446 491 541.

Folgende Einzeltests werden durchgeführt: ¥ Line Strip (RGB, 3D, flat) - Immediate Mode ¥ Line Strip (RGB, 3D, flat) - Display List Mode ¥ Line Strip (RGB, Z, 3D, flat) - Immediate Mode ¥ Line Strip (RGB, Z, 3D, flat) - Display List Mode ¥ Line Strip (RGB, 3D, AA, flat) - Immediate Mode ¥ Line Strip (RGB, 3D, AA, flat) - Display List Mode

9.2.8 OPClist.ndx OPClist.ndx enthält eine Reihe von Tests für die verschie- densten Operationen mit Graphikprimitiven (Linien, Drei- ecke, Quadrate) und weitere Operationen, die nicht von Primitiven abhängig sind, wie zum Beispiel das Löschen eines Windows. Dies gibt einen Überblick über die maximale Leistung des Systems. Das Löschen eines Windows ist typischerweise eine der teu- ersten Operationen für einen1280× 1024 Monitor, da über eine Million Pixel bearbeitet werden müssen. Für einfache Graphikanwendungen kann die Löschoperation mehr Zeit in Anspruch nehmen als das komplette restliche Zeichnen. Wenn man nun nicht nur den Color Buffer, sondern auch den Depth und Stencil Buffers löschen muss, kann die Löschoperation sogar dreimal so teuer sein. Gewisse Maschinen haben Hardware, welche es erlaubt, mehr als einen Puffer gleichzeitig zu löschen. In den Clear Tests wird die Leistung mit verschiedenen Puffervariationen gemessen. Die Tests sind im indexierten Farbmodus. ¥ Clear (color index) ¥ Points (color index) ¥ Lines (color index) ¥ Line Loop (color index) ¥ Line Strip (color index) 9.2 Die OPC Skripte 103

¥ Triangles (color index) ¥ Triangle Strip (color index) ¥ Triangle Fan (color index) ¥ Quads (color index) ¥ Quad Strip (color index) ¥ Polygon (color index) ¥ Text (color index)

9.2.9 OPClist.rgb OPClist.rgb enthält eine handvoll Tests für verschiedenste Operationen auf Graphikprimitiven und weitere Operatio- nen, die nicht von Primitiven abhängig sind, wie zum Bei- spiel Window Clears. Es werden die gleichen Tests wie im OPClist.ndx Skript durchgeführt, die Tests sind im RGB Farbmodus. ¥ Clear (RGB) ¥ Points (RGB) ¥ Lines (RGB) ¥ Line Loop (RGB) ¥ Line Strip (RGB) ¥ Triangles (RGB) ¥ Triangle Strip (RGB) ¥ Triangle Fan (RGB) ¥ Quads (RGB) ¥ Quad Strip (RGB) ¥ Polygon (RGB) ¥ Text (RGB) 104 9 Der GLperf Benchmark

9.2.10 ReadPixl.ndx ReadPixl.ndx misst die Leistung der glReadPixels Color Index Operationen. glReadPixels liest einen rechteckigen Bereich von Pixeln aus dem Frame Buffer und schreibt ihn in den Speicher. Abbildung 8.2 hilft, diesen Pixelbefehl zu verstehen. Zu beachten ist, dass dieser Test auch den Speicherzugriff misst. Der Test läuft im “Immediate” Modus ab. Die Breite und Höhe der ReadPixels Bilder (ImageWidth, ImageHeight) werden in 2er Potenz-Schritten von 16 bis auf 512 erhöht. (16, 32, 64, 128, 256, 512).

Es wird nur ein Test durchgeführt: ¥ ReadPixels (color index, ubyte)

9.2.11 ReadPixl.rgb ReadPixl.rgb misst die Leistung der glReadPixels RGB Ope- rationen. Dieses Skript misst die gleiche Operation wie ReadPixl.ndx. Beide Tests laufen im “Immediate” Modus ab. Die Breite und Höhe der ReadPixels Bilder (ImageWidth, ImageHeight) werden von 16 bis 512 erhöht, in 2er Potenz- Schritten. (16, 32, 64, 128, 256, 512)

Es werden zwei Tests durchgeführt: ¥ ReadPixels (RGB, ubyte) ¥ ReadPixels (RGBA, ubyte) 9.2 Die OPC Skripte 105

9.2.12 TexImage.rgb TexImage.rgb misst die Leistung der glTexImage2D RGB Operationen. glTexImage2D spezifiziert ein zweidimensionales Textur- bild, welches auf eine Graphikprimitive gelegt wird. Die ersten vier Tests beschreiben Download Tests von Tex- turen aus dem Systemspeicher in den Graphik/Texturspei- cher. Die anderen zwei Tests beschreiben Texturwechsel im Texturspeicher. Die ersten vier Tests laufen im “Immediate” Modus ab. (Die Tests im “Display List” Modus ablaufen zu lassen, würde nicht viel Sinn machen, da viele Systeme in diesem Modus die Texturen mit glCallList binden. Dies ist jedoch nicht das, was hier gemessen werden soll.) Die letzten zwei Tests generieren Zahlen, welche angeben, wie schnell Texturen gebunden (texture binding mit glCallList oder texture object) werden können. Diese Tests laufen im “Display List” Modus ab. Die Breite und Höhe der TexImage Bilder (ImageWidth, ImageHeight) werden von 32 bis 2048 erhöht, in 2er Potenz-Schritten. (32, 64, 128, 256, 512, 1024, 2048). Somit werden folgende Tests durchgeführt: ¥ TexImage - Download(RGB, ubyte, point draw) ¥ TexImage - Download(RGBA, ubyte, point draw) ¥ TexImage - Download(RGB, ubyte, mipmapped, point draw) ¥ TexImage - Download(RGBA, ubyte, mipmapped, point draw) ¥ TexImage - Switching(RGB, ubyte) ¥ TexImage - Switching(RGB, ubyte, mipmapped)

9.2.13 TriFill.rgb TriFill.rgb misst den Einfluss der Vergrösserung der Primi- tive auf das Zeichnen von Polygonen. In jedem Fall wird der Grössenparameter (Size in Pixel) von 1 bis 541 in 10% Schritten erhöht. Dies gibt die folgende Liste von 48 Zahlen:1 2 3 4567891011131517192124 27 30 33 37 41 46 51 57 63 70 77 85 94 104 115 127 140 154 170 187 206 227 250 275 303 334 368 405 446 491 541. Folgende Tests werden mit diesem Skript durchgeführt: ¥ Triangle Strip (RGB, 3D, flat) - Immediate Mode ¥ Triangle Strip (RGB, 3D, flat) - Display List Mode ¥ Triangle Strip (RGB, Z, 3D, flat) - Immediate Mode ¥ Triangle Strip (RGB, Z, 3D, flat) - Display List Mode 106 9 Der GLperf Benchmark

¥ Triangle Strip (RGB, 3D, smooth) - Immediate Mode ¥ Triangle Strip (RGB, 3D, smooth) - Display List Mode ¥ Triangle Strip (RGB, Z, 3D, smooth) - Immediate Mode ¥ Triangle Strip (RGB, Z, 3D, smooth) - Display List Mode ¥ Triangle Strip (RGB, Z, 3D, smooth, 1 inf light) - Immediate Mode ¥ Triangle Strip (RGB, Z, 3D, smooth, 1 inf light) - Display List Mode ¥ Triangle Strip (RGB, 3D, 64x64 RGB nearest modulated texture, smooth, 1 inf light) - Immediate Mode ¥ Triangle Strip (RGB, 3D, 64x64 RGB nearest modulated texture, smooth, 1 inf light) - Display List Mode ¥ Triangle Strip (RGB, 3D, 64x64 RGB linear modulated texture, smooth, 1 inf light) - Immediate Mode ¥ Triangle Strip (RGB, 3D, 64x64 RGB linear modulated texture, smooth, 1 inf light) - Display List Mode ¥ Triangle Strip (RGB, 3D, 64x64 RGB trilinear modulated texture, smooth, 1 inf light) - Immediate Mode ¥ Triangle Strip (RGB, 3D, 64x64 RGB trilinear modulated texture, smooth, 1 inf light) - Display List Mode

9.3 Benchmarking mit GLperf

GLperf verwendet die Kommandozeile zur Eingabe von Daten. GLperf gibt die Testresultate entweder in “Objekte pro Sekunde” oder in “Pixel pro Sekunde” an. Das Wechseln dieser Angabe erfolgt über die Kommandozeile beim Aufruf von GLperf. Andere Informationen über das System - alle Rendering Zustände, die Zeit um Display Lists aufzubauen und der benutzte Datensatz - werden ebenfalls ausgegeben. Ein Benchmark mit GLperf ist ein einzelner Aufruf von GLperf mit der Angabe eines Skriptes. Im Skript wird spezifiziert, welches Primitiv getestet werden soll, zum Beispiel ein 50 Pixel grosser Triangle Strip. Ein Skript erlaubt das Testen von vielen Primitiven gleichzeitig.

9.3.1 Beispielaufruf von GLperf Ein Beispielaufruf von GLperf lautet wie folgt:

GLperf [-d] [-p] [-s] [-u] input_file

-d gibt an, ob ein Delta Output gemacht werden soll. Wenn ein Test mit Delta Output durchgeführt wird, erhält man in der Ausgabe nur die Differenzen zwischen dem vorangegangenen Test und dem Aktuellen. Standard ist kein Delta Output. -p gibt an, dass die Testresultate in Pixel pro Sekunde gemacht werden. Standard ist Objekte pro Sekunde. 9.4 Compilieren von GLperf 107

-s spezifiziert, dass ein Delta Output vom Standard-Status gemacht werden soll. Der Standard-Status gibt zum Beispiel an, dass es sich um GLperf 3.1.2 handelt, oder dass Doublebuffering gemacht wird. Standard ist kein Delta Output om Standard-Status. -u gibt an, dass die Testresultate pro Microsekunde gemacht werden. Standard ist pro Sekunde. input_file ist der Name der Eingabedatei, zum Beispiel eines der vorgegebenen Stan- dard Skripte.

9.4 Compilieren von GLperf

Das Compilieren des GLperf Benchmarks zeigte sich weniger schwierig als der Viewperf Benchmark. Hier werden nur die Veränderungen angegeben, die vorgenommen werden mussten, um GLperf zu compilieren.

9.4.1 Sun unter Solaris Auf den Suns ist die Texture2D OpenGL Erweiterung (Extension) nicht vorhanden. Deshalb musste aus dem Quellcode von Hand jeder Verweis auf diese Kommandos entfernt werden. Da die Standard Skripte der OPC jedoch keine dieser Kommandos benutzen, ist dies unproblema- tisch. Wenn man ein eigenes Skript schreiben will, muss darauf geachtet werden, dass diese Kom- mandos nicht benutzt werden, da sonst die Tests nicht sehr aussagekräftig sind. Die fehlenden Kommandos werden dann entweder durch andere ersetzt oder einfach übergangen. Im Anhang A.3.2 befindet sich eine Liste all dieser Kommandos.

9.4.2 SGI unter IRIX Unter IRIX zeigte sich alles problemlos. Manchmal lief die Compilation mit dem gmake Pro- gramm besser als mit dem make Programm.

9.4.3 Pentium Pro/Pentium II unter Windows NT Zuerst mussten die Umgebungsvariablen so gesetzt werden, dass sie der Kommandozeilencom- piler verwenden kann (das Programm nmake zum Beispiel). Dies geschieht mit einem Batch- file, das man auf den Pentium II Workstations unter “C:\DevStudio\VC\bin\vcvars32.bat” findet und startet. Dieses wird vom Visual C Studio zur Verfügung gestellt. Es mussten ein paar kleine Veränderungen an Makefile.win vorgenommen werden. Die Stan- dard Paths für die OpenGL Libraries mussten verändert werden. Wichtig ist, dass man bei “GL_H=” und “GLU_H=” den richtigen Pfad eingibt.

9.5 Zusammenfassung

GLperf ist ein standardisierter und von der Industrie akzeptierter 3D Benchmark, der die Lei- stung von OpenGL Graphikoperationen misst. GLperf verwendet dazu dreizehn Skripte, welche verschiedene Modi und Testprimitiven verwenden. Eine Messung ergibt ein Ergebnis in Anzahl gezeichneter Primitiven pro Sekunde. GLperf eignet sich, um genaue Angaben über die 3D Graphikleistung eines Systems zu erhalten. Es generiert aber ein riesiges Datenvolumen, welches sehr schwer zu sortieren und analysieren ist. 108 9 Der GLperf Benchmark 10 10Der SPEC CPU95 Benchmark

Der SPEC CPU95 Benchmark [19], misst die Leistung des Prozessors, der Speicherhierarchie und des Compilers eines Computersystems. CPU95 seinerseits benutzt die CINT95 Tests mit acht Programmen um die Festkommaeinheit und die CFP95 Tests mit zehn Programmen um die Gleitkommaeinheit zu testen. CPU95 ist nicht dazu konstruiert, andere Computersystemkomponenten zu messen, weshalb es sich gut dazu eignet, den Einfluss der Systemleistung auf die Graphikleistung zu betrachten. Das “C” im Namen von CINT95 und CFP95 steht für component, und steht dafür, dass nicht ein System getestet wird (das würde mit einem “S” angegeben), sondern dass es sich dabei um ein Komponenten Benchmark Programm handelt. SPEC CPU95 wird von der Open Systems Group (OSG) der SPEC entwickelt. Die ‘95 Version ist das zweite Update des Benchmarks. SPEC CPU89, das Original, wurde 1989 entwickelt.

10.1 Einführung SPEC95 wurde entwickelt, um vergleichbare Messungen der Leistung von Computersystemen mit einem gut bekannten, rechenintensiven Workload durchzuführen. Um dies auch auf verschiedenen Plattformen durchführen zu können, entschied sich die OSG den Benchmark als Quellcode zu unterhalten. Obwohl das Benchmark Programm oft nur als Prozessorbenchmark bezeichnet wird, misst es eigentlich folgende drei Komponenten eines Computersystems: ¥ Prozessor ¥ Speicher Hierarchie ¥ Compiler Das Programm wurde nicht entwickelt, um andere Komponenten zu testen, wie zum Beispiel Graphik, Netzwerk, I/O oder Fähigkeiten des Betriebssystem. SPEC CPU95 ist für viele Betriebssysteme erhältlich, unter anderem für viele UNIX Versionen und Windows NT.

10.1.1 Charakteristiken von CPU95 Das SPEC CPU95 Benchmark Programm kann folgende Messungen durchführen:

109 110 10 Der SPEC CPU95 Benchmark

CINT95 Tests: Metrik Erklärung SPECint95 Das geometrische Mittel von acht normalisierten Laufzeitverhältnis- sen (eine für jeden Integer Benchmark). Der Benchmark wird aggressiv compiliert. SPECint_base95 Das geometrische Mittel von acht normalisierten Laufzeitverhältnis- sen (eine für jeden Integer Benchmark). Der Benchmark wird konservativ compiliert. SPECint_rate95 Das geometrische Mittel von acht normalisierten Durchsatzraten (eine für jeden Integer Benchmark). Der Benchmark wird aggressiv compiliert. SPECint_rate_base95 Das geometrische Mittel von acht normalisierten Durchsatzraten (eine für jeden Integer Benchmark). Der Benchmark wird konservativ compiliert. Tabelle 10.1: CINT95 Metriken

CFP95 Tests:

Metrik Erklärung SPECfp95 Das geometrische Mittel von zehn normalisierten Laufzeitverhältnis- sen (eine für jeden Floating-Point Benchmark). Der Benchmark wird aggressiv compiliert. SPECfp_base95 Das geometrische Mittel von zehn normalisierten Laufzeitverhältnis- sen (eine für jeden Floating-Point Benchmark). Der Benchmark wird konservativ compiliert. SPECfp_rate95 Das geometrische Mittel von zehn normalisierten Durchsatzraten (eine für jeden Floating-Point Benchmark). Der Benchmark wird aggressiv compiliert. SPECfp_rate_base95 Das geometrische Mittel von zehn normalisierten Durchsatzraten (eine für jeden Floating-Point Benchmark). Der Benchmark wird konservativ compiliert. Tabelle 10.2: CFP95 Metriken

Base und Non-Base. Um die Leistungsvergleiche auf verschiedenen Plattformen zu ermögli- chen, musste die OSG das Benchmark Programm als Quellcode zur Verfügung stellen. So muss der Benchmark vom Benutzer compiliert werden. Es war klar, dass das Programm so compiliert werden soll, wie dies ein durchschnittlicher Benutzer macht. Aber wie compilieren Benutzer ihre Programme? Einerseits compilieren gewisse Benutzer ihre Programme mit vielen verschiedenen Compilern und Compiler Flags um die bestmögliche Leistung zu erhalten, andererseits compilieren Benutzer ihre Programme mit den normalen Optionen, die vom Compilerhersteller empfohlen werden. Die OSG anerkennt, dass sie nicht genau definieren kann, wie Benutzer ihre Programme compilieren, zwei Referenzpunkte sind aber möglich. Die Base Metrik ist nötig für alle publizierten Resultate. Dabei werden Regeln vorgegeben, wie der Benchmark compiliert werden darf. Die Non-Base Metrik ist optional. Für diese Resultate werden weniger strenge Regeln vorgegeben. 10.2 Die Integer Programme 111

Referenzzeit/Referenzmaschine. Die Verhältnisse für jeden Test werden mit der SPEC-Refe- renzzeit und der aktuellen Laufzeit berechnet. Dabei wurde eine SPARCstation 10/40 (40 MHz SuperSPARC ohne Level 2 Cache) als Refe- renzmaschine verwendet, um die Normalisierungen der Leistungmetriken vorzunehmen. Jeder Test des Benchmark Programm wurde auf dieser Maschine gemessen und als Referenzzeit definiert. Es dauerte etwa 48 Stunden, um eine SPEC-konforme Ausführung durchzuführen.

Laufzeit versus Durchsatz. Es gibt verschiedene Arten, die Leistung eines Computersystems zu messen. Eine Möglichkeit ist zu messen, wie schnell ein Computer eine einzelne Aufgabe durchführen kann. Dies ist eine Geschwindigkeitsmessung. Eine andere Möglichkeit ist zu bestimmen, wieviele Aufgaben ein Computer in einer gewissen Zeit abarbeiten kann. Dies nennt man eine Durchsatz-, Kapazitäts- oder Ratenmessung. Die SPEC Geschwindigkeitsmessungen (zum Beispiel SPECint95) werden gebraucht, um die Laufzeit der Durchführung einer einzelnen Aufgabe eines Computers zu messen. Die SPEC Ratenmessungen (zum Beispiel SPECint_rate95) werden verwendet, um die Durch- satzrate einer Maschine zu testen, die verschiedene Aufgaben bewältigen muss.

10.2 Die Integer Programme

Die Programme in SPEC CINT95 werden verwendet, um die Integer Leistung eines Systems zu messen.

Hier eine kleine Erklärung der in SPEC CINT95 vorkommenden Tests.

Benchmark Referenzzeit Anwendungsbereich Spezielle Aufgabe 099.go 4600 Spiele, Künstliche Spielt das “Go” Spiel gegen sich selber. Intelligenz 124.m88ksim 1900 Simulation Simuliert den Motorola 88100 Proz- essor und lässt Dhrystone und ein Mem- ory Test Programm laufen. 126.gcc 1700 Programmierung, Compiliert einen vorbearbeiteten Compilierung Quellcode in optimierten SPARC As- sembler Code. 129.compress 1800 Kompression Komprimiert eine grosse Textdatei (ca. 16 MByte) unter Benutzung der Limpel-Ziv Codierung. 130.li 1900 Sprachinterpreter Lisp Interpreter. 132.ijpeg 2400 Bildbearbeitung Führt eine JPEG Bildkomprimierung mit verschiedenen Parametern durch. 134.perl 1900 Shell Interpreter Führt Text- und numerische Manipula- tionen durch. (Anagramme/Primzahlen- faktorisierung) 147.vortex 2700 Datenbank Errichtet und manipuliert drei relation- ale Datenbanken. Tabelle 10.3: CINT95 Benchmark 112 10 Der SPEC CPU95 Benchmark

10.3 Die Floating-Point Programme

Die Programme in SPEC CFP95 werden verwendet, um die Floating-Point Leistung eines Systems zu messen. Hier eine kleine Erklärung der in SPEC CFP95 vorkommenden Tests. Benchmark Referenzzeit Anwendungsbereich Spezielle Aufgabe 101.tomcatv 3700 Flüssigkeitsdy- Generiert ein zweidimensionales Koordi- namik, Geome- natensystem um generelle geometrische trische Translation Bereiche. 102.swim 8600 Wettervorhersage Löst flache Wassergleichungen mit Hilfe von Approximationen mit finiten Differ- enzen. (der einzige Benchmark in CFP95 der nur einfache Präzision erfordert) 103.su2cor 1400 Quantenphysik In der Quark-Gluon Theorie werden Mas- sen von elementaren Teilchen berechnet. 104.hydro2d 2400 Astrophysik Hydrodynamische Navier-Stokes Glei- chungen werden benutzt um galaktische Strahlen zu berechnen. 107.mgrid 2500 Elektromagnetismus Berechnung eines 3D Potentialfeldes. 110.applu 2200 Flüssigkeitsdy- Löst ein Matrix System mit Pivot-Strate- namik, Mathematik gien. 125.turb3d 4100 Simulation Simuliert Turbulenzen in einem kubis- chen Bereich. 141.apsi 2100 Wettervorhersage Berechnet Statistiken über Temperaturen und Schadstoffe in einem Bereich. 145.fpppp 9600 Chemie Berechnet Ableitungen von Multielek- tronen 146.wave5 3000 Elektromagnetismus Löst Maxwell’sche Gleichungen in einem kartesischen Netz. Tabelle 10.4: CFP95 Benchmarks

10.4 Benchmarking mit CPU95

SPEC CPU95 verwendet die Kommandozeile zur Eingabe der gewünschten Aktionen, Modi, Anzahl Durchläufe, etc. Die Compilieroptionen und Flags werden in Konfigurationsdateien gespeichert. Dort werden auch Angaben zum getesten System gemacht. Base Run. Um einen Base Run durchzuführen, müssen gewisse Regeln befolgt werden. ¥ Kein Quelldatei- oder Subroutinenname darf in einem Optimierungsﬂag oder in einer Compiler Option vorkommen. ¥ Flags, welche vorgerechnete Routinen ersetzen, die in der Basis des Routinennamen eines Benchmarks vorkommen, sind nicht zulässig. 10.5 Compilieren von CPU95 113

¥ “Feedback directed”-Optimierungen sind erlaubt. ¥ Flags, welche Datentypgrössen dahingehend verändern, dass sie nicht die Standardda- tentypgrössen des Compilierungssystems besitzen, sind nicht erlaubt. ¥ Es müssen immer die gleichen Compiler Flags und Optionen für alle Benchmarks verwendet werden. Sie müssen auch alle in der gleichen Reihenfolge angegeben werden. ¥ “Assertion Flags” sind nicht erlaubt. ¥ Es dürfen Flags verwendet werden, welche die numerische Genauigkeit oder Empﬁnd- lichkeit verändern, indem sie die Floating-Point Operationen mit algebraischen Identi- täten umstellen. ¥ Optimierungen sind auf vier Optimierungsﬂags und Compileroptionen limitiert.

10.4.1 Beispielaufruf von CPU95

runspec -a validate -c luxo.cfg -i ref -n 3 -o all -d -D -I -v 100 int

-a action die Aktion, die runspec ausführen soll; [build|setup|run|compare|report|validate|clean|trash|clobber|nuke] -c name Name der Konfigurationdatei, die sich in /config befindet. -i input SPEC Eingabedatei, die verwendet wird; [test|train|ref]; default: ref -n num die Anzahl der Durchläufe von runspec; für einen “offiziellen’ Lauf muss n mindestens 3 sein -o type der Typ des Testberichts; [asc|html|ps|raw|all] -d löscht explizit die Benchmark Arbeitsverzeichnisse, da diese ansonsten stan- dardmässig weiterverwendet werden -D löscht bereits existierende Programmdateien der verwendeten Konfiguration -I ignoriert Fehler, Benchmark wird bei einem Fehler nicht beendet -v level setzt die Menge der Kommandozeilenausgabe fest; zwischen 0-100 list_of_benchmarks kann ‘all’, ‘int’, ‘fp’ oder eine Liste der Einzelbenchmarks sein (Bei- spiel (147.vortex oder 147)

10.5 Compilieren von CPU95

Das Compilieren des SPEC CPU95-Benchmarks zeigte sich sehr schwierig. Auch nach Rück- sprache mit SGI und nach Konsultieren diverser Newsgruppen war es nicht möglich den 147.vortex Test zu compilieren. Hier werden wiederum nur die Veränderungen angegeben, die vorgenommen werden mussten, um SPEC CPU95 erfolgreich zu compilieren.

10.5.1 Sun unter Solaris Der compilierte Benchmark wurde freundlicherweise vom Institut für Computersysteme zur Verfügung gestellt. 114 10 Der SPEC CPU95 Benchmark

10.5.2 SGI unter IRIX Die SPEC Installation musste manuell durchgeführt werden, da nicht alle Dateien zur Verfü- gung gestellt wurden. Die folgenden Anweisungen werden vom install.sh Script generiert: cd /home/spec95/tools/src/make-3.74 make clean; rm config.cache ./configure --prefix=’/home/spec95’ /bin/sh build.sh cp make /home/spec95/bin/specmake

cd /home/spec95/tools/src/perl5.001l ../make-3.74/make distclean; rm config.sh ./Configure -dOes -Ddosuid=undef -Dstatic_ext=Spec -Dusedl=undef -Dprefix=/home/spec95 ../make-3.74/make cp -pr perl /home/spec95/bin/specperl cp -pr lib /home/spec95/bin /home/spec95/bin/relocate Es ist wichtig, die zur Verfügung gestellten perl und make Versionen zu installieren, da sie Erweiterungen beinhalten, die nicht dem Standard entsprechen. Um perl erfolgreich zu installieren, benötigt man zwei zusätzliche Dateien, die man aus einer Standard-Distribution kopieren kann: spec95/tools/src/perl5.001l/configure spec95/tools/src/perl5.001l/hints/aux.sh Ein anderes Problem ist die Messung der Zeiten auf den verschiedenen Betriebssystemen. Specperl stellt eine System-Variable zur Verfügung, welche nicht auf allen Systemen richtig funktioniert. Wenn man nun Null-Laufzeiten erhält, muss man folgendes durchführen. In der Datei spec95/bin/unix.pl muss man alle Vorkommen von spectime auf &spectime ändern, und am Schluss der Datei vor dem 1 die folgende Subroutine einfügen: sub spectime { # a wrapper for Win32::SpecTime my($sec,$usec) = 0; # the hack for when Win32::SpecTime doesn’t exist $sec = time; $usec = 0; #&Win32::SpecTime($sec,$usec); return($sec, $usec); } 1; #allready exists Mit diesen Änderungen ist es möglich, mit SPEC95 zu benchmarken.

10.5.3 Pentium Pro/Pentium II unter Linux Der compilierte Benchmark wurde freundlicherweise vom Institut für Computersysteme zur Verfügung gestellt. Leider war es nur möglich, den Integer Benchmark zu starten.

10.6 Zusammenfassung

SPEC CPU95 ist ein standardisierter und von der Industrie akzeptierter Systemleistungsbench- mark, der den Prozessor, die Speicherhierarchie und den Compiler misst. SPEC CPU95 verwendet dazu zwei Teilprogramme, SPEC INT95 und SPEC FP95, mit zehn bzw. acht 10.6 Zusammenfassung 115

Programmen, welche die Festkommaeinheit bzw. die Gleitkommaeinheit testen. Für beide Teil- programme wird eine Zahl als gewichtetes Resultat der Einzeltests angegeben; grössere Zahlen geben dann grössere Leistung an. Die Ergebnisse werden in SPECmarks angegeben. 116 10 Der SPEC CPU95 Benchmark 11 11Resultate und Analyse

In diesem Kapitel werden die gesammelten Resultate präsentiert. Soweit es mit den vorhande- nen Informationen möglich war, werden diese kommentiert und analysiert. Zuerst werden die Resultate von Viewperf, danach die von GLperf und zu guter Letzt die von SPEC CPU95 präsentiert - jeweils mit der Angabe der Bedingungen, der Dokumentation von Spezialtests und einer Analyse. Die gesammelten Erkenntnisse werden in einer kurzen Zusammenfassung kommentiert.

11.1 Viewperf Der Viewperf-Benchmark zeichnete sich durch Zuverlässigkeit aus. Es konnten keine speziellen Fehler dokumentiert werden. Es wurden diverse Spezialtests durchgeführt, um zum Beispiel den Einfluss des Netzwerks zu messen.

11.1.1 Bedingungen beim Ausführen von Viewperf Anzahl Durchläufe. Die Tests der Viewsets wurden bei allen Maschinen fünf mal laufen gelassen. Der ermittelte Wert für einen Test entspricht dem arithmetischen Mittel aus den Einzeltests. Netzwerk. Die Maschinen waren alle am Netzwerk. Der Netzwerk Overhead ist nicht berück- sichtigt worden, dürfte aber, da die Benchmarks über die Weihnachtstage (22. - 25. 12.1998) und ansonsten am späten Abend (nach 21h00) liefen, sehr gering sein. (für den Spezialtest siehe Abschnitt 11.1.3) Benutzermodus. Die Resultate der Onyx2 wurden im “Single User Mode” durchgeführt. Alle anderen Tests wurden im “Multi User Mode” durchgeführt. Bildschirmauflösung. Die Auflösung war bei allen Maschinen1280× 1024 Pixel. Farbtiefe. Die Farbtiefe war bei den SGI Computern bei 32 bit (true color), bei den Windows NT-Rechnern nur bei 16 bit, da 32-bit Rendering von der FireGL 1000 nicht unterstützt wird.

117 118 11 Resultate und Analyse

11.1.2 Die Resultate Die ausführlichen Resultate befinden sich auf der CD der Semesterarbeit. Es werden hier nur die geometrischen Mittel der Einzeltests angegeben. . ID ProCDRS DX DRV AWadvs Light CDRS gogh 5.825 8.3744 6.2192 15.22 0.97926 47.43 caroll 0.76428 1.6074 0.71552 1.257 0.19754 6.8806 escher 1.1642 3.5216 1.2336 1.1892 0.21906 11.382 mondrian 2.3344 3.056 2.3916 5.978 0.55002 16.746 birs 9.5702 15.798 9.939 17.438 1.5196 34.95 luxo N/A 34.438 18.344 34.842 2.625 68.438 ppro 1.926 3.886 2.360 4.801 0.4675 14.92 ptwo 5.556 7.619 4.710 10.213 1.010 36.05 antimon 4.0608 4.2654 1.319 4.48075 0.35872 33.098 Tabelle 11.1: Viewperf Resultate in [Bilder pro Sekunde]

Abbildung 11.1: Überblick Viewperf

ProCDRS Test auf Luxo. Der ProCDRS Test auf der Onyx2 konnte leider nicht durchgeführt werden. Er wurde zweimal gestartet und die Maschine stürzte zweimal ab. Abklärungen haben nichts über dieses Problem ergeben. Es kann hier nur angefügt werden, dass das Viewset noch sehr neu ist und demzufolge noch der eine oder andere Fehler vorhanden sein könnte. 11.1 Viewperf 119

11.1.3 Der Test ohne Netzwerk

Zur näheren Betrachtung des Netzwerkoverheads wurde eine O2 vom Netz abgetrennt, die Benchmarks laufen gelassen und dann mit den anderen Resultaten verglichen. In Tabelle 11.2 bezeichnet mondrian die Maschine mit Netzwerk und barks die Maschine ohne Netzwerk. Der ID ProCDRS DX DRV AWadvs Light CDRS mondrian 2.3344 3.056 2.3916 5.978 0.55002 16.746 barks 2.3902 3.0504 2.5242 6.038 0.55544 16.444 Tabelle 11.2: Resultate mit und ohne Netzwerk

Benchmark lief zwischen 5% schneller bis fast 2% langsamer (Tabelle 11.3). Aus diesen Zahlen kann man schliessen, dass das Netzwerk nicht alleine für die Varianzen in den Resultaten verantwortlich ist, das Betriebssystem spielt sicher die gleichgrosse Rolle. ProCDRS DX DRV AWadvs Light CDRS Differenz + 2.39% - 1.84% + 5.25% + 0.99% + 0.98% - 1.84% Tabelle 11.3: Differenzen

Zur Kontrolle wurde ein Test-For-Zero-Mean durchgeführt. Dieser Test bestimmt, ob die Mit- telwerte der beiden Tests nicht signifikant unterschiedlich sind. Auf eine Erklärung des Tests wird hier verzichtet. In [10] sind die Details des Test-For-Zero- Mean zusammengestellt.

Was Resultat Sample Mean 0.9883 Sample Variance 7.225 Sample Standard Deviation 2.688 Confidence Interval for Mean 0.9883± 7.225⁄ 5 = 0.9883± 1.2027 90% Confidence Interval (-1.434, 3.410) 95% Confidence Interval (-3.159, 5.835) Tabelle 11.4: Test-For-Zero-Mean

Die Vertrauensintervalle beinhalten die Zahl Null. Somit sind die zwei Resultate nicht verschieden. Das heisst, dass man mit 95% (bzw. 90%)-Sicherheit nicht aussagen kann, ob der Unter- schied der Mittelwerte signifikant von Null verschieden ist. Dies bedeutet, dass die Test mit und ohne Netzwerk nicht verschieden sein müssen.

11.1.4 Application Binary Interfaces

Mit der gogh wurde ein Test durchgeführt, der zeigen sollte, ob die Definition des Application Binary Interfaces ABI eine Rolle spielt. Tabelle 11.5 zeigt die Tests mit verschiedenen ABI’s. Wie man sieht, können die Werte besser (gogh: CDRS), schlechter (gogh: AWadvs) oder etwa gleich sein. Es muss somit je nach Anwendung die 64-bit oder die neue 32-bit ABI bevorzugt 120 11 Resultate und Analyse werden. Als Folge daraus wurden auf den SGI Workstations mit R10000 Prozessor jeweils die Tests mit beiden ABI’s durchgeführt. Das bessere Resultat wurde verwendet. ID ProCDRS DX DRV AWadvs Light CDRS -64 5.8236 8.3744 6.2192 15.22 0.97926 33.59 -n32 5.825 8.373 6.179 13.15 0.9770 47.43 Tabelle 11.5: Resultate mit verschiedenen ABI’s auf den SGI Workstations (hier gogh)

ID ProCDRS DX DRV AWadvs Light CDRS -64 N/A 34.438 18.344 34.842 2.625 68.438 -n32 N/A 31.4 18.356 34.788 2.571 68.47 Tabelle 11.6: Resultate mit verschiedenen ABI’s auf den SGI Workstations (hier luxo)

11.1.5 Auﬂösungen Bei den PC Workstations wurden die Tests in jeweils zwei Auflösungsstufen durchgeführt. Die erste Zahl entspricht dem Resultat unter1280× 1024 Bildpunkten, die zweite Zahl demjenigen unter1024× 768 Bildpunkten. Diese Zahlen sind in Tabelle 11.7 eingetragen. In den Resul- tatsübersichten sind wiederum nur die Werte mit der Auflösung1280× 1024 angegeben, da diese auf allen Maschinen verwendet wurde. Die Zahlen zeigen, dass der Einfluss der Auflösung sehr gering ist. Viewperf rendert immer im gleichgrossen Fenster. Der Ausschnitt vom Monitrobild, der nicht von Viewperf gebraucht wird, ist bei der höheren Auflösung grösser. Dieser Ausschnitt muss auch dargestellt werden. Die kleinen Unterschiede kommen daher, dass die Graphikarte auch Ressourcen für diesen Aus- schnitt braucht. ID ProCDRS DX DRV AWadvs Light CDRS ppro1280× 1024 1.926 3.886 2.360 4.801 0.4675 14.92 ppro1024× 768 2.006 3.907 2.388 4.823 0.4695 15.20 ptwo1280× 1024 5.556 7.619 4.710 10.213 1.010 36.05 ptwo1024× 768 5.8484 8.185 5.2318 10.512 1.0294 40.862 Tabelle 11.7: Resultate mit verschiedenen Auflösungen auf den PC Workstations

11.1.6 Entkopplung des Bufferaustauschs vom vertikalen Refresh des Bildes Die meisten OpenGL Implementationen unterstützen Doublebuffering, welche zwei komplette Bildschirmbuffer zur Verfügung stellen. Ein Buffer wird am Monitor dargestellt, während im anderen Buffer das neue Bild gezeichnet wird. Wenn das Zeichnen fertig ist, werden einfach beide Buffer ausgetauscht, so dass in den zuvor dargestellten Buffer jetzt gezeichnet wird und vice versa. Mit Doublebuffering sieht der Betrachter nie ein partiell gezeichnetes Bild. Normalerweise wartet die swap_the_buffers Routine, welche den Pufferaustausch vornimmt, bis die aktuelle Monitor Refresh Periode vorbei ist, so dass der gesamte vorherige Puffer ange- zeigt wird. Um höhere CDRS Werte zu erlangen, kann die Synchronisation zwischen dem Monitor Refresh und dem Bufferaustausch abgestellt werden. Auf der SGI Maschine wird das mit einer Umge- 11.1 Viewperf 121 bungsvariable gemacht. Diese heisst DECOUPLE_SWAPBUF und sie muss auf ‘y’ gesetzt werden. (setenv DECOUPLE_SWAPBUF=’y’). Ohne diese Synchronisation kann der Buffer- austausch zu jeder Zeit während des Monitor Refreshs stattfinden, was zu Diskontinuitäten aber auch zu höheren Messwerten führen kann. Nehmen wir an, dass das System das Bild auf dem Monitor 60 Mal in der Sekunde erneuert. Dies führt dazu, dass die höchste Bildrate, die wir erreichen können, 60 Bilder pro Sekunde ist. Wenn alle Bilder unter160⁄ Sekunde gelöscht und gezeichnet werden können, wird die Ani- mation glatt sein. Oft ist es aber der Fall, dass die Bilder zu kompliziert sind, um in 160⁄ Sekunde gezeichnet zu werden, dann wird dasselbe Bild mehr als einmal auf dem Bildschirm dargestellt. Wenn zum Beispiel ein Bild in145⁄ Sekunde gezeichnet wird, erhält man 30 Bilder pro Sekunde und das Graphiksystem macht130⁄ Ð190145⁄ = ⁄ Sekunde pro Bild gar nichts, was einem Drittel der Zeit entspricht. Wenn wir nun die Synchronisation abstellen, kann diese Zeit auch benutzt werden.Wie man in Tabelle 11.9 sieht, spielt dies hauptsächlich beim CDRS Viewset eine Rolle. Auf der gogh erzielt man damit 10 Bilder pro Sekunde mehr. Auf der Onyx2 Maschine ergibt sich durch Ausschalten der Synchronisation für das CDRS Viewset ein Wert von 157.25 (Tabelle 11.8). Dies ist ein Leistungszuwachs von 230%. Beim AWadvs Viewset ist der Leistungsunterschied 30%. Zur Publikation auf der Viewperf Homepage [17] werden von den meisten Herstellern die Resultate mit dieser Entkoppelung angegeben. Dies ist sicher nicht richtig, da die Qualität der gerenderten Bilder sehr schlecht ist. ID DX DRV AWadvs Light CDRS sync. 34.438 18.344 34.842 2.625 68.438 no sync. 37.495 23.215 45.17 2.599 157.25 Tabelle 11.8: Resultate mit und ohne Synchronisation (Beispiel luxo)

ID ProCDRS DX DRV AWadvs Light CDRS sync. 5.825 8.3744 6.2192 15.22 0.97926 47.43 no sync. 5.8236 8.928 6.471 16.252 0.98372 57.012 Tabelle 11.9: Resultate mit und ohne Synchronisation (Beispiel gogh) 122 11 Resultate und Analyse

11.1.7 Analyse

Abbildung 11.2: Viewperf - Light Viewset

Texture Engine. Das Fehlen der Texture Engine bei den Indigo2 XZ und Extreme-Systemen (caroll, escher) zeigt sich deutlich bei den ProCDRS, CDRS und AWadvs Viewsets. Dabei werden die texturierten Tests jeweils schneller von caroll (schnellerer Prozessor, schlechtere Graphik) durchgeführt. Das Textur-Mapping wird also tatsächlich durch die CPU ausgeführt. ID 1 2 3 4 5 6 7 8 9 10 caroll 3.00 1.90 0.45 0.49 0.14 0.06 0.15 0.07 0.28 0.30 escher 4.01 3.17 0.99 0.99 0.10 0.05 0.08 0.05 0.63 0.65 Tabelle 11.10: ProCDRS Resultate für die Indigo2-Systeme

Geometry Engine. Bei den FireGL 1000-Systemen zeigt sich deutlich, dass die heutigen PC- Graphikbeschleuniger ohne Geometry Engine stark vom Hauptprozessor abhängig sind. Die Messungen des Pentium II-Systems mit der AGP Karte sind bei allen Viewsets mehr als doppelt so gut, wie diejenigen des Pentium Pro-Systems. Es ist nicht nur der Prozessor des Pentium II- Systems, der doppelt so schnell ist. Auch die Daten können doppelt so schnell vom Speicher auf die Graphikkarte übertragen werden. Dies zeigt sich speziell bei den Wireframe Tests von ProCDRS: da ist das Pentium II/AGP System viermal schneller (doppelte CPU-Leistung, doppelte Speicherbandbreite) als das Pentium Pro System. ID 1 2 3 4 5 6 7 8 9 10 ppro 2.26 2.40 1.67 2.15 1.40 1.78 1.19 1.60 1.15 1.55 ptwo 9.21 9.56 3.96 4.84 3.23 3.86 2.77 3.57 2.69 3.48 Tabelle 11.11: ProCDRS Resultate für die Pentium-Systeme 11.1 Viewperf 123

Abbildung 11.3: Viewperf - ProCDRS Viewset: Display List Build-Time

Texture Engine II. Bei der Sun Ultra 1 mit der Creator3D-Karte fehlt ebenfalls die Texture- Mapping Hardware. Dies hat ebenfalls schlechte Werte bei den ProCDRS, CDRS und AWadvs Viewsets zur Folge. ID 1 2 3 4 5 6 7 8 9 10 antimon 10.3 9.97 2.71 2.89 0.61 0.62 0.55 0.56 2.25 2.53 Tabelle 11.12: ProCDRS Resultate für die Sun Ultra1 mit Creator3D

Verhältnis zwischen Preis und Leistung. Das Maximum Impact- und das Pentium II-System sind ebenbürtig, mit kleinen Vorteilen für die SGI Maschine. Dies zeigt sich bei den DRV und AWadvs Viewsets, vorallem bei komplexen Szenen. Zu beachten ist, dass das Maximum Impact-System um einen Faktor 15 teurer ist als das Pentium II-System.

Display List. Die Pentium II-Systeme haben grosse Mühe, eine Display List schnell aufzubauen. Bei den PC-Systemen werden die Display Lists durch den Systemprozessor aufgebaut und nicht, wie bei allen anderen Systemen, durch das Graphiksubsystem. Dies führt dazu, dass alle Daten vom Graphiksubsystem über den Bus (PCI oder AGP) an die CPU transferiert werden müssen. Dort werden sie abgearbeitet und schliesslich zum Graphiksubsystem (erneut über den langsamen Bus) zurücktransferiert. Die Maschinen sind zwischen einem Faktor 20 (Pentium II/AGP) und einem Faktor 60 (Pentium Pro/PCI) langsamer als das Maximum Impact System.

Onyx2. Die Onyx2 mit Infinite Reality2-System ist das Mass aller Dinge. Sie ist fast bei allen Test doppelt so schnell, wie die anderen Systeme. Speziell bei Wireframe Rendering ist sie fast viermal so schnell wie die Octane MXE. 124 11 Resultate und Analyse

Abbildung 11.4: Viewperf - ProCDRS Viewset

Wireframe Rendering. Die Leistungen beim Wireframe Rendering wirft einige Fragen auf. Die Onyx2 und die Indigo2 Maximum Impact zeigen einen deutlichen Leistungsvorsprung gegenüber der Octane oder den Pentium-Systemen. Die Graphikpipeline wird jedoch bei Wire- frame Rendering Aufgaben gleich abgearbeitet, wie im normalen Modus, bis auf das Fehlen der Shading Operationen. Nur scheint es unrealistisch, dass die Onyx2 für Shading Operationen viel mehr Zeit braucht als die Octane. Eine mögliche Erklärung betrifft den Hidden-Line Removal Algorithmus. Während im Solid Rendering ein (einfaches) Hidden-Surface Removal gemacht wird (mittels Z-Buffer), muss für Wireframe Rendering das komplexere Hidden-Line Removal durchgeführt werden. Hidden- Line Removal wird dabei nicht in Hardware unterstützt. Es gibt zwei Techniken um dies mit Hilfe der Hidden-Surface Removal Funktionen durchzuführen, entweder mit Polygon Offset oder mit dem Stencil Buffer. Die Lösung mit Polygon Offset ist die bevorzugte Technik, da sie fast immer schneller ist. Dabei wird jedes Objekt zweimal gezeichnet. Die hervorgehobenen Eckpunkte werden in der Vordergrundfarbe gezeichnet, mit gefüllten Polygonen, aber im GL_LINE Polygon-Modus, um sie als Wireframe zu rasterisieren. Danach werden die gefüllten Polygone im Standard Polygon-Modus gezeichnet. Dies füllt das Innere des Wireframes. Man weist einen genügend grossen Polygon Offset zu, um die gefüllten Polygone ein bisschen weiter weg vom Betrachter zu bringen. Mit diesem Polygon Offset tritt das Innere genügend zurück, damit die hervorgehobenen Eckpunkte ohne unerwünschte visuelle Artefakte gezeichnet werden. Dies zeigt deutlich, dass das Hidden-Line Removal viel aufwendiger ist als das Hidden-Surface Removal, wenn keine Hardware-Unterstützung für Hidden-Line Removal vorhanden ist und es mit diesen Techniken gelöst werden muss. Die Octane und die Pentium-Systeme scheinen einen komplexeren Hidden-Line Removal Algorithmus zu implementieren als die Infinite Reality2 und Maximum Impact. Abbildung 11.5 zeigt den Algorithmus für den Hidden-Line Algorithmus mit Polygon Offset, wie er im OpenGL Programming Guide der Insight Library von SGI beschrieben wird. Um ein Hidden-Surface Removal durchzuführen, muss man nur die erste Zeile (glEna- ble(GL_DEPTH_TEST) ausführen und dann die Polygone zeichnen. 11.1 Viewperf 125

glEnable(GL_DEPTH_TEST); glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); set_color(foreground); draw_object_with_filled_polygons();

glPolygonMode(GL_FRONT_AND_BACK, GL_FILL); glEnable(GL_POLYGON_OFFSET_FILL); glPolygonOffset(1.0, 1.0); set_color(background); draw_object_with_filled_polygons(); glDisable(GL_POLYGON_OFFSET_FILL);

Abbildung 11.5: Beispiel Hidden-Line Algorithmus mit Polygon Offset 126 11 Resultate und Analyse

11.2 GLperf Der GLperf-Benchmark zeichnete sich durch Unzuverlässigkeit aus. Verschiedene Tests stürz- ten immer wieder ab. Zusätzlich fehlten in den Log-Dateien immer wieder Fragmente der eigentlichen Ausgabe.

11.2.1 Bedingungen beim Ausführen von GLperf Anzahl Durchläufe. Die Tests wurden bei allen Maschinen nur einmal laufen gelassen. Auf der Onyx2 wurden die Tests fünfmal ausgeführt. Da die Laufzeit bei allen anderen Maschinen aber dermassen lang war (ca. 22 Stunden), wurde bei den anderen Maschinen auf mehrfache Tests verzichtet. Netzwerk. Die Maschinen waren alle am Netzwerk. Der Netzwerk Overhead ist nicht berück- sichtigt worden, dürfte aber, da die Benchmarks in der Nacht liefen, sehr gering sein. Benutzermodus. Die Resultate der Onyx2 wurden im “Single User Mode” ausgeführt. Alle anderen Tests wurden im “Multi User Mode” durchgeführt. Bildschirmauflösung. Die Bildschirmauflösung war bei allen Maschinen1280× 1024 Pixel. Farbtiefe. Die Farbtiefe war bei den SGI Computern bei 32 bit (true color), bei den Windows NT-Rechnern nur bei 16 bit, da 32-bit Rendering von der FireGL 1000 nicht unterstützt wird.

11.2.2 Die Resultate Die für diese Arbeit relevanten Zahlen werden durch die folgenden Skripte abgedeckt: Skript Beschreibung Spezielles TexImage.rgb misst Leistung der nur Display List Modus glTexImage2D RGB 500× 500 Pixel grosse Quads Operationen. flat- und smotth-shaded, nearest-neighbor, lineare und trilineare Filterung FillRate.rgb Pixelfüllraten Immediate und Display List Modus Triangle Strips 1-541 Pixel grosse Dreiecke flat- und smotth-shaded, nearest-neighbor, lineare und trilineare Filterung Light.rgb misst Einfluss der An- Immediate und Display List Modus zahl Lichtquellen für Triangle Strips und Quads das Zeichnen einer Pri- smooth-shaded, Z-buffered mitive 0-8 Lichtquellen TriFill.rgb Dreieckfüllraten Texture-Download und Texturwechsel Tests Texturwechsel: Display List oder Texture Object 32× 32 -2048× 2048 Pixel grosse Texturen Tabelle 11.13: Die 4 verwendeten Scripts von GLperf

Antimon (Sun). Die Tests konnten auf der Sun mit dem komplierten GLperf nicht durchgeführt werden. Beim Aufruf mit einem OPC Skript stürzte das Programm jeweils mit einem Segmen- tation Fault ab. Abklärungen haben ergeben, dass es ein FLTBOUNDS Fehler ist. Dies ist eine Floating Point Ausnahme. Leider konnte der Fehler nicht behoben werden.Mit dem von Sun 11.2 GLperf 127 zur Verfügung gestellten Programm konnten die Tests dann ohne Probleme durchgeführt werden. Die Ergebnisse sind aber mit Vorbehalt zu geniessen, da keine Angaben über das Kompi- lieren und eventuelle Veränderungen vorhanden sind.

11.2.3 TexImage - Texture Download/Switching Die Ergebnisse dieser Tests sind in Millionen Texture Elements (Texels) pro Sekunde Die Tests laufen alle im Immediate Modus. ¥ Texture Download, RGB Textur- 32× 32 64× 64 128× 128 256× 256 512× 512 1024× 1024 2048× 2048 grösse gogh 4.92 9.45 18.9 19.5 23.9 34.2 4.47 caroll 2.64 3.65 4.10 4.10 2.81 2.84 0.317 escher 1.99 2.16 3.10 3.24 2.31 2.33 0.269 mondrian 3.11 7.17 8.79 9.78 9.07 8.22 4.11 birs 7.41 23.6 44.7 59.0 64.5 66.7 56.0 luxo 8.69 26.5 38.9 65.3 79.9 84.1 84.9 ppro 3.69 7.55 4.27 4.00 1.53 0.592 0.750 ptwo 6.95 12.6 8.31 8.09 8.15 3.51 1.36 antimon 6.13 8.44 8.68 7.68 8.60 8.35 7.01 Tabelle 11.14: Texture Download im RGB Farbmodus

¥ Texture Download, RGBα Textur- 32× 32 64× 64 128× 128 256× 256 512× 512 1024× 1024 2048× 2048 grösse gogh 4.54 12.1 20 24.3 25.8 26.1 4.53 caroll 2.19 2.97 2.84 2.63 2.13 2.13 0.316 escher 1.71 1.75 2.11 2.06 1.74 1.75 0.266 mondrian 5.30 10.5 19.4 20.9 16.1 13.3 4.08 birs 7.28 22.2 43.2 58.0 64.1 66.1 47.5 luxo 8.69 26.7 38.4 64.4 78.5 81.7 82.0 ppro 4.16 7.67 7.83 8.81 1.22 0.518 0.644 ptwo 8.63 14.5 14.9 17.5 15.1 2.83 1.19 antimon 10.5 22.6 25.6 20.9 18.4 19.3 17.6 Tabelle 11.15: Texture Download im RGBα Farbmodus 128 11 Resultate und Analyse

Die Ergebnisse dieser Tests sind in Millionen Texture Elements (Texels) pro Sekunde Die Tests laufen alle im Immediate Modus. ¥ Texture Download, RGB, mipmapped Textur- 32× 32 64× 64 128× 128 256× 256 512× 512 1024× 1024 2048× 2048 grösse gogh 1.06 3.32 7.46 10 22.6 23.9 13.8 caroll 1.12 1.93 2.17 2.22 2.10 2.12 0.604 escher 0.870 1.54 1.65 1.78 1.72 1.74 0.500 mondrian 0.995 2.54 4.74 6.23 6.41 6.16 24.7 birs 1.67 5.39 15.1 30.2 42.4 66.4 26.6 luxo 0.166 0.594 2.05 6.70 17.8 32.5 41.6 ppro 3.33 6.86 4.36 3.96 1.53 0.589 0.750 ptwo 6.28 12.0 8.26 8.16 8.18 3.50 1.34 antimon 2.39 4.59 5.89 6.27 6.16 6.22 6.38 Tabelle 11.16: Texture Download im RGB Farbmodus, Mipmapped

¥ Texture Download, RGBα , mipmapped Textur- 32× 32 64× 64 128× 128 256× 256 512× 512 1024× 1024 2048× 2048 grösse gogh 1.04 3.01 7.99 13.9 17.3 26.1 10.4 caroll 0.934 1.55 1.64 1.68 1.55 1.59 0.597 escher 0.733 1.22 1.32 1.36 1.30 1.31 0.499 mondrian 1.18 2.99 7.25 10.4 10.4 9.67 3.87 birs 1.65 5.31 14.8 29.7 41.9 65.9 26.3 luxo 0.168 0.597 2.07 6.71 17.7 32.0 40.6 ppro 3.76 7.84 7.73 8.73 1.22 0.514 0.641 ptwo 7.82 14.5 14.7 17.1 15.1 2.84 1.17 antimon 2.98 7.94 13.7 13.9 13.4 13.2 13.4 Tabelle 11.17: Texture Download im RGBα Farbmodus, Mipmapped 11.2 GLperf 129

Die Ergebnisse dieser Tests bezeichnen geladene Texturbilder pro Sekunde. Die Tests liefen im Display List Modus, im RGB Farbraum. Die Textur ist64× 64 Pixel gross. ¥ Texture Switching (Texture Binding with Display List)

Gezeichnete Pri- Keine Primitive Texurierter Punkt Texturiertes mitive zwischen Dreieck dem Laden gogh 3140 2840 2840 caroll 797 790 755 escher 643 627 599 mondrian 1690 1680 1660 birs 6500 5350 5320 luxo 2710 2710 2710 ppro 16200 12200 12200 ptwo 498000 152000 160000 antimon 105000 45700 40100 Tabelle 11.18: Texture Switching im RGB Farbmodus

¥ Texture Switching (Texture Binding with TexObj)

Gezeichnete Pri- Keine Primitive Texurierter Punkt Texturiertes mitive zwischen Dreieck dem Laden gogh 1400000 115000 85700 caroll 27400 14100 8790 escher 21000 11300 6750 mondrian 10400 28900 24800 birs 1960000 161000 119000 luxo 189000 184000 177000 ppro - - - ptwo - - - antimon - - - Tabelle 11.19: Texture Switching im RGB Farbmodus 130 11 Resultate und Analyse

Die Ergebnisse dieser Tests bezeichnen geladene Texturbilder pro Sekunde. Die Tests liefen im Display List Modus, im RGB Farbraum. Die Textur ist Pixel gross. ¥ Texture Switching, mipmapped (Texture Binding with Display List) Gezeichnete Pri- Keine Primitive Texurierter Punkt Texturiertes mitive zwischen Dreieck dem Laden der Textur gogh 743 742 738 caroll 530 521 505 escher 395 396 386 mondrian 580 617 613 birs 1250 1190 1200 luxo 143 143 142 ppro 15800 12000 12000 ptwo 405000 141000 149000 antimon 18900 15200 14700 Tabelle 11.20: Texture Switching im RGB Farbmodus, Mipmapped

¥ Texture Switching, mipmapped (Texture Binding with TexObj) Gezeichnete Pri- Keine Primitive Texurierter Punkt Texturiertes mitive zwischen Dreieck dem Laden der Textur gogh 1410000 54700 46800 caroll 22200 14900 8620 escher 17000 11200 6050 mondrian 42400 27800 24700 birs 1980000 82100 63100 luxo 189000 184000 177000 ppro - - - ptwo - - - antimon - - - Tabelle 11.21: Texture Switching im RGB Farbmodus, Mipmapped 11.2 GLperf 131

Texture Switching. Bei den Texture Switching Tests kann man die Verwendungsart der Tex- turen wählen (TexImageSrc). Zur Auswahl stehen Display List (TexImageSrc DisplayList) und Texture Objects (TexImageSrc TexObj). “Display Listed” Texturen werden von den SGI Gra- phiksubsystemen (e.g. MXE, IR etc.) nicht optimiert, da alle Anwendungen Texturobjekte verwenden. Texure “Binding” ist ein Ausdruck aus der IRIS GL, dem Vorgänger von OpenGL. Die Idee dahinter ist, dass viele Texturen im Textur-Speicher verbleiben, und dass die jeweils benötigte Textur vor dem Rendering “gebunden” wird. Vor OpenGL 1.1 (oder der “texture_object”- Extension für OpenGL 1.0) war der einzige Weg dies zu tun, die Texturen in eine Display List einzufügen. Dies war jedoch nicht befriedigend, da Display Lists unveränderlich sind und viele OpenGL Benutzer die Texturdefinition nach der Initialisierung noch verändern wollten. So kam die Idee der Textur Objekte und des glTexBind[EXT] Calls auf, welche die gleiche Funktiona- lität erlaubt wie in der IRIS GL. Wenn für die Texture Switching Tests die Verwendungsart der Textur (TexImageSrc) auf “Dis- playList” gesetzt wird, kann die Switching-Leistung für in Display Lists gebundene Texturen gemessen werden. Entsprechend kann, wenn die Verwendungsart auf “TexObj” gesetzt wird, die Switching-Leistung für Textur Objekte gemessen werden.

Abbildung 11.6: GLperf - Texture Download (immediate, RGBα )

Texture Download Analyse.

Die Onyx2 Infinite Reality2 ist auch hier das Mass aller Dinge. In den Texture Download Tests kommt das System auch noch mit der 24 MByte grossen Textur (2048×α 2048 im RGB Modus) zurecht. Das System besitzt 80 MByte Texturspeicher und kann diesen Speicher auch schnell füllen. Ein Test mit einer noch grösseren, 96 MByte Textur (4096×α 4096 im RGB Modus) führte jedoch zu einem Systemabsturz. Dabei wäre interessant gewesen, die Grösse zu bestimmen bei welcher die Onyx2 den Einbruch erleidet. Die Spitze der Leistung scheint ja bei der 24 MByte Textur noch nicht erreicht. 132 11 Resultate und Analyse

Abbildung 11.7: GLperf - Texture Switching (Display List or Texture Object, 64× 64 Pixels Texture, RGB)

Die FireGL 1000-Karte ist eindeutig für kleinere Texturgrössen entwickelt worden. Die Lei- stung erreicht einen Höhepunkt bei einer Texturgrösse von 0.375 MByte (256×α 256 im RGB Modus). Die O2 mit der UMA Speicherarchitektur könnte eigentlich einen Texture Download durch simples Pointer-Umsetzen realisieren, da der Texturspeicher und der normale Speicher physikalisch am selben Ort ist. Dies scheint aber nicht der Fall zu sein, da die Geschwindigkeit einem normalen Kopieren entspricht. Die Indigo2 XZ und Extreme-Systeme besitzen keine Hardware Unterstützung für Texture Mapping und keinen speziellen Texturspeicher. Dies führt zu sehr schlechten Resultaten in den Texture Download Tests. Texture Switching Analyse. Die Tests zeigen, dass das Onyx2 System einfach in jedem Test durch Homogenität glänzt. Sie zeigt zwar bei den Tests, bei welchen keine Primitive zwischen dem Laden der Textur gezeichnet wird, keine Spitzenleistung. Sie hält diese Leistung jedoch auch bei veränderten Bedingun- gen (zeichnen von Punkten und Dreiecken zwischen den Ladevorgängen) bei. Die Octane MXE und das Maximum Impact System besitzen eine andere Charakteristik. Sie leisten fast zehnmal mehr Texturelemente pro Sekunde als die Onyx2, wenn keine Primitive zwischen dem Laden der Texturen gezeichnet wird. Müssen jedoch dazwischen noch etwas gezeichnet werden, sinkt deren Leistung unter die Hälfte der Leistung des Onyx2-Systems. Das Pentium II-System zeigt eine erstaunliche Leistung bei diesen Tests und erzielt bei allen Tests mit kleinen Texturen gute Leistungen. 11.2 GLperf 133

11.2.4 Light - Lichtquellen

Alle Ergebnisse bezeichnen Millionen Dreiecke pro Sekunde. Die Dreiecke sind in Triangle Strip zusammengefasst. Die Tests laufen im Display List Modus und im RGB Farbraum. Das Z Buffering ist eingeschaltet und wir rendern im Smooth Shaded Modus Licht- 0 1 2 3 4 5 6 7 8 quel- lenanzahl gogh 2.00 1.78 1.22 1.07 0.949 0.855 0.776 0.713 0.659 caroll 0.241 0.179 0.139 0.121 0.108 0.0952 0.0877 0.0805 0.0741 escher 0.560 0.402 0.310 0.264 0.231 0.206 0.184 0.168 0.154 mondrian 0.679 0.486 0.443 0.408 0.377 0.349 0.327 0.307 0.289 birs 2.07 2.07 1.73 1.51 1.34 1.20 1.09 1.00 0.923 luxo 3.75 3.75 3.75 3.75 3.32 2.91 2.60 2.35 2.14 ppro 0.484 0.484 0.394 0.344 0.302 0.268 0.236 0.214 0.196 ptwo 0.742 0.742 0.742 0.742 0.688 0.609 0.535 0.484 0.444 antimon 0.829 0.717 0.507 0.419 0.362 0.320 0.290 0.256 0.239 Tabelle 11.22: Lichtquellen

Analyse

Die Onyx2 IR zeigt hier die wahren Stärken. Die Onyx2 ist bis 3 Lichtquellen durch die Raster Engine limitiert. Mit mehr Raster Engines würde die Onyx2 eine Leistung von 5.11 Millionen Dreiecke pro Sekunde erreichen. Diese Resultate zeigen, dass die Geometry Engine des Infinite Reality2 Systems deutlich leistungsfähiger ist, als diejenige der Octane MXE. Der Unterschied der beiden Systeme entspricht einem Faktor 2.47. Die Geometry Engine GE16 der Onyx2 Infi- nite Reality2 leistet somit etwa 3.320 GFLOPS. Die Octane und die Maximum Impact sind ohne Lichtquelle fast gleich schnell - beide kommen auf zwei Millionen Dreiecke pro Sekunde. Bei keiner und einer Lichtquelle ist die Octane MXE nicht durch die Geometry Engine limitiert, sondern durch die Raster Engine. Dies zeigt sich deutlich, weil die Leistung bei beiden Tests gleich ist. Danach wird die Leistung durch die Geo- metry Engine limitiert. Die Geometry Engines GE12 der Octane MXE leisten zusammen 1344 MFLOPS, diejenigen des Maximum Impact-Systems, zwei GE11 Geometry Engines, zusammen 960 MFLOPS. Das führt zu 40% mehr Leistung der Geometry Engines der Octane gegen- über denjenigen des Maximum Impact-Systems. Die Resultate für mehrere Lichtquellen sind genau um diesen Faktor 1.4 verschieden. Ähnlich sieht es aus, wenn man das Maximum Impact-System mit der O2 vergleicht. Der Lei- stungsunterschied der Geometry Engines (bei der O2 ist das der R5000 Prozessor) ergibt einen Faktor 2.67. Die Resultate des Maximum Impact-Systems sind genau um diesen Faktor besser als diejenigen der O2. Auch bei den Indigo2 XZ und Extreme Systemen, wo die Geometry Engine GE7 eingesetzt werden (viermal 32 MFLOPS für das XZ System (total 128 MFLOPS) und achtmal 32 MFLOPS für das Extreme-System (total 256 MFLOPS)) kann man diese Ver- gleiche anstellen. Es zeigt sich, dass dieser Test sehr gut geeignet ist, die Geometry Engines miteinander zu vergleichen. 134 11 Resultate und Analyse

Abbildung 11.8: GLperf - Lights (Triangle Strips, RGB, Display List, Smooth Shaded, Z-Buffered)

Die Resultate der Pentium II Maschine wird bis zu 3 Lichtquellen durch die Raster Engine auf dem Permedia-Chip limitiert. Danach ist die Geometry Engine, der Pentium Prozessor (Pro und II), für die Limitierung verantwortlich. Das Pentium II-System verzeichnet 11.2 SpecMarks für die Floating-Point Tests, das Pentium Pro-System hingegen nur 4.99 SpecMarks. Das Pentium II-System bietet somit 2.24 mal mehr Leistung für Floating Point Berechnungen. Die Resultate für mehrere Lichtquellen unterscheiden sich um den Faktor 2.27. Da die Beleuchtungsberech- nungen ausschliesslich von der FP Unit des Prozessors übernommen werden, verdeutlicht dies, dass die Berechnungen tatsächlich von der CPU durchgeführt werden. System Totale MFLOPS Indigo2 XZ 128 Indigo2 Extreme 256 Indigo2 Maximum Impact 960 O2 R5000 @ 180 MHz ca. 360 Octane MXE ca. 1344 Onyx2 Infinite Reality2 ca. 3320 Sun Ultra1 170 Creator3D ca. 370 Pentium Pro @ 180 MHz ca. 310 Pentium II @ 400 MHz ca. 700 Tabelle 11.23: Beleuchtungsberechnungen 11.2 GLperf 135

In Tabelle 11.23 werden die geschätzten Leistungen der Geometry Engines (oder der die Geo- metrieberechnungen durchführenden Prozessoren) in MFLOPS wiedergegeben.

11.2.5 FillRate - Pixelfüllraten

Alle Ergebnisse bezeichnen Millionen Pixel pro Sekunde. Die Tests laufen im Display List Modus, mit500× 500 Pixel grosse Quadraten und im RGB Farbraum. Die Textur ist 64× 64 Pixel gross und ebenfalls im RGB Farbraum. Modi flat flat, smooth smooth, smooth, smooth, smooth, Z Z Z, Z, Z, nearest linear trilinear gogh 235 171 235 172 116 116 116 caroll 37.8 33.7 37.9 33.7 0.32967 0.22782 0.10857 escher 75.2 74.9 75.2 74.9 0.256533 0.17149 0.08904 mondrian 65.9 58.9 65.8 58.8 35.1 34.3 31.1 birs 240 175 239 175 131 131 131 luxo 236 218 236 218 121 122 122 ppro 303 46.4 79.2 46.4 24.37 17.61 7.577 ptwo 623 77.6 81.9 77.6 39.4 25.4 13.61 antimon 56.9 56.9 54.9 56.0 9.21 9.25 9.10 Tabelle 11.24: Pixelfüllraten

Analyse

Auffallend sind die zwei sehr hohen Zahlen des Flat-Shaded Tests für die Intel Maschinen. Es konnte dabei keine Erklärung gefunden werden, ob dies ein Fehler ist oder ob dies wirklich der Realität entspricht. Denkbar wäre eine Optimierung für den Flat-Shaded Modus bei diesen Maschinen. Da dieser Modus aber visuell keine guten Renderingresultate liefert, scheint es eher ein Fehler zu sein. Wenn man diese Resultate mit denjenigen auf der SPEC Homepage vergleicht, fällt auf, dass für Intel-Systeme die Leistungen für Flat- und Smooth-Shaded (ohne Z- Buffer) gleich sind. Somit scheinen Werte im Bereich 80 MPixels/s für die Flat-Shaded Tests realistischer. Ein erneutes Durchführen der Tests brachte aber leider keine Verbesserungen. Wiederum kann man Vergleiche zwischen den drei Indigo2-Systemen durchführen. Das Extreme System (escher) besitzt zwei Raster Engines RE3, während das XZ System (caroll) nur über einen RE3 verfügt. Das Extreme System bietet dann auch die genau doppelte Leistung des XZ Systems. Bei den Textur-Tests (letzten drei Spalten in Tabelle 11.24) fällt auf, dass weder das XZ noch das Extreme System Texture-Mapping in Hardware durchführen. Der Host-Pro- zessor (der R4400) ist dafür verantwortlich. Da das XZ System den schnelleren Prozessor (200 MHz gegenüber 150 MHz) besitzt, ist die Leistung auch dementsprechend besser als beim Extreme System. Das Maximum Impact System mit zwei Raster Engines vom Typ RE4 und je zwei Texture Engines bietet die viel bessere Leistung als die XZ oder Extreme Systeme. Die Texture Engines führen auch zu guten Resultaten für die Textur-Tests. Interessant ist, dass hier das Onyx2 System nicht viel besser ist als die Octane oder das Maxi- mum Impact System. Doch durch die Möglichkeit noch mehr Raster Manager (vom Typ RM9s) 136 11 Resultate und Analyse

Abbildung 11.9: GLperf - Pixel Fill Rates (500× 500 Pixels Quad, RGB, Display List,64× 64 Pixels Texture) dazu zu installieren, wäre eine höhere Leistung der Onyx2 möglich. Die Skalierbarkeit der Onyx2 mit mehreren Pipelines und mehreren Raster Managern kann hier natürlich nicht berück- sichtigt werden.

11.2.6 TriFill - Dreieckfüllraten

Alle Ergebnisse bezeichnen Millionen Dreiecke pro Sekunde. Die Dreiecke sind in Triangle Strip zusammengefasst. Die Tests laufen im RGB Farbraum.

Uns interessierten die folgenden Modi:

¥ Immediate, Flat Shaded, Z Buffering

¥ Display List, Flat Shaded, Z Buffering

¥ Display List, Smooth Shaded, Z Buffering

¥ Display List, Smooth Shaded, Z Buffering, 1 Inﬁnite Light

¥ Display List, Smooth Shaded, Nearest Texture, 1 Inﬁnite Light

¥ Display List, Smooth Shaded, Linear Texture, 1 Inﬁnite Light

¥ Display List, Smooth Shaded, Trilinear Texture, 1 Inﬁnite Light

Das Verhalten der ersten vier Tests ist sehr ähnlich. Deshalb wird als Beispiel der Test smooth- shaded, Z-buffered, 1 infinite light besprochen. Ebenso sind die texturgefilterten Resultate ver- gleichbar ausgefallen. Als Beispiel wird da der trilinear-filterted-texture-Test besprochen. 11.2 GLperf 137

Abbildung 11.10: GLperf - Triangle Fill Rates (Triangle Strip, RGB, Display List, Smooth Shaded, Z Buffered, 1 Infinite Light)

Abbildung 11.11: GLperf - Triangle Fill Rates (Triangle Strip, RGB, Display List, Smooth Shaded, Trilinear Filtered Texture, 1 Infinite Light) 138 11 Resultate und Analyse

Analyse Der flache Anfang der Kurven zeigt offensichtlich einen Bereich, bei welchem die Leistung unabhängig von der Dreiecksgrösse ist. In dieser Region nehmen wir an, dass das System geometrie limitiert ist - i.e. es sind die Berechnungen für die Transformation von Eckpunkten, die Beleuchtungsberechnungen und das Dreiecks-Setup (welche alle unabhängig von der Dreiecks- grösse sind), welche das System zurückhalten - und nicht die Pixelfüllrate (Rasterisierung). Abhängig vom System und dem Rendering-Modus kann dieser Flaschenhals auch von der CPU und/oder von der Busbandbreite verursacht werden. Wenn die Dreiecke grösser werden, wird irgendwann die Rasterisierung der limitierende Faktor werden. Dies hat zur Folge, dass die Lei- stung plötzlich abnimmt. Dieser Punkt und die Rate, bei welcher die Kurve fällt, kann benutzt werden, um die Füllraten-Leistung eines Systems zu bestimmen. Aus den Resultaten des Textur-Tests kann man wiederum sehen, dass die Geometry Engines des Onyx2 Infinite Reality2 Systems viel stärker sind als diejenigen der Octane oder des Maxi- mum Impact-Systems. Doch die Resultate zeigen auch deutlich, dass die Raster Engines/Mana- gers der drei Systeme gleich gute Leistungen vollbringen. Die anderen Systeme wiederspiegeln zu Beginn der Kurven eigentlich die CPU Leistungen. Erst nach dem Abfall wird die Rasterisierung der Graphiksubsysteme getestet. Dort zeigt sich die O2 als Spitzenreiter.

11.3 SPEC CPU95 Aus Zeitgründen konnten nicht alle Tests durchgeführt werden. Der Fokus lag eindeutig bei den SGI Maschinen, da keine publizierten Resultate für sie verfügbar sind.

11.3.1 Bedingungen beim Ausführen von CPU95 Anzahl Durchläufe. Die Tests wurden bei allen Maschinen dreimal laufen gelassen. Der ermittelte Wert für einen Test entspricht dem Median aus den drei Einzeltests. Die resultierende SPECmark ist das geometrische Mittel aus den Einzeltests. Netzwerk. Die Maschinen waren alle am Netzwerk. Der Netzwerk Overhead ist nicht berück- sichtigt worden, dürfte aber, da die Benchmarks am späten Abend (nach 21h00) liefen, sehr gering sein. Benutzermodus. Alle Tests wurden im “Multi User Mode” durchgeführt.

11.3.2 Die Resultate Es werden hier nur die SPECmarks und die Medians der Einzeltests angegeben. 147.vortex. Der Benchmark 147.vortex konnte auf dem SGI Maschinen, auch nach Rückspra- che mit SGI und der SPEC, nicht laufengelassen werden. Die Integer SPECmark der SGI wurde aus dem geometrischen Mittel der anderen 7 Tests ermittelt. 11.3 SPEC CPU95 139

Tabelle 11.25 zeigt die Medians der Integer Tests. ID 099. 124. 126. 129. 130. 132. 134. 147. go m88 gcc com- li ijpeg perl vortex ksim press gogh 9.31 8.82 7.92 8.64 7.45 8.02 10.2 N/A caroll 3.70 2.49 3.01 4.04 3.75 3.38 3.97 N/A escher 2.87 1.90 2.37 3.11 2.87 2.59 2.72 N/A mondrian 5.43 5.03 4.84 3.96 5.29 4.78 6.27 N/A birs 13.3 11.8 12.0 13.9 11.8 12.0 16.4 13.7 luxo 10.4 8.26 8.72 10.8 8.23 8.76 9.55 N/A ppro 7.27 7.00 7.16 5.12 7.88 7.50 8.20 8.71 ptwo 14.6 15.7 14.8 11.8 15.8 15.6 17.8 17.3 antimon 5.96 4.71 5.13 5.93 4.50 5.64 5.22 5.15 Tabelle 11.25: CINT95

Tabelle 11.26 zeigt die Medians der Gleitkomma Tests.

ID 101. 102. 103. 104. 107. 110. 125. 141. 145. 146. tom- swim su2 hydro mgrid applu turb3d apsi fpppp wave5 catv cor 2d gogh 12.1 15.0 6.23 4.12 8.59 7.45 9.12 9.18 28.2 17.3 caroll 4.88 8.05 2.26 1.83 3.42 3.12 4.00 3.68 4.83 5.03 escher 3.97 6.64 1.85 1.54 2.80 2.48 3.12 3.04 3.66 4.00 mondrian 6.78 9.51 2.49 2.34 4.63 4.10 5.78 6.27 14.8 6.65 birs 26.1 41.5 10.9 10.7 18.1 13.2 16.0 15.1 35.0 27.0 luxo 24.2 33.9 10.1 10.7 18.5 11.7 13.3 15.6 26.7 24.6 ppro 7.72 11.1 2.69 3.01 2.84 2.88 5.14 5.25 9.59 6.44 ptwo 15.7 22.7 7.78 7.12 7.69 7.24 10.6 14.2 16.9 11.5 antimon 13.1 24.7 4.62 4.51 4.60 5.30 5.82 7.08 9.46 10.2 Tabelle 11.26: CFP95 140 11 Resultate und Analyse

Abbildung 11.12: SPEC int_base95 und SPEC fp_base95

Tabelle 11.27 zeigt die Baseline SPECmarks der Integer und Gleitkomma Tests. ID SPECint_base95 SPECfp_base95 gogh 8.50 10.2 caroll 3.43 3.80 escher 2.60 3.06 mondrian 4.96 5.50 birs 13.0 19.2 luxo 9.20 17.5 ppro 7.28 4.99 ptwo 11.6 11.2 antimon 5.26 7.61 Tabelle 11.27: Base SPECmarks 95

Bei den fettgedruckten Werten handelt sich um selber ausgeführte Messungen, alle anderen sind von der SPEC Homepage [18]. Das Ziel dieser Werte war nicht das System absolut zu benchmarken, sondern die Unterschiede der einzelnen Maschinen zu ermitteln. Da die Zeit drängte, wurden dann die Resultate von besagter WWW-Seite genommen. Dies reicht, um einen Über- blick der Systeme zu erhalten. 11.3 SPEC CPU95 141

Abbildung 11.13: CINT95 Resultate 142 11 Resultate und Analyse

Abbildung 11.14: CFP95 Resultate 11.4 Schlussbemerkungen 143

11.4 Schlussbemerkungen Es zeigte sich, dass die “starken” SGI Systeme doch noch eine Klasse für sich sind, sowohl in der Leistung wie auch im Preis. Die Onyx2 Infinite Reality2 überflügelte die anderen System in fast jedem Test. Einzig die Leistung der Raster Engine der Onyx2 wird von der Octane und dem Maximum Imapct System erreicht. Es wäre somit sinnvoll, das getestete Onyx2 System mit mehr Raster Engines zu bestücken. Die PC-Systeme zeigen trotz ihres günstigen Preises eine erstaunliche Leistung. Die Kombination zwischen Standard-Systemkomponenten (Intel-Prozessoren, Windows NT) und dedizierter Graphikhardware, wie sie SGI neu auch in den Visual Workstations einsetzt, ergibt neue Möglichkeiten zur Optimierung des Preis/Leistungs-Verhältnisses. 144 11 Resultate und Analyse 12 12Schlussworte

12.1 Zusammenfassung

Das Ziel dieser Arbeit war einerseits die Beschreibung aller Systeme. Dazu wurde hauptsäch- lich im Internet nach Informationen gesucht, sogenannte White Papers durchforscht und wenn nötig direkt mit den Herstellern diskutiert. Andererseits befassten wir uns mit der Leistungsmessung und der Analyse dieser Messungen. Dazu wurden Standard-Bechmarks verwendet, welche von der Standard Performance Evalua- tion Corporation SPEC entwickelt werden. Der grosse Zeitaufwand war dabei das Compilieren der Programme auf den Rechnern, was sich als sehr schwierig entpuppte. Die Analyse der Resultate zeigte, dass herkömmliche PC-Systeme diverse Probleme mit dem Datentransport haben, welcher sich negativ auf die Graphikleistung auswirkt. Ausserdem werden diverse Aspekte der Graphik-Pipeline, vorallem das Geometrie-Setup und Transforma- tionen immer noch vom Hauptprozessor ausgeführt. Die sgi Maschinen zeigten ein homogenes Verhalten über alle Tests, welche zu guten Graphi- kleistungen führten.

12.2 Fazit und Schlussbemerkungen

Diese Arbeit mitsamt den ganzen Resultaten auf der Semesterarbeits-CD bietet die grösste Sammlung simultan ausgeführter 3D Graphikleistungsmessungen. Die GLperf-Resultate sind einzigartig; selbst die publizierten Resultate auf der GLperf Homepage besitzen nicht diesen Umfang und dieses breite Spektrum. Interessant wäre es, diese Arbeit kontinuierlich fortzusetzen. Jede neue Maschine und jede zur Verfügung stehende Testmaschine sollte unter die Lupe genommen werden, so dass Leistungs- vergleiche sehr schnell möglich werden. Die “harte” Arbeit ist getan, der Aufwand neue Messungen durchzuführen ist klein. Davon pro- fitieren konnte man schon für eine neue Testserie für die Revision der Studentenlabors im IFW C-Stock. Diese Resultate und eine Analyse befindet sich im Anhang B.

12.3 Dank

Wir möchten allen Personen herzlich danken, welche uns bei dieser Arbeit in irgendeiner Weise unterstützt haben.

145 146 12 Schlussworte

Einen besonderen Dank richten wir an Reto Lütolf und Daniel Bielser, die Dank ihrer umgäng- lichen Art viel zu dieser Arbeit beigetragen haben. Einen weiteren Dank widmen wir Oliver Staadt für die Hilfe beim Kompilieren der Benchmark Programme und das vermittelte Know-How über die sgi-Maschinen. Zudem danken wir Chri- stian Kurmann und Felix Rauch für die Bereitstellung des SPEC CPU95 Benchmarks für die Intel-Maschinen und die allgemeine Hilfe bei der Fehlerbehebung bei diesem Benchmark. Ein Dankeschön gebührt ausserdem Florian Nussberger und Daniel Von Büren für die Hilfe an der Onyx2 und die Zeit, die sie für uns investierten, sowie André Naef und Michael Baumer, die uns ebenfalls beim Kompilieren, vorallem an den Intel-Rechnern, geholfen haben. 13Referenzen

[1] David A. Patterson und John L. Hennessy. Computer Architecture: A Quantitative Approach. Morgan Kaufman Publishers, 1996. [2] Diamond Multimedia Systems, Inc. Fire GL 1000 PRO. Homepage under http:// www.diamondmm.com/products/current/firegl-1000pro.cfm. [3] Evans & Sutherland. AccelGalaxy. Homepage under http://www.es.com/wg/ prod11.html. [4] Industrial Business Machines (IBM). Data Explorer. Homepage under http://www.hurs- ley.ibm.com/dx/ or http://www.almaden.ibm.com/dx/. [5] Intergraph Corporation. Design Review. Homepage under http://www.intergraph.com/ visualization/designrv.asp. [6] Intergraph Corporation. Intense3D Wildcat 4000 Graphics Accelerator. Homepage under http://www.intergraph.com/ics/wildcat/wc4000/default.asp. [7] Lightscape Technologies, Inc. Lightscape Visualization System. Homepage under http:// www.lightscape.com. [8] OpenGL - The Open Graphics Library. Homepage under http://www.opengl.org. [9] Parametric Technology Corporation. Pro/DESIGNER. Homepage under http:// www.ptc.com. [10] Rai Jain. The Art Of Computer Systems Performance Analysis: Techniques for Experi- mental Design, Measurement, Simulation, and Modeling Performance Evaluation. John Wiley & Sons, 1991. [11] sgi - Silicon Graphics Inc. Homepage under http://www.sgi.com. [12] sgi - Silicon Graphics Inc. Visual Workstations. Homepage under http://visual.sgi.com. [13] sgi Alias/Wavefront. Advanced Visualizer. Homepage under http://www.aw.sgi.com. [14] Texas Instruments Incorporated. 3D Graphics - TVP4020. Homepage under http:// www.ti.com/sc/docs/msp/multimed/index.htm. [15] The MIPS ABI Group, Inc. Information and Specifications. Homepage under http:// www.mipsabi.org. [16] The OpenGL Performance Characterization Project. The GLperf Benchmark. Homepage under http://www.spec.org/gpc/opc.static/glpind%7E1.html. [17] The OpenGL Performance Characterization Project. The Viewperf Benchmark. Home- page under http://www.spec.org/gpc/opc.static/opcview.html.

149 150 .

[18] The Standard Performance Evaluation Corporation. General Information. Homepage under http://www.spec.org. [19] The Standard Performance Evaluation Corporation. The SPEC CPU95 Benchmark. Homepage under http://www.spec.org/osg/cpu95. 10 1 81 11 A AAnhang

A.1 Die Open Graphics Library1

A.1.1 Computergraphik Tutorial Zuerst werden wichtige OpenGL Graphikfunktionen erklärt: Accumulation buffer. A buffer in which multiple rendered frames can be composited to produce a single blended image. Used for effects such as depth of field, motion blur, and full-scene anti-aliasing. Alpha blending. Provides a means to create transparent objects. Using alpha information, an object can be defined as anything from totally transparent to totally opaque. Anti-aliasing. A rendering method used to smooth lines and curves. This technique averages the color of the pixels adjacent to the line. It has the visual effect of softening the transition of the pixels on the line and those adjacent to the line, thus providing a smoother appearance. Color-index mode. Color buffers store color indices rather than red, green, blue, and alpha color components. Display list. A named list of OpenGL commands. The contents of a display list may be prepro- cessed and might therefore execute more efficiently than the same set of OpenGL commands executed in immediate mode. Double buffering. Used to provide smooth animation of objects. Each successive scene of an object in motion can be constructed in the back or "hidden" buffer and then displayed. This allows only complete images to ever be displayed on the screen. Gouraud shading. Smooth interpolation of colors across a polygon or line segment. Colors are assigned at vertices and linearly interpolated across the primitive to produce a relatively smooth variation in color. Immediate mode. Execution of OpenGL commands when they’re called, rather than from a display list. Pixel operations. Storing, transforming, mapping, zooming.

1. http://www.opengl.org

149 150 A. Anhang

Primitives. A point, line, polygon, bitmap, or image. Raster primitives. Bitmaps and pixel rectangles. RGBA mode. Color buffers store red, green, blue, and alpha color components, rather than indices. Stencil planes. A buffer that can be used to mask individual pixels in the color frame buffer. Texture mapping. The process of applying an image to a graphics primitive. This technique is used to generate realism in images. For example, a tabletop drawn as a rectangle could have a wood-grain texture applied to it to make it look more realistic. Three Dimensional Texturing. Three-dimensional texturing for supporting hardware-accelerated volume rendering. Transformation. The ability to change the rotation, size, and perspective of an object in 3D coordinate space. Z-buffering. The Z-buffer is used to keep track of whether one part of an object is closer to the viewer than another. It is important in hidden surface removal.

A.1.2 Die OpenGL Primitiven Damit man einen Überblick bekommt, was mit diesen Pri- mitiven in OpenGl gemeint ist, hier ein graphischer Über- blick. Die Primitiven unterstützen den Programmierer um geometrische Objekte zu konstruieren. Jedes geometrische Objekt wird durch ein Satz von Ecken und dem Typ der Primitive, die gezeichnet wird, beschrieben. Ob und wie die Ecken verbunden sind wird durch den Typ der Primitive festtgelegt.

A.1.3 Die OpenGL Pipeline

OpenGL operiert auf Bilddaten, genauso wie auf geometrischen Primitiven. A.2 Viewperf 151

A.2 Viewperf

A.2.1 Die Viewperf Kommandozeilen Parameter

In Tabelle A.1 werden die Kommandozeilen Parameter von Viewperf 6.1 kurz erklärt. Dies hilft beim Verständnis der Viewset Scripts und beim Entwickeln von eigenen Scripts..

Tabelle A.1: Viewperf command line options

-polygon -pg Viewpoint object to be used in the tests -triangle -tr Viewpoint object to be used in the tests -quad -qd Viewpoint object to be used in the tests -mesh -mh Mesh object to be used in the tests -rendermode -rm POINT, VECTOR, LINE, POLYGON, TMESH, TFAN, TRIANGLE, or QUAD - default LINE -vcriteria -vcrit AUX Visual selection criteria - EXACT, MIN - default MIN -vid Ask AUX for visual with ID = -vaccum -vac Ask AUX for an accumulation buffer visual -valpha -val Ask AUX for an alpha buffer visual -vdepthbuffer -vz Ask AUX for a depth buffer visual -vstencil -vst Ask AUX for a stencil buffer visual -indirectrender -ir Render indirect - default direct -nodither -ndi Disable dithering -ortho -or Parallel/Orthographic projection - default Perspective -displaylist -dl Render with display list mode -vertexarray -va Render with vertex array mode (OpenGL1.1) -interleaved -il Packing vertex data interleaved in memory -colorper -cp FRAME = Color per Frame, PRIMITIVE = Color per Primitive, VERTEX = Color per Vertex - default FRAME -texture -tx Image for texturing -texgen -txg is image for enviroment mapping is SPHERE_MAP, OBJECT_LINEAR, EYE_LINEAR - default EYE_LINEAR -texobj -txo Texture object mode is list of images -magfilter -magf NEAREST, LINEAR - default NEAREST 152 A. Anhang

Tabelle A.1: Viewperf command line options

-minfilter -minf NEAREST, LINEAR, NEAREST_MIPMAP_NEAREST, LINEAR_MIPMAP_NEAREST, NEAREST_MIPMAP_LINEAR, LINEAR_MIPMAP_LINEAR - default NEAREST -texenv -te Texture enviroment, MODULATE, DECAL, BLEND - default DECAL -texcomp -tc Texture components where is 1,2,3, or 4 - default 3 -blend -bl Enable Blending -srcblendfunc -sbf ZERO, ONE, DST_COLOR, ONE_MINUS_DST_COLOR, SRC_ALPHA, ONE_MINUS_SRC_ALPHA, DST_ALPHA, ONE_MINUS_DST_ALPHA, SRC_ALPHA_SATURATE - default SRC_ALPHA -dstblendfunc -dbf ZERO, ONE, SRC_COLOR, ONE_MINUS_SRC_COLOR, SRC_ALPHA, ONE_MINUS_SRC_ALPHA, DST_ALPHA, ONE_MINUS_DST_ALPHA, - default ONE_MINUS_SRC_ALPHA -linewidth -lw Linewidth for wire/vector tests - default 1.0 -xwinsize -xws Size of test windows X dimension - default 700 -ywinsize -yws Size of test windows Y dimension - default 700 -numframes -nf Number of frames to be rendered during measurement. Takes priority over -mp -numilights -nil Turns on infinite lights - default 0 -numllights -nll Turns on local lights - default 0 -colormaterial -cm is FRONT, BACK, FRONT_AND_BACK - default FRONT is AMBIENT, DIFFUSE, EMISSION, SPECULAR, AMBIENT_AND_DIFFUSE - default AMBIENT_AND_DIFFUSE -backface -bf Cull Backfacing primitives - default off -frontface -ff Cull Frontfacing primitives - default off -singlebuffer -sb Single buffer mode -fog -fg Enable fog -linesmooth -ls Enable line antialiasing A.2 Viewperf 153

Tabelle A.1: Viewperf command line options

-polysmooth -ps Enable polygon antialiasing

-facetnormal -fn Use facet normals when lighting

-linestipple -lp Enable line stipple

-polystipple -pp Enable polygon stipple

-batch -bt Batch primitives together per glBegin/glEnd. Valid with POINT, VEC- TOR, TRIANGLE, and QUADS -polymodefront -pmf POINT, LINE, or FILL - default FILL -polymodeback -pmb POINT, LINE, or FILL - default FILL -flat -f Set shademodel to FLAT - default GOURAUD -zbuffer -zb Enable zbuffer for tests - default off -clip -c Align object on 3D clip boundary

-lighttwoside -l2s Light both sides of model

-localview -lv Define local viewer for lit tests

-normalize -nm Enable normal normalization

-minperiod -mp Set minimum testing period in seconds

-mblur Use motion blur with num being amount of decay

-aa_multi Full scene antialiasing rendered x times at an offset of r. r should be tuned to the viewset -walkthru -wt Walkthru mode -grab Screen capture -grabonly -go Don’t run benchmark, just do screen capture

-swap Force byte swapping

-notitle -nt Disable title screen

-startframe -sf Set starting frame of a walkthru

-framepause -fp Pause after each frame waiting for enter key

-newview -nv Enable new view frustum calculation

-fov Set field of view in degrees

-spin x y z dx dy dz Set rotation initial valüs and speeds (degrees)

The -threads option is applicable only if Viewperf has been compiled with the C Preprocessor variable MP defined. Viewperf should only be compiled this way if the vendor supplied makefile has defined the MP flag (-DMP). 154 A. Anhang

A.3 GLperf

A.3.1 Die Grammatik der Eingabedateien Die Eingabedateien für GLperf müssen der folgenden Grammatik genügen. Suite -> GlobalProperty Suite | TestDescription Suite | TestDescription TestDescription -> TestName | TestName { LocalPropertyList } LocalPropertyList -> Property | Property LocalPropertyList GlobalProperty -> Property Property -> ( PropertyName AttributeValue ) AttributeValue -> Range | List | Wildcard Range -> from int to int | from int to int step int | from int to int step int % | from float to float | from float to float step float | from float to float step float % List -> Value | Value List Value -> Enumerated | float | int | 0xhex Wildcard -> ALL | * Where TestName is one of: ¥ BitmapTest ¥ ClearTest ¥ CopyPixelsTest ¥ DrawPixelsTest ¥ LineLoopTest ¥ LineStripTest ¥ LinesTest ¥ PointsTest ¥ PolygonTest ¥ QuadStripTest ¥ QuadsTest ¥ ReadPixelsTest ¥ TexImageTest ¥ TextTest ¥ TransformTest ¥ TriangleFanTest ¥ TriangleStripTest ¥ TrianglesTest Where PropertyName and Enumerated are one of the values listed in the tables on [GLperf:WWW]. A.3 GLperf 155

A.3.2 Die fehlenden OpenGL Kommandos auf den SUN’s

Die folgenden Kommandos werden in SUN Solaris 2.6 OpenGL nicht unterstützt:

GL_ALPHA4_EXT GL_ALPHA8_EXT GL_ALPHA12_EXT GL_ALPHA16_EXT GL_LUMINANCE4_EXT GL_LUMINANCE8_EXT GL_LUMINANCE12_EXT GL_LUMINANCE16_EXT GL_LUMINANCE_ALPHA GL_LUMINANCE4_ALPHA4_EXT GL_LUMINANCE6_ALPHA2_EXT GL_LUMINANCE8_ALPHA8_EXT GL_LUMINANCE12_ALPHA4_EXT GL_LUMINANCE12_ALPHA12_EXT GL_LUMINANCE16_ALPHA16_EXT GL_INTENSITY_EXT GL_INTENSITY4_EXT GL_INTENSITY8_EXT GL_INTENSITY12_EXT GL_INTENSITY16_EXT GL_RGB2_EXT GL_RGB4_EXT GL_RGB5_EXT GL_RGB5_A1_EXT GL_RGB8_EXT GL_RGB10_EXT GL_RGB10_A2_EXT GL_RGB12_EXT GL_RGB16_EXT GL_RGBA2_EXT GL_RGBA4_EXT GL_RGBA8_EXT GL_RGBA12_EXT GL_RGBA16_EXT GL_POST_COLOR_MATRIX_COLOR_TABLE_SGI GL_PIXEL_TRANSFORM_COLOR_TABLE_EXT GL_PROXY_PIXEL_TRANSFORM_COLOR_TABLE_EXT

The above listed commands are deleted from GLperf’s Source Code in order to compile the GLperf Benchmark under Solaris 2.6. In order to have representative benchmarks it is kindly requested not to use the above commands while comparing with systems other than Solaris. 156 A. Anhang B BWeitere Tests

Im Zuge der Revision der Studentenlabors im IFW C-Stock wurden noch weitere Maschinen getestet. Es handelt sich dabei um ein Dell Computersystem mit drei verschiedenen Graphik- karten und um die SGI Visual Workstation 320 (NT-Box).

B.1 Das Dell Computersystem mit drei verschiedenen Graphikkarten Als Basis dient eine Dell Precision 410 mit einem Intel Pentium III (500 Mhz) Prozessor, 256MB Arbeitsspeicher und einer interner SCSI-Festplatte. Die getesteten Graphiksubsysteme stammen aus den Leistungsbereichen Low-End, Mid-range und High-End. Alle werden über den AGP-Slot ins PC-System integriert.

B.1.1 Diamond FireGL 1000 PRO (AGP) Die Karte ist mit einem 3DLabs Permedia P2 Graphikprozessor (auch Texas Instruments TVP4020 genannt) ausgerüstet und besitzt einen integrierten Geometry-Setup-Prozessor (3Dlabs Delta3D) zur Entlastung der Haupt-CPU. Die FireGL 1000 integriert einen 8 MByte grossen Speicher, der dynamisch in Frame Buffer und Texture Memory unterteilt ist. Von der Hardware werden sowohl bilineares Texture-Mapping, Double-Buffering, wie auch 16-bit Z-Buffering unterstützt. Jedoch wird keine trilineare Filterung der Texturen unterstützt. Es sind OpenGL-Treiber für Windows NT/95 und für Linux verfügbar. Die maximale Auflö- sung beträgt 1280x1024 bei 16-bit Z-Buffering, 24-bit-Farbtiefe und 100 Hz Bildwiederholfre- quenz. Es ist kein true-color Rendering möglich. Die Karte kostet ca. $200. In Tabelle 13.1 sind die wichtigsten Informationen des Permedia2 zusammengefasst. Weitere Informationen unter [2] und [14].

157 158 B. Weitere Tests

Tabelle 13.1: Spezifikationen der Diamond FireGL 1000 PRO Eigenschaft Diamond FireGL 1000 PRO Graphikcontroller 3Dlabs Permedia 2 bzw. Texas Instruments TVP 4020 Architektur 64 bit Bus AGP Video RAM 8 MByte DRAM (dynamische Unterteilung in Frame und Textur Speicher) 3D Operationen Gouraud & Flat Shading, 16 bit Z-Buffer, Alpha Blending, Bilinear Filtering, Hardware Texture Mapping RAMDAC Speed 230 MHz Chip Clock Speed 83 MHz Bandbreite 664 MByte/s AGP Features AGP 1x (266MByte/s); Full Sideband Addressing; DMA Mode Texturing Geometry Pipeline Processor 3Dlabs Delta 3D Peak Rates (published) 1 Mio. Polygons/s / 80 Mio. Pixels/s

B.1.2 Evans & Sutherland AccelGalaxy 52 Die AccelGalaxy vertritt die mittlere Leistungsklasse. Sie unterstützt in Kombination mit dem REALimage 2100-Chip den neuen Befehlssatz SSE des Pentium III-Prozessors. Die AccelGa- laxy leistet ca. 4 Millionen 3D Dreiecke pro Sekunde (25 pixels, Gouraud-shaded) Das System ist mit 20 MByte 3DRAM für Frame- und Local-Buffer und separaten 32 MByte CDRAM Texturspeicher ausgerüstet. Die Hardware unterstützt bi- und trilinear gefiltertes Tex- ture-Mapping mit Perspective-Correction und MIP-Mapping, Gouraud-Shading, Anti-Alasing und 24-bit Z-Buffering. Die AccelGalaxy unterstützt Stereo-Rendering und Dual Screen Modus mit einer Karte. Treiber sind für die Betriebssysteme Windows NT und Linux erhältlich. Die maximale Auflö- sung beträgt 1280x1024 bei 24-bit Z-Buffering, 24-bit Farbtiefe und 85 Hz Bildwiederholfre- quenz. Die Karte kostet ca. $1200. Weitere Informationen unter [3].

B.1.3 Intergraph Intense 3D Wildcat 4000 Das Intergraph-Graphiksystem zählt sowohl leistungsmässig wie auch preislich zur absoluten Topklasse. Das System besteht aus zwei Karten, die in den AGP Slot und in einen PCI Slot eingesetzt werden. Die Karte beruht auf der Wildcat Technologie von Intense3D und implementiert die ParaScale Architektur, welche hochskalierbar ist und mehrere parallel arbeitende Geometriebeschleuniger Chips und Rasterization Engines unterstützt. Das Kernstück der Wildcat bildet ein 3000 MFLOPS leistender Geometriebeschleuniger ASIC (Application Specific Integrated Circuit). B.2 Die sgi Visual Workstation 320 159

Dieser übernimmt sämtliche Beleuchtungs- und Transformationsberechnungen. Der Rasteriza- tion Engine ASIC leistet bis zu 6 Millionen 3D Dreiecke pro Sekunde oder 68 Millionen Pixels pro Sekunde (trilinear MIP-mapped). Die Karte besitzt 16 MByte Framebuffer und 64 MByte Texturspeicher. Die Wildcat 4000 Technologie unterstützt Stereo-Rendering und Multi Screen Modi. Die Liste der durch Hardware unterstütz- ten Funktionen ist lang und beinhaltet unter anderem folgende Punkte: bi- und trilinear gefiltertes Texture-Mapping, Gouraud-Shading, Anti-Alasing, Alpha- Blending und 24-bit Z-Buffering. Opti- mierte Open GL-Treiber sind bis jetzt nur für Windows NT verfügbar. Die Inter- graph-Karte kostet ca. $3000. Weitere Informationen unter [6].

B.2 Die sgi Visual Workstation 320 Die Visual Workstation 320 von sgi ist die billigste Maschine der neuen Windows NT Rechner von sgi. Als Basis diente ein intel Pen- tium II Prozessor mit 450 MHz Taktfrequenz, 256 MByte ECC SDRAM und einer 6.4 GByte Ultra ATA Harddisk. In anderen Visual Workstations kommen intel Pentium III Prozessoren zum Einsatz. Die Visual Workstations sind dann optimiert für die neuen SIMD Instruktionen (SSE). Mit einem revolutionär neuen System-Design, welches den Fla- schenhals in traditionellen PC-basierten Systemen eliminiert, bieten die Visual Workstations einen enormen Durchsatz, welcher von High-End Computer Graphik und Multimedia-Bearbei- tung (Ton- und Bild gleichzeitig) benötigt wird. Das neue Design, welches Intergrated Visual Computing (IVC) genannt wird (siehe Abbildung 13.1), transportiert Graphikdaten mit bis zu 3.2 GByte pro Sekunde sechsmal schneller als AGPx2-basierte Systeme. Zusammen mit dem Cobalt Graphik Chipset bieten die Visual Work- stations eine unglaubliche 2D-, 3D- und Digital-Media-Leistung, welche kein anderes Win- dows NT-System erreichen kann. Die Visual Workstations bieten ausserdem eine Fülle von Schnittstellen, unter anderem IEEE 1394 (Firewire), USB, Composite und S-Video (NTSC und PAL) I/O und 16-bit Audio Stereo I/O. Eine Visual Workstation kostet zwischen $3500 (VW 320) und $6500 (VW 540). Als Vergleich kostet eine Dell Precision 410 mit der Intergraph Intense3D Wildcat 4000 $6400, mit der Accel- Galaxy 52 $4600. Weitere Informationen unter [12]. 160 B. Weitere Tests

Abbildung 13.1: Die sgi Integrated Visual Computing (IVC) Architektur im Ver- gleich zur herkömmlichen PC Architektur B.3 Resultate und Analyse 161

B.3 Resultate und Analyse In den folgenden Kapiteln wird ein kurzer Überblick der Resultate der in B.1 und B.2 beschriebenen Systeme gegeben. Auf eine detailierte Analyse wird aber verzichtet.

B.3.1 Viewperf

Abbildung 13.2: Überblick Viewperf 162 B. Weitere Tests

Abbildung 13.3: Viewperf - Light Viewset

Abbildung 13.4: Viewperf - ProCDRS Viewset: Display List Build-Time B.3 Resultate und Analyse 163

B.3.2 GLperf

Abbildung 13.5: GLperf - Texture Download (RGBα , no mip-mapping)

Abbildung 13.6: GLperf - Lichtquellen 164 B. Weitere Tests

Abbildung 13.7: GLperf - Pixelfüllraten

Abbildung 13.8: GLperf - Dreieckfüllraten (smooth, 1 infinite light) B.4 Schlussbemerkungen 165

Abbildung 13.9: GLperf - Dreieckfüllraten (trilinear filtered texture, 1 infinite light)

B.4 Schlussbemerkungen Es soll hier nur ein kleine Zusammenfassung der Ergebnisse dieser Tests gegeben werden. Die Visual Workstation zeichnet sich durch eine sehr gute Geometry Engine aus. Sowohl beim Lichtquellen- wie auch beim Dreiecksfüllraten-Test von GLperf fallen die hohen Werte auf. Bei den Dreiecksfüllraten ist die Visual Workstation sogar die einzige Maschine, welche auch bei kleinen Dreiecksgrössen nicht durch die Geometry Engine limitiert wird. Sie kommt sogar fast an die Rasterleistungen der Onyx2 Infinite Reality2 Single Pipe heran. Die Visual Workstation scheint auch die UMA viel besser als die O2 auszunutzen. Bei den Textur Download Tests erreicht die sie ebenfalls fast so gute Werte wie die Onyx2 oder die Octane. Sie scheint auch bei der grössten Textur den Höhepunkt noch nicht erreicht zu haben. Die Raster Engine der Wildcat-Karte erreicht ebenfalls gleich hohe Leistungen wie die Onyx2 oder Visual Workstation. Doch bei kleinen Dreiecken kann die Geometry Engine, wie übrigens auch bei der AccelGalaxy-Karte, nicht mehr mit der Raster Engine mithalten. Beim Überblick mit Viewperf zeigt sich aber doch, dass das Wildcat-System einiges leisten kann. In drei von fünf Tests überflügelt sie die AccelGalaxy und die Visual Workstation gleich um das doppelte. Beim komplexen Lightscape Viewset erreicht sie als einzige PC-Karte die Werte der Onxy2 Infinite Reality2. Als Schlussworte kann hier nur nochmals angefügt werden, dass die Kombination von Standard System-Hardware (CPU, Memory, etc.) mit einem gut durchdachten Bussystem (z.B. UMA) und spezieller Graphikhardware wohl die Architektur der Graphiksysteme der Zukunft sein werden.