Winkelunabhängiges AF per Shader (Split aus: G70: Nur noch mit flimmernder Grafik?)

[Gast]

http://www.beyond3d.com/forum/showthread.php?t=23270

Kann einer mal erklären was da gemacht wurde? Der AF Tester zeigt ja scheenes 16x!AF ^^

[MikBach]

http://www.beyond3d.com/forum/showthread.php?t=23270

Kann einer mal erklären was da gemacht wurde? Der AF Tester zeigt ja scheenes 16x!AF ^^
Winkelunabhängigkeit per Shader? :confused:
Und was an dem Shader nicht Radeon-kompatibel sein soll, kann ich auf den ersten Blick nicht erkennen.
Und nur für quadratische Texturen, nicht für rechteckige.

Fake?

[reunion]

Er schreibt doch selber, warum die Shader nicht auf PS2.0/b-Hardware laufen.
Die Performance dürfte allerdings ohnehin unterirdisch sein, vielleicht intressant für den G70.

[MadManniMan]

Richtig interessant könnte ein solcher Shader als Hauptdarsteller einer "Referenz-Qualitäts-Alternative" ;)

:idea:

[MikBach]

Er schreibt doch selber, warum die Shader nicht auf PS2.0/b-Hardware laufen.
Die Performance dürfte allerdings ohnehin unterirdisch sein, vielleicht intressant für den G70.
Er schreibt was von 2.x.
2.a und 2.b fallen doch unter 2.x oder habe ich was verpasst?

Dass die Performance extrem leidet, dürfte klar sein.

[reunion]

Er schreibt was von 2.x.
2.a und 2.b fallen doch unter 2.x oder habe ich was verpasst?



2.b ist nichts anderes als 2.0 mit etwas verlängertem shader_instructions.

[MikBach]

2.b ist nichts anderes als 2.0 mit etwas verlängertem shader_instructions.
Geometry Instancing?
Soll aber offiziel erst ab 3.0 unterstützt werden.

[reunion]

Geometry Instancing?
Soll aber offiziel erst ab 3.0 unterstützt werden.

Steht doch dort. (http://www.beyond3d.com/forum/showpost.php?p=558709&postcount=4) ddx, ddy und tex2D mit Ableitungen sind mit PS2.0/b offensichtlich nicht möglich.

[MikBach]

Steht doch dort. (http://www.beyond3d.com/forum/showpost.php?p=558709&postcount=4) ddx, ddy und tex2D mit Ableitungen sind mit PS2.0/b offensichtlich nicht möglich.
Meine Frage war auf deine Aussage bezogen, dass nur die Shaderlänge den einzigen Unterschied zu 2.0 darstellt, aber egal.

Zum Quote:
Auch wenn das mit 2.b nicht gehen sollte, so kann man imo den Shader umschreiben, das es geht.

[Gast]

Laut der Microsoft Documentation gehts nicht, es sei denn du weist wie man anders zu "texldd" kommt.

Sehe grade das bei Beyond näher erklärt wird.

[MikBach]

Laut der Microsoft Documentation gehts nicht, es sei denn du weist wie man anders zu "texldd" kommt.

Laut der M$ Dokumentation beherrschen ATI-Karten auch kein Geometry Instancing.

[deekey777]

Die texldd Instruktion wird scheinbar nur vom 2_a unterstützt; einer der 3D Gurus hat sich schon darüber beschwert, daß diese Instruktion zum Vorteil von 2_b aus dem 2_x gestrichen wurde.

Oder auch nicht.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/graphics/reference/assemblylanguageshaders/pixelshaders/instructions/texldd.asp


€: Wie wäre es, wenn man das ganze heraussplittet und daraus einen neuen Thread zB im Technologie-Bereich erstellt?

Nicht daß jemand denkt, ich hätte das ganze aus dem B3D abgeschrieben: Ich habe den Thread schon früher gesehen, aber nicht die aktualisierte Version mit dem Link zu MSDN.

[Coda]

Auch wenn das mit 2.b nicht gehen sollte, so kann man imo den Shader umschreiben, das es geht.The x and y gradient values are used to select the appropriate mipmap level of the texture for sampling.Das kannst du nicht emulieren.

[MikBach]

Das kannst du nicht emulieren.
Man kann alles per Software emulieren. :wink:

[Coda]

So, wie denn? Die einzelnen Mips trennen und an verschieden Texturstages hängen geht nicht, weil kein dynamisches Branching und averaging von der größten Mip aus geht auch nicht, weil es ja beliebig klein werden kann was auch wieder flow-control bräuchte.

Ich wüsste sonst keinen Weg gezielt auf die Mips zugreifen zu können.

Der Shader macht übrigens gar kein AF sondern verschiebt nur die Mips LOD ins positive. Aua.

[MikBach]

So, wie denn? Die einzelnen Mips trennen und an verschieden Texturstages hängen geht nicht, weil kein dynamisches Branching und averaging von der größten Mip aus geht auch nicht, weil es ja beliebig klein werden kann was auch wieder flow-control bräuchte.
Per Software geht alles, auch wenn manchmal sehr langsam...

Der Shader macht übrigens gar kein AF sondern verschiebt nur die Mips LOD ins positive. Aua.
Autsch.
Also ein Fake...

[Coda]

Per Software geht alles, auch wenn manchmal sehr langsam...Du meinst per Software-Rasterizer? Also in einen auf einer bisherigen ATi-GPU ausführbaren Fragment Program bekommst du diesen Shader definitiv nicht übersetzt.

[aths]

Winkelunabhängigkeit per Shader? :confused:
Und was an dem Shader nicht Radeon-kompatibel sein soll, kann ich auf den ersten Blick nicht erkennen.Dann riskier doch noch einen zweiten Blick.

Den Gradienten zurückzuliefern sieht 2.0 und 2.x 2_B nicht vor. 2_A (und damit auch 3.0) schon.


Laut der M$ Dokumentation beherrschen ATI-Karten auch kein Geometry Instancing.Deshalb kann die Radeon auch alles andere, was sie lt. MS' DX-Spec nicht können sollte?

Beim GI bin ich mir noch immer nicht darüber im klaren, wie viel Hardware der R420 hierfür anbietet und was ATI über den Treiber macht.


Meine Frage war auf deine Aussage bezogen, dass nur die Shaderlänge den einzigen Unterschied zu 2.0 darstellt, aber egal.

Zum Quote:
Auch wenn das mit 2.b nicht gehen sollte, so kann man imo den Shader umschreiben, das es geht.Da bin ich gespannt, wie du das anstellen möchtest. Das würde für auch Xmas' Diplomthema nützlich sein.

[aths]

Man kann alles per Software emulieren. :wink:Weiter oben wolltest du es noch im Shader machen. Ich bin gespannt auf deinen Shader-Beispielcode, der ddx und ddy, und texldd ersetzt.

[MikBach@work]

Weiter oben wolltest du es noch im Shader machen. Ich bin gespannt auf deinen Shader-Beispielcode, der ddx und ddy, und texldd ersetzt.
Ich nehme alles zurück und behaupte das Gegenteil. :D
Ist schon ein Weilchen her, dasd ich mich ein wenig mit Shadern befasst habe.

[Coda]

Hm ich bin mir inzwischen nicht mehr sicher ob dass nicht wirklich AF ist und das Ding über den gradient-texture-load die TMU einfach "austrickst", weil sie sich dann nicht sicher sein kann welcher Texturwinkel gerade vorhanden ist...

Schade nur dass es eben abhängig von den Texturpropertionen ist, wobei man das ja mit Konstanten parametrisieren könnte.

Beim GI bin ich mir noch immer nicht darüber im klaren, wie viel Hardware der R420 hierfür anbietet und was ATI über den Treiber macht.Imho ist das ein Treiber-Hack. Das ist aber auch nicht weiter schlimm, weil GI eigentlich nur ein Fix für den ewig hohen D3D-Call-Overhead ist, der damit auch schon vermieden wird.

[zeckensack]

Weiter oben wolltest du es noch im Shader machen. Ich bin gespannt auf deinen Shader-Beispielcode, der ddx und ddy, und texldd ersetzt.DDX und DDY sind kein Problem (http://www.beyond3d.com/forum/showthread.php?p=243690#post243690).

Texldd ist eines, aber da würde ich gerne den Shader mal sehen. Texldd mit Ergebnissen von DDX und DDY zu füttern ist ziemlich von hinten durch die Brust ins Auge.

edit: richtig krasse Sachen kann man meistens mit summed area tables implementieren, und dafür baucht's kein SM3.

[aths]

Hm ich bin mir inzwischen nicht mehr sicher ob dass nicht wirklich AF ist und das Ding über den gradient-texture-load die TMU einfach "austrickst", weil sie sich dann nicht sicher sein kann welcher Texturwinkel gerade vorhanden ist...Er hat das berühmte Muster erzeugt, wie es in diesem Tunnel bei bilinearem 16x AF optimalerweise aussehen sollte. Er filtert die Textur nicht 16x anisotrop, zumindest nicht mit seinem Shader den er vorgestellt hat, soweit ich HLSL lesen kann.

edit: Mich würde mal der ASM-Output interessieren, aber ich habe gerade kein DX SDK installiert. Kann mal wer den Shader übersetzen?

[aths]

DDX und DDY sind kein Problem (http://www.beyond3d.com/forum/showthread.php?p=243690#post243690).Was sagt der Link jetzt?
Bei der Radeon hast du im Pixel keinen Zugriff auf den Nachbarpixel. Mit ddx und ddy kann man die Differenz zum Nachbarpixel (innerhalb des Quads) bestimmen, wahrscheinlich macht das keine ALU sondern die Tex-Unit da die das eh braucht, zur LOD-Bestimmung. So weit mein Kenntnisstand.
Was du auf b3d geschrieben hast, habe ich leider nicht verstanden. Du willst über eine weitere Textur irgendwie an den Gradienten herankommen?

Texldd ist eines, aber da würde ich gerne den Shader mal sehen. Texldd mit Ergebnissen von DDX und DDY zu füttern ist ziemlich von hinten durch die Brust ins Auge.Genau dazu ist texldd doch da :) Man holt erst die Gradienten, modifiziert sie, und geht mit texldd wieder auf die Textur.

edit: richtig krasse Sachen kann man meistens mit summed area tables implementieren, und dafür baucht's kein SM3.Was diese summed area tables sein soll, habe ich bis heute nicht verstanden – genauso wenig, ob man damit winkelunabhängiges AF ersetzen kann.

Je mehr ich über AF nachdenke, desto mehr fällt mir auf, wie wenig ich darüber weiß, was die Hardware tatsächlich macht. Jedenfalls macht weder Radeon noch GeForce das, was ich machen würde.

[zeckensack]

Was sagt der Link jetzt?
Bei der Radeon hast du im Pixel keinen Zugriff auf den Nachbarpixel. Mit ddx und ddy kann man die Differenz zum Nachbarpixel (innerhalb des Quads) bestimmen, wahrscheinlich macht das keine ALU sondern die Tex-Unit da die das eh braucht, zur LOD-Bestimmung. So weit mein Kenntnisstand.
Was du auf b3d geschrieben hast, habe ich leider nicht verstanden. Du willst über eine weitere Textur irgendwie an den Gradienten herankommen?Alle Grafikchips die bei "dependent reads" ordentliches Mip-Mapping unterstützen, tun dies indem sie die Differenzen der Texturkoordinaten innerhalb eines Quads ausrechnen, und davon ausgehend dann die LOD-Berechnung durchführen.

Dh ich kann mir einen Gradienten zwar nicht direkt in ein Register holen, aber ich kann den Chip dazu bringen ihn auszurechnen, und dieses Ergebnis in einem Texturlookup zu verwurschteln. Die Textur muss dann nur noch so präpariert werden, dass möglichst unverfälscht der "verursachende" Gradient auch aus dem Textursampler wieder zurückkommt.

Und das macht man eben mit einer 1D-Textur, bei der jede Mipmapstufe mit einer Graustufe gefüllt ist, die den zum entsprechenden LOD gehörenden Gradienten kodiert, und dann trilinearer Filterung, um auch Zwischenstufen zu erhalten.

Mittels "dependent read" kann man dann im Shader jede beliebige Funktion "ableiten".
Genau dazu ist texldd doch da :) Man holt erst die Gradienten, modifiziert sie, und geht mit texldd wieder auf die Textur.Ob das sinnvoll ist, hängt davon ab was genau da modifiziert wird. Mal zwei wäre zB selten dämlich, da man mit gleichem Ergebnis einfach den LOD-Bias um eins erhöhen kann. Bzw generell ist hier Multiplikation dämlich.
Was diese summed area tables sein soll, habe ich bis heute nicht verstanden – genauso wenig, ob man damit winkelunabhängiges AF ersetzen kann.SATs sind die coolste Speicherverschwendung die je erfunden wurde. Man braucht zwar plötzlich für alles mindestens FP16 pro Kanal, aber dafür kann man sich die Mipmaps sparen, und kann beliebig große rechteckige Filterkernel fahren.
http://developer.nvidia.com/docs/IO/8230/GDC2003_SummedAreaTables.pdf
(die ersten drei Seiten sollten genügen)

[MikBach]

Also hatte ich doch nicht ganz Unrecht. :D

Zumindest, dass ddx und ddy nicht gehen sollten, kam mir bisschen spanisch vor.

[Coda]

Er hat das berühmte Muster erzeugt, wie es in diesem Tunnel bei bilinearem 16x AF optimalerweise aussehen sollte. Er filtert die Textur nicht 16x anisotrop, zumindest nicht mit seinem Shader den er vorgestellt hat, soweit ich HLSL lesen kann.Fragt sich jetzt ob in dem Bild zusätzlich zu dem Shader 16xAF aktiviert war, oder der Shader einfach ein positives LOD-BIAS erzeugt.

[MikBach]

Fragt sich jetzt ob in dem Bild zusätzlich zu dem Shader 16xAF aktiviert war, oder der Shader einfach ein positives LOD-BIAS erzeugt.
Was hat denn der positive LOD-BIAS mit der der Winkelunabhängigkeit zu tun?

[aths]

Also hatte ich doch nicht ganz Unrecht. :D

Zumindest, dass ddx und ddy nicht gehen sollten, kam mir bisschen spanisch vor.Ich zweifle ehrlich gesagt daran, dass du wusstest was ddx und ddy überhaupt machen.

[aths]

Fragt sich jetzt ob in dem Bild zusätzlich zu dem Shader 16xAF aktiviert war, oder der Shader einfach ein positives LOD-BIAS erzeugt.Der Shader berechnet offenbar den richtigen LOD für 16x AF, wobei "richtig" im Sinne der richtigen MIP-Wahl zu verstehen ist. Der G70 kann meines Wissens bei aktiviertem 16x AF bei bestimmten Winkeln um die Z-Achse nur 2x AF tatsächlich applizieren. Da nützt der Trick nichts, am LOD zu wurschteln, man bekommt über den G70-Texturfilter kein winkelunabhängiges 16x AF.

[MikBach]

Ich zweifle ehrlich gesagt daran, dass du wusstest was ddx und ddy überhaupt machen.
Woran du zweifelst oder nicht, juckt mich ehrlich gesagt ziemlich wenig.

[aths]

Alle Grafikchips die bei "dependent reads" ordentliches Mip-Mapping unterstützen, tun dies indem sie die Differenzen der Texturkoordinaten innerhalb eines Quads ausrechnen, und davon ausgehend dann die LOD-Berechnung durchführen.

Dh ich kann mir einen Gradienten zwar nicht direkt in ein Register holen, aber ich kann den Chip dazu bringen ihn auszurechnen, und dieses Ergebnis in einem Texturlookup zu verwurschteln. Die Textur muss dann nur noch so präpariert werden, dass möglichst unverfälscht der "verursachende" Gradient auch aus dem Textursampler wieder zurückkommt.

Und das macht man eben mit einer 1D-Textur, bei der jede Mipmapstufe mit einer Graustufe gefüllt ist, die den zum entsprechenden LOD gehörenden Gradienten kodiert, und dann trilinearer Filterung, um auch Zwischenstufen zu erhalten.

Mittels "dependent read" kann man dann im Shader jede beliebige Funktion "ableiten".Hrm. Hast du das mal ausprobiert? Die Präzision von FP32-ddx wird sicher nicht erreicht, aber vielleicht reicht die Auflösung ja für Feld- und Wiesen-Anwendungen.

Ob das sinnvoll ist, hängt davon ab was genau da modifiziert wird. Mal zwei wäre zB selten dämlich, da man mit gleichem Ergebnis einfach den LOD-Bias um eins erhöhen kann. Bzw generell ist hier Multiplikation dämlich.Der bewusste Shader macht hier mehr als nur Multiplikationen.

SATs sind die coolste Speicherverschwendung die je erfunden wurde. Man braucht zwar plötzlich für alles mindestens FP16 pro Kanal, aber dafür kann man sich die Mipmaps sparen, und kann beliebig große rechteckige Filterkernel fahren.
http://developer.nvidia.com/docs/IO/8230/GDC2003_SummedAreaTables.pdf
(die ersten drei Seiten sollten genügen)Danke. Guck ich mir morgen an, wenn ich geistig fitter bin als jetzt.

[aths]

Woran du zweifelst oder nicht, juckt mich ehrlich gesagt ziemlich wenig.Anstatt erst Allgemeinplätze von dir zu geben, die nicht gerade davon zeugen dass du wirklich weißt, wovon du sprichst, dann plötzlich zu widerrufen als es 'Butter bei die Fische' heißt, um nur kurz darauf dann doch weiterhin zu versuchen, den Wissenden zu emulieren, könntest du das nächste mal einfach versuchen, vorher abzuschätzen ob du das Fachwissen für Fachdiskussionen mitbringst.

Das sage ich so hart, wie es ist. Vom großen Rumerzählen lernt keiner was, das verwirrt den Leser nur.

SATs sind die coolste Speicherverschwendung die je erfunden wurde. Man braucht zwar plötzlich für alles mindestens FP16 pro Kanal, aber dafür kann man sich die Mipmaps sparen, und kann beliebig große rechteckige Filterkernel fahren.
http://developer.nvidia.com/docs/IO/8230/GDC2003_SummedAreaTables.pdf
(die ersten drei Seiten sollten genügen)Hab mal kurz drübergeschaut. Damit kann man rechteckige Filterkernel realisieren – für vernünftiges AF braucht man mindestens Parallelogramme. edit: Ok, das gibt die Folie auch zu. edit2: Auf die Idee solcher Tables wäre ich nie gekommen. Mir ist eigentlich alles recht, was ohne MIPs auskommt – MIPs halte ich aus diversen Gründen für eine Notlösung.

[MikBach]

Anstatt erst Allgemeinplätze von dir zu geben, die nicht gerade davon zeugen dass du wirklich weißt, wovon du sprichst, dann plötzlich zu widerrufen als es 'Butter bei die Fische' heißt, um nur kurz darauf dann doch weiterhin zu versuchen, den Wissenden zu emulieren, könntest du das nächste mal einfach versuchen, vorher abzuschätzen ob du das Fachwissen für Fachdiskussionen mitbringst.

Das sage ich so hart, wie es ist. Vom großen Rumerzählen lernt keiner was, das verwirrt den Leser nur.
Was willst mir jetzt damit sagen?
Ich habe echt keinen Bock den Thread über die FX rauszusuchen, wo du meintest, dass die FX dem R350 in Sachen Shader gleichwertig sein sollte.
Ich meinte, dass die FX gnadenlos untergeht, aber du und Demi waren anderer Meinung.
Das war die falsche Meinung.
Also komm mal wieder zurück auf den Teppich, wenn es nicht geht, dann schnall dich mal an. :D

[zeckensack]

Hrm. Hast du das mal ausprobiert? Die Präzision von FP32-ddx wird sicher nicht erreicht, aber vielleicht reicht die Auflösung ja für Feld- und Wiesen-Anwendungen.Das funktioniert wirklich.
Folgendes Bild stammt aus dem Glide2-SDK-Test #21 auf meiner Radeon 9600SE. Eine Funktion des Textur-LODs wird hier als Überblendfaktor zwischen zwei Texturen benutzt. Und zwischen LOD und reinen Derivaten ist kein hindernder Unterschied. Für die Derivate würde man eine logarithmische Funktion in die Mipmap-Level kodieren, für den LOD ist sie linear.

Beachtenswert ist das krasse Banding. Hier schlägt die geringe Filterpräzision voll durch. Brilinear ist bei sowas auch extrem problematisch, zum Glück ist "Catalyst AI" (hrhr) mittlerweile aber nicht mehr dämlich genug, das zu versuchen.

edit: der LOD-Lookup ist hier eine 8 Bit-Textur, das erklärt aber das massive Banding IMO nicht.
//generate lod lookup texture
ubyte* stuff=(ubyte*)malloc(256);
glActiveTextureARB(GL_TEXTURE2_ARB);
glGenTextures(1,&lod_texture);
glBindTexture(GL_TEXTURE_1D,lod_texture);

for (int miplevel=0;miplevel<9;++miplevel)
{
int size=1<<(8-miplevel);
uint linear=32*miplevel;
if (linear==256) linear=255;
memset(stuff,linear,size);

glTexImage1D(GL_TEXTURE_1D,miplevel,GL_ALPHA8,size,0,GL_ALPHA,GL_UNSIGNED_BYTE,s tuff);
}
glTexParameteri(GL_TEXTURE_1D,GL_TEXTURE_MIN_FILTER,GL_NEAREST_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_1D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
glEnable(GL_TEXTURE_1D);
free(stuff);

[aths]

Was willst mir jetzt damit sagen?
Ich habe echt keinen Bock den Thread über die FX rauszusuchen, wo du meintest, dass die FX dem R350 in Sachen Shader gleichwertig sein sollte.
Ich meinte, dass die FX gnadenlos untergeht, aber du und Demi waren anderer Meinung.
Das war die falsche Meinung.Jo, den Thread kannst du gerne heraussuchen und dann im Kontext zitieren. Wenn ich wirklich Schnodder geschrieben habe, gebe ich das dann auch zu. Wobei man beim Thema Shader-Rechenkraft hinterfragen muss, ob die in der Spiele-Praxis genutzte Rechenkraft meint oder die theoretische Rechenkraft. Wenn man sich in einer Prognose irrt (soweit ich mich erinnere, folgerte ich von der theoretischen Rechenkraft dass es nur eine Frage der Zeit sei, bis man das in Spielen merkt, wobei die FX 5900 tatsächlich nie den Anschluss gefunden hat) ist das imo nicht gleichwertig mit einem Verhalten, das Wissen über Shader-Features vortäuscht und über Befehle mitzudisktutieren ohne die Befehle nachgeschlagen, geschweige denn die Beschreibung verstanden zu haben.

Ich musste beim Nachschlagen von ddx zum Beispiel erst noch mal Xmas fragen, weil ich den Input nicht verstand. Wie ddx funktioniert hatte ich falsch in Erinnerung. Da breche ich mir keinen Zacken aus der Krone, das zuzugeben. Xmas hatte mir das vor einiger Zeit schon mal erklärt, leider bin ich da etwas vergesslich wenns um solche Details geht. Und um die knappe Erläuterung im MSDN voll zu verstehen fehlt es mir meist an der praktischen Erfahrung mit Shadern. Die ist für Shader-Programmierer gedacht, der ich nicht bin.

Den Shadercode von Hyp-X im b3df z. B. habe ich missverstanden, weil mir HLSL schon auf diesem Niveau zu hoch, seine Rechnung zu mathematisch anspruchsvoll für einen aths am Abend ist.

Also komm mal wieder zurück auf den Teppich, wenn es nicht geht, dann schnall dich mal an. :DDas ist ein offizieller Thread zu einem Artikel, hier lesen mit erhöhter Wahrscheinlichkeit auch Leute von außen. Da braucht es Ernsthaftigkeit. Ob man dir abnimmt, Pixelshader-Kenntnis zu haben, kannst du gerne in anderen Threads ausprobieren.



Das funktioniert wirklich.
Folgendes Bild stammt aus dem Glide2-SDK-Test #21 auf meiner Radeon 9600SE. Eine Funktion des Textur-LODs wird hier als Überblendfaktor zwischen zwei Texturen benutzt. Und zwischen LOD und reinen Derivaten ist kein hindernder Unterschied. Für die Derivate würde man eine logarithmische Funktion in die Mipmap-Level kodieren, für den LOD ist sie linear.

Beachtenswert ist das krasse Banding. Hier schlägt die geringe Filterpräzision voll durch. Brilinear ist bei sowas auch extrem problematisch, zum Glück ist "Catalyst AI" (hrhr) mittlerweile aber nicht mehr dämlich genug, das zu versuchen.Aus dem Beispielbild kann ich nicht viel entnehmen. Die Schritte im LOD scheinen allerdings zu groß zu sein, jeweils zwei Quads hoch statt nur einem Quad.

[Xmas]

Der Shader macht übrigens gar kein AF sondern verschiebt nur die Mips LOD ins positive. Aua.
Der Shader sollte tatsächlich in einigermaßen korrektem, winkelunabhängigem AF resultieren.

DDX und DDY sind kein Problem (http://www.beyond3d.com/forum/showthread.php?p=243690#post243690).
Das ist leider kein Ersatz für DDX und DDY:
However, this will only get one scalar value. The fetched value will probably be a funtion of the max of the x and y gradients for trilinear filtering, and a function of the min for anisotropic filtering. I don't see how you could specifically retrieve the x and y gradients this way, zeckensack.
Der Shader um den es hier geht benötigt nun mal genau DDX und DDY als Vektoren, und nicht irgendwelche Skalarwerte mit max(du/dx, du/dy) oder ähnlichem.

Texldd ist eines, aber da würde ich gerne den Shader mal sehen. Texldd mit Ergebnissen von DDX und DDY zu füttern ist ziemlich von hinten durch die Brust ins Auge.
Natürlich sollten die Ergebnisse entsprechend modifiziert werden – oder die verwendeten Texturkoordinaten.

PS2.0 bietet ja texldb bzw. tex*Dbias(), aber das reicht nicht aus um winkelunabhängiges AF zu erreichen. Dafür müssen tatsächlich die Gradienten verändert werden. Mal abgesehen davon dass texldb bei PS <3.0 angeblich nur einen Bias in den Grenzen von -3 bis +3 erlaubt, und außerdem IMO sowohl von ATI als auch von NVidia falsch implementiert ist (nämlich nach dem Clamp auf positive Werte... :uclap:).

[Coda]

Der Shader sollte tatsächlich in einigermaßen korrektem, winkelunabhängigem AF resultieren.Ja, das ist mir später ja auch aufgefallen...

[MadManniMan]

Der Shader sollte tatsächlich in einigermaßen korrektem, winkelunabhängigem AF resultieren.

Könnte man da auch noch ein lineares Filtern draufbasteln? *immernoch an "Referenz-AF" denkt*

[MikBach]

Jo, den Thread kannst du gerne heraussuchen und dann im Kontext zitieren. Wenn ich wirklich Schnodder geschrieben habe, gebe ich das dann auch zu. Wobei man beim Thema Shader-Rechenkraft hinterfragen muss, ob die in der Spiele-Praxis genutzte Rechenkraft meint oder die theoretische Rechenkraft. Wenn man sich in einer Prognose irrt (soweit ich mich erinnere, folgerte ich von der theoretischen Rechenkraft dass es nur eine Frage der Zeit sei, bis man das in Spielen merkt, wobei die FX 5900 tatsächlich nie den Anschluss gefunden hat) ist das imo nicht gleichwertig mit einem Verhalten, das Wissen über Shader-Features vortäuscht und über Befehle mitzudisktutieren ohne die Befehle nachgeschlagen, geschweige denn die Beschreibung verstanden zu haben.
Das haben wir schon mal diskutiert und da ich nicht nachtragend bin, lasse ich es.
In dem Thread ging es um 9800PRO gegen 5900Ultra (Ende 2003).
Ich meinte, dass die 5900 in Spielen mit SM2 gegen einen R350 gnadenlos untergehen wird, das hast du anders gesehen.
Und du hast falsch gelegen.
Also klopf nich so grosse Sprüche... :wink:


Das ist ein offizieller Thread zu einem Artikel, hier lesen mit erhöhter Wahrscheinlichkeit auch Leute von außen.

War doch nur Spass. :)
Du nimmst aber alles bitterernst. ;D

[zeckensack]

Der Shader sollte tatsächlich in einigermaßen korrektem, winkelunabhängigem AF resultieren.Ich verstehe immer noch nicht wie man zu diesem Schluss kommen kann :|
Der Shader führt zu anderer Miplevel-Auswahl. Mehr kann man mit expliziten Gradienten nicht erreichen.

Das ist leider kein Ersatz für DDX und DDY:

Der Shader um den es hier geht benötigt nun mal genau DDX und DDY als Vektoren, und nicht irgendwelche Skalarwerte mit max(du/dx, du/dy) oder ähnlichem.Mintmaster hat es nicht verstanden.
max(du/dx, 0/dy)=du/dx für du>=0 (dx>0 ist gegeben)
max(0/dx,dv/dy)=dv/dy für dv>=0 (dy>0 ist gegeben)

Allgemein:
max(d_whatever/dx,0/dy)=d_whatever/dx
max(0/dx,d_whatever/dy)=d_whatever/dy

In 1D-Probleme zerlegen, und ein wenig Mittelstufenmathe, und dann klappt das auch für den generellen Fall.

PS2.0 bietet ja texldb bzw. tex*Dbias(), aber das reicht nicht aus um winkelunabhängiges AF zu erreichen. Dafür müssen tatsächlich die Gradienten verändert werden.Siehe oben. Wie soll das gehen? Wie bringt man einen Textursampler dazu, anisotrop zu filtern, indem man an den Gradienten spielt?

[Mr. Lolman]

Das haben wir schon mal diskutiert und da ich nicht nachtragend bin, lasse ich es.
In dem Thread ging es um 9800PRO gegen 5900Ultra (Ende 2003).
Ich meinte, dass die 5900 in Spielen mit SM2 gegen einen R350 gnadenlos untergehen wird, das hast du anders gesehen.

Man hat ja auch dm NV40 eine überlegene Shaderleistung bescheinigt. Bei den letzten Benchmarks die Leo gemacht hat, siehts aber nicht danach aus.

[Quasar]

Man hat ja auch dm NV40 eine überlegene Shaderleistung bescheinigt. Bei den letzten Benchmarks die Leo gemacht hat, siehts aber nicht danach aus.
Wenn ich mir jetzt mal als Beispiel den Shadermark herauspicke, dann schaut es überwiegend sehr wohl so aus. In etlichen Shadern liegt die Performance auf etwa gleichem Niveau, in einigen kann die NV40 sogar davonziehen (in anderen wiederum die X850 XTPE) und nur in sehr wenigen spiegelt sich das Takt- und Füllratenverhältnis von +30% zu gunsten der X850 XTPE wieder.

Auch der Pixelshader-Test des 3DMark05 zeigt einen leichten Vorsprung für die NV40.

Daß sie davon in realen Games bisher (und in Zukunft??) nur wenig in die Praxis umsetzen konnte, liegt vielleicht auch daran, daß viele Games nach wie vor sehr stark auf Texturen setzen, wie auch die texturlastigeren Shader in den Tests nahelegen.

[reunion]

Wenn ich mir jetzt mal als Beispiel den Shadermark herauspicke, dann schaut es überwiegend sehr wohl so aus. In etlichen Shadern liegt die Performance auf etwa gleichem Niveau, in einigen kann die NV40 sogar davonziehen (in anderen wiederum die X850 XTPE) und nur in sehr wenigen spiegelt sich das Takt- und Füllratenverhältnis von +30% zu gunsten der X850 XTPE wieder.

Auch der Pixelshader-Test des 3DMark05 zeigt einen leichten Vorsprung für die NV40.

Daß sie davon in realen Games bisher (und in Zukunft??) nur wenig in die Praxis umsetzen konnte, liegt vielleicht auch daran, daß viele Games nach wie vor sehr stark auf Texturen setzen, wie auch die texturlastigeren Shader in den Tests nahelegen.


Ich würde sagen es liegt eher daran, dass Shadermark oder 3dmark FP32 nur dort anwenden, wo es auch notwendig ist - alles andere wird mit FP16 berechnet, was auch beim NV40 mit einem mächtigen Performanceschub belohnt wird. Spiele setzten allerdings größtenteils auf volle Präzision. Teste mal die von dir angesprochenen Benchs mit FP32, und du wirst sehen, dass NV40 auch Taktbereinigt nicht wirklich im Vorteil ist.

[Xmas]

Könnte man da auch noch ein lineares Filtern draufbasteln? *immernoch an "Referenz-AF" denkt*
Du meinst, trilinear statt bilinear wie in den Screenshots? Klar, ich denke Hyp-X hat hier nur bilinear verwendet um das ganze deutlicher sichtbar zu machen.

Ich verstehe immer noch nicht wie man zu diesem Schluss kommen kann :|
Der Shader führt zu anderer Miplevel-Auswahl. Mehr kann man mit expliziten Gradienten nicht erreichen.
Doch, da die Berechnung des Anisotropie-Grades nämlich genauso wie die LOD-Berechnung auf eben diesen Gradienten basiert. Sonst könnte man auch gleich texldl nehmen.

Mintmaster hat es nicht verstanden.
max(du/dx, 0/dy)=du/dx für du>=0 (dx>0 ist gegeben)
max(0/dx,dv/dy)=dv/dy für dv>=0 (dy>0 ist gegeben)

Allgemein:
max(d_whatever/dx,0/dy)=d_whatever/dx
max(0/dx,d_whatever/dy)=d_whatever/dy

In 1D-Probleme zerlegen, und ein wenig Mittelstufenmathe, und dann klappt das auch für den generellen Fall.
Leider übersiehst du da etwas, und das ist dass es sich nicht um ein reines 1D-Problem handelt, solange die LOD-Auswahl Quad-basiert ist. Wenn du auf eine 1D-Textur zugreifst und somit nur u hast, ist der LOD von max(du/dx, du/dy) abhängig. Du kannst doch nicht garantieren, dass sich diese Koordinate in Y-Richtung nicht verändert.

Siehe oben. Wie soll das gehen? Wie bringt man einen Textursampler dazu, anisotrop zu filtern, indem man an den Gradienten spielt?
Gradienten sind überhaupt der einzige Weg, die Notwendigkeit für AF festzustellen. Stehen die Gradienten senkrecht aufeinander, und einer ist viermal länger als der andere, bekommst du 4x AF in Richtung des längeren Gradienten. Eigentlich ein sehr einfaches Konzept. Das Problem der Winkelabhängigkeit besteht nur dann, wenn die Gradienten eben nicht senkrecht aufeinander stehen.

[zeckensack]

Du meinst, trilinear statt bilinear wie in den Screenshots? Klar, ich denke Hyp-X hat hier nur bilinear verwendet um das ganze deutlicher sichtbar zu machen.


Doch, da die Berechnung des Anisotropie-Grades nämlich genauso wie die LOD-Berechnung auf eben diesen Gradienten basiert. Sonst könnte man auch gleich texldl nehmen.


Leider übersiehst du da etwas, und das ist dass es sich nicht um ein reines 1D-Problem handelt, solange die LOD-Auswahl Quad-basiert ist. Wenn du auf eine 1D-Textur zugreifst und somit nur u hast, ist der LOD von max(du/dx, du/dy) abhängig. Du kannst doch nicht garantieren, dass sich diese Koordinate in Y-Richtung nicht verändert.Natürlich kann ich das. Ich brauche für eine allgemeine Lösung einen dependency level. Dann kann ich eine der Koordinaten auf Null setzen, so dass deren Ableitung ebenfalls Null wird, und somit in der Max-Funktion keinerlei Relevanz mehr hat. Wenn ich über x ableiten will, setze ich die X-Koordinate auf die abzuleitende Funktion, und die restlichen Elemente auf Null (q auf 1, wenn ich mag). Wenn ich über y ableiten will, sinngemäß die Y-Koordinate auf die abzuleitende Funktion, und x/z auf Null.

Damit kann dann zB du/dy ausrechnen. Um mal Butter bei die Fische zu bekommen (ich befürchte mich versteht hier niemand so richtig), das geht so://generate lod lookup texture
ubyte* stuff=(ubyte*)malloc(256);
glActiveTextureARB(GL_TEXTURE0_ARB);
glGenTextures(1,&lod_texture);
glBindTexture(GL_TEXTURE_1D,lod_texture);

for (int miplevel=0;miplevel<=8;++miplevel)
{
int mip_size=1<<(8-miplevel);
uint deriv=(1<<miplevel)+1;
if (deriv>=256) deriv=255;
memset(stuff,deriv,mip_size);

glTexImage1D(GL_TEXTURE_1D,miplevel,GL_ALPHA8,size,0,GL_ALPHA,GL_UNSIGNED_BYTE,s tuff);
}
glTexParameteri(GL_TEXTURE_1D,GL_TEXTURE_MIN_FILTER,GL_NEAREST_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_1D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
glEnable(GL_TEXTURE_1D);
free(stuff);!!ARBfp1.0
TEMP du_o_dy;
TEMP lookup_coords;
MOV lookup_coords.xzw,{0.0,0.0,0.0,1.0};
MOV lookup_coords.y,fragment.texcoord[0].x;

TEX du_o_dy,lookup_coords,texture[0],1D;
MUL du_o_dy,du_o_dy,255.0;
...Hier füttere ich wieder eine interpolierte Texturkoordinate ein, aber es sollte nun nicht mehr viel Glauben deinerseits nötig sein, wenn ich dir sage dass man damit beliebige Funktionen ableiten kann.

Hier gibt's dann noch die Einschränkung, dass das Ergebnis maximal 255 sein kann. Der Rest ist Hardware-Präzision und ansonsten pure Fleißarbeit. Wenn [1..255] als Wertebereich nicht genügt, dann muss eine größere Textur in einem genaueren Format her. ZB 11 Stufen in INT16 für maximal 1024. Oder man macht den Lookup doch wieder linear, und biegt ihn sich (hier konkret mit du_o_dy:=pow(2,lookup) später zurecht).
Gradienten sind überhaupt der einzige Weg, die Notwendigkeit für AF festzustellen. Stehen die Gradienten senkrecht aufeinander, und einer ist viermal länger als der andere, bekommst du 4x AF in Richtung des längeren Gradienten.Nur wenn das AF auch angeschaltet wurde! Und dann brauche ich auch nicht mehr die "natürlichen" Gradienten zu befummeln, um in den "einfachen" Winkeln AF zu erhalten. Das geht dann von ganz alleine.
Anders herum, wenn ich das AF nicht schon aktiviert habe, kriege ich über modifizierte Gradienten auch kein vernünftiges AF an den "schwierigen" Winkeln. Es gibt nur zwei Möglichkeiten:
a)Die Änderung ist äquivalent zu abgesenktem LOD-Bias
b)Die Änderung ist äquivalent zu einer gedrehten Line of anisotropy
(und Mischungen)
Dass a scheiße ist, sollte offensichtlich sein.
B ist ebenfalls scheiße, weil man dann zwar die Filterlogik dazu bringt "AF" zu machen (dh mehrere Mip-Samples verrechnet werden), allerdings völlig falsches AF, mit dem richtigen Maximalgrad, aber mit den falschen Samples.
Eigentlich ein sehr einfaches Konzept. Das Problem der Winkelabhängigkeit besteht nur dann, wenn die Gradienten eben nicht senkrecht aufeinander stehen.Im bekannten AF-Tunnel stehen die Gradienten (du/dx;du/dy und dv/dx;dv/dy) an jedem Punkt senkrecht aufeinander.

[aths]

Das haben wir schon mal diskutiert und da ich nicht nachtragend bin, lasse ich es.
In dem Thread ging es um 9800PRO gegen 5900Ultra (Ende 2003).
Ich meinte, dass die 5900 in Spielen mit SM2 gegen einen R350 gnadenlos untergehen wird, das hast du anders gesehen.
Und du hast falsch gelegen.Dass du da richtig lagst, ist wahrscheinlich keine Folge eines Verständnisses der Architektur.

War doch nur Spass. :)
Du nimmst aber alles bitterernst. ;DUnd dann war es nur Spaß. Immer die gleiche Ausrede. Zum Spaßmachen haben wir die Spielwiese.


Könnte man da auch noch ein lineares Filtern draufbasteln? *immernoch an "Referenz-AF" denkt*Du meinst, um trilineares AF zu bekommen?

[Xmas]

Natürlich kann ich das. Ich brauche für eine allgemeine Lösung einen dependency level. Dann kann ich eine der Koordinaten auf Null setzen, so dass deren Ableitung ebenfalls Null wird, und somit in der Max-Funktion keinerlei Relevanz mehr hat. Wenn ich über x ableiten will, setze ich die X-Koordinate auf die abzuleitende Funktion, und die restlichen Elemente auf Null (q auf 1, wenn ich mag). Wenn ich über y ableiten will, sinngemäß die Y-Koordinate auf die abzuleitende Funktion, und x/z auf Null.Es reicht nicht, die restlichen Koordinaten auf Null zu setzen. Lies nochmal was ich geschrieben habe: Wenn du nur u hast, dann hängt der LOD von max(du/dx, du/dy) ab. Denn diese einzelne U-Koordinate ändert sich sowohl horizontal als auch vertikal im Screen-Space.

Mal ein Beispiel um das zu verdeutlichen:
Ein Quad hat vier Pixel:
A B
C D
mit den Texturkoordinaten:
(0, 1) (1, 0)
(2, 3) (3, 2)

Mit den Gradienteninstruktionen ergeben sich ddx = B - A = (1, -1) und ddy = C - A = (2, 2).

Nun kommt jemand auf die Idee, nur eine Komponente der Texturkoordinaten zu nehmen und durch LOD-Ermittlung die Gradienten bestimmen zu wollen. Also nur diese Texturkoordinaten zum Zugriff auf eine 1D-Textur zu verwenden:
0 1
2 3

Dummerweise ist jetzt B - A = du/dx = 1 kleiner als C - A = du/dy = 2. Deswegen wird die 2 zur Ermittlung des LOD verwendet, die 1 kommt gar nicht zum Einsatz. Auf diese Weise kriege ich also du/dx nie heraus, wenn du/dy größer ist!

Nur wenn das AF auch angeschaltet wurde! Und dann brauche ich auch nicht mehr die "natürlichen" Gradienten zu befummeln, um in den "einfachen" Winkeln AF zu erhalten. Das geht dann von ganz alleine.
Anders herum, wenn ich das AF nicht schon aktiviert habe, kriege ich über modifizierte Gradienten auch kein vernünftiges AF an den "schwierigen" Winkeln. Es gibt nur zwei Möglichkeiten:
a)Die Änderung ist äquivalent zu abgesenktem LOD-Bias
b)Die Änderung ist äquivalent zu einer gedrehten Line of anisotropy
(und Mischungen)
Dass a scheiße ist, sollte offensichtlich sein.
B ist ebenfalls scheiße, weil man dann zwar die Filterlogik dazu bringt "AF" zu machen (dh mehrere Mip-Samples verrechnet werden), allerdings völlig falsches AF, mit dem richtigen Maximalgrad, aber mit den falschen Samples.Natürlich muss AF eingeschaltet sein, sonst macht die Hardware ja kein AF. Aber um es winkelunabhängig zu bekommen, muss man die Gradienten verändern. Ja, Hyp-X' Methode ändert die Line of Anisotropy. Nämlich zur längsten Diagonale im Viereck. Das ist übrigens häufig die beste Line of Anisotropy. Nur beim Wechsel von einer Diagonale zur anderen könnte das problematisch sein.
Im bekannten AF-Tunnel stehen die Gradienten (du/dx;du/dy und dv/dx;dv/dy) an jedem Punkt senkrecht aufeinander.Tun sie nicht.
Edit: Meinst du wirklich (du/dx, du/dy) und (dv/dx, dv/dy)? Es kommt auf den Winkel zwischen (du/dx, dv/dx) und (du/dy, dv/dy) an.
Das kannst du mit einem kurzen Shader ganz leicht nachprüfen:
gradx = normalize(ddx(Input.Texcoord));
grady = normalize(ddy(Input.Texcoord));
return abs(dot(gradx, grady));
Sieht so aus. (http://www.xm45.de/Bilder/tunnelgrad.png)

Hier nochmal, warum das so ist:
http://www.xm45.de/Bilder/tunnelgrad2.png
Links Screen Space, rechts Texture Space. Das Pixelraster ist rot gepunktet, die roten Kreuze die Samplepositionen, ddx lila, ddy grün. Wie man sieht, stehen ddx und ddy im Texture Space bei einer gedrehten Fläche nicht mehr annähernd senkrecht aufeinander.



edit by aths: Hatte das Posting versehentlich editiert statt zu zitieren. Hatte zum Glück noch eine Page offen wo das Posting in der Threadansicht war, und habs damit rekonstruiert.

[MadManniMan]

Richtig, ich meinte Tri-AF nach laut diesem Shader.

Kann man eigentlich auch ohne weiteres bestimmen, wie weit die Mips nach hinten geschoben werden dürfen? Ich denke da grad an Nyquist - und im Zusammenhang mit ihm immernoch an Quasi-Referenz-AF :idea:

[MikBach@work]

Dass du da richtig lagst, ist wahrscheinlich keine Folge eines Verständnisses der Architektur.
Also habe ich wahrsagerische Fähigkeiten? :rolleyes:
*scnr* :)

Und dann war es nur Spaß. Immer die gleiche Ausrede. Zum Spaßmachen haben wir die Spielwiese.

Man, das war doch auf diese Aussage bezogen:
Also komm mal wieder zurück auf den Teppich, wenn es nicht geht, dann schnall dich mal an. :D

Oder soll ich noch mehr Smiles hinknallen, damit du verstehst, dass es Spass war?

BTW hier ist für mich EOD über die alte Geschichte, wir wollen die schöne Shaderdiskussion nicht kaputt machen. :)

[Mr. Lolman]

Wenn ich mir jetzt mal als Beispiel den Shadermark herauspicke, dann schaut es überwiegend sehr wohl so aus. In etlichen Shadern liegt die Performance auf etwa gleichem Niveau, in einigen kann die NV40 sogar davonziehen (in anderen wiederum die X850 XTPE) und nur in sehr wenigen spiegelt sich das Takt- und Füllratenverhältnis von +30% zu gunsten der X850 XTPE wieder.

Auch der Pixelshader-Test des 3DMark05 zeigt einen leichten Vorsprung für die NV40.

Daß sie davon in realen Games bisher (und in Zukunft??) nur wenig in die Praxis umsetzen konnte, liegt vielleicht auch daran, daß viele Games nach wie vor sehr stark auf Texturen setzen, wie auch die texturlastigeren Shader in den Tests nahelegen.

Schau mal da: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3459585#post3459585

[Gast]

Also habe ich wahrsagerische Fähigkeiten? :rolleyes:
*scnr* :)

Man, das war doch auf diese Aussage bezogen:


Oder soll ich noch mehr Smiles hinknallen, damit du verstehst, dass es Spass war?

BTW hier ist für mich EOD über die alte Geschichte, wir wollen die schöne Shaderdiskussion nicht kaputt machen. :)

Auch dir möchte ich folgenden Thread ans Herz legen, da die Moderation zuweilen nicht alles sehen kann, schreite ich hier als mündiger User ein.

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=111796#post111796

[MikBach@work]

Auch dir möchte ich folgenden Thread ans Herz legen, da die Moderation zuweilen nicht alles sehen kann, schreite ich hier als mündiger User ein.

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=111796#post111796
LOL, ein Gast-Mod. =)

Danke Gast. ;)

[zeckensack]

<...>
Ich gebe mich in fast allen Punkten geschlagen. Da muss ich wohl nochmal zurück ans Reißbrett :)
a)ich hatte die LOD-Formel falsch im Kopf. Steht ja oben, wie ich mir das vorstellte.
b)ich habe die Perspektivkorrektur völlig vergessen :(

Was noch fehlt: ich bin immer noch nicht davon überzeugt, dass hierbei brauchbares AF herauskommt. Bis morgen versuche ich meine Gedanken dazu nochmal zu sortieren.