ATi Project "Loci"

[Quasar]

Original geschrieben von Ailuros
Schon wahr Quasar. Obwohl ich ernsthafte Zweifel habe dass sie schon so weit sind (Teufel wie will jemand Shader specs fuer DX-Next definieren wenn dieses immer noch unter Verhandlungen liegt; genau das gleiche gilt auch fuer R500), grueble ich trotz allem gerade darueber nach, was jeglichen IHV haette aufhalten koennen universale Einheiten schon so frueh zu verwenden. Gleiches gilt natuerlich auch fuer NV40.

Technisch ist es nicht unmoeglich so wie ich es sehe, aber von Shader 4.0 Komplianz kann man in keinem Fall reden; im Ideal-Fall von Shader 3.0 Komplianz mit ein paar Anteilen die zu zukuenftigen Shadern gehoeren.

Ich spekuliere jetzt mal rein auf der Basis des schon vorhandenen:
ATi hat mit dem R300 einen großen Wurf gelandet, nV ist mit dem nV3x mehr oder minder auf die Schnauze gefallen (ok, soweit ist's keine Spekulation..).
Bis es DX-Next gibt, also es Zeit wird für zwingend notwendige, einschneidende Veränderungen, wird man bei ATi IMO (JETZT ist's Spekulation) eher den Weg weitergehen, der einen bis hierher zum Erfolg führte: brutal schnelle, aber "nur" eingeschränkt programmierbare 2.0-Shader. Das brächte ihnen Vorteile bei allen Spielen, die stark auf DX9 basieren und bereits in der Entwicklung sind, da die meisten (Spieler und Entwickler) mit der bisher gebotenen Feature-List ja durchaus zufrieden zu sein scheinen. Gleichzeitig könnte man mit diesem Schritt und der bisher erreichten Marktsättigung versuchen, die exzessive Nutzung von, ich nenn's mal nV-Shadern, einzudämmen.
Wenn man jetzt den Pfad verliesse, den man eingeschlagen hat, also die Shader in ihrer Mächtigkeit, nicht Redundanz stärkt, hätte man das Problem, das nV im nV30 mitgeschleppt hat, wie ein Klotz am Bein: Man könnte sich teilweise nur unzureichend von der Vorgängergeneration absetzen.

nV hingegen muss etwas tun. Einfach nur mehr FP-Einheiten in ihre Chips reinpumpen bis zum Erbrechen wird bis zum Jahre 2005 nicht genug sein (vom FSAA will ich gar nicht erst anfangen). Und da ihr Shadercore sowie das Vertex-Array sowieso schon eher in Richtung unified shader gehen (klar sind sie längst noch nicht am Ziel!), läge m.E. der sinnvollere Weg, bereits jetzt nochmal in den sauren Apfel zu beissen und vielleicht nocht nicht voll 4.0-compliant shader zu entwickeln, aber zumindest die Recheneinheiten komplett flexibel nutzbar zu machen.

Das hätte IMO folgende Vorteile:
- Gleichzeitg mögliche Bedienung Marktsegmente (CGI, CAD/CAM und GAMER)
- Die Werbewirksamen "Eckdaten" könnten stark erhöht werden ("bis zu" bekäme eine völlig neue Bedeutung ;))
- man könnte eine "nützliche" app-Erkennung einbauen und bei Spielen mit hoher Geometrielast den Focus dorthin verlagern bzw. bei hohen Pixelshader-Anforderungen mehr der internen FP-Einheiten dem Pixel-Prozess zuordnen
- Man bekäme wieder den Vorsprung bei den Entwicklern und hätte gleichzeitig die Möglichkeit, einige unique features in die Games einzubauen bzw. einbauen zu lassen.

as always just my €.02

[Ailuros]

Bis es DX-Next gibt, also es Zeit wird für zwingend notwendige, einschneidende Veränderungen, wird man bei ATi IMO (JETZT ist's Spekulation) eher den Weg weitergehen, der einen bis hierher zum Erfolg führte: brutal schnelle, aber "nur" eingeschränkt programmierbare 2.0-Shader.

Hier moechte ich noch hinzufuegen dass ATI nicht die einzigen mit PS/VS2.0 und FP24 fuer PS sind. Obwohl natuerlich ATI als grosser Spieler zuerst damit fertig war etc etc, koennte man unter Umstaenden sogar sagen dass nicht "nur" Microsoft die ganze Idee als gut empfand.

Wenn man jetzt den Pfad verliesse, den man eingeschlagen hat, also die Shader in ihrer Mächtigkeit, nicht Redundanz stärkt, hätte man das Problem, das nV im nV30 mitgeschleppt hat, wie ein Klotz am Bein: Man könnte sich teilweise nur unzureichend von der Vorgängergeneration absetzen.

Deshalb fragte ich ja auch schon oben was man genau mit doppelter Leistung meint und unter welchen Bedingungen; aber in dem Fall sieht es auch nicht anders aus zwischen NV3x und NV4x.

Irgendwas macht mir hier nicht ganz Sinn, Mufu z.B. erwaehnt auch Doom3 Leistung. Entweder hat ATI da mehr Z/stencil Einheiten oder behandelt die loops beim MSAA ganz anders. Das heisst aber nur dass hier eine offensichtliche Schwaeche behandelt wird; selbst wenn ich eine zweite TMU, hoehere Taktraten und vielleicht 4- oder 5-way hierarchical Z dazurechne, kann ich mir schwer die doppelte Leistung von einer R350 vorstellen.

nV hingegen muss etwas tun. Einfach nur mehr FP-Einheiten in ihre Chips reinpumpen bis zum Erbrechen wird bis zum Jahre 2005 nicht genug sein (vom FSAA will ich gar nicht erst anfangen). Und da ihr Shadercore sowie das Vertex-Array sowieso schon eher in Richtung unified shader gehen (klar sind sie längst noch nicht am Ziel!), läge m.E. der sinnvollere Weg, bereits jetzt nochmal in den sauren Apfel zu beissen und vielleicht nocht nicht voll 4.0-compliant shader zu entwickeln, aber zumindest die Recheneinheiten komplett flexibel nutzbar zu machen.

Genau das wollte ich sagen mehr oder weniger; der multi array VS des NV3x ist nur einen kleinen Schritt von VS3.0 entfernt. Ich sehe aber trotz allem keinen Grund warum nicht ein oder beide IHVs schon universale Einheiten gewaehlt haben koennten. Es hat nicht nur Vorteile mit arithmetischer Effizienz sondern es muesste auch HW sparen so wie ich das Ganze verstanden habe. Angenommen Einheiten bei R420 sind immer noch getrennt, wieso macht es hier nicht auch viel mehr Sinn an einen multi-array zu denken? Es geht ja hier eigentlich nur darum was am Ende heraus kommt; ob man jetzt z.B. 4 VS oder einen 4-way multi-array hat (mit gleicher Programmierbarkeit) sollte eigentlich egal sein; multi-threading/application stack muss man ja in beiden Situationen verwenden. Die letztere Loesung sieht IMO billiger in HW-Platz aus.

Die Frage ist hier wie sie den ganzen Wirrwarr ihrer eigenen Spekulationen entbuendeln wollen (ja ich meine hier Mufu). Wie soll das jetzt aussehen zwischen R3xx und R5xx? 8*1-->8*2-->16*2? "Wahre" oder "virtuelle" Pipelines? Der Quatsch ist mir aus dem Grund egal, weil es mir persoenlich wichtiger ist wie viele arithmetic ops jede Architektur pro Takt ausfuehren kann.

ATI steht bei 8 ops im R3xx; hier klingt es mir logischer an 12 ops in R420 und 16 ops in R500 zu denken, da R420 nach allen Angaben ein abgespeckter R400/500 sein soll. 32 ops fuer R500 erscheint mir eher als Wahnsinn.

Ich hab noch tonnenweise an Fragen im Hinterkopf, die ich aber fuer die Veroeffentlichung von NV40 und dergleichen und den Testresulateten dieser Architekturen mal aufgehoben habe. Ich bezweifle z.B. dass dynamic branching unter allen Situationen die ultimate Loesung mit SIMD Architekturen sein kann. Es bleibt wohl eher dem/den Entwickler(-n) offen, was und unter welchen Situation die besten Resultate geben kann (static oder dynamic...).

Uebrigens bezweifle ich auch dass jegliche topology/tesselation relative Erwartungen in zukuenftiger HW voll getroffen werden.

Alles IMHO; kann natuerlich auch total daneben liegen, wie es auch des oefteren vorkommt.

***edit: hier sollte man natuerlich hinzufuegen dass wo immer man volle PS/VS3.0 Unterstuetzung sieht in zukuenftigen Architekturen, dass die Shader auch nicht komplett auf maximal 3.0 begrenzt sein muessen. Architekturen haben in ihrer Mehrzahl alle "Pflicht"-features eines API um dessen Komplianz zu erreichen; dabei werden meistens optionale Features ausgelassen und zur gleichen Zeit ein paar zukuenftige Shader Aspekte hinzugefuegt. Haengt wohl alles von den Prioritaeten eines jenigen IHVs ab und was jeder als notwendig fuer einen spezifischen Zeitraum empfindet. Das heisst aber wiederrum nicht dass Realitaet dieses auch als nutzvoll beweisen wird.

[Quasar]

Original geschrieben von Ailuros
Hier moechte ich noch hinzufuegen dass ATI nicht die einzigen mit PS/VS2.0 und FP24 fuer PS sind. Obwohl natuerlich ATI als grosser Spieler zuerst damit fertig war etc etc, koennte man unter Umstaenden sogar sagen dass nicht "nur" Microsoft die ganze Idee als gut empfand.
Ich meinte eigentlich weniger die Beschränkung auf FP24, sondern eher die Programmierbarkeit vs. Performance.

Ich habe den Eindruck, daß ATi momentan eher länger an einer Schiene, nämlich der Performance, festhalten wird und diese auf ein Level ausbaut, welches auch Full-DX9-Games erlaubt, während nV eher in Richtung Vielseitigkeit gehen könnte und die Performance dann quasi automatisch erwartet, bis die Full-DX9-Games am Markt sind.


Original geschrieben von Ailuros
Deshalb fragte ich ja auch schon oben was man genau mit doppelter Leistung meint und unter welchen Bedingungen; aber in dem Fall sieht es auch nicht anders aus zwischen NV3x und NV4x.

Irgendwas macht mir hier nicht ganz Sinn, Mufu z.B. erwaehnt auch Doom3 Leistung. Entweder hat ATI da mehr Z/stencil Einheiten oder behandelt die loops beim MSAA ganz anders. Das heisst aber nur dass hier eine offensichtliche Schwaeche behandelt wird; selbst wenn ich eine zweite TMU, hoehere Taktraten und vielleicht 4- oder 5-way hierarchical Z dazurechne, kann ich mir schwer die doppelte Leistung von einer R350 vorstellen.

Bezgl. nV3x und nV4x glaube ich das nicht. IMO hat man zuviel der ursprünglichen nV3x-Konzeptes, welches wohl viel zu ehrgeizig gewesen ist, streichen müssen und wird es nun, da der 0,13µ auch in Low-K oder meinetwegen mit östlichen toten Fischen bei IBM ins Rollen kommt, einfach wieder dazupacken können. ATi war von vornherein auf Machbarkeit bei 0,15µ ausgelegt, so daß hier Grundsätzlicheres geändert werden müsste.
Da MuFu immer nur auf D3 herumreitet, denke ich, daß evtl. der Stencil/MSAA-Fix beim R350 noch nicht 100%ig ausgefallen ist. Vielleicht steckt da noch einiges an Potential im R300-Core. :)


Original geschrieben von Ailuros
Genau das wollte ich sagen mehr oder weniger; der multi array VS des NV3x ist nur einen kleinen Schritt von VS3.0 entfernt. Ich sehe aber trotz allem keinen Grund warum nicht ein oder beide IHVs schon universale Einheiten gewaehlt haben koennten. Es hat nicht nur Vorteile mit arithmetischer Effizienz sondern es muesste auch HW sparen so wie ich das Ganze verstanden habe. Angenommen Einheiten bei R420 sind immer noch getrennt, wieso macht es hier nicht auch viel mehr Sinn an einen multi-array zu denken? Es geht ja hier eigentlich nur darum was am Ende heraus kommt; ob man jetzt z.B. 4 VS oder einen 4-way multi-array hat (mit gleicher Programmierbarkeit) sollte eigentlich egal sein; multi-threading/application stack muss man ja in beiden Situationen verwenden. Die letztere Loesung sieht IMO billiger in HW-Platz aus.

Ich bezog das jetzt aber nicht nur auf den VS, sondern allgemein auf Shader. Nicht, daß ich das für den nV4x erwarte, aber komplett ausschließen will ich's auch nicht.


Original geschrieben von Ailuros
Die Frage ist hier wie sie den ganzen Wirrwarr ihrer eigenen Spekulationen entbuendeln wollen (ja ich meine hier Mufu). Wie soll das jetzt aussehen zwischen R3xx und R5xx? 8*1-->8*2-->16*2? "Wahre" oder "virtuelle" Pipelines? Der Quatsch ist mir aus dem Grund egal, weil es mir persoenlich wichtiger ist wie viele arithmetic ops jede Architektur pro Takt ausfuehren kann.

ATI steht bei 8 ops im R3xx; hier klingt es mir logischer an 12 ops in R420 und 16 ops in R500 zu denken, da R420 nach allen angeben ein abgespeckter R400/500 sein soll. 32 ops fuer R500 erscheint mir eher als Wahnsinn.

Wenn ich sehe, wieviel ATi mit dem R300/R350-Design aus dem 0,15µ Prozeß herausgeholt hat und mir vorstelle, die Transition auf 0,13µ hat besser als erwartet, oder zumindest gut geklappt, dann braucht der R420 bis auf ein paar kleine Fixes (vielleicht single-Pass 4xMS) evtl. überhaupt keine großartigen Architekur-Änderungen, um auf der 2.0-Shaderperformance seite selbst mit einem gut gelungenen nV40 konkurrieren oder ihn sogar ausstechen zu können.
Was in dem Rage3D-Thread so anklang, R420 mit derselben Kühllösung wie die 9800XT, da könnte ich mir schon an die 550MHz vorstellen, wenn der low-k 0,13µ auf dem R420 gut hinhaut.

[Demirug]

Die Idee für die PS und VS die gleichen Einheiten zu nutzen hatte ich ja auch schon. Problematisch ist dabei allerdings das die meisten IHVs es derzeit bevorzugen Vertex daten einzeln zu bearbeiten und Pixel in Blöcken. Wobei es bei den Pixelblöcken ja primär um das einsparen von Kontrollogik geht. Wären da nicht so ein paar dumme anweisungen die Informationen von den nachbarpixel brachen wäre es eigentlich ganz leicht Pixel auch einzeln zu betrachten. Das einzige auffällige was dann PS und VS noch unterscheidet sind die Interpolatoren. Aber die Interpolatoren könnte man dann bei Vertexprocessing für HOS Geschichten "missbrauchen".

Hier moechte ich noch hinzufuegen dass ATI nicht die einzigen mit PS/VS2.0 und FP24 fuer PS sind. Obwohl natuerlich ATI als grosser Spieler zuerst damit fertig war etc etc, koennte man unter Umstaenden sogar sagen dass nicht "nur" Microsoft die ganze Idee als gut empfand.

Was S3 und XGI angeht bin ich mir nicht sicher ob man dort nicht auf die finale Spec gewartet hat bis man mit dem Design der Details angefangen hat. Und wenn man den Gerüchten glauben schenkt wollte MS eigentlich FP16/FP32 (wie es bei Medienprocessoren durchaus üblich ist) musste dann aber Zugeständnisse machen. Wie eine Spec zusammengestrichen werden kann weisst du ja selbst.

[MadManniMan]

Original geschrieben von Quasar
Ich habe den Eindruck, daß ATi momentan eher länger an einer Schiene, nämlich der Performance, festhalten wird und diese auf ein Level ausbaut, welches auch Full-DX9-Games erlaubt, während nV eher in Richtung Vielseitigkeit gehen könnte und die Performance dann quasi automatisch erwartet, bis die Full-DX9-Games am Markt sind.

So gesehen könnte der R420 die GF4 von ATi werden... :grübel: Dabei stellt sich nur die Frage, inwieweit nV das Land sehen kann, wie ATi im Herbst 2002 auf die GF4 antworten zu können.
Tripipes? Neue AF-Dimensionen mit wenig Performancehit bei mindestens gleichwertigem AA? ... Ich wahrscheinlich nicht kreativ genug, aber an mehr als ein Speedupgrade bei ATi und eine Anpassung nVs an die erstrebenswerten R300-Dinge kann ich noch nicht so recht glauben... :ratlos:

[Ailuros]

Ich meinte eigentlich weniger die Beschränkung auf FP24, sondern eher die Programmierbarkeit vs. Performance.

Ich habe den Eindruck, daß ATi momentan eher länger an einer Schiene, nämlich der Performance, festhalten wird und diese auf ein Level ausbaut, welches auch Full-DX9-Games erlaubt, während nV eher in Richtung Vielseitigkeit gehen könnte und die Performance dann quasi automatisch erwartet, bis die Full-DX9-Games am Markt sind.

Den Eindruck haben viele von uns, nur kommt man dann schnell wieder auf "0" zurueck, weil weder Mufu noch jemand anders momentan genaue Informationen ueber ATI's genaue Plaene hat.

Wenn Du nach meiner persoenlichen Meinung fragen wuerdest, ist mir eine gesunde Balance zwischen Leistung und Features um einiges Mal lieber. Der Punkt wo ein IHV die Leistung erwartet sagt mir auch nicht viel; NV koennte in dem Sinn auch die Leistung fuer PS/VS2.0 extended und NV3x erwarten, aber zu dem Zeitpunkt werden wohl diese Karten schon lange vergessen sein, weil sie ganz einfach von ihren Nachfolgern in den Schatten gestellt werden.

Bezgl. nV3x und nV4x glaube ich das nicht. IMO hat man zuviel der ursprünglichen nV3x-Konzeptes, welches wohl viel zu ehrgeizig gewesen ist, streichen müssen und wird es nun, da der 0,13µ auch in Low-K oder meinetwegen mit östlichen toten Fischen bei IBM ins Rollen kommt, einfach wieder dazupacken können. ATi war von vornherein auf Machbarkeit bei 0,15µ ausgelegt, so daß hier Grundsätzlicheres geändert werden müsste.
Da MuFu immer nur auf D3 herumreitet, denke ich, daß evtl. der Stencil/MSAA-Fix beim R350 noch nicht 100%ig ausgefallen ist. Vielleicht steckt da noch einiges an Potential im R300-Core.

In dem Sinn strich NV die originalen NV30 Konzepte oder versetzte sie in die Zukunft, was aber auch anscheinend nicht anders war bei ATI und deren originalem R400 Projekt.

Was die stencil ops/MSAA Kombinationen betrifft, will ich wetten dass wenn jemand einen ATI Angestellten vertraulich fragt, dass die Antwort in der "...wir hatten zu wenig Zeit..." Richtung sein wird. Es gibt mehrere und sehr einfache Loesungen dafuer, soweit ich hier gewisse Dinge nicht missverstanden habe.

Wenn ich sehe, wieviel ATi mit dem R300/R350-Design aus dem 0,15µ Prozeß herausgeholt hat und mir vorstelle, die Transition auf 0,13µ hat besser als erwartet, oder zumindest gut geklappt, dann braucht der R420 bis auf ein paar kleine Fixes (vielleicht single-Pass 4xMS) evtl. überhaupt keine großartigen Architekur-Änderungen, um auf der 2.0-Shaderperformance seite selbst mit einem gut gelungenen nV40 konkurrieren oder ihn sogar ausstechen zu können.
Was in dem Rage3D-Thread so anklang, R420 mit derselben Kühllösung wie die 9800XT, da könnte ich mir schon an die 550MHz vorstellen, wenn der low-k 0,13µ auf dem R420 gut hinhaut.

Kommt ganz drauf an was deren reales Ziel ist und wie tief die Aenderungen die sie vorgenommen haben wirklich sind.

Wieso ist single pass 4xMSAA eine kleine Aenderung? So wie es aussieht nimmt R3xx je 2x samples einen loop vor, bis zu maximal 3 loops um 6xMSAA zu erreichen. Mit einem vierten loop hat man schon 8xMSAA. Der einzige notwendige Trick waere hier einfach den Leistungseinbruch der loops zu minimalisieren.

550MHz ist ein bisschen gewagt IMO, aber ich will mich ueberraschen lassen. Ich wuerde eher auf 500-525MHz raten, fuer den letzten Fall mit ein paar extra "Hand-Optimierungen".

Nimm mal alle Moeglichkeiten was die gesamte Produkt-linie von Value bis zu High end betrifft und skalier die Spekulationen von unten nach oben, angefangen von einem schnelleren RV360 als Basis. Noch weiter was wenn das "disable one block..." Konzept auch weiterhin benutzt wird, weil man es doch nicht als unrentabel empfand?

Demi,

Die Idee für die PS und VS die gleichen Einheiten zu nutzen hatte ich ja auch schon. Problematisch ist dabei allerdings das die meisten IHVs es derzeit bevorzugen Vertex daten einzeln zu bearbeiten und Pixel in Blöcken. Wobei es bei den Pixelblöcken ja primär um das einsparen von Kontrollogik geht. Wären da nicht so ein paar dumme anweisungen die Informationen von den nachbarpixel brachen wäre es eigentlich ganz leicht Pixel auch einzeln zu betrachten. Das einzige auffällige was dann PS und VS noch unterscheidet sind die Interpolatoren. Aber die Interpolatoren könnte man dann bei Vertexprocessing für HOS Geschichten "missbrauchen".

AHA! Interessant; wusste ich nicht.

Was S3 und XGI angeht bin ich mir nicht sicher ob man dort nicht auf die finale Spec gewartet hat bis man mit dem Design der Details angefangen hat. Und wenn man den Gerüchten glauben schenkt wollte MS eigentlich FP16/FP32 (wie es bei Medienprocessoren durchaus üblich ist) musste dann aber Zugeständnisse machen. Wie eine Spec zusammengestrichen werden kann weisst du ja selbst.

Ja schon, aber selbst die Kleinen IHVs sitzen nicht immer in einer Ecke und hoeren nur zu. Es gab tatsaechlich ein Wirrwarr mit den minimum 256 oder 512 Instruktionen fuer PS/VS3.0, so wie es aussieht und dass nur warum sich so manche darueber beschwert haben dass es zu viel ist. In der finalen Form wurde dann natuerlich doch auf 512 minimum festgesetzt.

Was floating point accuracy betrifft, gab es so eigentliche hin und her Gewerkel, und ich erwarte dass Microsoft ihre originale Vorstellung von "DX-Next" auch nie so wie sie heute in previews aussieht veroeffentlichen wird.

Ich wollte jetzt nicht damit sagen dass die "Kleinen" jetzt ploetzlich ein API definieren, aber so ganz unbedeutend ist ihre Meinung oder Stimme nun auch wieder nicht. Ich will sogar spekulieren dass wenn es nicht FP24 gegeben haette, dass vielleicht die Kleinen FP32 ueberhaupt nicht unterstuetzt haetten; na ja wenn dann vielleicht auf Papier heh....

[Ailuros]

Original geschrieben von MadManniMan
So gesehen könnte der R420 die GF4 von ATi werden... :grübel: Dabei stellt sich nur die Frage, inwieweit nV das Land sehen kann, wie ATi im Herbst 2002 auf die GF4 antworten zu können.
Tripipes? Neue AF-Dimensionen mit wenig Performancehit bei mindestens gleichwertigem AA? ... Ich wahrscheinlich nicht kreativ genug, aber an mehr als ein Speedupgrade bei ATi und eine Anpassung nVs an die erstrebenswerten R300-Dinge kann ich noch nicht so recht glauben... :ratlos:

Ist mir Meckermaul aber in beiden Situationen zu wenig. Wenn ich =/>400$ fuer so ein Produkt in H1 2004 wieder bezahlen soll, dass sind mir marginale Leistungs-steigerungen zu wenig.

:(

[Demirug]

Original geschrieben von Ailuros
Demi,

AHA! Interessant; wusste ich nicht.

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=72688

Meine Überlegungen in dem Punkt sind aber inzwichen viel weiter als das was ich da damals geschrieben haben.


Ja schon, aber selbst die Kleinen IHVs sitzen nicht immer in einer Ecke und hoeren nur zu. Es gab tatsaechlich ein Wirrwarr mit den minimum 256 oder 512 Instruktionen fuer PS/VS3.0, so wie es aussieht und dass nur warum sich so manche darueber beschwert haben dass es zu viel ist. In der finalen Form wurde dann natuerlich doch auf 512 minimum festgesetzt.

Was floating point accuracy betrifft, gab es so eigentliche hin und her Gewerkel, und ich erwarte dass Microsoft ihre originale Vorstellung von "DX-Next" auch nie so wie sie heute in previews aussieht veroeffentlichen wird.

Ich wollte jetzt nicht damit sagen dass die "Kleinen" jetzt ploetzlich ein API definieren, aber so ganz unbedeutend ist ihre Meinung oder Stimme nun auch wieder nicht. Ich will sogar spekulieren dass wenn es nicht FP24 gegeben haette, dass vielleicht die Kleinen FP32 ueberhaupt nicht unterstuetzt haetten; na ja wenn dann vielleicht auf Papier heh....

Die "Kleinen" werden als von ATI der Wunsch nach FP24 kamm bestimmt mit Freude zugestimmt haben.

[Ailuros]

Die "Kleinen" werden als von ATI der Wunsch nach FP24 kamm bestimmt mit Freude zugestimmt haben.

Und genau das meinte ich auch. Wie man es auch ansieht, es ist wohl wahrscheinlich auch ein Grund warum sich ATI's Idee doch durchgesetzt hat.

Meine Überlegungen in dem Punkt sind aber inzwichen viel weiter als das was ich da damals geschrieben haben.

Meine einzige Lektuere bis jetzt wo ich nachschlagen kann ist der B3D-DX Next Preview. Also hab ich noch mal schnell durchgeblaettert:

http://www.beyond3d.com/articles/directxnext/
http://www.beyond3d.com/articles/directxnext/index.php?p=6

Wenn man schon von vereinten Shadern spricht, warum wird dann spaeter in einem anderem slide PS frame buffer access erwaehnt? Da es nach dem Author womoeglich eine optionale Funktion sein wird, ist es wohl auch egal ob und wer es ueberhaupt implementieren wird.

Wie kann man theoretisch ueberhaupt Latenzen und cache misses verstecken oder ueberwaeltigen, wenn man zur gleichen Zeit vertex und pixel texture accesses hat, in einem unifizierten Shader Modell?

***edit: war wohl ne bloede Frage, denn ich hab den VM Teil wohl uebersehen....

[Demirug]

Original geschrieben von Ailuros
Und genau das meinte ich auch. Wie man es auch ansieht, es ist wohl wahrscheinlich auch ein Grund warum sich ATI's Idee doch durchgesetzt hat.

Was wäre wohl passiert wenn MS nicht darauf eingegangen wäre?

Meine einzige Lektuere bis jetzt wo ich nachschlagen kann ist der B3D-DX Next Preview. Also hab ich noch mal schnell durchgeblaettert:

http://www.beyond3d.com/articles/directxnext/
http://www.beyond3d.com/articles/directxnext/index.php?p=6

Wenn man schon von vereinten Shadern spricht, warum wird dann spaeter in einem anderem slide PS frame buffer access erwaehnt? Da es nach dem Author womoeglich eine optionale Funktion sein wird, ist es wohl auch egal ob und wer es ueberhaupt implementieren wird.

Wie kann man theoretisch ueberhaupt Latenzen und cache misses verstecken oder ueberwaeltigen, wenn man zur gleichen Zeit vertex und pixel texture accesses hat, in einem unifizierten Shader Modell?

***edit: war wohl ne bloede Frage, denn ich hab den VM Teil wohl uebersehen....

Vereinte Shader heisst ja nur das der Syntax und Funktionsumfang der gleiche ist. Gerade Informationen wie die aktuelle Framebuffer Farbe sind ja Eingangswerte und die sind ja sowieso unterschiedlich. Da sehe ich jetzt keine Wiederspruch weil es ja gar nicht anders geht.

VM macht die Latenzen bei Speicherzugriff aber eher schlimmer den besser. Es kann ja damit ständig passieren das man die entsprechenden Daten erst einmal aus einer anderen Quelle einlagern muss.

Versteckt werden die Latenzen indem man die entsprechende Pipeline lang (sehr lang) macht. Nach der Speicheranforderung schickt man den Pixel/Vertex erst mal auf die Wartebank bis das ganze im Cache angekommen ist. Genau diese lange Wartebank ist ja das Problem der NV3X PS. Da ist einfach nicht genügend Platz für fette (viele Temps) Pixel.

Es macht IMHO sehr viel Sinn schon bei VS/PS 3.0 auf eine gemeinsame Shader Funktionseinheit zu setzten. Damit spart man sich zumindestens den Ärger was das Teilen der TMUs angeht.

[robbitop]

meinst du dass man das bei nVIDIA/ATi genauso sieht und einen gemeinsamen Shader verwendet?

Ist dies bei der nV3x Architektur mit einem gewissen Aufwand realisierbar?
(über die R500 Architektur ist ja noch nicht allzuviel bekannt)

[Blutgrätsche]

Mir gefallen Quasars Spekulationen sehr gut: MSAA, Doom3, Performance statt Flexibilität usw. Unified shaders erfordern eine neue Architektur, die sich nicht einfach schnell aus dem Boden stampfen lässt. Ich erwarte also weiterhin getrennte PS und VS. An die Verlagerung der Berechnungen von traditionellen fixed function (FF) units - z.B. Triangle-Setup (bereits im VS enhalten?) oder Interpolatoren - glaube ich auch nur in einem begrenzten Masse. Die Rechenleistung der FF units ist enorm. FF units sind wesentlich billiger (etwa 2-3 fach billiger, das ist keine Spekulation) als programmierbare Einheiten, so dass auch Ineffizienzen oder "zu gross" gebaute Einheiten noch verschmerzbar sind. Sicherlich geht der Trend zu mehr Programmierbarkeit und Flexibilität. Aber GPUs, die VS, PS und FF in einem einzigen gigantischen (unwahrscheinlich) oder mehreren/vielen verteilten, programmierbaren Rechenwerken (wahrscheinlicher, siehe Sonys Cell-Processor) vereinen/aufteilen, erwarte ich erst im Jahr 2005.

Es ist relativ einfach und billig die Leistung für Doom3 bzw. Shadow-Volume Spielen massiv zu erhöhen, da hier nur Z/Stencil Leistung gefragt ist. Warum also nicht z.B. 32 Z/Stencil (Pixel) Berechnungen in die early Z/Stencil Einheit packen? Ailuros' "4- oder 5-way hierarchical Z" Gedanke ist Unsinn ('Tschuldigung). Zunächst braucht's ebenfalls Stencil-Berechnungen. Was allerdings wesentlich wichtiger ist: Wie soll überhaupt hierachical Z/Stencil funktionieren. Schritt 1: Z/Stencil-Vergleich auf oberster Ebene (z.B. 64x64 Pixelblock), also Speicher-Lesezugriff. Vergleich bringt kein eindeutiges/verwertbares Resultat. 2. Schritt: Z/Stencil-Vergleich auf nächst kleinerer Ebene (4x16x16). Wiederum Speicher-Lesezugriff und kein eindeutiges/verwertbares Resultat. 3. Schritt wie gehabt, bringt aber diesmal ein eindeutiges/verwertbares Ergebnis. Also Update/Schreiben aller oberen Ebenen. Was ist dann mit den anderen unteren Ebenen? Wieviele Daten (Bandbreite) werden gelesen/geschrieben? Und vor allem: Wie kompensiert man die hohen Latenzen des "multiple dependent memory read"? Blöder Vergleich: "4- oder 5-way hierachical Z" ist eine Kombination aus hierachischem Mipmapping (bereits zwei Takte für Trilinear, weil zwei verschiedene Addressen) und dependent texture read (Latenz des externen Speichers), also so ziemlich die übelste Kombination, die sich ein HW-Designer vorstellen kann. Niemand wird das so machen!

[Demirug]

Original geschrieben von robbitop
meinst du dass man das bei nVIDIA/ATi genauso sieht und einen gemeinsamen Shader verwendet?

Ist dies bei der nV3x Architektur mit einem gewissen Aufwand realisierbar?
(über die R500 Architektur ist ja noch nicht allzuviel bekannt)

Was nV/ATI macht darfst du mich nicht fragen. Eine PS 3.0 Unit könnte man auf jeden Fall relative leicht modifizieren so das sie auch VS 3.0 Programme ausführen kann.

[Xmas@home]

Original geschrieben von Blutgrätsche Es ist relativ einfach und billig die Leistung für Doom3 bzw. Shadow-Volume Spielen massiv zu erhöhen, da hier nur Z/Stencil Leistung gefragt ist. Warum also nicht z.B. 32 Z/Stencil (Pixel) Berechnungen in die early Z/Stencil Einheit packen? Ailuros' "4- oder 5-way hierarchical Z" Gedanke ist Unsinn ('Tschuldigung). Zunächst braucht's ebenfalls Stencil-Berechnungen. Was allerdings wesentlich wichtiger ist: Wie soll überhaupt hierachical Z/Stencil funktionieren. Schritt 1: Z/Stencil-Vergleich auf oberster Ebene (z.B. 64x64 Pixelblock), also Speicher-Lesezugriff. Vergleich bringt kein eindeutiges/verwertbares Resultat. 2. Schritt: Z/Stencil-Vergleich auf nächst kleinerer Ebene (4x16x16). Wiederum Speicher-Lesezugriff und kein eindeutiges/verwertbares Resultat. 3. Schritt wie gehabt, bringt aber diesmal ein eindeutiges/verwertbares Ergebnis. Also Update/Schreiben aller oberen Ebenen. Was ist dann mit den anderen unteren Ebenen? Wieviele Daten (Bandbreite) werden gelesen/geschrieben? Und vor allem: Wie kompensiert man die hohen Latenzen des "multiple dependent memory read"? Blöder Vergleich: "4- oder 5-way hierachical Z" ist eine Kombination aus hierachischem Mipmapping (bereits zwei Takte für Trilinear, weil zwei verschiedene Addressen) und dependent texture read (Latenz des externen Speichers), also so ziemlich die übelste Kombination, die sich ein HW-Designer vorstellen kann. Niemand wird das so machen!
Wieso sollte man einen dependent Read machen und nicht stattdessen unkonditional alle Werte des Blocks lesen? ATI speichert AFAIK immer nur einen Wert pro Block, nicht zwei. Das sind 24 Bit. Nehmen wir mal drei Ebenen hierZ an, so sind das 1 + 4 + 16 = 21 Werte á 24 Bit, 63 Bytes. Aufgrund des Zusammenhangs der Werte kann man möglicherweise auch noch etwas komprimieren. Ebenso kann man sie hervorragend cachen, und wenn man genügend Platz hat sogar vollständig on-Chip implementieren. 63 Bytes für einen 64x64 Pixel Block sind gar nicht allzu viel.

[Demirug]

Original geschrieben von Xmas@home
ATI speichert AFAIK immer nur einen Wert pro Block, nicht zwei.

Ja, immer nur einen Z-Wert pro Block. Deswegen soll man den Z-Test ja auch nicht umdrehen weil man sonst den Hir-Z Test komplett deaktivert. Wobei sie das beim R420 ja unter umständen ändern. Diese Sache wirkt sich ja negativ bei D3 aus.

[Blutgrätsche]

Original geschrieben von Xmas@home
Wieso sollte man einen dependent Read machen und nicht stattdessen unkonditional alle Werte des Blocks lesen? ATI speichert AFAIK immer nur einen Wert pro Block, nicht zwei. Das sind 24 Bit. Nehmen wir mal drei Ebenen hierZ an, so sind das 1 + 4 + 16 = 21 Werte á 24 Bit, 63 Bytes. Aufgrund des Zusammenhangs der Werte kann man möglicherweise auch noch etwas komprimieren. Ebenso kann man sie hervorragend cachen, und wenn man genügend Platz hat sogar vollständig on-Chip implementieren. 63 Bytes für einen 64x64 Pixel Block sind gar nicht allzu viel.
Ich nehme mal 32 bit =24 bit z + 8 bit stencil. Also 21x4 Byte = 84 Byte. Schlimmster Fall: 1600x1200/64*84 =252000 Bytes. Das Ganze on-chip zu speichern ist bei weitem zu teuer, aber cachen macht natürlich Sinn. Aber wozu überhaupt die 1+4 Bytes? Im schlimmsten Fall (der nicht ganz selten vorkommen sollte) muss man ohnehin die 16 Werte heranziehen. Warum also nicht auch die 5 Bytes weglassen und immer mehrere Blöcke parallel bearbeiten? Der Rechenaufwand (bisschen multiplizieren und vergleichen) kostet wirklich nicht die Welt. Nur hat man es dann eben nicht mehr mit einem hierachical Z zu tun. Ich glaube ja eh, dass mit hierachical z bestenfalls 2 Stufen gemeint sind: Der Blockbuffer und der normale Z-Buffer. Eine NV-Präsentation, die nicht nur ihren eigenen Ansatz diskutiert, erwähnt interessanterweise das Wort "hierachical Z" nicht, was darufhin deutet, dass der auch von NV diskutierte 2 Stufen Ansatz mit "hierachical Z" wohl eher eine falsche oder irreführende Bezeichnung trägt.

[Blutgrätsche]

Korrektur/Nachtrag: 1+4=5 Werte (nicht Bytes). Wenn zwei Werte pro Block, dann ist die Speicherung im Chip auch mit Kompression immer noch bei weitem zu teuer. Und notwendig ist es ebenfalls nicht unbedingt. (Der Z/Stencil Durchlauf braucht eh keinen Color-Buffer oder Texturzugriff).

[Xmas@home]

Original geschrieben von Blutgrätsche
Ich nehme mal 32 bit =24 bit z + 8 bit stencil. Also 21x4 Byte = 84 Byte. Schlimmster Fall: 1600x1200/64*84 =252000 Bytes. Das Ganze on-chip zu speichern ist bei weitem zu teuer, aber cachen macht natürlich Sinn. Aber wozu überhaupt die 1+4 Bytes? Im schlimmsten Fall (der nicht ganz selten vorkommen sollte) muss man ohnehin die 16 Werte heranziehen. Warum also nicht auch die 5 Bytes weglassen und immer mehrere Blöcke parallel bearbeiten? Der Rechenaufwand (bisschen multiplizieren und vergleichen) kostet wirklich nicht die Welt. Nur hat man es dann eben nicht mehr mit einem hierachical Z zu tun. Ich glaube ja eh, dass mit hierachical z bestenfalls 2 Stufen gemeint sind: Der Blockbuffer und der normale Z-Buffer. Eine NV-Präsentation, die nicht nur ihren eigenen Ansatz diskutiert, erwähnt interessanterweise das Wort "hierachical Z" nicht, was darufhin deutet, dass der auch von NV diskutierte 2 Stufen Ansatz mit "hierachical Z" wohl eher eine falsche oder irreführende Bezeichnung trägt.
Es gibt ja durchaus einige Forschung auf dem Gebiet, und es gibt dabei Erkenntnisse dass bis zu 5 Stufen bei heutigen Auflösungen Sinn machen könnten. Denn neben den Kosten sind ja auch die Ersparnisse enorm.

Deine Rechnung ist falsch weil du nur einmal durch 64 teilst. Wenn du 64x64 Pixel Blöcke mit drei Ebenen und Z+Stencil nimmst, kommst du bei einem 2048x2048 Rendertarget auf 32x32 Blöcke, also 84KiB.

[Blutgrätsche]

Original geschrieben von Xmas@home
Es gibt ja durchaus einige Forschung auf dem Gebiet, und es gibt dabei Erkenntnisse dass bis zu 5 Stufen bei heutigen Auflösungen Sinn machen könnten. Denn neben den Kosten sind ja auch die Ersparnisse enorm.

Deine Rechnung ist falsch weil du nur einmal durch 64 teilst. Wenn du 64x64 Pixel Blöcke mit drei Ebenen und Z+Stencil nimmst, kommst du bei einem 2048x2048 Rendertarget auf 32x32 Blöcke, also 84KiB.
1. Absatz ist mir zu ungenau und sagt nichts.

Jupp, die Rechnung ist falsch. Kommt davon, wenn ich 8x8=64 Pixel meine, aber 64x64 schreibe und dann auch noch deine Bytes übernehme und nur auf 32 bit anpasse. An meiner Argumentation und Schlussfolgerung ändert das aber auch nichts. (Jeder kann sich meinetwegen seine eigene Blockgrösse aussuchen. Allerdings: Je grösser die Blocks desto geringer die Wahrscheinlichkeit, dass sich damit was anfangen lässt.)

[Ailuros]

Original geschrieben von Xmas@home
Es gibt ja durchaus einige Forschung auf dem Gebiet, und es gibt dabei Erkenntnisse dass bis zu 5 Stufen bei heutigen Auflösungen Sinn machen könnten. Denn neben den Kosten sind ja auch die Ersparnisse enorm.

Deine Rechnung ist falsch weil du nur einmal durch 64 teilst. Wenn du 64x64 Pixel Blöcke mit drei Ebenen und Z+Stencil nimmst, kommst du bei einem 2048x2048 Rendertarget auf 32x32 Blöcke, also 84KiB.

Die Forschung bei ATI ist schon in diese Richtung gegangen; ob die Resultate der Vergangenheit jetzt gut waren oder ob dieses doch dann irgendwie benutzt wurde weiss momentan nur ATI.

Uebrigens gab es gleiche theoretische Vorbehaltungen in der Vergangenheit wenn 3-way hierarchical Z angesprochen wurde, lange vor der R300 Veroeffentlichung. Macro/micro tiling hoert bei weitem nicht mit 3-way auf.

Uebrigens B3D hat ja auch schon wieder einen relevanten Thread, wo man eigentlich sehen kann wie viel Ahnung jeder hat ueber R420; nur mehr Spekulationen:

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

Das mit dem V-buffer ist mir schon seit einiger Zeit bekannt und ich halte es als genauso bloede Idee wie die vorige Idee mit anderem Namen.

[betasilie]

Original geschrieben von Quasar
Ich spekuliere jetzt mal rein auf der Basis des schon vorhandenen:
ATi hat mit dem R300 einen großen Wurf gelandet, nV ist mit dem nV3x mehr oder minder auf die Schnauze gefallen (ok, soweit ist's keine Spekulation..).
Bis es DX-Next gibt, also es Zeit wird für zwingend notwendige, einschneidende Veränderungen, wird man bei ATi IMO (JETZT ist's Spekulation) eher den Weg weitergehen, der einen bis hierher zum Erfolg führte: brutal schnelle, aber "nur" eingeschränkt programmierbare 2.0-Shader. Das brächte ihnen Vorteile bei allen Spielen, die stark auf DX9 basieren und bereits in der Entwicklung sind, da die meisten (Spieler und Entwickler) mit der bisher gebotenen Feature-List ja durchaus zufrieden zu sein scheinen. Gleichzeitig könnte man mit diesem Schritt und der bisher erreichten Marktsättigung versuchen, die exzessive Nutzung von, ich nenn's mal nV-Shadern, einzudämmen.
Wenn man jetzt den Pfad verliesse, den man eingeschlagen hat, also die Shader in ihrer Mächtigkeit, nicht Redundanz stärkt, hätte man das Problem, das nV im nV30 mitgeschleppt hat, wie ein Klotz am Bein: Man könnte sich teilweise nur unzureichend von der Vorgängergeneration absetzen.


Das ist auch imo der wahrscheinlichste Weg, den ATI einschlagen wird, um dann direkt den Sprung zu 4.0Shadern zu machen.

Die Frage ist allerdings nun, wann wird ATI den Sprung zu einer Shader4.0 Architektur machen? Vielleicht doch früher, als wir alle denken? ... Selbst wenn so ein Chip knapp am dem DX-Next Siegel scheitern würde, aber gute PS2.0/3.0-Leistung bieten würde, hätte ATI dann einen soliden Grundstein gelegt für Folgeprodukte.

Somit hätte ATI die Technolgierevulotion für vernünftige 3.0-Shader übersprungen, um direkt einen ganzen Schritt zu machen und wäre ggf. trotzdem bei aktuellen und zukünftigen Anwendungen performant.

Naja, nichts ist unmöglich, aber ich halte das Quasars Ausführungen auch für am wahrscheinlichsten. ... Sauschnelle 2.0-Shader, die fürs Jahr 2004 reichen werden. Hinzu tippe ich dann noch drauf, dass der R420 wesentlich besser mit Stencilschatten zurrechtkommt. :D


Edit:
Trotzdem geht mir die Möglichkeit nicht aus dem Kopf, dass der R420 tatsächlich rudimentäre quasi-4.0Shader haben könnte, deren Priorität allerdings auf performanter 2.0Shader-Berechnung liegt. =)

[Ailuros]

Original geschrieben von Blutgrätsche
1. Absatz ist mir zu ungenau und sagt nichts.

Jupp, die Rechnung ist falsch. Kommt davon, wenn ich 8x8=64 Pixel meine, aber 64x64 schreibe und dann auch noch deine Bytes übernehme und nur auf 32 bit anpasse. An meiner Argumentation und Schlussfolgerung ändert das aber auch nichts. (Jeder kann sich meinetwegen seine eigene Blockgrösse aussuchen. Allerdings: Je grösser die Blocks desto geringer die Wahrscheinlichkeit, dass sich damit was anfangen lässt.)


Hierarchical z buffering would add even more benefit, especially if the upper levels were cached on the chip. I would recommend up to 5 levels (for quick elimination of large stencil polys, bounding volume occlusion checks, etc.).

Providing for the use of z occlusion culling using bounding volumes to eliminate unnecessary hidden vertex and pixel processing. This becomes an ever increasing issue as triangle rates and scene complexity increase. It think it important to provide this capability as a standard feature across all 3d hardware vendors and APIs. Z occlusion culling works particularly well with 5 or more levels of hierarchical z to quickly determine the visibility of the bounding volumes.

http://www.beyond3d.com/forum/viewtopic.php?p=47049&highlight=hierarchical+z#47049

Vom gleichen Herrn wurde dieser Absatz damals als Bloedsinn empfunden:

The merging of vertex shaders and pixel shaders into a single, completely programmable, high-level, floating point, 3D hardware language. Some vendors are likely to merge the floating point hardware functionality of pixel processors and vertex processors as well. In this case they would likely allocate the merged set of floating point processors dynamically much like P10 allocates them dynamically for just vertex shaders. --- timeframe: late 2003 - 2004

Kleiner Hint: er hockt auf der Ostkueste

:bäh:

Mehr Geblubber:

http://www.beyond3d.com/forum/viewtopic.php?p=12403&highlight=hierarchical+z#12403

http://www.beyond3d.com/forum/viewtopic.php?p=10148&highlight=hierarchical+z#10148

[Ailuros]

Original geschrieben von betareverse
Das ist auch imo der wahrscheinlichste Weg, den ATI einschlagen wird, um dann direkt den Sprung zu 4.0Shadern zu machen.

Die Frage ist allerdings nun, wann wird ATI den Sprung zu einer Shader4.0 Architektur machen? Vielleicht doch früher, als wir alle denken? ... Selbst wenn so ein Chip knapp am dem DX-Next Siegel scheitern würde, aber gute PS2.0/3.0-Leistung bieten würde, hätte ATI dann einen soliden Grundstein gelegt für Folgeprodukte.

Somit hätte ATI die Technolgierevulotion für vernünftige 3.0-Shader übersprungen, um direkt einen ganzen Schritt zu machen und wäre ggf. trotzdem bei aktuellen und zukünftigen Anwendungen performant.

Naja, nichts ist unmöglich, aber ich halte das Quasars Ausführungen auch für am wahrscheinlichsten. ... Sauschnelle 2.0-Shader, die fürs Jahr 2004 reichen werden. Hinzu tippe ich dann noch drauf, dass der R420 wesentlich besser mit Stencilschatten zurrechtkommt. :D

Wie gross sieht der Unterschied momentan zwischen 3.0 und den immer noch theoretischen 4.0 Shadern aus? Ach ja die letzteren haben vereinte PS/VS. Was sonst?

Mit PS/VS3.0 liegt die Anzahl der Instruktionen zwischen 512 und >32.000, das im Vergleich zum theoretischen "unlimited" in 4.0. Glaubt hier vielleicht jemand dass selbst R500 oder NV50 zu so krassen maximalen Zahlen die den "upper threshold" der 3.0 Shader signifizieren kommen werden?

Oben hab ich einen Link ueber derartige Spekulationen im B3D Forum ueber R420 gepostet. Ein bisschen mehr VS (in der tesselation Richtung womoeglich) Schnickschnack ergibt keine 4.0 Shader automatisch.

Zu dem hab ich ernsthafte Zweifel was voll programmierbare Tesselation in DX-Next betrifft und das nicht ohne Grund. Entwickler die ernsthafte und robuste HOS Unterstuetzung fuer DX-Next Architekturen erwarten, werden wohl teilweise enttaeuscht werden.

Um es zusammenzufassen R420's VS hat im besten Fall ein paar Anschlaege die leicht ueber die VS3.0 Spezifikationen (topology/tesselation) greifen, aber derartige trends sind genauso bei anderen PS/VS3.0 Architekturen zu erwarten. Also sagen uns derartige Spekulationen nichts neues. Grund zur Unruhe geben mir aber trotz allem die "hints" zu dem V-buffer und das Thema wurde ja auch schon des oefteren besprochen.


***edit:

Trotzdem geht mir die Möglichkeit nicht aus dem Kopf, dass der R420 tatsächlich rudimentäre quasi-4.0Shader haben könnte, deren Priorität allerdings auf performanter 2.0Shader-Berechnung liegt.

Siehe oben V-buffer (nur "V" anstatt von "F" uebrigens). Wieso jetzt eine von Grund auf CPU-artige Logik fuer PS/VS3.0 oder dynamic loops/branching eine bessere Idee sein koennte, ueberlass ich mal lieber Demirug.

Ich denke zwar nicht dass dynamic loops/branching in allen Faellen die beste Loesung ist, aber nur constant loops zu haben limitiert das Ganze viel zu viel in meiner primitiven Denkweise....

[zeckensack]

Witzig =)

Ich weiss ja nicht, warum ihr euch hier so auf CPU-artige Logik und zwischen Blöcken geteilte Funktionseinheiten einschiesst ... beides ist extrem teuer (in die space) und bringt IMO viel zu wenig Gewinn.

1)Demirug,
wegen "dynamic branching", ja, ist ein Problem, trotzdem gibt's bei Pixel Shading immer noch genug Entropie (die Werte sollten schon kontinuierlich sein, sonst hätte man Aliasing => kaputte Software).
Was ist besser:
a)Vierfach SIMD, ungleiche branches führen im worst case zu einem Durchsatzeinbruch auf 25%.
b)Vier komplett autarke Pipelines mit separater branch-Logik etc, die im gleiche worst case überhaupt nicht einbrechen, dafür aber auch viele viele Transistoren verschlingen.

Wie oft tritt der worst case auf? Ich schätze mal 5% aller Pixel gehen überhaupt unterschiedliche Wege durch dynamic branches, und ich schätze weiter, dass nur etwa 2% den worst case treffen.

Für sowas optimiert man nicht, das ist Verschwendung von Zeit, Geld und Energie.

2)"unit sharing"
Siehe oben. Das teure sind nicht die Funktionseinheiten, sondern die Kontroll-Logik (und die Cache-Anbindungen für Texturen, Shader-Code, Framebuffer-Blöcke, etc).

Aus 2xSIMD lässt sich sehr simpel 4xSIMD machen, und im Durchschnitt erreicht man eine vernünftige Durchsatzsteigerung.

Bevor ich sechs "verschiebbare" Funktionseinheiten baue, baue ich lieber einen 4xSIMD-VS und einen 4xSIMD-PS. Kostet auch nicht mehr Transistoren. Maximaler Durchsatzverlust pro Takt = 33%. Duh. Wahrscheinlich sogar weniger, weil ich kohärente Speicherzugriffe garantieren kann.
Und selbst wenn das nicht wichtig sein sollte ... Texturzugriffe aus dem VS und aus dem PS zB sind eben nicht gleich zu handhaben. Die Latenz-Charakteristik ist ganz anders, eben aufgrund der unterschiedlichen Position im Pipeline-Ablauf. Textur-Zugriff im PS hat ein ganz anderes Cache-Verhalten, und, und, und ...


Richtig interessant wird das ganze IMO nur bei TBDRs, aber da ist die Lösung auch viel eleganter ... :naughty:

[Demirug]

zeckensack, bei mir bezieht sich das CPU-artig eigentlich immer áuf den Punkt der (weitgehend) beliebigen Codefolge vorallem im Bezug auf gegenzeitige Abhängigkeiten (Dependent Reads). In diesem Punkt gibt ja ATI auch durchaus zu das je grösser diese Abhängigkeiten werden desto ineffektiver arbeitet iherer Lösung.

Was das SIMD angeht so habe ich AFAIR deine Lösung für Quads die unterschiedliche Codepfade brauchen ja schon selbst mal als gangbar ausgeführt. Ob es nun 4 fach oder 2 fach SIMD wird ist eine Frage der Optimierung. Optimieren kann man da allerdings erst wenn man Shader zur Simulation hat. Deswegen dürfte wohl first Gen PS 3.0 Hardware eher auf die bekannten Quads setzen. Bezüglich der Entropie würde ich aber sagen das PS 3.0 dazu verleiten werden harte brüche im Shading zu haben. Es ist durchaus verlockend ein Objekt das unterschiedliche Texturen nutzt auf einmal durchzujagen und nicht mehr Texturweise zu zerlegen. Die Tauglichkeit dieser Idee wird allerdings von der PS 3.0 Speed beim dynamic branching abhängen. Wenn es dabei heftige Unterschiede zwischen ATI und nVidia gibt könnten wir das gleiche wie schon mit den PS 2.0 nochmal (durchaus auch mit verdrehten Rollen) erleben.

Sicherlich kostet die Kontrollogik Transitoren im verhältniss zu einer "echten" CPU kommen GPU derzeit mit relative wenig aus. Ich erinnere mich das bei CPU mehr als die hälfte für die Kontrollogik verwendet wird. Zu dieser gehören aber auch die ganzen Dinge welche verhindern sollen das die Pipeline leerläuft oder blockiert. Diese Problem haben wir bei GPUs ja nicht. Die arbeit lässt sich ja sehr gut in viele kleine Threads aufteilen. 400-500 (oder noch mehr) völlig getrennt ausführbare arbeiten lassen sich in einem Grafikchip immer finden. Damit ist die Kontrollogik nahezu darauf begrenzbar das man neben den Funktioneinheiten ein Steuerwort mitschiebt welches jeder Einheit sagt was sie tun soll. Steuerbits die man dabei dann nicht mehr braucht muss man ja nicht mehr weiterschieben. Zudem könnte man dieses Steuerwort ja auch an mehrern stellen der Pipeline neu laden. Dann muss man nicht alle Bits von Anfang an durchschleifen. Wo da aber das beste Verhältniss liegt müsste man natürlich mit den geeigneten Mittel ausprobieren.

Was das "Unit Shareing" angeht so wirst du mich nicht davon abbringen das für eine gute Idee zu halten. Der VS und PS 3.0 Befehlsumfang ist nahezu identisch. Man könnte also ohne Probleme durch einen PS auch Verticen berechnen lassen. Was spricht also dagegen eine 4xSIMD Einheit zu bauen welche sowohl vom Vertex-DMA aus auch vom Primitive Setup gespeist wird. Die ergebnisse würden dann wahlweise in die ROPs oder den Post-Vertexcache gehen. Alles was man dafür tun müsste ist jedem "Quad" ein Bit mitgeben ob es sich nun um 4 Verticen oder 4 Pixel handelt. Das Bit könnte man auch in den Befehlssteuerwörtern hinterlegen. Das sind aber Details. Jagt man beides durch die gleiche Pipeline kann man eine hervoragende Lastverteilung ereichen. Man steuert einfach über die Gatekepper ob man als nächtest wieder Verticen oder Pixel berechnen möchte. Damit erreicht man in exxtremen Situationen (nur VS-Last oder nur PS-Last) sehr viel aber auch bei allem dazwischen ergibt sich eine gute Auslastung.

Was man dann natürlich noch steigern sollte ist die Auslastung der Einheiten in der Pipeline. Da wird ja viel verschwendung betrieben.

[zeckensack]

Original geschrieben von Demirug
Sicherlich kostet die Kontrollogik Transitoren im verhältniss zu einer "echten" CPU kommen GPU derzeit mit relative wenig aus. Ich erinnere mich das bei CPU mehr als die hälfte für die Kontrollogik verwendet wird.IMO noch viel mehr. Ich verweise auf den werten Hans de Vries (http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html) (K8-Übersicht in gross (http://146.82.66.43/news/Opteron_1600x1200.jpg)).
Den L2-Cache mal komplett rausgerechnet, würde ich 10% echte Arithmetik schätzen (7% FP, 3% Integer).
Zu dieser gehören aber auch die ganzen Dinge welche verhindern sollen das die Pipeline leerläuft oder blockiert. Diese Problem haben wir bei GPUs ja nicht. Die arbeit lässt sich ja sehr gut in viele kleine Threads aufteilen. 400-500 (oder noch mehr) völlig getrennt ausführbare arbeiten lassen sich in einem Grafikchip immer finden. Damit ist die Kontrollogik nahezu darauf begrenzbar das man neben den Funktioneinheiten ein Steuerwort mitschiebt welches jeder Einheit sagt was sie tun soll. Steuerbits die man dabei dann nicht mehr braucht muss man ja nicht mehr weiterschieben. Zudem könnte man dieses Steuerwort ja auch an mehrern stellen der Pipeline neu laden. Dann muss man nicht alle Bits von Anfang an durchschleifen. Wo da aber das beste Verhältniss liegt müsste man natürlich mit den geeigneten Mittel ausprobieren.Äh, ja, der Vergleich passt natürlich nicht exakt, sollte er auch garnicht.
Natürlich sollte es reichen, wenn man die Ausführungseinheiten mit den Informationen "Was", "Woher" und "Wohin" füttert, nur dadurch sparst du die Komplexität auch nicht wirklich ein. Du verlagerst sie an eine andere Stelle, eben was man bei CPUs unter Scheduling (und Retire) versteht. Schliesslich musst du die ganzen Ergebnisse auch wieder zurücksortieren, wenn du sie 'lose' durch die Pipeline jagst.
Was das "Unit Shareing" angeht so wirst du mich nicht davon abbringen das für eine gute Idee zu halten. Der VS und PS 3.0 Befehlsumfang ist nahezu identisch. Man könnte also ohne Probleme durch einen PS auch Verticen berechnen lassen. Was spricht also dagegen eine 4xSIMD Einheit zu bauen welche sowohl vom Vertex-DMA aus auch vom Primitive Setup gespeist wird. Die ergebnisse würden dann wahlweise in die ROPs oder den Post-Vertexcache gehen. Alles was man dafür tun müsste ist jedem "Quad" ein Bit mitgeben ob es sich nun um 4 Verticen oder 4 Pixel handelt. Das Bit könnte man auch in den Befehlssteuerwörtern hinterlegen. Das sind aber Details. Jagt man beides durch die gleiche Pipeline kann man eine hervoragende Lastverteilung ereichen. Man steuert einfach über die Gatekepper ob man als nächtest wieder Verticen oder Pixel berechnen möchte. Damit erreicht man in exxtremen Situationen (nur VS-Last oder nur PS-Last) sehr viel aber auch bei allem dazwischen ergibt sich eine gute Auslastung.4 Verts oder 4 Pixel?
Das kann's ja nun auch nicht sein. Eine getrennte Lösung kann immerhin beides parallel ausführen, und muss sich nicht entscheiden. Pipelining ahoi.

Stichwort Unterauslastung: es kann dir passieren, dass entweder der VS oder der PS zu wenig Arbeit hat. Die jeweils andere Einheit läuft dann aber fast garantiert unter Vollast (sofern nicht andere Probleme auftreten, Bandbreitenmangel zB, und da ist "Gewaltentrennung" eher im Vorteil). Auch hier gibt's also wieder einen worst case, und dieser führt zum völligen Stillstand von entweder VS oder PS. 50% Verlust also, wenn man so will.

Das finde ich nicht sooo tragisch, dass man dafür die komplette Architektur umschmeissen muss. Die richtige Balance kann man ja auch über die Anzahl (bzw SIMD-Breite) der Einheiten einstellen. Es ist ja immer noch eher so, dass in den allermeisten Fällen die Füllrate die Performance limitiert, sodass man den VS eher etwas kleiner auslegt.
Und unterausgelastete Pixel-Prozessoren sind dann Füllrate "for free", das kann man in höhere Auflösungen investieren. Ist IMO alles völlig unkritisch ... :)

[Quasar]

Original geschrieben von zeckensack
Witzig =)

Ich weiss ja nicht, warum ihr euch hier so auf CPU-artige Logik und zwischen Blöcken geteilte Funktionseinheiten einschiesst ... beides ist extrem teuer (in die space) und bringt IMO viel zu wenig Gewinn.


Ich fänd's schon einen Gewinn, wenn man mal ganz laienhaft gerechnet, den ganzen Ballast wegwirft (wie es ATi wohl stärker tat, als nV) und sich auf viele frei zuteilbare Funktionseinheiten konzentriert.

Szenario1:
Ich bin nV (in der prä-nV3x-Ära) und möchte weiterhin (Semi-)Profi-OpenGL Beschleuniger anbieten. Die brauchen IMO eine deutlich höhere Vertexleistung, als eine reine Gamerkarte.
Nun kann ich, wie beim nV30 geschehen, viele viele Transistoren darauf verwenden, ein recht mächtiges VS-Array zu basteln, mit dem ich diesen Markt bedienen kann.

Szenario2:
Ich bin nV (in der prä-nV3x-Ära) und möchte weiterhin Gamer-Karten anbieten, die auch mit den vielen vielen Spielen zurechtkommen, die einige ISV per OpenGL-Extension auf meine (lt. u.a. auch dir) früher recht fortschrittlichen und mächtigen Register Combiner optimierten.
Nun muss ich, wie beim nV30 geschehen, viele viele Transistoren aufwenden, um (waren's 8? *Nachschau*: jo) etliche Reg-Combiners einbauen, damit die älteren Games noch ordentlich laufen.

Szenario3:
Du ahnst es... ich bin nV blablabla und mir gehen die Transistoren aus, um zwei 4xSIMD-Pixelprozessoren einzubauen, um ein richtig fettes Temp-Register-File reinzuquetschen etc.pp. Ausserdem machen die Transistoren, die ich schon habe, zuviel Hitze, da meine Foundry nicht das leistet, was ich erhofft hatte (bzw. mein Design irgendwo einen Fehler hat).



Szenario4:
Ich bin nV, baue einen Unified Shader (spare mir das Ganze Legacy-Geraffel, extra HW für die DVD-/Video-Beschleunigung) und passe ihn je nach Erfordernissen statisch (per BIOS) oder dynamisch (per Treiber) an die gegebene Situation an.

Auch eine Möglichkeit, um prima Strom zu sparen. Die ganzen FP-Rechner kann ich im 2D-Modus abschalten, für DVD- und Video-Beschleunigung brauch' ich nur einen Bruchteil davon, ebenso für 2D-Strategie.
Wenn dann ein Freak ankommt und mir ProEngineer mit 40M-Poly-Szenen startet, aber nur Drahtgitter braucht, kann ich mir die in den Szenarien 1 & 2 brachliegenden "Pixel"-FP-Rechner zunutze machen und meine "Vertex"-FP-Rechenwerke unterstützen und vice-Versa, wenn ein Game mit 50k-Polys daherkommt, aber für jeden einzelnen Pixel einen 60-Instruktionen-PS laufen läßt.


(Merkt man, daß ich das P10-Konzept mag?) ;)

[Demirug]

Original geschrieben von zeckensack
Äh, ja, der Vergleich passt natürlich nicht exakt, sollte er auch garnicht.
Natürlich sollte es reichen, wenn man die Ausführungseinheiten mit den Informationen "Was", "Woher" und "Wohin" füttert, nur dadurch sparst du die Komplexität auch nicht wirklich ein. Du verlagerst sie an eine andere Stelle, eben was man bei CPUs unter Scheduling (und Retire) versteht. Schliesslich musst du die ganzen Ergebnisse auch wieder zurücksortieren, wenn du sie 'lose' durch die Pipeline jagst.

In wie fern "lose"? Du meist jetzt wenn ich den Quad auftrenne? Das hätte ich ja gar nicht vor. Ich würde einen Quad immer noch von einem Pixelprozessor bearbeiten lassen. Das ist ja schon notwendig wegen DDX/DDY. Die änderung wäre nur das ich pro Quad dann 4 durchläufe bräuchte. Wegen DDX/DDY müsste man dann noch einen Sync Befehl einbauen aber das ist ja nicht weiter kompliziert.

4 Verts oder 4 Pixel?
Das kann's ja nun auch nicht sein. Eine getrennte Lösung kann immerhin beides parallel ausführen, und muss sich nicht entscheiden. Pipelining ahoi.

Ähm ich meinte hier 4 Verts oder 4 Pixel pro Shadereinheit pro Übernahme Takt. Davon kann man dann natürlich mehrer pro Chip verbauen. Ein Highendchip hätte dann zum Beispiel 4 davon. Die "normale" Variante 3 und der kleinste 2.

Stichwort Unterauslastung: es kann dir passieren, dass entweder der VS oder der PS zu wenig Arbeit hat. Die jeweils andere Einheit läuft dann aber fast garantiert unter Vollast (sofern nicht andere Probleme auftreten, Bandbreitenmangel zB, und da ist "Gewaltentrennung" eher im Vorteil). Auch hier gibt's also wieder einen worst case, und dieser führt zum völligen Stillstand von entweder VS oder PS. 50% Verlust also, wenn man so will.

Das finde ich nicht sooo tragisch, dass man dafür die komplette Architektur umschmeissen muss. Die richtige Balance kann man ja auch über die Anzahl (bzw SIMD-Breite) der Einheiten einstellen. Es ist ja immer noch eher so, dass in den allermeisten Fällen die Füllrate die Performance limitiert, sodass man den VS eher etwas kleiner auslegt.
Und unterausgelastete Pixel-Prozessoren sind dann Füllrate "for free", das kann man in höhere Auflösungen investieren. Ist IMO alles völlig unkritisch ... :)

Gerade bei Fullscreen Effekten (Tiefenunschärfe, Glow, ...) bringt mir Füllrate reichlich wenig. Da hätte ich schon gerne die Rechenleistung der VS für das Pixelprocessing. Aber denken wir einmal weiter. Wenn die Texel-Füllrate der limitierenden Faktor ist dann verblasse ich sowieso PS-Rechenleistung. Was hält mich also davon ab mit dieser Rechenleistung Verticen zu rechnen? Natürlich muss man die Architektur etwas ändern. Aber so tramatisch ist das nun auch wieder nicht und man erreicht auf diese weise abenteuerlich hohe Leistungen bei den auch so beliebten theoretischen Zahlenangaben auf der Verpackung. :D

[Quasar]

Original geschrieben von Demirug
[...] man erreicht auf diese weise abenteuerlich hohe Leistungen bei den auch so beliebten theoretischen Zahlenangaben auf der Verpackung. :D

:lol: Ja, genau.

Entweder

Bis zu 30 Mrd. Polygone pro Sekunde
oder

Bis zu 4 Mrd. trilinear gefilterte Pixel pro Sekunde

[Demirug]

Original geschrieben von Quasar
Ich bin nV, baue einen Unified Shader (spare mir das Ganze Legacy-Geraffel, extra HW für die DVD-/Video-Beschleunigung) und passe ihn je nach Erfordernissen statisch (per BIOS) oder dynamisch (per Treiber) an die gegebene Situation an.

Auch eine Möglichkeit, um prima Strom zu sparen. Die ganzen FP-Rechner kann ich im 2D-Modus abschalten, für DVD- und Video-Beschleunigung brauch' ich nur einen Bruchteil davon, ebenso für 2D-Strategie.
Wenn dann ein Freak ankommt und mir ProEngineer mit 40M-Poly-Szenen startet, aber nur Drahtgitter braucht, kann ich mir die in den Szenarien 1 & 2 brachliegenden "Pixel"-FP-Rechner zunutze machen und meine "Vertex"-FP-Rechenwerke unterstützen und vice-Versa, wenn ein Game mit 50k-Polys daherkommt, aber für jeden einzelnen Pixel einen 60-Instruktionen-PS laufen läßt.

(Merkt man, daß ich das P10-Konzept mag?) ;)

Meine Lösung macht das ganze ja ständig dynamisch (Power Managment könnte man auch noch einbauen) selbst.

Was das jetzt mit dem P10-Konzept zu tun hat ist mir nicht ganz klar. Das einzige was man dort tun kann ist Funktioneinheiten abschalten. Also einen der beiden Memory-Kontroller. Bis zu 15 der 16 VS oder 3 der 4 Pixelprozessoren. Umverteilen kann man da leider nichts.

[Quasar]

Original geschrieben von Demirug
Umverteilen kann man da leider nichts.

Echt nicht? Komisch, ich dachte, genau dafür wäre der Schalter im Treiber für Geometrie- bzw. Pixeloptimerung da.

[Demirug]

Original geschrieben von Quasar
Echt nicht? Komisch, ich dachte, genau dafür wäre der Schalter im Treiber für Geometrie- bzw. Pixeloptimerung da.

Nach allem was ich an Konzepten und Patenten (in denen steht wirklich P10) gesehen habe geht das nicht.

Das der Schalter bei Geometrie Optimierung Pixel einheiten rauswirft ist ja schnell ersichtlich. Damit ist auch der Verlust an Fillrate erklärbar. Ich habe jetzt leider keine Benchmarks zur Hand die anzeigen wie stark der Vertexleistunggewinn dann ist. Als Erklärung fallen mir aber nur zwei Optionen ein:

-Bei der Pixeloptimierung sind VS deaktiviert weil der Chip sonst zu heiss wird/zuviel Strom zieht.
-Bei der Pixeloptimierung ziehen die Pixelprozessoren soviel Bandbreite an sich das für die VS nicht mehr genügend übrig bleibt. Das glaube ich aber selbst nicht so ganz weil man in diesem Fall ja bei untexturierten Flächen die volle VS Leistung bekommen sollte.

[Quasar]

Also einmal (http://www.tilebase.de/reviews/VP560/VP560_03.html) der Link zu Tilebase und der 'Vermutung', daß da Einheiten umgeschaltet werden (die Optimierung wird erst nach Neustart aktiv!) und weiter unten auf derselben Seite gibt's ein paar Unterschiede zwischen Textur- und Geometrie-Optimierung.

Andere Erklärungsangebote von Tilebase.de:
- Taktraten,
- Cachestategien
- Cachegrößen

[Demirug]

Original geschrieben von Quasar
Also einmal (http://www.tilebase.de/reviews/VP560/VP560_03.html) der Link zu Tilebase und der 'Vermutung', daß da Einheiten umgeschaltet werden (die Optimierung wird erst nach Neustart aktiv!) und weiter unten auf derselben Seite gibt's ein paar Unterschiede zwischen Textur- und Geometrie-Optimierung.

Andere Erklärungsangebote von Tilebase.de:
- Taktraten,
- Cachestategien
- Cachegrößen

Habe den Test damals auch gelesen und kurz darauf die Patente zum P10 gefunden. Das es irgendwie mit dem Speicher zu tun hat möchte ich ja wie schon gesagt nicht ausschliessen.

[Gast]

Original geschrieben von Ailuros

Kleiner Hint: er hockt auf der Ostkueste

:bäh:



SA arbeitet für ATi? Die sind doch inzwischen die einzigen, die an der Ostküste ein Team haben, oder?
3DLabs in Alabama zähle ich jetzt mal nicht zur Ostküste, da liegen ein paar Meter dazwischen, oder bist du da anderer Ansicht?

Ich dachte bisher immer SA arbeitet jetzt für Nvidia (und zuvor für 3DFx).

Danke für diese wichtige Info, wenn's denn stimmt.

[Ailuros]

Original geschrieben von Gast
SA arbeitet für ATi? Die sind doch inzwischen die einzigen, die an der Ostküste ein Team haben, oder?
3DLabs in Alabama zähle ich jetzt mal nicht zur Ostküste, da liegen ein paar Meter dazwischen, oder bist du da anderer Ansicht?

Ich dachte bisher immer SA arbeitet jetzt für Nvidia (und zuvor für 3DFx).

Danke für diese wichtige Info, wenn's denn stimmt.

Keine Ahnung wo genau er arbeitet oder wer er ist. IPs kann man aber auf messageboards sehen und diese dann auch dementsprechend "tracen".

Um ehrlich zu sein bezweifle ich dass er bei jeglichem der Graphik-IHVs arbeitet, aber im Grunde ist es mir auch egal. Was mir wichtig ist, ist dass seine Eingaben auf allen B3D boards meistens hoechst interessant und so objektiv wie moeglich waren.

[Blutgrätsche]

Ailuros,
ich wollte ja eigentlich nichts mehr zum hierachical Z Nebenthema schreiben, weil ich eigentlich schon alles wichtige gesagt habe, aber da ich dein Vorschlag einfach als Unsinn abgekanzelt habe, muss ich dann doch noch.

Erstmal eine weiterer SA-Link
http://www.beyond3d.com/forum/viewtopic.php?p=50700#50700
Folgt man den darin enthaltenen Link, dann gibt's vom Erfinder des HierZ (Greene) Modifikationen, um die Idee auf HW umzusetzen. Interessant ist dabei die stark modifizierte Datenstruktur im abschliessenden Teil, die es bei ATI (noch) nicht gibt. Ausserdem ist/war(?) Greene bei NV und aus seinen Patenten und Ideen ist jedenfalls bei NV nichts geworden.

Zum 4/5-way Hier-Z. Ich halte ja schon von 3 Stufen nicht viel, da kann ich mit 4/5 Stufen bzw. Ebenen noch weniger anfangen. Nehmen wir die von SA empfohlenen 5 Stufen, also 1,4,16,64,256 Pixelblöcke. HW rendert Dreiecke in Kacheln. Diese sind mindestens so gross wie die Anzahl der Pipes und maximal so gross, um ein Page-Break zu verhindern. Soweit ich weiss arbeiten alle HW-Hersteller mit maximal 8x8=64 Pixelblöcken. Die 256-Pixel Stufe kann mal also nicht mehr voll nutzen, da es so grosse Blöcke nicht gibt. Es ist auch wenig sinnvoll oder notwendig, 256 Pixel in einem Takt zu bearbeiten bzw wegzuwerfen. Woher kommt dieser extreme Drang (Gier) zur Optimierung? Der Fall tritt nur sehr selten ein und es reicht eigentlich aus, jeweils 64 Pixel in insgesamt vier Takten oder sogar jeweils 16 Pixel insgesamt 16 Takten wegzuwerfen, was auch besser der Geometrie eines Dreiecks (keine quadratische Bounding-Box) entspricht. Mein 32-Pixel Beispiel ist nur deshalb sinnvoll, da Stencil-Schatten leider ein schon absurdes Fillrate-Monster ist.

Kleine Dreiecke (nicht Schatten-Dreiecke) sind sehr problematisch für hierZ und die Regel. Einige andere wichtige Probleme (immer noch nicht alle und ggf. sogar generell unlösbar) hat SA schon beschrieben. Seine bester "Lösungvorschlag": Kleine Blöcke parallel bearbeiten, der hierZ Vorteil ist dabei kaum mehr auszumachen. Die höheren Stufen sind in der Regel unnütz und das Cachen der höheren Stufen impliziert eine doppelte Cache/Speicher Verwaltung. Das kostet Aufwand, teuren internen Speicher und zusätzliche externe Bandbreite mit (wie gesagt) fragwürdigen Nutzen. Alles, was ATI im Endeffekt bisher spart, ist mehr oder weniger Rechenleistung, die billig zu haben ist. Mit Doom3 muss/sollte nun die Rechenleitung massiv erhöht werden. Einen etwaigen minimalen Vorteil eines HierZ kann ich dann nicht mehr feststellen, und erst recht nicht durch eine Erweiterung auf 5 Stufen.

P.S.
Diese langen Postings sind mir einfach zu anstrengend. Ailuros, erwarte also keine weitere Antwort auf etwaige Postings deinerseits. (Darfst aber meine Argumente natürlich zerreissen.)

[Ailuros]

Diese langen Postings sind mir einfach zu anstrengend. Ailuros, erwarte also keine weitere Antwort auf etwaige Postings deinerseits. (Darfst aber meine Argumente natürlich zerreissen.)

Wenn ich wuesste was genau die Kerle bis jetzt angerichtet bzw nachgeforscht haben, dann koennte ich mich auch hinsetzen und ueber das Rechengewarkel zu argumentieren.

Es war kein Vorschlag; wenn ich weiss dass IHV sich mit Moeglichkeit X schon beschaeftigt hat intern, dann besteht immer die Moeglichkeit dass es ein Erfolg oder Misserfolg war und dementsprechend benutzt wurde/wird oder nicht.

Nehmen wir die von SA empfohlenen 5 Stufen, also 1,4,16,64,256 Pixelblöcke.

Und wo beschreibt SA die Idee genau, dass Du ueberhaupt vom obrigen ausgehst?

Mit Doom3 muss/sollte nun die Rechenleitung massiv erhöht werden. Einen etwaigen minimalen Vorteil eines HierZ kann ich dann nicht mehr feststellen, und erst recht nicht durch eine Erweiterung auf 5 Stufen.

Als ob Doom3 das "be all end all" waere. Aber wenn's schon sein muss die Idee Z/stencil Einheiten zu implementieren die sich dynamich re-konfigurieren koennten, hoert sich mir schon gut genug an (nein nicht meine Idee natuerlich). IMO haben die R3xx sowieso die groessten Probleme wenn stencil ops und MSAA kombiniert wird und natuerlich skaliert das Problem dementsprechend je hoeher die Anzahl der loops.

Doom3 gehoert uebrigens zu den von SA staendig erwaehnten "two pass mechanisms" oder das was er staendig mit "application driven deferred rendering" meint.

Ausserdem ist/war(?) Greene bei NV und aus seinen Patenten und Ideen ist jedenfalls bei NV nichts geworden.

Jegliche Occlusion Culling Implementierung fand wohl NV dann eines Morgens in der Post oder?

Aus Patenten/Ideen wird nicht immer etwas; es ist genug wenn eine durchaus toll erscheinende Idee irgendwo nur in einem Fall zusammenbricht. Oder kann es auch mit der HW zu knapp werden; der PPP-Mythos bei NV z.B. ist schon seit 2001 erschienen, gehoert aber zum ersten NV30 Flop.


Einige andere wichtige Probleme (immer noch nicht alle und ggf. sogar generell unlösbar) hat SA schon beschrieben. Seine bester "Lösungvorschlag": Kleine Blöcke parallel bearbeiten, der hierZ Vorteil ist dabei kaum mehr auszumachen.

Es sieht eher so aus als ob er in dem Post versucht hat die Probleme von hierarchical Z zu analysieren und moegliche Loesungen dafuer gegeben hat. Hier war die Loesung zum parallel plane Problem tatsaechlich eine Mischung aus ATI/NV Loesungen. For the record: tiles parallel zu bearbeiten ist auch keine gute Idee fuer TBDRs.

Das 5 way Hier.Z wird in einem anderen Thread und unter anderen Vorraussetzungen erwaehnt. Wobei er aber developer support in die Mischung warf, was gleich zu Widerspruechen fuehrte.

Wie waere es aber mit einem macro tile worth half a frame?

Kleine Dreiecke (nicht Schatten-Dreiecke) sind sehr problematisch für hierZ und die Regel.

Genauso fuer TBDRs, also braucht man hier wohl auch effiziente Loesungen.

Die höheren Stufen sind in der Regel unnütz und das Cachen der höheren Stufen impliziert eine doppelte Cache/Speicher Verwaltung.

Wobei naechster Generation Karten mit weniger als 256MB Speicher ankommen werden oder bleibt caching auch gleich ueber Generationen?

[Blutgrätsche]

Ailuros,
da wir ja jetzt unter uns sind, können wir ja mal locker-flockig unbeschwerten Smalltalk betreiben.

Original geschrieben von mir
Nehmen wir die von SA empfohlenen 5 Stufen, also 1,4,16,64,256 Pixelblöcke.
Original geschrieben von Ailuros
Und wo beschreibt SA die Idee genau, dass Du ueberhaupt vom obrigen ausgehst?
Naja, wenn man die hierZ Definition nimmt (und SA nichts weiter dazu schreibt), dann stimmt das schon so. Ausser vielleicht, dass der 1 Pixelblock dem Z-Buffer entspricht. Wenn man jetzt ATIs 3 Stufen nimmt (4,16,64) und auf 5 Stufen erweitert, dann wären das genaugenommen 4,16,64,256,1024 Pixelblöcke.

Original geschrieben von Ailuros
Als ob Doom3 das "be all end all" waere. Aber wenn's schon sein muss die Idee Z/stencil Einheiten zu implementieren die sich dynamich re-konfigurieren koennten, hoert sich mir schon gut genug an (nein nicht meine Idee natuerlich).

Doom3 gehoert uebrigens zu den von SA staendig erwaehnten "two pass mechanisms" oder das was er staendig mit "application driven deferred rendering" meint.
Man kann von John Carmack und Doom3 halten, was man will, aber er nutzt sein(en) Einfluss/Machtposition sehr geschickt: 1. Er hat sein 2-sided Stencil bekommen, um Geometrieleistung zu sparen. 2. Er hat seinen Algorithmus schon vor Jahren den IHV zugänglich gemacht und um spezielle HW-Optimierungen gebeten. NV hat auf das Fillrate-Problem mit 8 pipes Stencil/Z reagiert und ATI wird sicherlich mit dem R420 da nicht nachstehen wollen. 3. Sein Stencil-Schatten-Algo hat "Vorreiter"-Funktion und macht sich massiv in zukünftigen Spiele-Engines und Benchmarks (3DMark2003) breit. 4. Nur das Sihouetten- bzw. Schattenpolygon-Generierungs-Problem (TM) bekommt er erst in DXnext, was die Objekte wohl etwas kantig macht.

Die dynamische Reconfiguration verstehe ich nicht ganz. So wie ich es sehe ist es nicht sonderlich schwierig und darf auch ruhig Brute-Force sein. Es ist eigentlich nur sinnvoll, Stencil/Z am Anfang der Pixelverarbeitung (earlyZ) zu machen, um die weiteren Datenpfade nicht zu verbreitern und davon auch später Nutzen (Rendering-Pass) zu ziehen.

HW Deferred Shading ist nicht neu, z.B. die PixelFlow in den 90ern, wovon sich der PowerVR einiges abgeschaut (nicht kopiert) hat.

Original geschrieben von Ailuros
IMO haben die R3xx sowieso die groessten Probleme wenn stencil ops und MSAA kombiniert wird und natuerlich skaliert das Problem dementsprechend je hoeher die Anzahl der loops.
Hmm, widerspricht das meinem geraden Gesagten? Hab noch nicht darüber nachgedacht.

Original geschrieben von Ailuros
Jegliche Occlusion Culling Implementierung fand wohl NV dann eines Morgens in der Post oder?

Bin recht ratlos, was du damit sagen willst. Occlusion Query gab's in HW schon Anfang der 90er (Kubota) und Occlusion Culling ist davon nicht weit entfernt.

Original geschrieben von Ailuros
[Kleine-Dreiecke-Problem]
Es sieht eher so aus als ob er in dem Post versucht hat die Probleme von hierarchical Z zu analysieren und moegliche Loesungen dafuer gegeben hat. Hier war die Loesung zum parallel plane Problem tatsaechlich eine Mischung aus ATI/NV Loesungen. For the record: tiles parallel zu bearbeiten ist auch keine gute Idee fuer TBDRs.

Wobei naechster Generation Karten mit weniger als 256MB Speicher ankommen werden oder bleibt caching auch gleich ueber Generationen?

Wie waere es aber mit einem macro tile worth half a frame?

Genauso fuer TBDRs, also braucht man hier wohl auch effiziente Loesungen.
Wieso du jetzt TBDR dauernd einwirfst, bleibt mir schleierhaft.

Falls du es nicht gelesen hast, der Gast in diesem Thread war ich:
http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1424286#post1424286

[Ailuros]

Naja, wenn man die hierZ Definition nimmt (und SA nichts weiter dazu schreibt), dann stimmt das schon so. Ausser vielleicht, dass der 1 Pixelblock dem Z-Buffer entspricht. Wenn man jetzt ATIs 3 Stufen nimmt (4,16,64) und auf 5 Stufen erweitert, dann wären das genaugenommen 4,16,64,256,1024 Pixelblöcke.

Nochmal da ich es wahrscheinlich nicht klar genug gemacht habe:

Ich weiss nur dass Forschung betreffend >3-way Hier.Z schon vorkam, weiss aber nicht ob es ein Erfolg war und/oder ob es schon implementiert wurde.

Was jetzt genau SA damit meinte (da auch keiner damals nach Erlaeterungen fragte) kann ich auch nicht wissen. Ich hab aber trotzdem die Idee von "macro tiles worth half a frame" erwaehnt, ob es nun Sinn macht oder nicht ist eine ganz andere Sache und basiert nur auf persoenliche Spekulation. In dem Fall koennte man vielleicht die Szene in 2 oder 3 macro tiles aufteilen, und dann fuer jeden macro tile hierarchical Z wie zuvor anwenden. Hier koennte man diese macro tiles auch parallel bearbeiten.

Die dynamische Reconfiguration verstehe ich nicht ganz. So wie ich es sehe ist es nicht sonderlich schwierig und darf auch ruhig Brute-Force sein. Es ist eigentlich nur sinnvoll, Stencil/Z am Anfang der Pixelverarbeitung (earlyZ) zu machen, um die weiteren Datenpfade nicht zu verbreitern und davon auch später Nutzen (Rendering-Pass) zu ziehen.

Der Punkt war dass es mehrere als nur eine Loesung fuer das besagte Problem gibt. Wenn ich an eine Erweiterung von Hyper-Z denke dann ist es nicht nur auf stencil Leistung z.B. alleine konzentriert sondern Overdraw generell.

OT: Valve hat ja eine etwas komische Ankuendigung ueber zukuenftige HW und Spiele gemacht; wobei das was als "deferred rendering" erwaehnt wurde man wohl eher als deferred shading interpretieren sollte.

Bin recht ratlos, was du damit sagen willst.

Nur dass Greene einen respectablen Beitrag hatte im Bezug zu occlusion culling. Da Du in beiden Threads die Frage stellst wieso NVIDIA nicht Hierarchical Z benutzt hat bis jetzt, kommt gleich die Gegenfrage: warum benutzt NV nicht Gigapixel's TBDR?

Wieso du jetzt TBDR dauernd einwirfst, bleibt mir schleierhaft.

Wir reden doch die ganze Zeit ueber tiling oder nicht?

Spass beiseite manche Probleme sind auch da aufzutreffen (wie z.B. kleine Dreiecke) und nur aus dem Grund erwaehne ich es.

[Demirug]

Man muss einen Hir-Z Buffer ja nicht unbedingt speichern. Man kann in durchaus auch "On the Fly" erzeugen. Beim einladen und entpacken einer Z-Buffer Tile baut man in direkt auf. Geht man so vor macht es keinen Sinn den Hir-Z Buffer höher zu ziehen als die Tilegrösse ist. Natürlich gibt es auch hier die berühmte Aussnahme. Speichert man alle höheren Ebenen direkt im Chip kann man sie natürlich trotzdem nutzen.

Beim Stencilbuffer gibt es ja noch so einige Optimierungoptionen. Zum Beispiel folgenden Stencilwerte sind ja Skalare. Eine Pixelpipeline arbeitet aber mit Vector4 Werten. Theoretisch könnte man also 4 Stencilwerte pro Pixeloutput in den Shadern bearbeiten wenn man diese etwas erweitert. Dummerweise müsste man dabei unter umständen auch die 4 fache menge an Z-Werten berechnen. Dafür könnte man dann aber unter umständen die Interpolatoren für Texturekordinaten missbrauchen. Die braucht man ja bei einem Stencilpass sowieso nicht.