128 Bit Rendering

[aths]

Habe ich da was verpasst? Sowohl ATI als auch nV reden davon. Meinen die, intern 32 Bit pro Kanal (und dann 16 Bit im Framebuffer pro Kanal?)

Sind interne 32 Bit (sofern das zutrifft) nicht etwas großzügig bemessen?

[Demirug]

128 bit sind 32 bit pro Kanal. Allerdings Fliesspunkt.

Im Framebuffer ändert sich nichts. Da bleibt es bei 32 bit (8:8:8:8 oder 2:10:10:10). Es werden allerdings Offscreenn Surfaces mit 128 bit unterstützt. Diese können dann für Multipass mit hoher genauigkeit eingesetzt werden. Eine nette Sache dabei ist noch das man in einem Pass in mehr als einen Offscreen Buffer schreiben kann.

"großzügig bemessen?"

Eigentlich schon den Pixar benutzt 64 bit FP. Deshalb gibt es bei NVIDIA (ATi bin ich nicht sicher) auch einen 64 bit FP Mode (der wahrscheinlich schneller ist). Allerdings kann man damit wohl nur Texturen bis 1024*1024 benutzen.

JC wird freuen der schreit ja schon lange danach.

[aths]

Demirug, ich habe die DX9-Specs nicht hier, daher noch mal explizit die Nachfrage: DX9 setzt nicht voraus, dass auch ein 64-Bit-Framebuffer angeboten wird (oder zumindest 48 Bit?) Da vergeht einem ja (trotz 8 Texturen pro Pass) die Lust...

Soll der 32-Bit-Framebuffer weiterhin nur Fixpunkt-Werte aufnehmen?

[Demirug]

aths,

hab das passende Document gerade nicht zu hand. Das steht leider nur in der neuen Treiberspec. Aber wenn mich mein gedächtnis nicht im Stich läst wird dort nur von 2:10:10:10 als neuerung beim Framebuffer gesprochen.

Bei 32 Bit macht was anderes als Fixpunkt keinen Sinn. Für Flisspunkt sind das zuwening bits.

In Summe dürfte das aber nicht so Problematisch werden. Mit DX9 wird es wohl primär nur noch zwei Arte von Engine geben.

- All in one Pass
- Every Light one Pass

Bei der ersten ist das ja unproblematisch da ja Framebufferblending nur für Transparenz gebraucht wird.

Im zweiten Fall (DOOM III auf Hardware mit 7 Texturzugriffen pro Pass) sieht die Sache auch problematischer aus als sie ist. Die einzelnen Farbwerte der Fragmente werden ja nur addiert. Bei Additionen gibt es aber keine Problem mit der geringen Bitauflösung des Framebuffer.

[nggalai]

Hi aths,

zumindest laut dem letzten Siggraph-Paper von NV wird der Framebuffer 32bit FP bieten (IMO die einzige sinnvolle Lösung--sonst kannst Du Multipass-Rendering und render-to-texture bei voller Qualität wohl vergessen). Wie aber Demiurg schon im anderen Thread andeutete, ist hier die Frage, was denn NV hier genau als "Framebuffer" versteht.

ta,
-Sascha.rb

[nggalai]

*forum-tret*

[aths]

Danke für die Antworten.

64 Bit FP-Rendering bei 32 Bit Fixpunkt-Framebuffer würde ich angesichts der 8 Texturen einsehen. 128 Bit Rendering beim 32 Bit Framebuffer halte ich für übertrieben. Oder übersehe ich da was?

[Demirug]

aths,

ich hab ja schon gesagt das 64 bit ausreichen würden. In einem NVIDIA document wird allerdings darauf hingewissen das die Texturen dann nur noch 1024*1024 sein dürfen.

P.S. Wenn ich die NVIDIA Docs richtig verstanden habe wollen die 16 Texturen bei 1024 Zugriffe erlauben. Deine Spekulation würde dann ja doch stimmen.:D

[aths]

Demirug, dann verstehe ich nicht wieso sie (in diesem Falle erst mal ATI) Transistoren für 32 Bit verpulvern, wenn 16 Bit ausreichend wären. Gäbe es dafür eine Erklärung, die du dir vorstellen könntest?

[Demirug]

aths,

bin mir nicht ganz sicher aber irgendwo in den VS 2.0 Specs steht was von 32 bit FP Werte. Muss das aber nochmal genau nachprüfen in welche Zusammenhang. Dazu brauche ich aber die WinHEC Dokumente und die liegen leider im Büro.

Ansonsten habe ich den Verdacht das beim NV30 die ALUs so gebaut sind das sie entweder eine Instruktion mit 32 Bit oder 2 mit 16 Bit durchführen können.

[AlfredENeumann]

Originally posted by aths
Demirug, dann verstehe ich nicht wieso sie (in diesem Falle erst mal ATI) Transistoren für 32 Bit verpulvern, wenn 16 Bit ausreichend wären. Gäbe es dafür eine Erklärung, die du dir vorstellen könntest?

Könnte dir das (http://www.lostcircuits.com/video/ati_9700/8.shtml) weiterhelfen ?
Und vielleicht brauchen die das noch hierfür (http://www.ati.com/products/workstation/fireglx1/index.html).

[aths]

Alfred,

Bumpmapping kann zusätzliche Präzision gebrauchen, ja. Soweit ich weiß, gibt es aber für 32 Bit pro Kanal kein entsprechendes Texturformat. Das Beispiel selbst arbeitet ja auch mit "nur" 16 Bit, und nicht 32.

[AlfredENeumann]

Originally posted by aths
Alfred,

Bumpmapping kann zusätzliche Präzision gebrauchen, ja. Soweit ich weiß, gibt es aber für 32 Bit pro Kanal kein entsprechendes Texturformat. Das Beispiel selbst arbeitet ja auch mit "nur" 16 Bit, und nicht 32.

Aber erreichst man nicht mit höherer Präzision bessere Farbverläufe ?

[AlfredENeumann]

hab da in einem Preview auch was drüber gesehen. muß mal genau raussuchen

[aths]

Originally posted by AlfredENeumann
Aber erreichst man nicht mit höherer Präzision bessere Farbverläufe ? Die Bump- bzw. Normalmap kann feiner quantisiert werden, was mehr Details erlaubt. Die Grenzen heutiger Normalmaps lassen sich z.B. bei nVidias Chamälion-Demo beschauen.

Doch es gibt ja auch Grenzen nach oben hin. Mit 16 Bit Float lassen sich die Winkel bereits so fein abstufen, dass eine Erweiterung auf 32 Bit kaum Vorteile bringen dürfte. Wobei wie gesagt mein Hauptproblem das Texturformat ist, was meines Wissens keine 32 Bit pro Kanal unterstützt.

[RadioactiveMan]

Originally posted by aths
Die Bump- bzw. Normalmap kann feiner quantisiert werden, was mehr Details erlaubt. Die Grenzen heutiger Normalmaps lassen sich z.B. bei nVidias Chamälion-Demo beschauen.

Doch es gibt ja auch Grenzen nach oben hin. Mit 16 Bit Float lassen sich die Winkel bereits so fein abstufen, dass eine Erweiterung auf 32 Bit kaum Vorteile bringen dürfte. Wobei wie gesagt mein Hauptproblem das Texturformat ist, was meines Wissens keine 32 Bit pro Kanal unterstützt.

Es soll eigentlich in DX9 FP32 Formate geben(anders macht es wohl kaum Sinn), ABGR32f und diverse andere 16/32 Bit(per channel) FP Formate(unterscheiden sich durch Anzahl der Kanäle) laut M$s Meltdown DXG9 Slides.

Was die Erweiterung auf 32bit floating point precision bringt kannst du ja bald noch dem NVIDIA Whitepaper “Realistic Images: The
Importance of Numerical Precision.” entnehmen. ;)