Microsofts DirectX Next

Auf dem Microsoft Meltdown 2003 zeigte sich der Software-Gigant schon etwas freigiebiger mit Informationen zur nächsten Generation von DirectX, als es in der Vergangenheit der Fall war. In einigen Präsentationen ging Microsoft unter anderem auf Details zum 4.0-Shader Modell ein.

Der Download der kompletten Präsentationen ist seit nunmehr beinahe zwei Monaten öffentlich zugänglich, allerdings mit über 50MB nicht unbedingt etwas für Modem-User. Umso erstaunlicher ist es, dass sich bislang nur Beyond3D wirklich ausführlich damit beschäftigt haben.

Da jener Artikel in englischer Sprache verfasst wurde, wollen wir ihn hier für euch kurz und knackig zusammenfassen.

Microsoft führte DirectX in der aktuellen Version 9 (von der nach derzeitigem Kenntnisstand im Übrigen keine wie auch immer geartete 9.1-Version geplant ist) die mittlerweile wohlbekannten 2.0-Shader ein. Daneben gibt es aber, wie sollte es anders sein, eine Unzahl von Optionen, die Shader noch flexibler programmierbar zu gestalten, so wie es nVidia mit ihren "2.0+" genannten Shadern verwirklichte. Dies ist aber noch nicht die Spitze des Eisbergs, denn weniger bekannt ist, dass sowohl Vertex- als auch Pixelshader in Version 3.0 bereits komplett in DirectX9 spezifiziert sind.

Neben etlichen Feinheiten, wie erhöhtem Instruktionslimit und freierer Sprungmöglichkeiten innerhalb der Programme ist ein Kernpunkt z.B. im Vertexshader 3.0, dass dieser erstmals auch Texturzugriffe durchführen kann und damit wirklich brauchbares Displacement Mapping ermöglicht, welches extrem realistische, aber dabei genügsame Geometrie realisierbar erscheinen lassen würde.

In DirectX-Next geht man noch einen Schritt weiter: Durch viele redundante Funktionen im Pixel- und Vertexshader scheint es unsinnig, diese noch in separate Funktionseinheiten aufzuteilen, so dass sowohl die Programmiersyntax als auch die Shaderhardware an sich nicht mehr nach Pixel- und Vertexoperationen getrennt werden.

Dies hat, neben der leichteren Zugänglichkeit für die Programmierer, den Vorteil, dass man jetzt nur noch durch die Shaderleistung an sich limitiert ist, nicht aber durch eine, je nach Situation, womöglich schlechte Balance zwischen Vertex- und Pixelshaderleistung. Auf einem niedrigeren Niveau (Vertexshader 1.1 und Pixelshader 1.3) machte die Hardware des 3DLabs-Chip "P10" dies schon im letzten Jahr vor. Dort konnte begrenzt auch per Treiber entschieden werden, welche Funktionseinheiten nun Vertex- und welche Pixeloperationen durchführen sollten. Darüber hinaus wäre es bei weiterem Schrumpfen der Fertigungstechnologie natürlich auch leichter, die Geschwindigkeit zu steigern, da identische Funktionseinheiten "nur noch" dupliziert, aber nicht neu entworfen werden müssten.

Dieser Punkt ist von uns ein wenig zusammengefasst worden, nimmt er doch in der Microsofts Präsentation zwei Punkte ein, den sogenannten Topology Processor und die Tesselation Enhancements, welche allerdings nur logisch getrennte Einheiten darstellen müssen.

Kurz und knapp gesagt lässt sich hier erstmals auf die bislang festverdrahteten Einheiten zur Umwandlung der von der CPU gelieferten Vertex-Koordinaten in Dreiecke Einfluss nehmen und zusätzlich sind quasi jegliche Formen der sog. Higher Order Surfaces (HOS) möglich, wie sie ein kurzes Gastspiel schon in der Radeon 8500/9100 (n-Patches) und der GeForce 3/4 (RT-Patches) hatten, mangels praktischer Einsatzmöglichkeiten aber schnell wieder fallen gelassen wurden.

Mit dem PPP sind nur kaum noch Grenzen gesetzt, was die Zerlegung, Umwandlung und sogar die Erzeugung zusätzlicher Geometrie innerhalb bestehender Modelle in der GPU direkt angeht.

Durch diese bisher nicht spezifiziert Möglichkeit des Pixelshaders, den Inhalt des Framebuffers zu ändern, werden eine Menge z.B. von Blending Funktionen, die bisher von festverdrahteten Einheiten, die am Ende der Pipelines standen, quasi überflüssig, da man das nötige Überlagern diverser gerenderter Lichtquellen nun auch direkt im Pixelshader durchführen könnte. Ein anderes mögliches Gebiet, auf dem dieser Punkt nützlich sein dürfte, ist die Vermeidung vieler virtueller Render Targets, was bei einigen aktuellen Spielen die gleichzeitige Verwendung von FSAA und Full-Screen Effekten, wie z.B. Tiefenunschärfe oder Motion Blur wirkungsvoll verhindert.

Bei CPUs ein alter Hut werden mit DirectX-Next auch GPUs in die Lage versetzt, den von ihnen genutzten Speicher auch außerhalb des lokalen Karten-RAMs segmentiert zu adressieren. Dies ist insbesondere für die enormen Speichermengen von Nutzen, die z.B. 3D-Texturing inklusive MipMaps benötigt, da hier nicht die komplette Textur samt der verkleinerten Mip-Level im lokalen Speicher abgelegt werden muss, sondern nur der gerade benötigte Block, der auch direkt in einer kleineren MipMap vorhanden sein kann, von dem die Basis-Textur erst später benötigt wird.

Durch das virtuelle Speichermanagement und die damit verbundene Segmentierung direkt erforderlich ist, so abstrus es klingt, ein Integer Instruktion Set. Da bislang quasi alles innerhalb der Pipeline mit Floating-Point Genauigkeit geschieht. Das Problem ist, dass dies unter Umständen zu genau sein kann, wenn z.B. eine Speicheradresse nicht genau mit dem benötigten Texel übereinstimmt, wird derzeit einfach interpoliert und somit ein Teil des nächsten Texels mit eingebracht. Dummerweise ist durch die segmentierte Speicheraddressierung und die erweiterten Möglichkeiten z.B. der Pixelshader, auf den Speicher zuzugreifen, nun nicht mehr sichergestellt, dass zwei angrenzende Speicherblöcke überhaupt etwas miteinander zu tun haben, so können z.B. Texturinformationen und Geometriedaten direkt nebeneinander liegen und damit interpolierte Zugriffe ganz schön an die Wand laufen lassen.

Durch ein hoffentlich simpel zu implementierendes Integer Instruktionsset werden solche Dinge vermieden, da nur ganzzahlige Adressierungen möglich sind.

Wer genauere Informationen benötigt, der sei hier nochmals auf den detaillierteren Artikel bei Beyond3D verwiesen, auf dem unsere Newsmeldung basiert.

Die Kollegen dort folgern aus den bislang vorgestellten Details, dass DirectX-Next aus bestimmten Gründen für einen Tile-Based Deferred Renderer, wie es z.B. die Kyro-Chips von PowerVR waren, eine sehr gute, wenn nicht optimale Arbeitsgrundlage böte und nähren gleich schon die Gerüchte, PowerVR könnte bei der nächsten DirectX-Version wieder eine gute Rolle im Konzert der Großen spielen.

Wie auch immer sich das nun endgültig entwickeln mag, eines sei vorab schonmal erwähnt: Viele dieser auf dem Papier toll klingenden Dinge müssen erst einmal umgesetzt werden, zumal noch in den Sternen steht, was genau davon in die endgültig bindende DirectX-Spezifikation für einen DirectX-Next-compliant Grafikchip eingeht und was davon optional bleibt.

Darüberhinaus ist ja spätestens seit der letzten Version von DirectX, der Nummer 9, auch bekannt, dass relativ spät, nachdem schon viele Chip- und Softwareentwickler ihre Wünsche eingebracht hatten, noch einmal grundlegende Änderungen an der Spezifikation möglich sind, also freue man sich lieber nicht zu früh.