perf - Institut for Computer Systems

Transcription

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.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.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.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
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
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 Prozessoren und ihr Einfluss auf die Graphikleistung, die Systemarchitektur und die Graphiksubsysteme 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 Standard 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 performed 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 Graphics and standard PC workstations.
vii
viii
.
Eidgenössische
Technische Hochschule
Zürich
Ecole polytechnique fédérale de Zurich
Politecnico federale di Zurigo
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 ausgerü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 geradezu 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 Systemkomponenten 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 Infinite 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 Benchmark-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
(Prof. Dr. M. Gross)
Abgabe: 3. Juli 1999
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 Internet 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 schattiert, 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 Anwendungsbenchmark, der Viewperf Benchmark, dazu verwendet, die Graphikleistung realer 3D Anwendungen 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össen. 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 Primitiven 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 Speichergeschwindigkeit und die Busbandbreite als Flaschenhals zwischen Prozessor und Graphiksubsystem. Somit sind die von Viewperf und GLperf ermittelten Werte auch von diesen
Systemkomponenten abhängig. Aus diesem Grund wurde mit einem weiteren Benchmark Programm 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 Graphikbenchmark-Programme. Die mit CPU95 ermittelten Werte dienen jedoch der Analyse der Graphikleistung.
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
Name
OS
Vers.
Window CPU
Env.
Graphic System
gogh
SGI
Indigo2
IRIX
6.5
X
MIPS R10000
195 MHz
Maximum
Impact 10000
caroll
SGI
Indigo2
IRIX
6.5
X
MIPS R4400
200 MHz
XZ
escher
SGI
Indigo2
IRIX
6.5
X
MIPS R4400
150 MHz
Extreme
mondrian SGI
O2
IRIX
6.5
X
MIPS R5000
200 MHz
CRM
birs
SGI
Octane
IRIX
6.5
X
MIPS R10000
250 MHz
MXE
luxo
SGI
Onyx2
IRIX
6.4
X
MIPS R10000
8 × 195 MHz
Infinite Reality2
ppro
Dell
Optiplex
Pro
WinNT
4 SP3
Win
Intel Pentium
Pro 180 MHz
Diamond FireGL
1000 PRO PCI
ptwo
Dell
Precision
410
WinNT
4 SP3
Win
Intel Pentium II
2 × 400 MHz
Diamond FireGL
1000 PRO AGP
antimon
Sun
Ultra1
Solaris
Model 170 2.5
X
UltraSPARC I
167 MHz
Creator 3D
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 Graphiksystemen abgelöst. Damit stellen diese SGI Rechner die ältesten im Rahmen dieser Arbeit
getesteten Maschinen dar.
Ausgestattet wird die Indigo2 mit einem MIPS R44001 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
Um Konfusionen zu vermeiden, werden die älteren Indigo und die neueren Indigo2 Rechner oftmals durch ihre Gehäusefarbe identifiziert, besonders in älteren Dokumentationen und Whitepapers.
•
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 ausgehend, 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 Unterstü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
Abbildung 2.1:
Die Indigo2 XZ/Extreme Systemplatine
11
12
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 Subsysteme, 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-Verarbeitungsstufen 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
(GE7 Prozessor)
4
8
Raster Engines
(Typ 3)
1
2
Tabelle 2.2: Hardware Komponenten der Graphiksysteme.
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 Prozessoren 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-3DGraphik-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
3.
•
die Transformationen,
•
die Beleuchtungsberechnungen und
•
die Transformation von 3D-Welt- in 2D-Bildschirmkoordinaten vorgenommen.
In der Rasterverarbeitung laufen folgende Teilschritte ab:
•
Zuerst wird die sogenannte Scan-Conversion durchgeführt
Die in Bildschirmkoordinaten vorliegenden Graphikprimitiven werden in zusammenhängende Gruppen von Pixeln aufgeteilt.
•
Anschliessend wird für jedes einzelne Pixel einer Graphikprimitive mittels Z-Buffer-Algorithmus geprüft, ob der Bildpunkt sichtbar ist oder nicht (HiddenLine/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 Farbwerte 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
Gegegebenenfalls kommen noch weitere Operationen auf Pixelbasis hinzu wie etwa:
4.
•
Texture-Mapping1
•
Anti-Aliasing
•
Nebeleffekte
•
Stenciling
•
Alpha-Blending etc.
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
Als Verbindung zur CPU dient der 64 Bit breite GIO64 Bus. Mit dem Burst Mode2 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 übertragen werden, was eine sehr hohe Transferrate vom und zum Frame Buffer beziehungsweise ZBuffer zur Folge hat. Dies kommt vor allem bei graphik-orientierten Applikationen zum Tragen, 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 Graphikbefehlen wird analysiert und die Graphikprimitiven4 bestimmt, welche dann an die Geometry 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 Prozessor bearbeitet somit eine andere Graphikprimitive, welche aber alle zur selben Graphikinstruktion 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 Multiplikationen der andere für Additionen. Dank der kurzen Latenz der Mikro-Instruktionen erreicht
jeder GE7 Prozessor eine Leistung von 32 MFLOPS.
1.
2.
3.
4.
Nur bei Indigo2 Maximum Impact in Hardware.
Die Datenwörter werden nicht einzeln, sondern zu grossen Blöcken zusammengefasst übertragen.
FIFO = First In First Out Speicherverwaltung.
Jedes Graphische Objekt lässt sich in seine Graphikprimitiven - Punkte, Linien, Dreiecke und
Polygone - aufteilen.
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 Matrizenoperationen werden Transformationen, Rotationen und Skalierungen berechnet.
Im nächsten Schritt werden die einzelnen Punkte beleuchtet. Dazu stehen maximal acht Spotlights zur Verfügung. Die Materialspezifikationen beeinhalten ambient, diffuse und specular
reflectance Parameter und Informationen des Lichtmodels. Als Resultat dieser Beleuchtungsberechnungen 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 Einsatz kommt.
Im nächsten Schritt werden Triangle Meshes und Independant Quads aufgeteilt, da das Geometry-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 Dreiecksfläche (in X und Y-Richtung)
Die resultierenden Parameter werden von den GE7 Prozessoren ans Raster Subsystem weitergeleitet.
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ächsten 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 Subsystem 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
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 Applikationen 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 Processor (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.
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
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 befindet 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ürlich 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
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 kompakter als die nächst grösseren Indigo2 Systeme, sondern auch preislich attraktiver. Ausgestattet 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 Usermemory 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 Echtzeit 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
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 Prozessors 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 Prozessorarchitekturen 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 Features 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
R10000
R5000 SC, PC a
R4400 SC, PC, MC b
Superskalare Architektur
ANDES
(Advanced Superscalar Architecture) mit 4 Instruktionen pro Zyklus:
2 INT und 2 FP execute und 1
Load/Store pro Zyklus
Dual Issue:
FP Load/Store und FP ALU Instruktionen geladen im selben Zyklus
Nein
Pipeline
5-fach
5-fach
8-fach
Instruktionssatz
MIPS-IV
MIPS-IV
MIPS-III
Primary Data Cache
32 KBytes
32 KBytes
16 KBytes
Primary Instruction Cache
32 KBytes
32 KBytes
16 KBytes
Secondary Cache Unterstützung
128 bit Data Bus, Min. 512 KB
Max. 16 MB
(max.) 128 byte cache line refill
64 Bit Data Bus, Min 512 KB
Max. 2 MB
128 Bit Data Bus, Min 128 KB
Max. 4 MB
Branch Prediction
ja
nein
nein
Daten Abhängigkeiten
Register renaming/out of order exec.
nein
nein
Translation look aside buffer
64 Einträge
96 Einträge
96 Einträge
Multiprozessor unterstützt
ja
nein (nicht in der ersten Version)
ja (nur R4400 MC)
MADD Instruktionen
ja
ja
nein
Tabelle 3.1: Vergleich zwischen den MIPS Prozessoren R10000, R5000 und R4400
3 Die O2 von SGI
a. Bei der SC Variante ist sowohl ein primary und secondary cache vorhanden, die PC Ausführung hat nur den primary cache.
b. Bei der SC und MC Variante ist sowohl ein primary und secondary cache vorhanden, die PC Ausführung hat nur den primary cache. Der R4400 MC bietet noch
zusätzlichen Support für Multiprozessor Systeme.
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:
A×B+C = D
Dies sollte aber nicht mit dem bekannten MAC (multiply-accumulate) verwechselt werden,
das lediglich
A×B+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 Pipelinestufen 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 Mechanismus 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 aufweist, 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 ausnutzen.
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 Vergleich 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 Floatingpoint 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 Verarbeitung brauchen, wie zum Beispiel das Gouraud Shading.
•
Der R10000 war nie für Speichersysteme mit Unified 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 zurückgeliefert wird. Die cycle time definiert die minimale Zeit, welche zwischen zwei aufeinanderfolgenden 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.
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 herkö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 Hauptspeichers 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 Problemen 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 Hauptspeicher 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 Hauptspeicher mit der geforderten Leistung zu übertragen. Als Ausweg haben sich die Hardware Hersteller, 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 Problem 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 Graphik- und Hauptspeicher einen gemeinsamen physikalischen Speicher bilden. In der Sprache
des SGI Marketings nennt sich das Ganze schliesslich Integrated Visual Computing Architecture (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.
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 Vergleich 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 Graphikverarbeitung zurückzuführen ist.
3.2.1 Allgemeine Bemerkungen
Wie schon erwähnt führt die O2 alle Geometrie- und Beleuchtungsberechnungen im Hauptprozessor 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, 3DSzenen 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 zeitaufwendige Transfers zwischen dem Hauptspeicher und den Graphikboards notwendig werden. Ebenfalls 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 MemoryBandbreite (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 liegen1.
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 GraphikBerechnungen ü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 Systemen2 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 aufgefü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. Insbesondere 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 Graphiksysteme. 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 Rechnerreihe 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 Maximum Impact bei weitem übertreffen.
Das Kernstück der Octane-Systemarchitektur bildet ein Crossbar-Switch, welcher alle Komponenten im Rechner miteinander verbindet. Dank dieser Technologie kann eine durchschnittliche Ü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
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 GeometryEngine, 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 Maximum 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 TextureCache-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.
35
Nachfolgend werden die drei Modelle kurz vorgestellt:
•
Octane SE: Einfachste Ausführung: Die Graphikhardware besteht aus einer Geometrie- und Rasterengine und belegt einen XIO-Port. Ein solches System soll laut Hersteller 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 Rasterengines 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.
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 abgebildet. 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-Speichermodule. 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 Fliesskommaleistung 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
Standardmässig sind die Octane Systeme mit einem 24-Bit Audio-Subsystem, 10/100Base-TXEthernet 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 Verbindung 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 Auflö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 CCIR601 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.
Abbildung 4.1:
37
Die Octane Systemplatine
38
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 leistungsfä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 Prozessorleistung 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 Symptombekä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 herkö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 Graphikkarte 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 CrossbarSwitch 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ächsteilnehmer 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-Verbindung 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 Auflö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 Einsteigermodell 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
Octane Crossbar Switch
XIO
zusätzliches
Geometry
Subsytem
von Octane
SS und MX
XIO
Interface
Interface
GE
GE
Geometry
Subsytem
zusätzliches
Raster Subsytem von
Octane SS und MX
Raster
Subsytem
Raster Engine
Z Buffer
Raster Engine
Texture Engine
Texture Engine
(nur mit installiertem
Texturspeicher
funktionsfähig)
(nur mit installiertem
Texturspeicher
funktionsfähig)
Z Buffer
VRAM
VRAM
Texture Memory
Texture Memory
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 ultimate in supercomuting and visualization technologies and then designed a way to simultaneously 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
Um eine Übersicht zu erlangen, werden im ersten Teil dieses Abschnittes die verschiedenen
Onyx2 Systeme beschrieben. Anschliessend wird auf die spezielle Architektur dieses Grossrechners 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 Illustrationen dieselben sind. Das Onyx2 InfinteReality2 Visualisierungs-Subsystem besteht aus
drei Komponenten: Geometry Engine, Raster Manager und Display Generator. Die Geometry 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.
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 GraphikPipelines 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.
Abbildung 5.4:
45
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 Graphiksystem arbeitet demnach mit seiner vollen Leistung für die Darstellung auf nur einem Bildschirmfenster. Mit dieser geballten Ladung an Graphikleistung lassen sich absolut realitätsnahe
virtuelle 3D-Welten darstellen. Es bestehen grundsätzlich zwei Möglichkeiten um dieses Prinzip des Multi-Pipe Rendering Mode umzusetzen:
•
Digitales Multiplexing (DPLEX):
Dies ist eine Hardware Option, welche folgendes einfaches Prinzip ausnutzt: Die Graphik-Pipelines arbeiten parallel auf der Sequenz von Frames. Anschliessend werden die
berechneten Frames mit einem digitalen Multiplexer in der richtigen zeitlichen Reihenfolge 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 theoretisch eine Textur-Download Rate von 5 GB/Sec erzielen!
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 Terminologie 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 Verbindung miteinander. Vor allem in einem Mehrprozessorsystem würde ein gemeinsamer Systembus 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 hinzugefü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 Uniform 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 dazwischenliegenden 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.
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 diametral 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 Verbindungen 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!
Anzahl Knoten
Bisection Bandwith
Shared Bus
Hypercube
Komplett verbunden
2
1
1
1
4
1
2
4
8
1
4
16
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 Verbindungen 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 Verbindungen zwischen Knoten gebraucht werden. In der Abbildung 5.8 sind diese zusätzlichen Verbindungen 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 HypercubeArchitektur! 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.
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 Speichers 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äufigsten 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 Graphikhardware über den Crossbow anschliessen. Dies lässt sich besonders gut in den Abbildungen
5.2 bis 5.4 erkennen.
Abbildung 5.10:
53
Zusammenspiel von Node-Board, Router und Crossbow (CrossbarSwitch)
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 Abbildung 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 3DDaten sind dies Transformationen1 der Eckpunkte im Raum, das Beleuchten und das Clipping.
Im weiteren findet 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 gelieferten 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-Funktionen.
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 Processing 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 Videosignalcharakteristiken (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 einfallen 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 Gegenmassnahmen 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 Software 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 dynamischen 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 Texturen1, 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 Fahrsimulatoren 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 Erweiterungsfunktionen, 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 Operationsmodi. Im Immediate Mode ruft die Applikation direkt OpenGL Befehle auf. Alternativ
können die immediate Kommandos zu Display Lists kompiliert werden. Die Applikation kann somit immer diese Display Lists anstelle von immediate Kommandos ausführen.
•
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 Prozessor 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 Generation beeinhalten zusätzliche 25 Single-Cycle-Instruktionen, welche besonders für die Abarbeitung 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 Crossbar-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 vergangenen 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.
Elite3D m6
Elite3D m3
Creator 3D
System
Unterstützte Graphiksysteme
PGX24,
on board
Prozessoren
Max.
Anzahl
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.
Creator
Architektur
✔
✔
6.1 Systemarchitektur der Ultra1
61
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 findet 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
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 Komponenten 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 Vorteile 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 Verbindungen aufrecht erhalten. An dieser Stelle sei auf die hohen technischen Anforderungen hingewiesen, 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-stufige 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 KonvertierungsInstruktionen. 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 Dekompression 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 profitieren. Diese gestatten direkte 64 Bytes Load und Stores vom Prozessor in den Hauptspeicher und vom Hauptspeicher in den Framebuffer des Graphiksystems.
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 Übertragungen 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. Typischerweise 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 GraphikAlgorithmen 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 3DRAM’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 TextureMapping 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 hundert 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
Abbildung 6.2:
67
SUN Creator3D Graphiksystem
68
6 Ultra 1 von SUN
6.2.2 Elite 3D m3/m6
UPA
In der nachfolgenden Abbildung ist der schematische Aufbau der Elite3D Graphiksubsysteme
dargestellt, wie sie in den neueren SUN Ultra Modellen zum Einsatz kommen.
UPA Interface
AFB
Command
Nur Elite3D m6
AFB
Float
AFB
Float
AFB
Float
AFB
Float
AFB
Float
AFB
Draw
AFB
Float
AFB
Draw
3D RAM
3D RAM
3D RAM
3D RAM
3D RAM
3D RAM
RAM DAC
Monitor
Abbildung 6.3: SUN Elite3D Graphiksystem
3D RAM
3D RAM
3D RAM
3D RAM
3D RAM
3D RAM
7
7Zwei PC Systeme
In diesem letzten Abschnitt werden den SGI und SUN Maschinen zwei handelsübliche PCSysteme 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.
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 Systemarchitektur 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 Leistung 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 AGPSysteme 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. Verschafft 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 kostensparende 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-MHzTaktes 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 Hauptspeicher abzurufen und über den AGP bereitzustellen. Während eines Schreibzyklus liefert dagegen
die Graphikkomponente die Daten an den Chipsatz, welcher sie anschliessend in den Hauptspeicher 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 tatsä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 Anforderungen 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.
71
dige Mechanismen für ein Cache-Snooping1 nicht implementiert worden. Sollte bei Schreiboperationen 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 Digitaltechnik 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äutert1.
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 ausgeführt werden.
•
64 Bit breiter externer Bus
•
5-stufige 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 Prozessors 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 Graphikberechnungen 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 ContextSwitch zwischen der MMX- zur FP-Verarbeitung notwendig.
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 Hauptspeicher transportiert.
Der MMX Instruktionssatz umfasst insgesamt 57 Instruktionen, welche sich in folgende Gruppen 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 Operationen 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
Abbildung 7.2:
75
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, Windows NT, Windows 95 und OS/2.
Viewperf wurde 1994 in die Standard Performance Evaluation Corporation (SPEC) eingegliedert, 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 Messungen 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
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. Independent Software Vendors) zusammen, um Tests, Datensätze und Gewichte zusammenzustellen, 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 Plattformen 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 Utilities (PBMPLUS).
8.2 Die Viewsets
81
Viewperf ist nicht systemunabhängig. Wenn der Prozessor oder der Bus an seine Leistungsgrenzen 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
∏ (( frames ⁄ sec ond )i)
wi
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:
Wgm – CDRS – 05 = test1
0.50
⋅ test2
0.20
⋅ test3
0.15
⋅ test4
0.08
⋅ test5
0.05
⋅ test6
0.02
⋅ test7
0.00
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 harmonische 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ärker 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 Systemen 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 Graphik 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
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 Graphiksoftwarebranche 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 Anwendungen.
Name
Vendor
Pro
CDRS
Parametric Technology Modeling und Rendering Pro/DESIGNER
(PTC)
Application for ComputerAided Industrial Design
(CAID)
7
DX
Industrial Business Ma- Scientific Data Visualiza- Visualization Data
chines (IBM)
tion and Analysis Package Explorer
10
DRV
Intergraph
10
AWadvs Alias/Wavefront
Light
Description
Based on
3D Computer Model Re- Design Review
view Package for plant design models consisting of
piping, equipment and
structural elements such as
I-beams, HVAC ducting,
and electrical raceways
# of
Tests
Integrated workstation-ba- Advanced Visualizer 10
sed 3D animation system
that offers a comprehensive set of tools for 3D modeling, animation,
rendering, image composition, and video output
Lightscape Technology Radiosity Visualization
Inc.
Application with a physically based lighting interface
Tabelle 8.1: Überblick über die Viewperf 6.1 Viewsets
Lightscape Visualization System
4
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
Pro
CDRS
DX
DRV
AWadvs
Light
Grösse
200’000 3D-Punkte
Schwerpunkte
Wireframe-Darstellung mit geglätteten Linien
Alle Tests im Display List-Modus
texturiert
93’000 3D-Punkte
Dreiecks-Mesh
Wireframe, mit Z-Buffer
150’000 3D-Punkte
Dreiecks-Mesh
gouraud- und flat-shaded
62’000 3D-Punkte
1’100’000 3D-Punkte bzw.
1’800’000 3D-Punkte
texturiert (trilinear gefiltert)
Wireframe, unbeleuchtet, ohne Z-Buffer
farbige Wireframes
gouraud-shaded
keine Texturen
Tabelle 8.2: Grösse und Schwerpunkte der Viewsets
84
8.2.1 ProCDRS - Pro/DESIGNER
Das ProCDRS Viewset ist eine aktuellisierte Version des CDRS1 Viewsets und
steht in der Version 1 zur Verfügung. Es
modelliert die Graphikoperationen von Pro/
DESIGNER, der Industrial Design Software von Parametric Technology.
Das Viewset besteht aus zehn Tests; jeder
repräsentiert einen anderen Operationsmodus von Pro/DESIGNER.
Zwei Tests benutzen ein Wireframe (Drahtgitter) Modell, alle anderen verwenden ein
Shaded (schattiertes) Modell.
Das schattierte Modell ist eine Mixtur von Triangle Strips und Independant Triangles, mit ungefä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 ein 512 × 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 wissenschaftlichen 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 Workstations von Digital Equipment, IBM, Sun, Hewlett-Packard und Silicon Graphics erhältlich.
Die Tests visualisieren ein Set von Partikelverfolgungen 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
86
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 Ölplattformen 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, Komponenten 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 Triangle 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, flatshaded 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
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 Computeranimation, realistische Bildeffekte, Bewegungen für
eine unlimitierte Anzahl von Objekten, Kameras und
Lichtquellen.
Alle Operationen im Advanced Visualizer werden im Bildspeicherbereich mit doppelt gepufferten 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
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.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 Lightscape, ist die Fähigkeit, globale Beleuchtungseffekte zu simulieren. Das System
beinhaltet zwei integrierte Visualisierungskomponenten.
Die erste benutzt die progressive Radiosity Technik und generiert sichtunabhängige Simulationen 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 Visualisierung 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 Beleuchtungs- 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 Building model using smooth-shaded z-buffered quads with colors supplied
per vertex
Tabelle 8.7: Light Tests
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 Freiformkonturen besitzen.
CDRS ist der Vorgänger von ProCDRS. Es wurde aus verschiedensten 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 verfä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
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
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 Kommandozeilenoptionen, welche dem Programm gewisse Parameter mitgeteilt werden. Dazu gehört welcher
Datensatz eingelesen werden soll, welche Texturdatei benutzt werden soll, welche OpenGL Primitiven 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 Sekunden
-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 Prozeduraufrufregeln, welche Instruktionssatz-Architektur (ISA) unterstützt wird und welche Formate 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 Genauigkeit 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 abgestimmt 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
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 Computerverkä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 Graphiksystem bewältigen soll. Das Ziel von GLperf ist es, möglichst grosse Flexibilität in der Leistungsmessung ü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 flexibles 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: john.spitzer@raycer.com
93
94
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 Entwicklung einfach zu machen, führt GLperf nur einfachste syntaktische und semantische Überprü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 Magnification Filter zu GL_LINEAR.
Liste
(TexMinFilter GL_NEAREST
Zwei Tests werden gestartet. Der erste mit
dem Texture Minification Filter
GL_NEAREST, der zweite mit
GL_LINEAR_MIPMAP_LINEAR.
Werden mehrere Listen zusammenverwendet, kann das schnell zu sehr vielen Tests
führen.
GL_LINEAR_MIPMAP_LINEAR)
Bereich
(ObjsPerBeginEnd
from 100 to 10 step -10)
Die Zuweisung setzt einen Bereich für die
Anzahl Objekte, die pro Begin/End Paar
gezeichnet werden. Dieser wird von 100 bis
10 variiert, in abnehmenden Zehnerschritten.
Die Schrittweite ist standardmässig auf 1
eingestellt. Man kann auch in Prozentschritten gehen. (Beispiel: ... from 1 to 256
step 100%: führt zu 1, 2, 4, 8, 16, ...)
Wildcard
(Fog *)
(Fog ALL)
* und ALL sind Wildcards. Sie führen zu einer Reihe von Tests, mit jedem möglichenAttribut. Im angegebenen Fall werden
Tests produziert, in denen der FogMode Parameter zu folgenden Werten gesetzt wird:
Off, GL_LINEAR, GL_EXP, GL_EXP2. Wildcards für numerische Attribute, wie zum
Beispiel Size, sind illegal.
printf
TriangleStripTest {
(UserString printf
(“Triangle Strip: %.0f pixels”, Size))
(Size from 20 to 100 step 20)
}
Die printf Anweisung ist nur für die UserString Eigenschaft zulässig. Die printf Anweisung erlaubt die Ausgabe von Daten,
ähnlich wie in der Programmiersprache C.
Mehrfachzuweisung
DrawPixelsTest {
([ImageWidth ImageHeight]
16 32 64)
}
Mehrfache Zuweisungen ein und desselben
Wertes zu mehreren Eigenschaften sind zulä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 Graphikleistung 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 Codereplikation 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 Kommandos in der Display List werden ausgeführt, während sie compiliert werden. list deletion: (glDeleteLists) die Display List wird gelöscht.
96
Klassenhierarchie und Datenorganisation. Wenn eine Eingabedatei analysiert wird, generiert GLperf ein Objekt. Dieses besteht aus einem Satz von Testobjekten. Die Testklassenhierarchie 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
Property/String
Names
97
Description
Type
Possible
Values
Default Settable
Value
Printed
DrawPixelsWidth Width of DrawPiRanged
Width of Draw Pi- xels Call (width de- Integer
xels
faults to
ImageWidth unless
DrawPixelsWidthist
set, in which case it
sets the subimage
width
[1, 2048]
-1
Yes
Yes
DrawPixelsHeight Height of DrawPiRanged
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
[1, 2048]
-1
Yes
Yes
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 *)
(NormalData PerVertex)
}
// 0-8 Lichtquellen
// 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 Anwendung 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 Geschwindigkeitsmessgerä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.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 2 3 4 5 6 7 8
9 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 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 Operationen.
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, Texturing) 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)
glRasterPos*
Per Vertex
Operations &
Primitive
Assembly
glDrawPixels
Processor
Memory
Rasterization
(fog, texture)
PerFragment
Operations
Frame
Buffer
glReadPixels
glCopyPixels
Abbildung 9.2:
Pixel Datenfluss (glRasterPos* spezifiziert die Position für ein Pixel)
100
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 LookUp Table gespeichert.
Die Breite und Höhe der DrawPixels Bilder (ImageWidth,
ImageHeight) werden von 16 bis 512 erhöht, in 2er PotenzSchritten. (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 durchgeführt, mit dem Unterschied, dass sie im RGB Farbraum ausgeführt werden.
Die Breite und Höhe der DrawPixels Bilder (ImageWidth,
ImageHeight) werden von 16 bis 512 erhöht, in 2er PotenzSchritten. (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
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, flat)
•
Quads (RGB, Z, 3D, flat)
•
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 PerVertex Operationen, also eckpunktbezogene Operationen.
Diese Operationen werden in der Geometry Engine bearbeitet, wenn diese vorhanden ist, andernfalls werden die Berechnungen 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
101
102
9.2.7 LineFill.rgb
LineFill.rgb misst den Einfluss der Linienlänge auf die Renderingleistung 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 3 4 5 6 7 8 9
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 verschiedensten Operationen mit Graphikprimitiven (Linien, Dreiecke, 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 teuersten Operationen für einen 1280 × 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
•
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 Operationen, die nicht von Primitiven abhängig sind, wie zum Beispiel 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)
103
104
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 Operationen.
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 PotenzSchritten. (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 Texturbild, welches auf eine Graphikprimitive gelegt wird.
Die ersten vier Tests beschreiben Download Tests von Texturen aus dem Systemspeicher in den Graphik/Texturspeicher. 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 Primitive 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 4 5 6 7 8 9 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 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
•
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
-p
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.
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 Standard 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.
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 unproblematisch.
Wenn man ein eigenes Skript schreiben will, muss darauf geachtet werden, dass diese Kommandos 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.
Unter IRIX zeigte sich alles problemlos. Manchmal lief die Compilation mit dem gmake Programm 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 Kommandozeilencompiler verwenden kann (das Programm nmake zum Beispiel). Dies geschieht mit einem Batchfile, 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 Standard 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 Leistung 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
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
CINT95 Tests:
Metrik
Erklärung
SPECint95
Das geometrische Mittel von acht normalisierten Laufzeitverhältnissen (eine für jeden Integer Benchmark). Der Benchmark wird aggressiv compiliert.
SPECint_base95
Das geometrische Mittel von acht normalisierten Laufzeitverhältnissen (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ältnissen (eine für jeden Floating-Point Benchmark). Der Benchmark wird
aggressiv compiliert.
SPECfp_base95
Das geometrische Mittel von zehn normalisierten Laufzeitverhältnissen (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öglichen, 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-Referenzzeit und der aktuellen Laufzeit berechnet.
Dabei wurde eine SPARCstation 10/40 (40 MHz SuperSPARC ohne Level 2 Cache) als Referenzmaschine 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 Durchsatzrate 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
Intelligenz
Spielt das “Go” Spiel gegen sich selber.
124.m88ksim 1900
Simulation
Simuliert den Motorola 88100 Prozessor und lässt Dhrystone und ein Memory Test Programm laufen.
126.gcc
Programmierung,
Compilierung
Compiliert einen vorbearbeiteten
Quellcode in optimierten SPARC Assembler 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 Manipulationen durch. (Anagramme/Primzahlenfaktorisierung)
147.vortex
2700
Datenbank
Errichtet und manipuliert drei relationale Datenbanken.
1700
Tabelle 10.3: CINT95 Benchmark
112
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üssigkeitsdynamik, Geometrische Translation
Generiert ein zweidimensionales Koordinatensystem um generelle geometrische
Bereiche.
102.swim
8600
Wettervorhersage
Löst flache Wassergleichungen mit Hilfe
von Approximationen mit finiten Differenzen. (der einzige Benchmark in CFP95
der nur einfache Präzision erfordert)
103.su2cor
1400
Quantenphysik
In der Quark-Gluon Theorie werden Massen von elementaren Teilchen berechnet.
104.hydro2d 2400
Astrophysik
Hydrodynamische Navier-Stokes Gleichungen werden benutzt um galaktische
Strahlen zu berechnen.
107.mgrid
2500
Elektromagnetismus Berechnung eines 3D Potentialfeldes.
110.applu
2200
Flüssigkeitsdynamik, Mathematik
Löst ein Matrix System mit Pivot-Strategien.
125.turb3d
4100
Simulation
Simuliert Turbulenzen in einem kubischen Bereich.
141.apsi
2100
Wettervorhersage
Berechnet Statistiken über Temperaturen
und Schadstoffe in einem Bereich.
145.fpppp
9600
Chemie
Berechnet Ableitungen von Multielektronen
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 Optimierungsflag 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 Standarddatentypgrö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 Empfindlichkeit verändern, indem sie die Floating-Point Operationen mit algebraischen Identitäten umstellen.
Optimierungen sind auf vier Optimierungsflags 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 standardmä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 (Beispiel (147.vortex oder 147)
10.5 Compilieren von CPU95
Das Compilieren des SPEC CPU95-Benchmarks zeigte sich sehr schwierig. Auch nach Rücksprache 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.
Der compilierte Benchmark wurde freundlicherweise vom Institut für Computersysteme zur
Verfügung gestellt.
114
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 Systemleistungsbenchmark, der den Prozessor, die Speicherhierarchie und den Compiler misst. SPEC CPU95 verwendet dazu zwei Teilprogramme, SPEC INT95 und SPEC FP95, mit zehn bzw. acht
115
Programmen, welche die Festkommaeinheit bzw. die Gleitkommaeinheit testen. Für beide Teilprogramme 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
11
11Resultate und Analyse
In diesem Kapitel werden die gesammelten Resultate präsentiert. Soweit es mit den vorhandenen 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ücksichtigt 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 Maschinen 1280 × 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.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
3.0504
2.5242
6.038
0.55544
16.444
2.3902
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
Differenz + 2.39%
- 1.84%
DRV
AWadvs
Light
CDRS
+ 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 Mittelwerte der beiden Tests nicht signifikant unterschiedlich sind.
Auf eine Erklärung des Tests wird hier verzichtet. In [10] sind die Details des Test-For-ZeroMean 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 Unterschied 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
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 Auflösungen
Bei den PC Workstations wurden die Tests in jeweils zwei Auflösungsstufen durchgeführt. Die
erste Zahl entspricht dem Resultat unter 1280 × 1024 Bildpunkten, die zweite Zahl demjenigen
unter 1024 × 768 Bildpunkten. Diese Zahlen sind in Tabelle 11.7 eingetragen. In den Resultatsübersichten sind wiederum nur die Werte mit der Auflösung 1280 × 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 Ausschnitt braucht.
ID
ProCDRS DX
DRV
AWadvs
Light
CDRS
ppro
1280 × 1024
1.926
3.886
2.360
4.801
0.4675
14.92
ppro
1024 × 768
2.006
3.907
2.388
4.823
0.4695
15.20
ptwo 1280 × 1024
5.556
7.619
4.710
10.213
1.010
36.05
ptwo 1024 × 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 angezeigt 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 Bufferaustausch 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 unter 1 ⁄ 60 Sekunde gelöscht und gezeichnet werden können, wird die Animation glatt sein. Oft ist es aber der Fall, dass die Bilder zu kompliziert sind, um in 1 ⁄ 60
Sekunde gezeichnet zu werden, dann wird dasselbe Bild mehr als einmal auf dem Bildschirm
dargestellt. Wenn zum Beispiel ein Bild in 1 ⁄ 45 Sekunde gezeichnet wird, erhält man 30
Bilder pro Sekunde und das Graphiksystem macht 1 ⁄ 30 – 1 ⁄ 45 = 1 ⁄ 90 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.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 PCGraphikbeschleuniger 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 IISystems, 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 TextureMapping 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
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 Wireframe 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. HiddenLine 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 (glEnable(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.2 GLperf
Der GLperf-Benchmark zeichnete sich durch Unzuverlässigkeit aus. Verschiedene Tests stürzten 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ücksichtigt 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 Maschinen 1280 × 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.
Die für diese Arbeit relevanten Zahlen werden durch die folgenden Skripte abgedeckt:
Skript
Beschreibung
Spezielles
TexImage.rgb misst Leistung der
glTexImage2D RGB
Operationen.
nur Display List Modus
500 × 500 Pixel grosse Quads
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 Anzahl Lichtquellen für
das Zeichnen einer Primitive
Immediate und Display List Modus
Triangle Strips und Quads
smooth-shaded, Z-buffered
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 Segmentation 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 Kompilieren 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
Texturgrösse
32 × 32 64 × 64 128 × 128 256 × 256 512 × 512 1024 × 1024 2048 × 2048
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 α
Texturgrösse
32 × 32 64 × 64 128 × 128 256 × 256 512 × 512 1024 × 1024 2048 × 2048
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
Die Ergebnisse dieser Tests sind in Millionen Texture Elements (Texels) pro Sekunde Die Tests
laufen alle im Immediate Modus.
•
Texture Download, RGB, mipmapped
Texturgrösse
32 × 32 64 × 64 128 × 128 256 × 256 512 × 512 1024 × 1024 2048 × 2048
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
Texturgrösse
32 × 32 64 × 64 128 × 128 256 × 256 512 × 512 1024 × 1024 2048 × 2048
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 ist 64 × 64 Pixel gross.
•
Texture Switching (Texture Binding with Display List)
Gezeichnete Primitive zwischen
dem Laden
Keine Primitive
Texurierter Punkt
Texturiertes
Dreieck
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)
dem Laden
Keine Primitive
Texurierter Punkt
Texturiertes
Dreieck
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
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)
dem Laden der
Textur
Keine Primitive
Texurierter Punkt
Texturiertes
Dreieck
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)
dem Laden der
Textur
Keine Primitive
Texurierter Punkt
Texturiertes
Dreieck
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 Texturen wählen (TexImageSrc). Zur Auswahl stehen Display List (TexImageSrc DisplayList) und
Texture Objects (TexImageSrc TexObj). “Display Listed” Texturen werden von den SGI Graphiksubsystemen (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 Funktionalität erlaubt wie in der IRIS GL.
Wenn für die Texture Switching Tests die Verwendungsart der Textur (TexImageSrc) auf “DisplayList” 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
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 Leistung 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 Bedingungen (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
Licht0
quellenanzahl
1
2
3
4
5
6
7
8
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 Infinite 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 Geometry 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 Leistungsunterschied 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 Vergleiche anstellen.
Es zeigt sich, dass dieser Test sehr gut geeignet ist, die Geometry Engines miteinander zu vergleichen.
134
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 Beleuchtungsberechnungen 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 Geometrieberechnungen 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, mit 500 × 500 Pixel grosse Quadraten und im RGB Farbraum. Die Textur ist 64 × 64
Pixel gross und ebenfalls im RGB Farbraum.
Modi
flat
flat,
Z
smooth
smooth,
Z
smooth,
Z,
nearest
smooth,
Z,
linear
smooth,
Z,
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 ZBuffer) 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-Prozessor (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 Maximum Impact System. Doch durch die Möglichkeit noch mehr Raster Manager (vom Typ RM9s)
136
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ücksichtigt 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 Infinite Light
•
Display List, Smooth Shaded, Nearest Texture, 1 Infinite Light
•
Display List, Smooth Shaded, Linear Texture, 1 Infinite Light
•
Display List, Smooth Shaded, Trilinear Texture, 1 Infinite Light
Das Verhalten der ersten vier Tests ist sehr ähnlich. Deshalb wird als Beispiel der Test smoothshaded, Z-buffered, 1 infinite light besprochen. Ebenso sind die texturgefilterten Resultate vergleichbar 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
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 Dreiecksgrö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 Leistung 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 Maximum Impact-Systems. Doch die Resultate zeigen auch deutlich, dass die Raster Engines/Managers 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ücksichtigt 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.
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ücksprache 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.
go
124.
m88
ksim
126.
gcc
129.
compress
130.
li
132.
ijpeg
134.
perl
147.
vortex
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.
tomcatv
102.
swim
103.
su2
cor
104.
107.
110.
hydro mgrid applu
2d
125.
141.
turb3d apsi
145.
146.
fpppp wave5
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
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 Überblick der Systeme zu erhalten.
11.3 SPEC CPU95
Abbildung 11.13: CINT95 Resultate
141
142
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
12
12Schlussworte
Das Ziel dieser Arbeit war einerseits die Beschreibung aller Systeme. Dazu wurde hauptsächlich 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 Evaluation 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 Transformationen immer noch vom Hauptprozessor ausgeführt.
Die sgi Maschinen zeigten ein homogenes Verhalten über alle Tests, welche zu guten Graphikleistungen 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 Leistungsvergleiche sehr schnell möglich werden.
Die “harte” Arbeit ist getan, der Aufwand neue Messungen durchzuführen ist klein. Davon profitieren 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änglichen 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 Christian 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.
prod11.html.
[4]
Industrial Business Machines (IBM). Data Explorer. Homepage under http://www.hursley.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.
AccelGalaxy.
Homepage
under
http://www.es.com/wg/
[10] Rai Jain. The Art Of Computer Systems Performance Analysis: Techniques for Experimental 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. Homepage 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 preprocessed 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 Primitiven in OpenGl gemeint ist, hier ein graphischer Überblick.
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 <file>
Viewpoint object to be used in the tests
-triangle -tr <file>
-quad -qd <file>
-mesh -mh <file>
Mesh object to be used in the tests
-rendermode -rm <mode>
POINT, VECTOR, LINE, POLYGON, TMESH, TFAN, TRIANGLE, or
QUAD
- default LINE
-vcriteria -vcrit
AUX Visual selection criteria - EXACT, MIN
- default MIN
-vid <id>
Ask AUX for visual with ID = <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 <mode>
FRAME = Color per Frame, PRIMITIVE = Color per Primitive, VERTEX
= Color per Vertex
- default FRAME
-texture -tx <file>
Image for texturing
-texgen -txg <file><mode>
<file> is image for enviroment mapping <mode> is SPHERE_MAP,
OBJECT_LINEAR, EYE_LINEAR
- default EYE_LINEAR
-texobj -txo <file>
Texture object mode <file> is list of images
-magfilter -magf <flt>
NEAREST, LINEAR
- default NEAREST
152
A. Anhang
-minfilter -minf <flt>
NEAREST,
LINEAR,
LINEAR_MIPMAP_NEAREST,
LINEAR_MIPMAP_LINEAR
NEAREST_MIPMAP_NEAREST,
NEAREST_MIPMAP_LINEAR,
- default NEAREST
-texenv -te <env>
Texture enviroment, MODULATE, DECAL, BLEND
- default DECAL
-texcomp -tc <num>
Texture components where <num> 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 <width>
Linewidth for wire/vector tests
- default 1.0
-xwinsize -xws <side>
Size of test windows X dimension
- default 700
-ywinsize -yws <side>
Size of test windows Y dimension
- default 700
-numframes -nf <num>
Number of frames to be rendered during measurement. Takes priority over
-mp
-numilights -nil <num>
Turns on <num> infinite lights
- default 0
-numllights -nll <num>
Turns on <num> local lights
- default 0
-colormaterial -cm <side> <mode> <side> is FRONT, BACK, FRONT_AND_BACK
- default FRONT
<mode> is AMBIENT,
AMBIENT_AND_DIFFUSE
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
EMISSION,
SPECULAR,
A.2 Viewperf
153
-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, VECTOR, 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 <num>
Set minimum testing period in seconds
-mblur <num>
Use motion blur with num being amount of decay
-aa_multi <x> <r>
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 <trü/false>
Force byte swapping
-notitle -nt
Disable title screen
-startframe -sf <num>
Set starting frame of a walkthru
-framepause -fp
Pause after each frame waiting for enter key
-newview -nv
Enable new view frustum calculation
-fov <angle>
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_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 Graphikkarten 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 Bildwiederholfrequenz. 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 AccelGalaxy 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 Texture-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 Bildwiederholfrequenz. 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 Rasterization 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ützten Funktionen ist lang und beinhaltet
unter anderem folgende Punkte: bi- und
trilinear gefiltertes Texture-Mapping,
Gouraud-Shading, Anti-Alasing, AlphaBlending und 24-bit Z-Buffering. Optimierte Open GL-Treiber sind bis jetzt nur
für Windows NT verfügbar. Die Intergraph-Karte kostet ca. $3000.
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 Pentium 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 Flaschenhals in traditionellen PC-basierten Systemen eliminiert, bieten die Visual Workstations
einen enormen Durchsatz, welcher von High-End Computer Graphik und Multimedia-Bearbeitung (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 Workstations eine unglaubliche 2D-, 3D- und Digital-Media-Leistung, welche kein anderes Windows 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 AccelGalaxy 52 $4600.
160
B. Weitere Tests
Abbildung 13.1:
Die sgi Integrated Visual Computing (IVC) Architektur im Vergleich zur herkömmlichen PC Architektur
B.3 Resultate und Analyse
161
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
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
Abbildung 13.9:
165
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.

perf - Institut for Computer Systems

Transcription

Similar documents

Stoffkennwerte - Universität der Bundeswehr München

Rasterung

Grundzüge von Unix

SiS Newest AMD K7 Solution SiS Newest AMD K7 Solution

VIRTUAL REALITY VIRTUAL REALITY Gliederung

Qualip: Software-Suite für die Qualitätskontrolle eines Linux-PCs

chipsätze - Bodri.de

Schwedisches Fernsehen SVT

Entwicklung von Computerspielen

ATI Radeon HD 4800 Series (Microsoft Corporation