NV30 Einschränkungen (Split aus: FXT1 in DX9)

[Demirug]

FXT1 support in DX9 scheint nicht der Fall zu sein.

zeckensack,

Das beim NV30 die Float-Texturen nicht mehr gefiltert werden können war mir bekannt. Aber mal im ernst die Float Formate sind doch wohl eher nur als A-Buffer sinnvoll. Als Format für "normale" Texturen wäre das sowieso Overkill.

Wie sieht das eigentlich beim R300 aus? Dazu hab ich bisher leider nichts finden können.

[Xmas]

Bei Float-Texturen siehts so aus:

NV30: Non-2^x Texturen, keine Filterung, keine Cubemaps, keine Mipmaps

R300: 2^x Texturen, keine Filterung, Cubemaps, Mipmaps

[zeckensack]

Oh oh, wie konnte ich nur dieses Thema anschneiden :idea:

Originally posted by Demirug
zeckensack,

Das beim NV30 die Float-Texturen nicht mehr gefiltert werden können war mir bekannt. Aber mal im ernst die Float Formate sind doch wohl eher nur als A-Buffer sinnvoll. Als Format für "normale" Texturen wäre das sowieso Overkill.Für 'normale' Texturen nicht, IMO aber sehr schön für Lookups, also exp, log, sin, cos und (je nach Anwendungsfall) noch schlimmeres.

Da diese Funktionen alle stetig sind wäre ein (wie auch immer implementierter) Filtermechanismus schon sehr nett gewesen :)
Nun gut, sind 1D-Texturen, da kann man recht simpel zu Fuß filtern. Ist in dem Fall wirklich kein allzu großer Verlust :)

... aber wo wir gerade beim NV30-'Bashing' sind ;)
Was IMO wirklich schlimm ist, ist daß man die Cubemap-Addressierung auch noch zu Fuß machen muß. In Kombination mit dem fehlenden Filter wohlgemerkt, dh ich muß im Extremfall im PS vier Texel aus drei verschiedenen Seiten der Cubemap einlesen. Mir ist völlig unverständlich, wieso gerade dieses Feature gekickt wurde.

Gefilterte Float-Cubemaps sollten eigentlich sinnvoll für allerhand Vektortransformationen (nicht nur Normalisierung) einsetzbar sein, zumindest auf dem NV30 wird das aber nichts werden :bäh:

[Demirug]

Originally posted by zeckensack
Für 'normale' Texturen nicht, IMO aber sehr schön für Lookups, also exp, log, sin, cos und (je nach Anwendungsfall) noch schlimmeres.


Die ganzen Funktionen gibt es doch jetzt als Fragmebtshader ops warum also Lookups?


... aber wo wir gerade beim NV30-'Bashing' sind ;)
Was IMO wirklich schlimm ist, ist daß man die Cubemap-Addressierung auch noch zu Fuß machen muß. In Kombination mit dem fehlenden Filter wohlgemerkt, dh ich muß im Extremfall im PS vier Texel aus drei verschiedenen Seiten der Cubemap einlesen. Mir ist völlig unverständlich, wieso gerade dieses Feature gekickt wurde.

Gefilterte Float-Cubemaps sollten eigentlich sinnvoll für allerhand Vektortransformationen (nicht nur Normalisierung) einsetzbar sein, zumindest auf dem NV30 wird das aber nichts werden :bäh:

Wer bascht den? Wir diskutieren doch nur über die Design-Entscheidungen von NVIDIA.

Wobei auch hier habe ich noch einmal das gleiche Argument wie oben: Die Fragmentpipelines haben jetzt FP Einheiten womit die Cubemap krücken unnötig werden.

[Xmas]

Originally posted by zeckensack
Da diese Funktionen alle stetig sind wäre ein (wie auch immer implementierter) Filtermechanismus schon sehr nett gewesen :)
Nun gut, sind 1D-Texturen, da kann man recht simpel zu Fuß filtern. Ist in dem Fall wirklich kein allzu großer Verlust :)
Wenn schon die Präzision wichtig ist, wird man sich selten mit linearer Filterung zufrieden geben. IMO ist der Aufwand für festverdrahtete Float-Filterung zur Zeit viel zu hoch und der Nutzen zu gering.

... aber wo wir gerade beim NV30-'Bashing' sind ;)
Was IMO wirklich schlimm ist, ist daß man die Cubemap-Addressierung auch noch zu Fuß machen muß. In Kombination mit dem fehlenden Filter wohlgemerkt, dh ich muß im Extremfall im PS vier Texel aus drei verschiedenen Seiten der Cubemap einlesen. Mir ist völlig unverständlich, wieso gerade dieses Feature gekickt wurde.

Gefilterte Float-Cubemaps sollten eigentlich sinnvoll für allerhand Vektortransformationen (nicht nur Normalisierung) einsetzbar sein, zumindest auf dem NV30 wird das aber nichts werden :bäh:
Also ich muss sagen, auf hardwired Float-Cubemaps kann ich gut verzichten, und wenn die NVidia-Ingenieure irgendwo sparen mussten, finde ich durchaus einsichtig dass sie dies gestrichen haben, da man es mit PS nachbilden kann.

[zeckensack]

Originally posted by Demirug


Die ganzen Funktionen gibt es doch jetzt als Fragmebtshader ops warum also Lookups?Um das ganze optimierbar zu machen :bäh:

Sagen wir mal (nur mal so angenommen ...), ich möchte pro Pixel
a^(tan(b))
ausrechnen. Könnte vom großen Wertebereich profitieren. Ist dummerweise für b=0 nicht definiert, da sollte man einen sinnvollen Defaultwert rauskriegen.
2D-Float Lookup :jump1:

Wie schnell sind denn die transzendentalen Funktionen auf der NV30? Schneller als ein Texelfetch? Schaumer mal ...

Außerdem ist's monoton und damit filterbar, aber das kann man auch simpel zu Fuß machen (sehe ich ja ein).


Wobei auch hier habe ich noch einmal das gleiche Argument wie oben: Die Fragmentpipelines haben jetzt FP Einheiten womit die Cubemap krücken unnötig werden. Wieso sind Cubemaps auf einmal Krücken? Für die Rundumtextur wird's weiterhin sinnvolle Anwendungen geben.

Was mir überhaupt nicht einleuchten will: was hat Cubemap-Addressierung mit dem Texturformat zu tun? Für 'normale' Integertexturen gibt's das ja auch weiterhin, man sollte meinen daß die gleiche Logikschaltung auch für Float-Texturen verwendet werden kann (sofern sie denn 64/128bittige Elemente unterstützt, was ja wohl nicht zuviel verlangt ist).

Das schlimme an der Addressierung von Cubemaps ist doch die Auswahl einer der sechs Seiten und das Umsetzen der Texturkoordinaten (könnte man btw prima mit einer Lookup-Textur machen *eg*). Das bedeutet im Zweifelsfall conditional branches :o
Vom verschwendeten Leerraum in so einer Cubemap-'Emulations'textur ganz zu schweigen.

Also selbst wenn der NV30 unbegrenzte Programmlängen unterstützen würde wär's mir immer noch zu dumm, etwas zu programmieren was die HW eigentlich selbst viel effizienter kann (immer noch kann!, nur nicht für Float-Texturen ?-) ).

[zeckensack]

Originally posted by Xmas
Wenn schon die Präzision wichtig ist, wird man sich selten mit linearer Filterung zufrieden geben.Haha! =)
Float != hohe Präzision
Floats zeichnen sich durch konstante Präzision über einen hohen Wertebereich aus.

Eine Funktion ala 3^x-1 lässt sich sehr wohl brauchbar mit ein paar Zwischenwerten und linearem Filter annähern, sprengt aber trotzdem die Beschränkungen von Integerformaten.

IMO ist der Aufwand für festverdrahtete Float-Filterung zur Zeit viel zu hoch und der Nutzen zu gering.Nochmal: Den Punkt kann ich gut nachvollziehen. Geht mir primär um die Cubemaps.

Wird aber so langsam reichlich OT hier :D

[Demirug]

Originally posted by zeckensack
Um das ganze optimierbar zu machen :bäh:

Sagen wir mal (nur mal so angenommen ...), ich möchte pro Pixel
a^(tan(b))
ausrechnen. Könnte vom großen Wertebereich profitieren. Ist dummerweise für b=0 nicht definiert, da sollte man einen sinnvollen Defaultwert rauskriegen.
2D-Float Lookup :jump1:

Wie schnell sind denn die transzendentalen Funktionen auf der NV30? Schneller als ein Texelfetch? Schaumer mal ...

Außerdem ist's monoton und damit filterbar, aber das kann man auch simpel zu Fuß machen (sehe ich ja ein).


diese Grenzwertgeschichten kann man in der Regel mit einer zusätzlichen Instruction umgehen.

Die neuen Fragmentpipelines sind nicht unbedingt sehr Fetch freundlich deswegen würde ich sagen das rechnen günstiger zu haben ist und man den Texturecache besser für richtige Texturen benutzten sollte.


Wieso sind Cubemaps auf einmal Krücken? Für die Rundumtextur wird's weiterhin sinnvolle Anwendungen geben.


Ich meinte damit die Fälle in denen man eine Cubemap für Vectorfunktionen benutzt (z.B. Normalisiren). Ansonsten machen sie natürlich noch sinn.


Was mir überhaupt nicht einleuchten will: was hat Cubemap-Addressierung mit dem Texturformat zu tun? Für 'normale' Integertexturen gibt's das ja auch weiterhin, man sollte meinen daß die gleiche Logikschaltung auch für Float-Texturen verwendet werden kann (sofern sie denn 64/128bittige Elemente unterstützt, was ja wohl nicht zuviel verlangt ist).


Das ist eine durchaus berechtigte Frage. Aber irgendeinen Grund muss es haben.


Das schlimme an der Addressierung von Cubemaps ist doch die Auswahl einer der sechs Seiten und das Umsetzen der Texturkoordinaten (könnte man btw prima mit einer Lookup-Textur machen *eg*). Das bedeutet im Zweifelsfall conditional branches :o
Vom verschwendeten Leerraum in so einer Cubemap-'Emulations'textur ganz zu schweigen.


Ja wobei ich nach wie vor nicht sehe wofür man eine FP Cubemap braucht.


Also selbst wenn der NV30 unbegrenzte Programmlängen unterstützen würde wär's mir immer noch zu dumm, etwas zu programmieren was die HW eigentlich selbst viel effizienter kann (immer noch kann!, nur nicht für Float-Texturen ?-) ).

Ja wobei man wohl auch bei den TMUs immer mehr von den festen Funktionen weggehen wird und mehr davon in die Pipe verlagert um die Flexibilität zu erhöhen. Und mit einer HLSL hat man dann halt fertige Funktionen für sachen wie tri oder AF.

[zeckensack]

Originally posted by Demirug
diese Grenzwertgeschichten kann man in der Regel mit einer zusätzlichen Instruction umgehen.In diesem exotischen Beispielfall würde auch das nicht viel bringen, für b gegen null steigt das Funktionsergebnis erstmal gegen unendlich. Wenn ich dann bei b=0 einen Defaultwert ausspucke, dann ist ein Bruch in der Funktion da (nicht mehr stetig). Würde in der Praxis zu Aliasing führen.

Was diese Funktion eigentlich braucht (sofern sie denn überhaupt für Grafik sinnvoll einsetzbar ist), wäre ein Maximalwert für b=0, und drumherum eine Art Glockenverlauf, ie eine stark abgeflachte Spitze. Außerdem habe ich gerade beschlossen, daß der Exponent nur positiv sein soll, was ein Tangens für x<0 nicht ist. Damit könnte man den nutzbaren Definitionsbereich auf b<0 ausweiten.

Die 'Glocke' würde ich als Parabel auf einem per Bauchgefühl (aber von a abhängigem) 'eigentlichen' Maximalwert aufsetzen.

Also quasiif (abs(b)<=0.5)
return (pow(a,abs(tan(b)));
else
{
float base=pow(a,tan(0.5));
float overshoot=2.0-(4*b*b);
return (base*overshoot);
}
Dadurch liegt die Glockenspitze dann doppelt so hoch wie f(a,0.5) und die Glocke ist schön rund.

Sinn der Übung: Ich kann zwar viel alles im PS ausrechnen, aber wenn die Funktion immer komplizierter wird kommt irgendwann der Punkt wo's langsam wird. Warum soll ich sie nicht vorberechnen, wenn absehbar ist daß die Hardware nur begrenzt für solche Frechheiten brauchbar ist?

Oder wenn ich jetzt eine Funktion haben will, dessen Kurve sich nicht aus den Basisfunktionen ergibt. Die quasi in einem Editor 'designt' wird, und wo eine Gleichung garnicht bekannt ist. Ich kann ja immer noch Lookups für ortsabhängige Materialeigenschaften fordern, sowas kann man garnicht ausrechnen (zB Lichtbrechungen unter der Oberfläche eines Quarzes, weiß der Geier).

Ich hab' da mal was vorbereitet ... ist doch ein sehr beliebter Lösungsansatz bei komplizierten Dingen, die aber trotzdem in Echtzeit gebraucht werden. :)

Nujo, ich fordere keine allgemeine Praxisrelevanz meiner Ausführungen, aber Lookups sollten schon noch erlaubt sein, vor allem wenn sie potentiell dutzende von Berechnungsschritten und Branches verhindern helfen.
Vor allem Branches sollten bei parallelen Pipes verheerend sein (AFAIK, IMO, etc). :)

Die neuen Fragmentpipelines sind nicht unbedingt sehr Fetch freundlich deswegen würde ich sagen das rechnen günstiger zu haben ist und man den Texturecache besser für richtige Texturen benutzten sollte.IMO kommt's immer auf die Dosis an ;)
Eine Multiplikationstabelle würde ich auch nicht als 2D-Lookup bauen wollen. Sin/Cos sind auf aktuellen GHz-Schleudern im Schnitt schneller berechenbar als mit Lookups lösbar, insofern gelten sicher auch für Grafikchips inzwischen andere Maßstäbe als noch zB für 'nen 486er.

Aber ich bin mir sicher, es gibt bestimmt praxisrelevante Fälle wo die programmierbaren Einheiten vom Texelfetch dumm und dusselig geschlagen werden :D
Ich meinte damit die Fälle in denen man eine Cubemap für Vectorfunktionen benutzt (z.B. Normalisiren). Ansonsten machen sie natürlich noch sinn.Hmm ...
Beliebige Vektor-Mappings, die nicht ohne weiters mit Funktionen machbar sind.
Bsp: Vektornormalisierung. Duh. Aber zusätzlich an den 'Ecken' der Cubemap Inversion. (Stichwort 'unheard of fancy special effects')
Könnte man mit einer 6x4x4 Cubemap machen, mit selbstgebautem (nicht-linearem) Filter. Wenn nur nicht das Addressieren der Cubemaps für vier Texel 24 verschiedene (mittels insgesamt 16 ifs ausgewählte) Codeblöcke bedeuten würde.

Ja wobei man wohl auch bei den TMUs immer mehr von den festen Funktionen weggehen wird und mehr davon in die Pipe verlagert um die Flexibilität zu erhöhen. Und mit einer HLSL hat man dann halt fertige Funktionen für sachen wie tri oder AF. Tut mir bei 2D-Texturen auch überhaupt nicht weh :)

[Xmas]

Originally posted by zeckensack
Bsp: Vektornormalisierung. Duh. Aber zusätzlich an den 'Ecken' der Cubemap Inversion. (Stichwort 'unheard of fancy special effects')
Könnte man mit einer 6x4x4 Cubemap machen, mit selbstgebautem (nicht-linearem) Filter. Wenn nur nicht das Addressieren der Cubemaps für vier Texel 24 verschiedene (mittels insgesamt 16 ifs ausgewählte) Codeblöcke bedeuten würde.
Im Grunde ist es viel wichtiger, bei den Berechnungen hohe Präzision zu haben, als in den Texturen. Zur Not kann man nämlich hohe Präzision und großen Wertebereich durch 2 oder mehr 32Bit Texel Fetches erreichen. Das dürfte weitaus schneller sein als Cubemap Adressierung per PS nachzubilden.

[Unregistered]

wie oder wo kann man sowas lernen??? :)

[aths]

Originally posted by Unregistered
wie oder wo kann man sowas lernen??? :) Unsere Gurus zeichnen sich alle dadurch aus, dass sie seit Jahren 3D-Applikationen schreiben. Solches Wissen kommt dann wohl "automatisch".

[S3NS3_0F_D34TH]

:D Versteh kein wort. Musste ich schreiben, habe mich weggelacht. Studiert ihr alle sowas????????

[zeckensack]

Originally posted by S3NS3_0F_D34TH
:D Versteh kein wort. Musste ich schreiben, habe mich weggelacht. Studiert ihr alle sowas???????? Sowas kann man in D leider nicht studieren ;(
Sonst wäre ich sofort dabei.

[S3NS3_0F_D34TH]

Hehe, war auch nicht so ernst gemeint. Aber mal echt: Respekt :)

[Pussycat]

Wo denn wohl?

[vogel]

IEEE floats haben alles andere als konstante Praezision. Um 1 / -1 hast du die meiste Praezision.

-- Daniel, Epic Games Inc.

Originally posted by zeckensack
Floats zeichnen sich durch konstante Präzision über einen hohen Wertebereich aus.

[zeckensack]

Originally posted by vogel
IEEE floats haben alles andere als konstante Praezision. Um 1 / -1 hast du die meiste Praezision.

-- Daniel, Epic Games Inc.

Ich glaube wir reden aneinander vorbei ...
Die feinsten Zwischenschritte kann man natürlich dann speichern, wenn man einen möglichst kleinen Exponenten hat.

Was ich mit der konstanten Präzision meinte ist daß die Darstellung einer bestimmten Zahl (sofern sie noch normalisiert dargestellt werden kann) maximal um soundsoviel Prozent abweicht. Der absolute Fehler hängt von der Größe des Betrages der Zahl ab, der relative (aka prozentuale) Fehler hingegen nicht*

IEEE-754 32bit floats (1s8e23m + hidden bit) weichen um maximal 1/(2^22) ~= 240 ppb (parts per billion), =0.0000240% ab. Wenn ich mich nicht verrechent habe :D

Und das meinte ich mit konstanter Präzision über den gesamten Wertebereich (der Zusammenhang ist wichtig!)

*der maximale Fehler ist nicht wirklich konstant, er schwankt in bestimmten Intervallen zwischen 1/(2^22) und 1/(2^23), ist aber immerhin fast konstant :)