DirectX-Next

[Ailuros]

shamelessly plugged vom B3D forum:

http://www.beyond3d.com/forum/viewtopic.php?t=8959

Von Ilfirin:

The topology stuff seems to be the PPP we've been hearing about, only taken to a whole new level. Now rendering to cube-maps can be done in 1 pass rather than 6, point sprites should finally work as they should've all along, fur generation is all in hardware, as are shadow volumes, etc. Also allows lots more HOS stuff: Catmull-Rom, Bezier, B-spline and their rational versions, along with subdivision surfaces.

Frame Buffer Access from the pixel shader is finally in (officially).

Apparently you can now arbitrarily spill vertex shader results to a vidmem vertex buffer.

Sehr interessant.

Meinungen bitte und ein paar extra Analyzen waeren toll von unseren 3D-gurus hier :)

[Ailuros]

104 hits und kein einziger aufklaerender Kommentar? :(

[KEINPLAN]

Original geschrieben von Ailuros
104 hits und kein einziger aufklaerender Kommentar? :( Ja schaut so aus. Ich warte auch schon aber nun geht’s ins Bett.

Könnte ja sein das niemand was sagen darf

[Ailuros]

Die PPT kann man frei herunterladen und alles was ich lesen will sind ein paar Kommentare von unseren Gurus auf dass was da drin steht. Man kann ja oeffentliches Material frei beurteilen.

[Demirug]

Die Kernaussage des ganzen dürfte wohl "Unlimited Resources" sein. Leider wird das ganze dann gleich wieder auf einige nicht genau spezifizierte Resourcen begrenzt.

Der Rest ist mehr oder minder noch etwas unklar formuliert.

[Fragman]

da mir die dinge bis auf die ganzen hos nicht viel sagen, koennte mal jemand beispiele bringen was mit den genannten pixel und vertex ops moeglich wird?

[Demirug]

Original geschrieben von Fragman
da mir die dinge bis auf die ganzen hos nicht viel sagen, koennte mal jemand beispiele bringen was mit den genannten pixel und vertex ops moeglich wird?

Im Prinzip alles was man sich ausdenken kann. Das Limit wäre nur noch die Geschwindigkeit der Chips.

[Ailuros]

http://www.beyond3d.com/articles/directxnext/

[Ailuros]

Ich moechte erinnern dass der Artikel aus historischen Gruenden lesenswert ist. Hier geht es eher um den "it was meant to be..." Punkt.

3DCenter, 25.Maerz 2002, DX9.0 Preview:

http://www.3dcenter.de/artikel/2002/03-25.php

[Ailuros]

Von der Hauptseite kopiert:

Bei Beyond3D ist ein umfangreicher und sehr lesenswerter Artikel zu jenem Wissen erschienen, welches derzeit zur nächsten DirectX-Version bekannt ist - derzeit unter "DirectX Next" firmierend, von vielen Herstellerfirmen aber bereits als DirectX10 genannt. Beispielsweise sollen damit auch Grafikchips einen virtuellen Speicher bekommen, wo also der Grafikchip direkt einen Teil des PC-Hauptspeichern addressieren kann - wie beim 3Dlabs P10 verwirklicht, welcher leider nie in den Gamer-Markt gefunden hat. Zudem wird auch auf die weitere Entwicklung der Shader in der dann anstehenden Version 4.0 hingewiesen - hin zu größtmöglicher Flexibilität und (weitestgehend) ohne Limitierungen ...

Soweit so gut.

... Neben anderen Ausführungen zu Details von DirectX10 noch erwähnenswert wäre die abschließende Einschätzung von Beyond3D, wonach viele der Änderungen von DirectX10 Tile Based Renderern entgegenkommen würden. Dies muß nun natürlich gar nichts dazu sagen, daß außerhalb von PowerVR an solchen Chips gearbeitet wird. Aber zumindestens möglich wäre es durchaus, verfügen doch sowohl ATi (über die ArtX-Aquisitation) als auch nVidia (über die 3dfx-Aqisitation, welche die Patente und Ingenieure von GigaPixel mitbrachten) prinzipiell gesehen über die technischen Grundlagen und auch die Manpower zum Bau von Tile Based Renderern ...

Wie Ilfirin aber im Artikel schon betont hat, wird es noch so manche Zeit dauern bis das API erstmal definiert ist. Was wohl heissen kann dass wenn IHVs empfinden dass eine Loesung ihnen nicht unbedingt entgegenkommt fuer ihre Architekturen dass diese dann auch dementsprechend angepasst werden. Relative Kommentare von ATI und PVR Angestellten siehe hier:

http://www.beyond3d.com/forum/viewtopic.php?t=9315



... Andererseits bieten sich solche Chips immer mehr an, weil bei den herkömmlichen Renderern das Thema Verlustleistung eine immer größere Rolle spielt und zukünftig den erreichbaren Chiptakt immer stärker limitieren wird. Beim Erreichen solcher Limits bieten sich dann natürlich TBRs aufgrund ihrer deutlich höheren Pro-MHz-Leistung an, um die 3D-Leistung trotz der Verlustleistunggrenze weiter zu steigern. Dies setzt natürlich voraus, einen TBR-Chip auf die gleichen oder ähnlichen Taktraten wie "normale" Grafikchips zu hiefen, was bisher eigentlich noch nirgendwo gelungen ist. Hier gilt schlicht das Prinzip abwarten - sowohl was ATi und nVidia bezüglich der DirectX10-Generation tun werden, als auch, wie dies bei PowerVR aussehen wird.


Ist es pro-MHz Leistung oder "unter Vorraussetzungen effektiverer Einsatz von Bandbreite"? Vorraussetzungen sind hier wohl die "corner cases" wo TBDRs ihren Bandbreiten-Vorsprung nun doch verlieren koennten, geloest werden. Selbst NVIDIA hat in ihren Praesentationen TBDR als eine moegliche Bandbreiten-Loesung erwaehnt.

Wenn ich in die Vergangenheit zurueckschlage dann kraenkelte eine GF2MX eher an fehlender Bandbreite als alles anderem.

Bis jetzt gibt es noch keine Anzeichen dass weder ATI oder NV in absehbarer Zeit einen Architektur-wechsel vorhaben. Warum auch? Solange das bisherige Rezept gut laeuft gibt es nicht viel Grund erstmal daran zu denken. PowerVR muss in diesem Fall beweisen koennen dass TBDR - und sie als momentan einziger Vertreter dieses Verfahrens - auch wirkliche Vorteile hat, und das schaffen sie natuerlich nur mit einem high-end chip.

Zu guter letzt wird wohl DX-Next dem XBox2 chip zugeschnitten sein; da bezweifle ich dass wenn Virtual Memory wirklich keine gute Idee fuer diesen ist, dass sie auch als absolute Vorraussetzung im API ankommt oder bis zur Finalisierung nicht dementsprechend modifiziert wird.

[Gast]

News Korrektur:
Virtueller Speicher befindet sich im Grafikkartenspeicher nicht im PC-Hauptspeicher.

Der Gedanke, dass DXNext (DX10) mehr auf den PowerVR oder Deferred Rendering (DF) zugeschnitten ist, ist mir beim Lesen der MS-Slides gar nicht gekommen. Ich habe die Verbesserungen eher unter dem Gesichtspunkt Flexibilität, Effizienz und unbegrenzte Resourcen gesehen, was auch nicht-interaktiven Grafik-Anwendungen (keine Spiele) zugute kommt, z.B. Offline-Rendering oder allgemeine Anwendungen ohne Grafik Hintergrund. Die B3D-Diskussion adressiert vornehmlich die Shader, also ein Problemfeld, dass Immediate Renderern (IR) und DR gleichermassen betrifft (kann mich hier irren).

Die Vorteile von DF sehe ich ohnehin mehr und mehr verschwinden. Early-Z adressiert die Z-Buffer Ineffizienz soweit es geht (Front-to-Back Rendering ist ohnehin fast Pflicht). Pixel-Caches und Kachel-Rendering von Dreiecken sowie gekachelten Texturen und Framebuffer reduzieren zumindest den Vorteil des "Tile-Based-Rendering". Lange und flexible Shader sind die Zukunft, d.h. die Pixel-Bandbreite sollte weniger wichtig werden.

Unklar ist mir allerdings der Framebuffer-Zugriff im Pixel-Shader. Warum schafft es Probleme? GLslang attestiert ebenfalls vage Probleme und hat daher das Feature erst mal aus der Spec entfernt, obwohl geplant. Mir will einfach nicht der "Groschen fallen", trotz B3D Artikel.

Die Dx10 Spec sollte sich bereits in einem sehr fortgeschrittenen Zustand befinden, schliesslich ist die Entwicklung von XBOX2, NV50 und R500 schon seit langem in Gange. An Details oder API Zugriffen auf HW Feature wird sicherlich noch gearbeitet, aber die HW Features sollten bereits fest liegen. Nebenbei: Die XBOX2 wird aller Wahrscheinlichkeit nach embedded RAM verwenden. (NV Aussage im April 2003: "Embedded RAM for console is ok". Steht nicht im Widerspruch zu der Tatsache, dass ATI den Chip entwickelt.)

IM oder DR Ansatz haben heutzutage IMO wenig mit dem Anspruch einer neuer, innovativen Architektur zu tun. Wie Kristof (Imagination Technology bzw. Ex-PowerVR) vor einigen Monaten im B3D Forum schrieb: NV und ATI Architekturen sind eigentlich ziemlich altmodisch. Ich bin mir sicher, dass er damit nicht den DR Ansatz meint, weil, uralte Argumente herauskramen ist etwas billig.
Eine neue, innovative Architektur im Grafik-Bereich ist z.B. die Playstation 3 ("Cell Prozessor"), wobei eine Pro/Contra Analyse schierig und aufwendig ist (im B3D-Forum bereits grob diskutiert). Um's mal schwammig zu sagen (bin schliesslich kein Hellseher): Diejenige Architektur, die Rechenleistung flexibel nutzbar macht und dabei effizient bleibt (Kosten/Performance Relation), sowie Kommunikation und Speichersystem optimal gestaltet, wird in der Zukunft "die Nase vorne haben". Nebenbei gilt (wenn ich mich nicht irre) bisher die *Faustformel*: "Kombinatorische Logik" (ALU, Controller) haben einen Anteil von rund 50%, der Rest ist Speicher (Register, Caches, FIFOs, Buffer). Verdrahtungsaufwand/platz habe ich einfach mal weggelassen.

P.S.
Ziemlich viel oberflächlicher Text, aber sei's drum. (Wer will, darf den Satz als Entschuldigung verstehen.)

[Demirug]

Original geschrieben von Gast
News Korrektur:
Virtueller Speicher befindet sich im Grafikkartenspeicher nicht im PC-Hauptspeicher.

Ja, aber der Hautpspeicher ist dann die "Auslagerungsdatei".

Der Gedanke, dass DXNext (DX10) mehr auf den PowerVR oder Deferred Rendering (DF) zugeschnitten ist, ist mir beim Lesen der MS-Slides gar nicht gekommen. Ich habe die Verbesserungen eher unter dem Gesichtspunkt Flexibilität, Effizienz und unbegrenzte Resourcen gesehen, was auch nicht-interaktiven Grafik-Anwendungen (keine Spiele) zugute kommt, z.B. Offline-Rendering oder allgemeine Anwendungen ohne Grafik Hintergrund. Die B3D-Diskussion adressiert vornehmlich die Shader, also ein Problemfeld, dass Immediate Renderern (IR) und DR gleichermassen betrifft (kann mich hier irren).

Habe ich mir auch schon gedacht. Da war wohl ein wenig der Wunsch der Vater des Gedanken.

Unklar ist mir allerdings der Framebuffer-Zugriff im Pixel-Shader. Warum schafft es Probleme? GLslang attestiert ebenfalls vage Probleme und hat daher das Feature erst mal aus der Spec entfernt, obwohl geplant. Mir will einfach nicht der "Groschen fallen", trotz B3D Artikel.

Ja, das Problem ist nicht wirklich leicht zu erkennen. Die Pixelprozessoren haben ja sehr lange Pipelines (> 200 Stufen). Ein Pixel muss da dann auch noch mehrfach durch. Da kann es durchaus passieren das vorne plötzlich ein Pixel auftaucht der auf das Ergebniss einer vorhergehenden Pixel-Berechnung zugreifen möchte die sich aber noch in der Pipeline befindet.

Die Dx10 Spec sollte sich bereits in einem sehr fortgeschrittenen Zustand befinden, schliesslich ist die Entwicklung von XBOX2, NV50 und R500 schon seit langem in Gange. An Details oder API Zugriffen auf HW Feature wird sicherlich noch gearbeitet, aber die HW Features sollten bereits fest liegen. Nebenbei: Die XBOX2 wird aller Wahrscheinlichkeit nach embedded RAM verwenden. (NV Aussage im April 2003: "Embedded RAM for console is ok". Steht nicht im Widerspruch zu der Tatsache, dass ATI den Chip entwickelt.)

Das "Embedded RAM for console is ok" bezog sich damals auf den Gamecube (bzw Flipper). Ich bin mir aber nun wirklich nicht sicher ob XBox2 wirklich DX-Next nutzen wird.

IM oder DR Ansatz haben heutzutage IMO wenig mit dem Anspruch einer neuer, innovativen Architektur zu tun. Wie Kristof (Imagination Technology bzw. Ex-PowerVR) vor einigen Monaten im B3D Forum schrieb: NV und ATI Architekturen sind eigentlich ziemlich altmodisch. Ich bin mir sicher, dass er damit nicht den DR Ansatz meint, weil, uralte Argumente herauskramen ist etwas billig.
Eine neue, innovative Architektur im Grafik-Bereich ist z.B. die Playstation 3 ("Cell Prozessor"), wobei eine Pro/Contra Analyse schierig und aufwendig ist (im B3D-Forum bereits grob diskutiert). Um's mal schwammig zu sagen (bin schliesslich kein Hellseher): Diejenige Architektur, die Rechenleistung flexibel nutzbar macht und dabei effizient bleibt (Kosten/Performance Relation), sowie Kommunikation und Speichersystem optimal gestaltet, wird in der Zukunft "die Nase vorne haben". Nebenbei gilt (wenn ich mich nicht irre) bisher die *Faustformel*: "Kombinatorische Logik" (ALU, Controller) haben einen Anteil von rund 50%, der Rest ist Speicher (Register, Caches, FIFOs, Buffer). Verdrahtungsaufwand/platz habe ich einfach mal weggelassen.

Wie sich Cell in der Praxis schlagen wird muss sich wirklich erst noch zeigen. Sony ist ja durchaus berüchtig was das entwerfen von Systemarchitekturen angeht.

Bist du bei den 50% sicher das sich das auf GPUs bezogen hat? Ich kenne diese Zahl nur in Verbindung mit CPUs. Bei GPUs ist der Logikanteil eigentlich viel höher.

[Gast]

Original geschrieben von Demirug
Ja, das Problem ist nicht wirklich leicht zu erkennen. Die Pixelprozessoren haben ja sehr lange Pipelines (> 200 Stufen). Ein Pixel muss da dann auch noch mehrfach durch. Da kann es durchaus passieren das vorne plötzlich ein Pixel auftaucht der auf das Ergebniss einer vorhergehenden Pixel-Berechnung zugreifen möchte die sich aber noch in der Pipeline befindet.


Ja, aber das Problem gibt es mit dependent texture read bereits. Pixel liegen ausserdem solange wie möglich im Cache. Mehrmaliger Zugriff bedeutet also nicht, jedesmal auf den externen Speicher zu warten. Es ist ja grundsätzlich möglich (DX10 zeigt es) und sinnvoll. Die Frage bleibt: Warum schafft es massive Probleme oder ist extrem aufwendig?


Das "Embedded RAM for console is ok" bezog sich damals auf den Gamecube (bzw Flipper). Ich bin mir aber nun wirklich nicht sicher ob XBox2 wirklich DX-Next nutzen wird.


Der Kontext des Zitats war eher die Zukunft. ("Embedded RAM will be just around the corner for a very long time.") XBOX2 Release ist (wenn ich mich nicht irre) 2005, also Weihnachten 2005 (wegen dem binären Marketing-Denken: entweder zu Weihnachten oder gar nicht). Da sollte DX10 nicht allzu weit entfernt sein.


Bist du bei den 50% sicher das sich das auf GPUs bezogen hat? Ich kenne diese Zahl nur in Verbindung mit CPUs. Bei GPUs ist der Logikanteil eigentlich viel höher.

Ein älterer 3DLabs Chip entsprach ca. diesem Verhältnis. Die exakten Daten jedes Chips kenne ich auch nicht (kann also falsch liegen). Wenn du Zahlen hast, immer her damit. Nicht ohne Grund fehlt es dem NV30 an Temp-Registern. Jeder Read/Write Port verdoppelt in etwa den Aufwand.

[Demirug]

Original geschrieben von Gast
Ja, aber das Problem gibt es mit dependent texture read bereits. Pixel liegen ausserdem solange wie möglich im Cache. Mehrmaliger Zugriff bedeutet also nicht, jedesmal auf den externen Speicher zu warten. Es ist ja grundsätzlich möglich (DX10 zeigt es) und sinnvoll. Die Frage bleibt: Warum schafft es massive Probleme oder ist extrem aufwendig?

Grundsätzlich möglich ist es (S3 will es mit dem DC ja auch schon anbieten). Dependet Texture Reads haben ja auch schon so ihere Tücken und ATIs R3XX Reihe ist kein echter Freund dieser Sache. Das Problem bei Framebuffer Zugriffe ist allerdings etwas anders gelagert. Bei einem Dependet Texture Reads greift man ja auf einen Wert der für den gleichen Pixel im gleichen Shaderprogramm berechnet wurde zu. Beim Framebufferzugriff braucht man das Endergebniss eines fertig gerechnet Pixels (welches unter Umständen durch die ROPs noch verändert wurde). Beispiel:

Die Pixelpipeline ist 200 Stufen lang. 100 Pixel wurden eingeschleust. Pixel 101 liegt nun auf der gleichen Position wie der erste Pixel. Dieser Pixel ist aber nun noch lange nicht fertig gerechnet. Was macht man nun wenn das Shaderprogramm das Endergebniss des ersten Pixels braucht? Die Antwort auf diese Frage ist die Lösung des Problems.

Der Kontext des Zitats war eher die Zukunft. ("Embedded RAM will be just around the corner for a very long time.") XBOX2 Release ist (wenn ich mich nicht irre) 2005, also Weihnachten 2005 (wegen dem binären Marketing-Denken: entweder zu Weihnachten oder gar nicht). Da sollte DX10 nicht allzu weit entfernt sein.

Ich kenne die Embedded RAM Aussage von nVidia im Context mit dem Gamecube. Sie wurde sicherlich öfter benutzt.

Zum Release sollten aber auch schon ein paar Spiele fertig sein. Das wird verdammt knapp wenn man auf DX-Next setzten möchte.

[Xmas]

Original geschrieben von Gast
Ja, aber das Problem gibt es mit dependent texture read bereits. Pixel liegen ausserdem solange wie möglich im Cache. Mehrmaliger Zugriff bedeutet also nicht, jedesmal auf den externen Speicher zu warten. Es ist ja grundsätzlich möglich (DX10 zeigt es) und sinnvoll. Die Frage bleibt: Warum schafft es massive Probleme oder ist extrem aufwendig?
Bei Dependent Texture Reads gibt es das Problem in dieser Form nicht, da es ja keine Out-of-Order Execution innerhalb eines Quads gibt. Sprich, die Texturkoordinaten für den Dependent Read liegen dann vor, wenn der Read gemacht werden soll (das kann natürlich etwas dauern, aber währenddessen werden andere Quads bearbeitet).

Beim Lesen des Framebufferinhalts ist es nun so: In der Pipeline befinden sich reichlich Quads. Diese müssen nicht zwangsläufig zum selben Polygon gehören, können also durchaus an derselben Position im Framebuffer liegen. Stell dir vor, Quad A ist schon halb durch, während Quad B, das an derselben Position liegt, gerade erst in die Pipeline kommt. Der Shader verlangt die Framebuffer-Farbe schon ganz am Anfang. In diesem Fall müsste Quad B erst einmal warten, bis Quad A die Pipeline komplett durchlaufen und den richtigen Framebuffer-Wert errechnet hat.

Die Problematik liegt hier nicht nur darin, Quad B warten zu lassen, sondern überhaupt erstmal eine solche Situation zu erkennen. Eine sehr aufwändige Moglichkeit: Man müsste ein Quad, das in die Pipeline eintritt, mit sämtlichen anderen Quads in der Pipeline gegenprüfen, um zu sehen ob ein anderes Quad schon an derselben Position liegt.

Beim normalen Alpha-Blending gibt es ein solches Problem nicht, weil das Blending garantiert am Ende der Pipeline liegt.