ATi's R300 VPU
Die Gerüchteküche brodelte wie
jedesmal vor dem Release eines neuen VPU's.
Sei 3dlabs ihren P10 vorstellten nennt man
die Chips VPU's (Visual Processing Unit)
und wendet sich daher vom alten GPU (Graphics
Processing Unit) ab - Marketing... Am 18.
Juli 2002 stellte ATi dann endlich den R300
VPU vor, welcher auf den Radeon 9500 / 9500
PRO / 9700 und 9700 PRO Karten Verwendung
findet. Auf den 9500'er PRO Karten wurde
jedoch das Speicherinterface reduziert und
auf der Radeon 9500 zusätzlich noch
4 Pipelines weggelassen. Der R300 ist der
erste DirectX 9 fähige VPU, was bedeutet,
dass er min. neue Pixel und Vertex Shader
besitzt, welche mit höherer Genauigkeit
rechnen und wesentlich komplexere Programme
verarbeiten können. Natürlich wurde
die R300 auch in anderen Bereichen gegenüber
dem R200 verbessert. Vorallem das Ani-Aliasing,
welches auf dem R200 fast nicht nutzbar war,
wurde ordentlich verbessert. Trotz des ähnlichen
Fertigunsverfahrens (0,15µ) von R200
und R300 ist eine höhere Taktung des
R300 möglich. Doch schauen wir uns die
Details nun genauer an.
Baugruppen des R300 VPU's
Hier die technischen Daten im Überblick:
| SiS Xabre | Matrox Parhelia 512 | NVIDIA GeForce 4 Ti | NVIDIA GeForce FX | ATi Radeon 8500 | ATi Radeon 9000 PRO | ATi Radeon 9700 PRO | |
| Pixel Pipelines | 4 | 4 | 4 | 8 | 4 | 4 | 8 |
| Shader Einheiten (pro Pipeline) | 2 | 4 | 2 | 1 | 2 | 1 | 1 |
|
Vertex Pipelines
|
1(feste TnL) | 4 | 2 | 1(FP-Array) | 2(VS + feste TnL) | 1 | 4 |
| max. Texturen pro Pixel | 4 | 4 | 4 | 16 | 6 | 6 | 16 |
| Chiptakt (MHz) | 183 - 300 | 220 | 275 - 300 | 500 | 275 | 275 | 325 |
| theo. max. Füllrate (GPixel/Sec) | 0,732 - 1,2 | 0,88 | 1,1 - 1,2 | 4 | 1,1 | 1,1 | 2,6 |
| theo. max. Füllrate (GTexel/Sec) | 1,464 - 2,4 | 3,52 | 2,2 - 2,4 | 4 | 2,2 | 1,1 | 2,6 |
| Speicherinterface (Bit) | 128 DDR | 256 DDR | 128 DDR | 128 DDR | 128 DDR | 128 DDR | 256 DDR / DDR II |
| Speichertakt (MHz) | 175 - 275 | 275 | 250 - 325 | 500 | 275 | 275 | 310 |
| Speicherbandbreite (GB/Sec) | 5,86 - 8,8 | 17,6 | 8 - 10,4 | 16 | 8,8 | 8,8 | 19,84 |
| Texelbandbreite (Bytes / Texel) | 4,00 - 3,6 | 5,00 | 3,64 - 4,3 | 4 | 4,4 | 8,8 | 7,6 |
| Pixelbandbreite (Bytes / Pixel) | 8,00 - 7,33 | 20,0 | 7,27 - 8,6 | 4 | 8,8 | 8,8 | 7,6 |
| hochauflösender Framebuffer (10:10:10:2) |
nein | ja | nein | ja | nein | nein | ja |
| DirectX Version (Pixel / Vertex Shader) |
DX 8 .1 (1.3 / 1.1 per CPU) |
DX 8 / 9 (teilweise) (1.3 / 2.0) |
DX 8.1 (1.3 / 1.1) |
DX 9 (2.0 Ext. / 2.0 Ext.) |
DX 8.1 (1.4 / 1.1) |
DX 8.1 (1.4 / 1.1) |
DX 9 (2.0 / 2.0) |
| Displacement Mapping | nein | ja (Sampled DM) | nein | nein | nein | nein | ja (Presampled DM) |
| Rendergenauigkeit | min. 36 | min. 40 | 36 | 128 | 48 | 48 | 96 |
| max. anisotrophisches Filtern bilinear / trilinear |
0 / nein | 2(16) / 2(8) Bisher durch Treiber limitiert! |
8 / 8 | 8 / 8 | 16 / 16 | 16 / 16 | 16 / 16 |
| HOS Einheit (RT-Patches/N-Patches) adaptive Tesselation |
nein | DM ja |
RT-Patches(nur OpenGL) ja |
nein nein |
ja (N-Patches) nein |
ja (N-Patches) nein |
ja (N-Patches) ja |
| Bandbreiten Features | keine | keine | Texturekompression, Lightspeed Architektur II, QuadCache, Fast-Z Clear |
Texturekompression, Intellisample Technologie |
Texturekompression, HyperZ II |
Texturekompression, HyperZ II |
Texturekompression, HyperZ III |
| FSAA Arten | Standard (Multi-Sampling) |
Standard (Multi-Sampling) 16x FAA (Fragment Anti-Aliasing) |
Standard, Quincunx, Accuview (Multi-Sampling) |
Standard, Quincunx, Accuview (Multi/Super-Sampling) |
adaptives FSAA (Super-Sampling) |
adaptives FSAA (Super-Sampling) |
adaptives FSAA (Multi-Sampling) |
| Multi-Monitor Betrieb | ja | ja | ja | ja | ja | ja | ja |
Daten von zukünftigen Produkten unterliegen bis zum Releasetermin ständigen Änderungen! Notebook- / Laptop- / Integrierte-Varianten von einigen Chips wurden nicht mit aufgeführt So wird in der Tabelle gerechnet:
- GB/s = (275 Mhz *2(DDR) *128 Bit / 8 Bit) / 1000 = 8,8 GB/s -> Hersteller Weg
- so nicht: GB/s = (275 Mhz *2(DDR) *128 Bit / 8 Bit) / 1024 = 8,59 GB/s
- so auch nicht: GB/s = (275000000 Mhz *2(DDR) *128 Bit / 8 Bit) / (1024*1024*1024) = 8,19 GB/s realer Wert!
Was ist wirklich neu/verbessert gegenüber dem R200 (Radeon 8500)?
- DirectX 9 Support
- 4 Vertex Shader (DX9 Verson 2.0)
- 8 Pixel Pipelines (DX9 Verson 2.0)
- Displacement Mapping
- 256 Bit Speicherinterface
- 4 Render Targets
- SmoothVision 2.0
- Truform 2.0
- HyperZ III
- verlustfreie Kompression der Farbwerte
- Fast Color Clear
- Videoshader
- Fullstream
- AGP 3.0 (AGP 8x)
Features im Detail
DirectX 9.0 Support
Hier wird bereits deutlich, dass der Sprung (vorallem bei den tech. Spezifikationen, weniger bei den Features) von DirectX 8 zu DirectX 9 recht groß ist, wobei hier vorallem die visuelle Qualität eine entscheidente Rollen spielen wird. Hier noch ein paar Beispiele der neuen DirectX 9 Technologien, weitere Details zu DirectX 9 werden in einem anderen Artikel folgen!
Schattenberechnung, Oberflächeneigenschaften und Motion Blur per Vertex und Pixel Shader
High Dynamic Range - durch die Erhöhung der Rechengenauigkeit werden solche Szenen erst möglich.
Mittels neuer Textureformate (höhere Bitanzahl pro Farbkanal) steigt die visuelle Qualität.
Der direkte Vergleich.
Vertex Shader
Nicht nur die Anzahl der Vertex Shader wurde erhöht,
sondern auch die Funktionalität. So bieten die neuen Vertex Shader 2.0 nun eine statische Flußsteuerung und können größere Programme verarbeiten.
Die reine Vertex Shader Leistung wurde gegnüber den R200 also deutlich verbessert, was sich noch dramatischer auswirken könnte, wenn die Vertex Shader Programme komplexer werden. 3D-Mark's Vertex Shader Test scheint nicht wirklich den Vertex Shader auszulasten, da eine Erhöhung der Taktrate nichts brachte. Die Angaben von ATi's Marketingabteilung konnte ich nicht erreichen 325 Mio. Tri/s vs. 106 Mio Tri/s.
Pixel Shader
Die Pixel Pipelines wurden gegebüber dem R200 von 4x2 auf 8x1 umgestellt. Jede Pipeline besitzt eine Shader Einheit.
Hier sieht man die eigentlichen Neuerungen. Die Pixel Shader Einheiten abreiteten seit DirectX 9 mit Fließkomma-Zahlen und natürlich werden auch dementsprechende Textureformante unterstützt.
| min. nötig für für DirectX 9 (pro Kanal, also RGBA) | ATi's R300 | NVIDIA's NV30 | |
| Farb- und Alphadaten | 16 Bit FP | 24 Bit FP | 32 Bit FP |
| andere Daten | 27 Bit FP | 32 Bit FP | 32 Bit FP |
Hier sieht man gut, wenn die Pixel Shader Programme aufwendiger werden wird der Abstand zwischen dem R300 und dem R200 größer, natürlich spielt hier auch die enorem Bandbreite des R300 eine große Rolle.
Truform 2.0
Truform aka. N-Patches nennt man eine Methode, welche mit Hilfe der Eckpunktnormalen aus einem flachen Dreieck eine gebogene Fläche macht. Neu an Truform 2.0 ist nun die Möglichkeit den Auflösungsgrad (Tessellation) stufenlos zu wählen. Bei dem R200 konnte man nur zwischen festen Werten (1, 2, 3, ...) wählen. Hierdurch kann die Polygonanzahl viel feiner verändert werden.
Gut zu sehen, wie sich die Polygonanzahl je nach Betrachtungsabstand verändert.
Displacement Mapping
Displacement Mapping kann je nach Art mit stufenloser Tessellation arbeiten. Es erzeugt durch die Interpretation einer Texture verschiedene Eckpunktpositionen/Eckpunktverschiebungen. Wie man oben im Beispiel gut sehen kann, stellt jeder Farbwert eine Höhenstufe dar. Somit lassen sich wunderbare Effekte erzeugen. Unter DX9 gibt es zwei unterschiedliche Methoden, eine arbeitet mit "Preimaged" Texturen, die andere mit adaptiver Tessellation also "Sampled". Der R300 beherscht leider nur "Preimaged" DM, wobei jeder Eckpunkt einer Flächen eine Texturekoordinate zugewiesen wird. Adaptive Tessellation, etwa für Landschaften ist so nicht möglich, denn dort werden Eckpunkte dynamisch erzeugt und dann die Texturekoordinaten zugewiesen. "Sampled" DM nach DX9 kann zur Zeit nur die Matrox Parhelia, es ist jedoch mit den Vertex Shadern nachbildbar. Über die Performance einer solchen Lösung kann jedoch momentan keinerlei Aussage getroffen werden. Der Geforce FX hat keinerlei Unterstützung für DM laut DX9, aber auch hier kann "Sampled" DM mittels der Vertex Shader erzeugt werden. Somit bleibt abzuwarten, ob dieses Feature zu DX9 Lebzeiten überhaupt eingesetzt wird.
Man kann z.B. einem Reifen ein Profil verleihen, welches wirklich auf Polygonbasis passiert und nicht wie bei Bump-Mapping nur auf rein optischer Täuschung durch Licht und Schatten. Somit lassen sich aus relativ simplen Polygonmodellen komplexe Polygonmodelle erzeugen (nur bei echtem "Sampled" DM), welche Bandbreite des AGP-Bus sparen!
Speicherinterface
Gegenüber dem R200 wurde ein sogenantes Crossbar Speicherinterface eingesetz, was nichts anderes bedeutet, als dass das Interface in vier kleinere unterteilt wurde (welche miteinander kommunizieren), da sonst pro Speicherzugriff min. 256 Bit (32 Byte) hätten übertragen werden müssen, auch wenn man nur 1 Byte benötigt hätte. Jetzt sind es min. 64 Bit (8 Byte) also genau ein Viertel. Die Gesamtbreite des Speicherinterface wurde gegenüber dem R200 von 128 Bit auf 256 Bit verdoppelt. Somit hat der R300 (bei gleichschnell getakteten RAM) die doppelte Bandbreite zur Verfügung und Bandbreite kann eine VPU (fast) nie genug bekommen ;)
HyperZ III
Unter HyperZ III werden verschiedene Technologien zusammengefasst, welche für Bandbreiteneinsparungen zuständig sind. Daran kann man sehen, wie wichtig genügend Speicherbandbreite für eine VPU sind.
Der erste Teil von HyperZ III dient dierekt zur Entlastung des Speicherinterface. Hierbei werden Z-Daten vor dem Schreiben in Z-Buffer komprimiert. Somit können sie später wieder komprimiert gelesen werden, was Bandbreite spart. Theoretisch entsteht dadurch auch eine Speicherplatzeinsparung, da es sich jedoch um eine verlustfreie Kompression handelt, können keine Vorhersagen über den Komprimierungsgrad getroffen werden, deshalb muss die Karte immer vom schlechtesten Fall ausgehen, welcher bedeutet, dass keine Komprimierung möglich ist. Dieses Verfahren wurde mit jeder HyperZ Version weiter optimiert und verbessert, sprich die Anzahl der Pixel, welche getestet werden können und der Kompressionsgrad wurden erhöht. Neben der Z-Kompression verwendet der R300 ein ähliches Verfahren für die Farbdatenkompression, welches jedoch nur bei aktiviertem FSAA wirksam wird.
Hierarchical Z unterteilt den Z-Buffer in große Blöcke, welche dann jeweils getestet werden. Hier soll z.B. das blaue Dreieck gezeichnet werden. Das orange Dreieck ist aber schon vorhanden und liegt näher am Betrachter. Als erstes werden die großen schwarzen Blöcke gestestet. Der Block mit dem roten Kreuz kann danach verworfen werden, da das orange Polygon das blaue an dieser Stelle vollständig überdeckt. Dies wird nun bei jedem weitern Block ebenfalls gestestet und danach werden die noch vorhandenen Blöcke verkleinert und der Vorgang startet erneut, solange bis keine Blöcke mehr da sind, oder die Blockgröße einen Minimalwert erreicht hat.
Danach folgt der Early Z Test (früher Z Vergleich) welchen es beim R200 noch nicht gab. Hier findet nun der vergleich der Pixel Z-Daten mit dem Z-Buffer statt. Der name "Early Z Test" hat folgenden Grund:
Beim R200 gab es noch keinen "Early Z Test", somit mussten die Pixel erst durch den Pixel Shader und wurden dann entweder gezeichnet oder verworfen, je nach Z Wert. Je komplexer die Pixel Shader Programme werden, desto mehr Arbeit wird also umsonst erledigt, wenn der Pixel später verworfen wird.
Der R300 führt den Z Test nun vor dem Pixel Shader aus und vermeidet somit unnötige Arbeiten. NVIDIA's GeForce 3 und 4 besitzen dieses Feature bereits.
Das letzt Feature von HyperZ III nennt man Fast Z Clear. Hierbei wird der Z Buffer 64 mal schneller gelöscht, als wenn man jeden Pixel einzeln löschen würde. Auch dies ist seit der GeForce 4 bei NVIDIA zu finden. Dieses Feature (Fast Color Clear) gibt es natürlich auch für den Backbuffer in welchem die Farberte abgelegt werden.
AGP 3.0
Zu AGP 3.0 (AGP 8x) kann man eigentlich nicht viel sagen. Die Transferrate vom Hauptspeicher zur VPU wurde erhöht. Ich halte dieses Feature bei Spielen für relativ nutzlos. Deutlich ist zu sehen, dass die AGP Geschwindigkeit nur auf synth. Benchmarks Einfluß hat. Hier wurden dynamische Vertexbuffer verwendet. Bei Spielen kommen diese jedoch seltener als statische zum Einsatz, da statische Vertexbuffer direkt im Speicher der Grafikkarte abgelegt werden können und nicht für jedes Frame neu über den AGP-Bus geholt werden müssen. Mit AGP 8x dürften dann bei dynamischen Vertexbuffern um die 70 Mio. Tri/s erreicht werden. Ein Eckpunkt war bei diesem Test 32 Byte groß (XYZ, Normalen und Texturekoordinaten). Anzumerken bleibt noch, dass kaum ein Spiel mehr als 20 Mio. Tri/s berechnet. Hier ist der Codecreatures Benchmark die bisher fordernste "Anwendung".
Smoothvision 2.0
FSAA
Smoothvision 1.0 der Radeon 8500 verwendete den Super-Sampling Algorithmus, welcher Texturen und Kanten glättet, jedoch bei 4xFSAA die vierfache Füllrate und Bandbreite benötigte. Daher war FSAA auf der Radeon 8500 kaum nutzbar, zumindest nicht bei modernen Spielen.
Super-Sampling benötigt bei 4xFSAA 4 Texturewerte und 4 Z-Werte, dafür werden aber auch die Texturen gefiltert.
Multi-Sampling benötigt bei 4xFSAA nur einen Texturewert und 4 Z-Werte, es werden keine Texturen gefiltert. Dadurch wird genau die gleiche Füllrate wie ohne FSAA benötigt.
Smoothvision 2.0 arbeitet mit einem rotierten+ungleichmäßigen (jittered) Samplingmuster, welches Kannten deutlich besser filtert als ein einfaches gleichmäßig angeordnetes. Angeblich verwendet Smoothvison 2.0 in manchen Situation auch Super-Sampling, jedoch konnte ich dies in Tests nicht bestätigen. Als weitere Verbesserung hat ATi die verlustfreie Kompression der Farbdaten eingebaut, welche genau wie die Z-Daten Kompression gerade bei FSAA enorme Bandbreiteneinsparungen bewirkt. NVIDIA's kürzlich vorgesteller NV30 bietet dieses Feature übringens auch. Ein weiteres Feature, welches auch der NV30 besitzt, ist die Gammakorrektur der AA Samples. Dies war bisher kaum möglich, da die VPU's intern nicht mit Fließkomma Farbwerten arbeiteten. Seit DirectX 9 gibt es jedoch die Möglichkeit innerhalb der VPU in einem linearen Gammaraum zu arbeiten.
Anisotropic Filtering
Der aniso. Filter wurde weiter verbessert und ist nun auch zu trilinearem Filtern in der Lage. Es gibt zweit Stufen, Leitung(bilinear) und Qualität(trilinear), jedoch ist er noch nicht ganz auf NVIDIA GeForce3/4 Niveau.
Videoshader / Fullstream
Mittels der Videoshader werden Videos gefiltert, was gerade bei der Halbzeilenwiedergabe(TV-Bilder) enorme Qualitätssprünge zeigt. Bisher wurden diese Aufgaben von speziellen Hardwareeinheiten erledigt, doch die neuen Pixel Shader sind mittlerweile so leistungsfähig, dass diese nun für jene Aufgaben verwendet werden. Fullstream bezeichnet eine Technik, welche grobe Videos, welche z.B. von einem Livestream stammen deutlich verbessern sollen. Ganz so deutlich wie hier zu sehen dürfte der Qualitätssprung allerdings nicht werden, denn wo nichts ist, da kann auch ein Pixel Shader keine Details mehr finden!
