DirectX - von den Anfängen bis zur Gegenwart (III) - Seite 2

Quelle: hem.passagen.se ÜBERBELICHTET Eine höhere interne Rendering-Genauigkeit erlaubt bessere Lichteffekte:.32 –Bit-Rendering (links) respektive 48-Bit-Rendering (rechts) auf einer Radeon 8500 unter OpenGL Blendendes Licht
Mit einer höheren Rendergenauigkeit ließen sich künftig Effekte von Lichtquellen darstellen, die dem Spieler den Eindruck vermitteln, er werde von der Helligkeit geblendet ("Overbright Lighting"). Szenen unter dem Einfluss greller Sonneneinstrahlung könnten damit realistischer dargestellt werden. Bei der Berechnung solcher Effekte müssen die Einflüsse mehrerer heller Lichtquellen kombiniert werden und es fallen Farbwerte an, die in den heutigen, 32-bittigen Farbraum nicht hineinpassen. Konkret müssten Zwischenresultate gespeichert werden, welche die Farbe "weißer sind als weiß" beinhalten. Zwar lässt sich auf dem Monitor keine Farbe darstellen, die "weißer als weiß" (Wert = 1) ist, doch für Zwischenberechnungen sind solche Farbwerte sehr nützlich und vereinfachen zudem die Programmierung von Shader-Effekten.

Der Radeon 8500 bietet bereits eine erste spürbare Verbesserung der internen Rechengenauigkeit. Die einzelnen Farbanteile können dort Werte von -8 bis 8 annehmen. Dies entspricht einer internen Rechengenauigkeit von 12 Bit pro Farbkanal oder insgesamt 48 Bit. Geforce- oder Voodoo5-Boards können hier mit 36 Bit respektive 40 Bit interner Rechengenauigkeit nicht mehr mithalten. Genutzt werden kann die höhere Präzision des Radeon 8500 jedoch nur unter OpenGL mit ATI-eigenen Schnittstellenerweiterungen. DirectX 9 will hier plattformübergreifende Zugriffsmöglichkeiten schaffen. Zur Diskussion steht eine Genauigkeitserweiterung auf64 Bit (16 Bit pro Farbanteil, 65.536 Farbanteilsabstufungen, mehrere Milliarden Farben).

Die Erhöhung der chipinternen Genauigkeit bringt für den Spieler keinerlei negativen Nebenwirkungen mit sich. Allerdings sind größere interne Speicherplätze und breitere Datenpfade notwendig, die mehr Siliziumfläche belegen und die Herstellung der Grafikchips verteuern. Erwarten Sie daher keine DirectX-9-Karten zum Schnäppchenpreis. Zum Verständnis: Ein Grafikchip mit 64 Bit interner Farbgenauigkeit arbeitet grundsätzlich nicht langsamer als einer mit nur 36-Bit-Rechengenauigkeit, da die Farbwerte der fertig berechneten Pixel wie bisher mit 32-Bit-Genauigkeit im Grafikkartenspeicher abgelegt werden können.

Ati-Techdemo zur Radeon 9700: (HDR-) Rendering with Natural Light

Quelle: http://www.pcgameshardware.de Geforce FX 5800 Ultra von MSI. Leistungsabfall vorprogrammiert
Sobald die Farbwerte der fertig berechneten Pixel mit 64-Bit-Genauigkeit im Grafikkartenspeicher (Framebuffer) abgelegt werden, verdoppelt sich die Anforderung an die Speicher-Transportkapazität ("Bandbreite") gegenüber 32-Bit-Rendering. Bereits heute zeigen selbst schnelle 3D-Renner Leistungsverluste, sobald die Bildpunkte im letzten Rendering-Schritt nicht auf 16 Bit heruntergerechnet werden ("Dithering"). Moderne Actionspiele wie Aquanox oder Comanche 4 würden daher selbst mit dem neuesten Geforce4-Ti-Beschleuniger an der 64-Bit-Datenflut ersticken, Bildwiederholraten im nicht spielbaren Bereich von 10-20 fps wären vorprogrammiert. Erst bei Beschleunigern ab rund 12 GB/s Transportkapazität bewältigen die Datenmassen hinreichend schnell (siehe Abschnitt: "So viel Transportkapazität erfordert externes 64-Bit-Rendering" ).

Die Vorteile eines 64 Bit genauen externen Farbspeichers bleiben daher vorerst gering. Erst wenn häufig spezielle Transparenz-Effekte ("Blending") zum Einsatz kommen, welche auf die bereits im Speicher abgelegten Pixelwerte zurückgreifen müssen, machen sich optische Unterschiede zwischen einem 32-bittigen und einem 64-bittigen Farbspeicher bemerkbar. Angesichts der steigenden Anzahl möglicher Texturzugriffe pro Pixelberechnung (heutige Chips bis zu sechs, künftig acht) sinkt die Bedeutung eines genauen Farbspeicher vorerst. Es werden noch Jahre vergehen, bis Spiele-Engines mit derartigen Anforderungen etabliert sind.

So viel Transportkapazität erfordert externes 64-Bit-Rendering.
Unsere Annahmen beziehen sich auf ein künftiges Spiel bei einer eingestellten Auflösung von 1.024x768x64bit mit trilinearem Texturfiltering. Der Overdraw, also die Anzahl der Mehrfachberechnungen eines Pixels, wird mit vier angenommen, pro Pixel sollen vier 32-Bit-Texturen in die Berechnung einfließen. Dank speziellen Techniken in modernen 3D-Chips reduziert sich der effektive Overdraw um 40 Prozent auf einen Wert von 2,4. Für realistische 60 Bilder pro Sekunde müssten die Speicherbausteine folgende Speicherkapazität zur Verfügung stellen (Berechnungsdetails in PCGH 04/2001, S. 117):

Texturspeicherbandbreite: 5,4 GB/s
Tiefenspeicherbandbreite: 1,1 GB/s
Bildspeicherbandbreite: 4,4 GB/s
Geometriebandbreite: 0,5 GB/s.
-------------------------------------------------
= Total: 11,4 GB/s

Transportkapazitäten dieser Größenordnung wird erst mit 400 MHz (800 MHz effektiv) schnellem 128-Bit-DDR-Speicher oder eingebettetem Speicher (E-DRAM) zur Verfügung gestellt. Nicht mit berücksichtigt in dieser Bandbreitenrechnung sind Optik-verbessernde Effekte wie Full Scene Anti Aliasing oder anisotropische Texturfilter.

Quelle: http://www.pcgameshardware.de UMFASSEND OpenGL 2.0 bietet ein einheitliches Konzept für Vertex- und Pixel-Shader (hier Fragment Processor genannt).
Die Alternative: OpenGL
Während Direct3D den Technikvorsprung weiter ausbaut, tritt man in der für die OpenGL-Weiterentwicklung zuständigen Kommission (ARB, "Architecture Review Board") weiter auf der Stelle. Marktführer und vorübergehendes ARB-Mitglied Nvidia stellte sich bei der letzten Verhandlung um die Verabschiedung eines DirectX-8.1-ähnlichen Shader-Standards für das kommende OpenGL 1.4 weiterhin quer. Die Kalifornier pochen auf die Patentrechte ("Intellectual Property") der eigenen Shader-Technologie. Der Standardisierungsversuch eines von Apple vorgestellten Standards schlug daher trotz der Zustimmung von Ati, PowerVR und Matrox fehl. Wegen der fehlenden Standardisierung versinkt OpenGL derzeit in einer Fülle neuer und nicht universell nutzbaren Erweiterungen. Allein Nvidia definiert über 70 eigene und nicht standardisierte Zugriffsfunktionen, die von anderen Chipherstellern nicht ohne Lizenzierung genutzt werden dürfen. Insgesamt sorgen 230 herstellerspezifische Erweiterungen für Verwirrung. So kommt es, dass Spieleentwickler derzeit mehrere verschiedene "proprietäre" OpenGL-Erweiterungen unterstützen müssten, wenn sie auf die programmierbaren Shader-Einheiten oder andere Spezialeinheiten der Grafikchips zugreifen sollen. Ein unhaltbarer Zustand.

Hollywood auf der Spur
Angesichts der Querelen zwischen Ati und Nvidia ergriff der neutrale Außenseiter 3D Labs (bekannt für teure OpenGL-Beschleuniger im Profi-Segment) das Zepter und riss die Entwicklung einer umfassenden Shader-Hochsprache für OpenGL 2.0 an sich. Der erste Entwurf ist bereits sehr vielversprechend. Das ambitionierte Vorhaben zielt von Beginn weg auf eine umfassende, durchdachte und leicht zu erlernende Hochsprache. Sowohl Texturzugriffs-, Pixel-, Eckpunkt- wie auch Nebelberechnungen sollen mit denselben Befehlen programmierbar sein. Ein neues Konzept zur Verwaltung von Texturen, ein flexibler Zugriff auf den Bildspeicher und generell bessere Kontrolle über die verschiedenen Datenspeicher moderner Grafikhardware runden die geplanten Neuerungen für OpenGL 2.0 ab. Interessanterweise werden auch speziell die Bedürfnisse von Spielern berücksichtigt, die Entwicklerschmieden Epic und id Software wirken aktiv am Standard mit. Konzepte zur Einsparung unnötiger Datentransporte (beispielsweise durch Caching von Dreiecksdaten auf der Grafikkarte) fließen in den Standard ein.

OpenGL 2.0 soll vorerst abwärtskompatibel zur aktuellen Version 1.3 bleiben, die neuen Funktionen der Version 2.0 sollen sich mit alten Kommandos mischen lassen. In einem zweiten Schritt ist jedoch ein "Pure OpenGL 2.0"-Modus eingeplant, eine schlanke (und daher sehr schnelle) Zwischenschicht mit rein programmierbaren Zugriffsfunktionen. Mit OpenGL 2.0 werden die PC-Spieleentwickler letztendlich mit einem ähnlichen Programmierkonzept ausgerüstet wie die Effekte-Künstler der Hollywood-Welt. Mit vergleichbaren Programmiersprachen wie "Renderman" wurden dort Spezialeffekte für Blockbuster wie "Phantom Menace" oder "Matrix" entwickelt. Geforce3-, Geforce4- und Radeon 8500-Karten werden jedoch am Versuch scheitern, Shader-Programme gemäß OpenGL-2.0-Rezeptur in Hardware auszuführen. Zum geplanten Veröffentlichungstermin von OpenGL 2.0 im ersten Quartal 2003 sollten jedoch die ersten OpenGL-2.0-kompatiblen 3D-Boards das Licht der Welt erblicken.

X-Faktor
Zweifellos, 64-Bit-Rendering, einheitliche Standards sowie flexiblere und mächtigere Shader dürften bei den Spieleentwicklern Gefallen finden. Die neuen Techniken vereinfachen die Entwicklung von Spezial- und besseren Lichteffekten. Doch erwarten Sie keine Wunder. Bis die neuen Konzepte in der Entwicklergemeinde Fuß fassen, wird noch einige Zeit verstreichen. Angesichts der Nähe zur Xbox-Hardware und der allgemein behäbigen Softwareentwicklung dürfte sich der aktuelle DirectX-8-Standard durchaus etwas länger halten können. Nvidia und Ati werden sich für ihre Chips der nächsten Generation (NV30 bzw. R200) daher noch etwas mehr einfallen lassen, um die Spieler zum Aufrüsten zu bewegen.
--

Zum Abschluss gibt es noch die zeitliche Entwicklung der einzelnen DirectX-Versionen in der Kurzfassung. Wie sie bereits erahnen, beschäftigt sich der folgende Teil der Reihe mit der Einführung der 2.0-Shader unter DirectX 9.

Die Zeitlinie im Überblick:

• 1994, Weihnachten: Die ersten Codezeilen werden von Craig Eisler, Alex St. John und Eric Engstrom geschrieben
• 1995, April: Die DirectX 1 Beta steht rechtzeitig zur CGDC zur Verfügung, eine Ati Mach 64 ist der erste "DirectX-Chip"
• 1995, 30. September: DirectX 1 ist final und wird veröffentlicht
• 1996, 5. Juni: DirectX 2 wird veröffentlicht, erstmals ist Direct3D mit von der Partie
• 1996, 15. September: DirectX 3 erblickt das Licht der Welt
• 1996, Dezember: Geplanter Release von DX4 für spezielle Features eines verspäteten Mobil-Chips von Cirrus Logic
• 1997, 16. Juli: DirectX 5 erscheint, am 5.5.1998 folgt DirectX 5.2
• 1998, 7. August: DirectX 6 samt Multitexturing-Support ist geboren; DX6.1 und 6.1a folgen am 3.2. bzw. 5.5.1999
• 1999, 22. September: DirectX 7 bringt H-TnL in die Windows-Welt, am 8.3.2000 folgt DX7.0a; 7.1 am 14.09.
• 2000, 12. November: DirectX 8 und die Geburtsstunde der Shader
• 2001, 5. Februar: Letzte Chance für Windows 95 mit DX8.0a
• 2001, 25. Oktober: DirectX 8.1 erscheint für Windows XP, Server 2003 und die Xbox
• 2002, 19. Dezember: DirectX 9 legt mit Gleitkomma-Unterstützung den Grundstein für moderne Spielegrafik, zahlreiche Updates erscheinen mit DirectX 9.0a, 9.0b, 9.0c.
• 2006, 30. November: DirectX 10 erscheint und bricht als erste DirectX-Version mit der Abwärtskompatibilität zu mindestens zwei vergangenen Versionen.
• 2008, 4. Februar: Mit Direct3D 10.1 erscheint im SP1 für Vista ein Update für DirectX 10, welchem sich Platzhirsch Nvidia bis heute verweigert
• 2008, November: Das DirectX-SDK bringt Unterstützung für DirectX 11 ohne dass passende Hardware verfügbar ist.

Artikel teilen

Microsofts DirectX ist seit Jahren der de-facto-Standard in Sachen Multimedia-API. PC Games Hardware wirft einen Blick zurück. Heute im Fokus: DirectX 9, die Entwicklung moderner Shader und der Zweikampf gegen OpenGL.

Per E-Mail versenden

8

1. Seite 1 DirectX - von den Anfängen bis zur Gegenwart (III) - Seite 1
2. Seite 2 DirectX - von den Anfängen bis zur Gegenwart (III) - Seite 2