Displacement Mapping auf der Radeon9700

[del_4901]

Hi,

Ich hätte da mal ne Frage, und hoffe das sich jemand mit der Sache auskennt. Weis einer, ob das Displacement Mapping auf dem R300 über die Vertex Shader Einheit realisiert wird, oder ob die dem Chip dafür eine spezielle Einheit (wie beim Parhelia) spendiert haben?
Ließe sich das nicht auch irgendwie performancetechnisch über Software austesten?

[x-dragon]

Teile teils. Displacement Mapping umfast 2 verschiedene Modi, einer z.B. für Landschaften und so und der andere für was andere. Der R300 unterstützt einen davon direkt und der andere läuft über den Vertexshader. Die GeforceFX läßt glaube ich beides über die Vertex-Shader laufen.

Irgendwo hatten wir das erst vor kurzem, vielleicht kann jemand einen Link angeben, weiss nicht mehr wo das genau drin war :).

[x-dragon]

.

[Demirug]

Ja es gibt zwei Arten von Displacement Mapping der R300 beherscht aber nur die einfache Variante. Diese ist aber im wesentlichen nur zum sparen von Bandbreite geeignet und im Handling für den Grafiker sehr gewöhnungsbedürftig.

Die komplizierte Variante wird von Matrox unterstützt.

Was nun der NV30 kann ist noch etwas unklar weil es wiedersprüchliche Aussagen dazu gibt.

[del_4901]

Originally posted by X-Dragon
Teile teils. Displacement Mapping umfast 2 verschiedene Modi, einer z.B. für Landschaften und so und der andere für was andere. Der R300 unterstützt einen davon direkt und der andere läuft über den Vertexshader. Die GeforceFX läßt glaube ich beides über die Vertex-Shader laufen.

Irgendwo hatten wir das erst vor kurzem, vielleicht kann jemand einen Link angeben, weiss nicht mehr wo das genau drin war :).

Mit den zwei Arten war mir klar. (hätte vielleicht die Frage besser stellen sollen) Aber ich hab so den verdacht das der R300 zum Displacen auch nur die normalen Vertexshader Einheiten nimmt. Und nicht wie beim Parhelia, wo dafür extra Transitoren verbraten wurden. Der Sache würde ich gerne mal auf den tiefsten grund aller Gründe gehn, auch wenn das Feature eh in nächster Zeit nicht die Unterstützung findet, wie das Matrox gerne hätte.

[x-dragon]

Vielleicht hilft das schon mal etwas weiter(für weitere Infos den Links folgen):

Originally posted by Demirug
...
Jetzt zum Thema "Sparversion":

DX 9 kennt zwei DM Verfahren:

Das "normale" Displacement Mapping wie wir es von Matrox kennen und das ich nach wie vor gut finde.

Als zweites gibt es noch das "Pre-Sampled Displacement Mapping" das von mir als Sparversion bezeichnet wird. Der Grund dafür ist einfach. Beim Sample des Displacement Vectors ist nur Point sampling möglich. Und die Position in der Map wird auch nicht von irgenwelchen Texturkorrdinaten bestimmt. Es wird einfach für jedes Vertex das gerechnet werden soll ein Index erhöht. Die "Textur" wird aufgrund diese Index einfach linear ausgelesen. Daraus ergibt sich das es nicht möglich ist die tessellation einfach auf eine andere stuffe zu stellen. Den für jede stuffe ist eine eigene "Displacement Map" erforderlich. Und Adaptive tessellation geht damit schon mal gar nicht. Ergo es läst sich damit nur Speicher und Bandbreite (AGP oder RAM) sparen. Das Handling ist aber grausam.
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=41216&perpage=15&pagenumber=2
Originally posted by Exxtreme
Neues auf www.tommti-systems.de :

"So, bisher gibt es leider noch keine weitere Aufklärung zu diesem Thema von den beiden Herstellern. Fakt ist jedoch zur Zeit:

* In DirectX 9 gibt es 2 Arten von DM:
* Preimaged (Precomputed/Presampled) DM (3D-Objekte besitzen festen Grad der Tesssellation, keine adaptive Tessellation möglich, besser für 3D-Objekte, schneller als "sampled DM")
* Sampled DM (adaptive Tessellation möglich (LOD), besser für 3D-Landschaften)
* Matrox Parhelia unterstützt bisher als einziger VPU "Sampled DM" nach DirectX 9
* NVIDIA's GeForce FX unterstützt keinerlei DM nach DirectX 9, jedoch ist es möglich "Sampled DM" mittels der Vertex Shader zu erzeugen, geht auch schon mittels DX8
* ATi's Radeon 9700 PRO kann zur Zeit nur "Preimaged DM" nach DX9, "Sampled DM" ist wie beim GeForce FX per Vertex Shader möglich, zusätzlich beherrscht der R300 noch N-Patches mit adaptiver Tessellation."
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=41216&perpage=15&pagenumber=4

[del_4901]

Naja es ist nur so, der R300 hat mit seinen ca. 100Mio Transistoren erstaunlich wenig, als da noch Platz währe für ne DM-Einheit (das weis Ati wohl eh besser als als ich, sei aber mal so dahingestellt) Die Vertexshader liegen aber eh im normalfall Größtenteils brach, da sie vom AGP-Bus bzw. der CPU nicht schnell genug befüttert werden können. Es würde also Sinn machen den DM Support in die vertesxshader zu verlagern, um den Transitorcount niedrig zu halten. Trueform ist ja auch schon "rausgeflogen". Bei einem so großem Chip macht das durchaus Sinn. Und wenn sie wirklich eine extra DM-Einheit haben sollten, warum haben sie dann nicht gleich sowas wie Matrox ringefriemelt (noch mehr Transistoren?) Halbe Sachen machen war noch nie ne Art von Ati. Ausserdem kahm der Parhelia vor dem R300, entweder der DM- Support wurde nachträglich "emuliert", weil man gesehn, hat wenn die das machen, dann brauchen wir das auch. Oder Es stand seid 2 Jahren fest, das der Chip Preimaged DM "blos" haben wird, und Ati hat sich von vornherein darauf eingelassen, wie ich schon erwähnte "halbe Sachen zu machen". Oder Sampled musste dem Transitorcount weichen. Aber Ati gibt dazu recht wenig Informationen.

[betasilie]

* ATi's Radeon 9700 PRO kann zur Zeit nur "Preimaged DM" nach DX9, "Sampled DM" ist wie beim GeForce FX per Vertex Shader möglich, zusätzlich beherrscht der R300 noch N-Patches mit adaptiver Tessellation."

So soll es sein.

[Xmas]

Die Beschreibung von Tommti-Systems stimmt aber nicht, da nicht Sampled DM, sondern nur Presampled DM per Vertex-Shader möglich ist.

[Demirug]

Originally posted by Xmas
Die Beschreibung von Tommti-Systems stimmt aber nicht, da nicht Sampled DM, sondern nur Presampled DM per Vertex-Shader möglich ist.

Ja Xmas, sampled DM geht nur dann mit den Vertexshadern wenn diese zugang zu einer TMU haben.

NVIDIA will dieses Problem auf eine recht brutale Art und Weise lösen.
Die Daten werden einmal durch die gesamte Pipeline (VS und PS) geschoben und der dabei entstehende Datenstrom wird in den Speicher geschrieben. Danach wird in einem zweiten Pass aufgrund dieser Daten das entgültige Ergebniss gerendert. Die Performance dürfte dabei aber nicht so gut sein.