Programmable Primitive Processor

[Ailuros]

Da das "triple-P" staendig in den Spekulationen der letzten Zeit erscheint, und die Informationen ueber die Einheit eher karg sind, kann jemand mal beschreiben zu was es eigentlich gut sein kann, selbst wenn API Unterstuetzung theoretisch fehlen wuerde?

Danke im voraus :)

[Demirug]

In der Vergangeheit wurde das Tri-Setup auch gerne als "Primitive Processor" bezeichnet weil dort alle arbeiten auf Primitiveebene (= Dreiecke, Linien, Punkte) erledigt wurde. Mit dem Aufkommen von HOS-Verfahren hat sich das jedoch etwas verschoben. Der Primitive Processor sitzt jetzt eigentlich vor dem Trisetup da er nun auch in der Lage sein muss zusätzliche Dreiecke zu erzeugen. Seit es also HOS-Verfahren in den Chips gibt ist der Primitive Prozessor die Einheit welche die Primitives erzeugt und das Trisetup zerlegt diese dann in Pixel/AA-Samples. Bisherrige "Primitive Prozessoren" sind recht blöd im besten Fall vergleichbar mit dem was HT&L auf Vertexebene ist. Man kann ein bischen was konfigurieren und das war es auch schon.

Ein Programmable Primitive Prozessor wäre dann also ein Primitive Shader im DX Sprachgebrauch welcher es erlaubt selbst zu entscheiden welche Primtives überhaupt zum Trisetup weitergereicht werden oder auch neue Primitives erzeugen kann.

Was man damit machen kann:

- Eingene HOS-Verfahren.
- dynamisches Geometrie LOD.
- Prozedurale Geometrie
- Geometrie kompression verfahren.
- ...

[loewe]

Das wäre dann ja eigentlich eine recht "intelligente" Einheit. Dafür werden doch eine ganze Menge Transistoren gebraucht.
Wird so ein PPP dann auch schon von den APIs unterstützt oder kann das Ding auch etwas tun, ohne eine spezielle Unterstützung durch die APIs/ Aplication?

Ansonsten könnte man sich das doch besser sparen?! Bei den NV Chips hat man ja doch immer wieder mal gemunkelt, nun ja auch wieder beim NV40?!

[Demirug]

Unter OpenGL schreibt sich ja jeder Hersteller seine API selbst.

Unter DX könnte man das ganze erst mal nur für die HOS Sachen die schon definiert sind benutzten.

Das man das bei NV immer wieder munkelt ist eigentlich kein Wunder steht ja in der Technologieroadmap drin. Das heist aber nicht das und vorallem wann es kommt. Diese Roadmap ist eher so eine Liste mit "Dinge die wir im Auge behalten". Da stehen auch so Sachen wie TBDR und eDRAM drin.

[Ailuros]

Unter DX könnte man das ganze erst mal nur für die HOS Sachen die schon definiert sind benutzten.

Eventuell auch Displacement Mapping durch VS3.0 z.B.? (fuer N-patches war ich sowieso nie sehr begeistert).

Ich denke ein PPP macht Euch Entwicklern das Leben dann (noch mehr bei voller API Kompatibilitaet) leichter, oder?

Ich hab uebrigens den Thread hier aufgemacht weil bei B3D das Ganze nur sehr karg besprochen wurde. Da wurde auch erwaehnt dass ein PPP ohne "dynamic allocation" nicht allzu viel Sinn macht.

***edit:

oooops haette ich fast uebersehen...

Geometrie kompression verfahren.

Bringt denn die Komprimierung von Geometrie eigentlich etwas? Ich hab mal vor einiger Zeit die derzeitige Forschung uber Geometrie-Kompression verfolgt und die Resultate sahen nicht besonders berauschend damals aus.

[Demirug]

Original geschrieben von Ailuros
Eventuell auch Displacement Mapping durch VS3.0 z.B.? (fuer N-patches war ich sowieso nie sehr begeistert).

jeder Chip der 3.0 fähige VS hat sollte auch DM in allen Varianten anbieten können. Der Treiber müsste bei Bedarf ja einfach vor den eigentlichen Shadercode nur noch ein paar Anweisungen setzten.

Allerdings können die VS nur den Texturesampleanteil übernehmen. Für das verfeinern der Geometrie braucht man nach wie vor ein HOS-Verfahren welches dann natürlich auch auf einem PPP laufen könnte.

Ich denke ein PPP macht Euch Entwicklern das Leben dann (noch mehr bei voller API Kompatibilitaet) leichter, oder?

Ja und Nein. Mann kann damit dann dinge tun die man sich vorher aus performancegründen nicht gewagt hat aber irgendwann wird dann auch erwartet das man es tut.

Ich hab uebrigens den Thread hier aufgemacht weil bei B3D das Ganze nur sehr karg besprochen wurde. Da wurde auch erwaehnt dass ein PPP ohne "dynamic allocation" nicht allzu viel Sinn macht.

Hängt davon ab wie man "dynamic allocation" definiert. Ein PPP der nur Dreiecke löschen aber keine erzeugen kann ist nur begrenzt tauglich. Warscheinlich wir eine Kenngrösse eines PPP sein wie viele Primtive er gleichzeitig bearbeiten kann.

Bringt denn die Komprimierung von Geometrie eigentlich etwas? Ich hab mal vor einiger Zeit die derzeitige Forschung uber Geometrie-Kompression verfolgt und die Resultate sahen nicht besonders berauschend damals aus.

Keine Ahnung ich weiss nur das es der NV2A kann und es scheinbar auch eigesetzt wird.

[Ailuros]

Wenn ich mich nicht irre hiess es dass Gigapixel ein gutes Geometrie-Kompressions Verfahren hatte. Das muss jetzt nicht heissen dass das Verfahren von NV2x etwas damit zu tun hat.

Die Debatte war damals heiss, als man hoerte dass bei FEAR der getrennte Geometrie-chip SAGE II biz zum theoretischen maximum von 250M vertices/sec (125M sustained) ging, wobei dann die "Spekulationen" auf eine Kombination von dedikiertem Speicher fuer Sage2, hierarchical Z und Geometrie-Kompression tendierte, um die binning Probleme zu uebergehen.

Ich hab irgendwo ein paar Studien uber solches Zeug ausgedruckt, aber wie gesagt sah es eher so aus als dass die Resultate bzw. Vorteile nicht all zu gross waren.

Danke nochmals fuer die ausfuerliche Erklaerungen. Auesserst interessant :)

[Pitchfork]

Sehen wir es doch mal von der API Seite. Wenn NV einen PPP in den nv40 einbauen will, dann wissen sie es seit langer Zeit. Und dann weiß es auch Microsoft. Und wenn Der PPP wirklich deutlich besser ist als das, was DX9 bisher bietet, dann hätte Microsoft auch entsprechende API für angeboten. Wenn also ein PPP kommt, wo ich mir wirklich noch nicht sicher bin, dann wird der PPP für NV eher ein Testlauf sein, um mit den Features zu experimentieren und er wird unter DX nur die bekannten API Sachen unterstützen und dem Coder keine Freiheiten lassen. Und auch unter OpenGL wird wohl nicht viel mehr gehen, einfach weil der PPP eher ein Testballon sein wird (wobei in Kombination mit vs_3_0 sind nPatches und Bezier Patches nicht gerade wertlos).... ähnlich wie das Presampled Displacement Mapping auf der R300.
Der Coder wird vom P im PPP erst mit DX10 und in einigen Jahren was haben.

Pitchfork

[Demirug]

Es wäre nicht das erste Mal das nv was in die Hardware einbaut was durch DX nicht abgedeckt wird und dann mit merkwürigen Tricks die Benutzung doch möglich macht.

[Ailuros]

Original geschrieben von Demirug
Es wäre nicht das erste Mal das nv was in die Hardware einbaut was durch DX nicht abgedeckt wird und dann mit merkwürigen Tricks die Benutzung doch möglich macht.

*ouch* ROFL das bringt ein paar gute alte Erinnerungen zurueck (nein nichts illegitimes, so wie cheats).

Wenn NV als einziger IHV einen PPP hat, dann sind die Chancen fuer volle API Kompatibilitaet unter DX geringer. Wenn aber mehrere IHV's einen haben werden, bin ich mir nicht so sicher ob M$ nicht doch noch einen kleinen DX Update liefern koennte; normalerweise waere allein der Druck vom Markt-Fueher genug. Kommt ganz drauf an wie stur M$ diesmal mit ihren Updates sein will.

Aber es wird wieder zu spekulativ damit; ich wollte nur eigentlich wissen zu was das Ding eigentlich gut sein kann.

Fuer OGL zumindest braucht man eben dann nicht unbedingt extravagante Tricks um es einzusetzen, so wie ich es verstanden habe.

[Pitchfork]

Original geschrieben von Demirug
Es wäre nicht das erste Mal das nv was in die Hardware einbaut was durch DX nicht abgedeckt wird und dann mit merkwürigen Tricks die Benutzung doch möglich macht.

MS wird ein so bedeutendes Feature (wenn es denn wirklich das bringt, was die Spekulationen versprechen) nicht einfach so ignorieren können und wollen. Wir reden hier ja nicht um Kleinigkeiten in den Register Combinern oder Shadow Buffer sondern um ein wesentliches Hardware Feature, das die Art, wie Content für Spiele erstellt wird, langfristig wesentlich umkrempeln können wird. Ich weiß, was die Gerüchteküche für DX10 als Termin nennt, aber wenn 2003 ein funktionalier PPP auf den Markt kommt, kann Microsoft schwerlich das Ding erst 2004+ unterstützen.

Nochmal:

- entweder ist das ne Ente
- oder es ist ein Testballon und deckt erstmal nur nPatches und rtPatches unter DX ab und über den praktischen Nutzen wird man noch lange streiten

Pitchfork

PS: Wieviele Jahre nach Erscheinen eines PPP wird dieser in Spielen ernsthaft eingesetzt?
Beginnt die Uhr mit der Verfügbarkeit der Hardware oder mit dem finalen API zu ticken?

[Demirug]

Original geschrieben von Pitchfork
MS wird ein so bedeutendes Feature (wenn es denn wirklich das bringt, was die Spekulationen versprechen) nicht einfach so ignorieren können und wollen. Wir reden hier ja nicht um Kleinigkeiten in den Register Combinern oder Shadow Buffer sondern um ein wesentliches Hardware Feature, das die Art, wie Content für Spiele erstellt wird, langfristig wesentlich umkrempeln können wird. Ich weiß, was die Gerüchteküche für DX10 als Termin nennt, aber wenn 2003 ein funktionalier PPP auf den Markt kommt, kann Microsoft schwerlich das Ding erst 2004+ unterstützen.

Nochmal:

- entweder ist das ne Ente
- oder es ist ein Testballon und deckt erstmal nur nPatches und rtPatches unter DX ab und über den praktischen Nutzen wird man noch lange streiten

Pitchfork

Ich glaube ja auch nicht wirklich daran das wir sowas schon im NV40 sehen werden. Zumindestens nicht in einer voll programmierbaren Form. PS 3.0 sind da erst mal herausforderung genug an die Designer.

IMHO kommt das Gerücht aus der gleichen Quelle nach der jede neue Generation von nVidia ein DR ist.

PS: Wieviele Jahre nach Erscheinen eines PPP wird dieser in Spielen ernsthaft eingesetzt?
Beginnt die Uhr mit der Verfügbarkeit der Hardware oder mit dem finalen API zu ticken?

Die guten alten 24 Monate würde ich mal sagen. Und was die Uhr angeht bin ich geneigt Hardware zu sagen. Aufgrund der API kann man sich zwar überlegen was man damit anstellen könnte aber ohne den Reality Check mit echter Hardware ist sowas verdammt heiss.

[Pitchfork]

Original geschrieben von Demirug

Die guten alten 24 Monate würde ich mal sagen. Und was die Uhr angeht bin ich geneigt Hardware zu sagen. Aufgrund der API kann man sich zwar überlegen was man damit anstellen könnte aber ohne den Reality Check mit echter Hardware ist sowas verdammt heiss.

Ich denke, es müssen sowohl halbwegs finales API und gescheite Hardware zusammen verfügbar sein, bevor da irgendwas passiert. Dh. wir sehen imho vor 2006 keine Spiele die einen PPP ernsthaft benutzen. Wobei sich das Ding wohl recht schnell für eine Terrain Engine einsetzen ließe oder für nen guten Ozean.

[Demirug]

Original geschrieben von Pitchfork
Ich denke, es müssen sowohl halbwegs finales API und gescheite Hardware zusammen verfügbar sein, bevor da irgendwas passiert. Dh. wir sehen imho vor 2006 keine Spiele die einen PPP ernsthaft benutzen. Wobei sich das Ding wohl recht schnell für eine Terrain Engine einsetzen ließe oder für nen guten Ozean.

Ja klar ohne API ist die Hardware recht wertloss.

Für Terrain/Wasser sollte (echtes) DM aber schon ausreichen da braucht man nicht unbedingt einen PPP.

Schattenvolumen müssten sich auch noch relative schnell umsetzen lassen.