Shader 2.0 vs 3.0

[Matti]

Was können die 3.0-Shader, was die 2.0er nicht können?

...z.B. würde ich mir globale Variablen wünschen, die sowohl vom Haupt-Programm als auch vom Shader geändert werden können ... das ganze auch für beliebig große Arrays.

...oder daß man Geometrie komplett im Vertex-Shader berechnen kann, also ohne den Shader von außen mit Vertexen zu füttern.


Und ist GLSL eigentlich schon für 3.0-Shader ausgelegt?

[Coda]

Static Branching im PixelShader
Dynamic Branching
Arbitrary Swizzle (auch nVidia SM 2.0)
Predication (auch nVidia SM 2.0)
Vertex Shader TMUs
Mehr PixelShader Inputregister, und all 10 sind floating point (einheitlich)
mehr temponäre Register


...z.B. würde ich mir globale Variablen wünschen, die sowohl vom Haupt-Programm als auch vom Shader geändert werden können ... das ganze auch für beliebig große Arrays.Uhm, sowas nennt man Rendertarget :D

...oder daß man Geometrie komplett im Vertex-Shader berechnen kann, also ohne den Shader von außen mit Vertexen zu füttern.Das gibt's erst mit WGF, außer man benützt Render-To-Vertexbuffer. Das geht aber nur mit nVidia Karten und OpenGL.

Und ist GLSL eigentlich schon für 3.0-Shader ausgelegt?Theoretisch ja, aber ich weiß nicht ob der nVidia Treiber es schon kann.

[Monger]

...
Arbitary Swizzle (auch nVidia SM 2.0)
Predication (auch nVidia SM 2.0)
...


Sorry wenn ich nachfrage, aber über die zwei Begriffe hab ich irgendwie nix ergooglen können...

Ich vermute, mit dem ersten ist Arbitrary gemeint?!? Arbitrary heißt "willkürlich" oder "beliebig", zu swizzle hab ich überhaupt keine sinnvolle Übersetzung gefunden, ganz zu schweigen von einer technischen Definition des gesamten Begriffes...

Predication gibt auch keinen Hinweis auf den technischen Gebrauch, also was heißen diese beiden Begriffe?

[Coda]

Ja da hast du recht. Irgendwie hatte sich bei mir "arbitary" im Gedächtnis verewigt, geht einem halt manchmal so als Englisch Autodidakt ;)

Du kannst in Pixelshadern die Ergebnisse von Berechnungen auf das Zielregister verteilen mit entsprechenden Modifiern. Z.B.:

MOV r0.yzwx, r1

Bei ATi hat man da nur begrenzte Möglichkeiten zu "swizzlen" nämlich:

.x, .y, .z, .w, .xyzw, .yzxw, .zxyw und .wzyx

Damit kann man alle anderen nachbilden, braucht aber mehr Instructions

Mit Predication kann man die Ausführung von ganzen Codeblöcken verhindern. Die Instructions werden soweit ich weiß aber trotzdem ausgeführt, aber die Ergebnisse verworfen (also kein richtiger Sprung)

[Monger]

...
Mit Predication kann man die Ausführung von ganzen Codeblöcken verhindern. Die Instructions werden soweit ich weiß aber trotzdem ausgeführt, aber die Ergebnisse verworfen (also kein richtiger Sprung)

Ich will nicht kleinlich wirken, aber müsste es dann nicht "Prediction" =Vorhersage heißen? Predication heißt nämlich so viel wie "Aussage"...
Ist das das selbe wie Branching? Damit wurde ja bei SM 3.0 ganz stark geworben...

Aber danke für die Info. Noch eine Frage zu den Registern: Heißt das, dass z.B. ATI Ergebnisse aus Shaderberechnungen eben nur in einer ganz bestimmten Weise in den Registern ablegen kann, oder andernfalls noch einige Zwischenschritte einlegen müsste? Das würde natürlich vorallem mit komplexeren Shader mit starker Registerauslastung zu Performance Problemen führen, richtig ?!?

[Coda]

Nein. Mit richtigem Branching werden die Blöcke wirklich übersprungen, also die Instructions gar nicht ausgeführt. Auch Loops sind mit Predication natürlich nicht möglich.

Aber danke für die Info. Noch eine Frage zu den Registern: Heißt das, dass z.B. ATI Ergebnisse aus Shaderberechnungen eben nur in einer ganz bestimmten Weise in den Registern ablegen kann, oder andernfalls noch einige Zwischenschritte einlegen müsste? Das würde natürlich vorallem mit komplexeren Shader mit starker Registerauslastung zu Performance Problemen führen, richtig ?!?Uhm. Das führt nur zu "Performanceeinbrüchen" wenn man Swizzles verwendet die ATi nicht direkt kann.

[Xmas]

...z.B. würde ich mir globale Variablen wünschen, die sowohl vom Haupt-Programm als auch vom Shader geändert werden können ... das ganze auch für beliebig große Arrays.
Meinst du, um Ergebnisse wie Minimum, Maximum oder Summe von Shaderdurchläufen zu berechnen? Ist leider wegen der Parallelität nur schwer möglich und natürlich nur für assoziative Operationen überhaupt sinnvoll.


Ich will nicht kleinlich wirken, aber müsste es dann nicht "Prediction" =Vorhersage heißen? Predication heißt nämlich so viel wie "Aussage"...
Ist das das selbe wie Branching? Damit wurde ja bei SM 3.0 ganz stark geworben...
Predication heißt, dass das Ergebnis einer Instruktion abhängig von einem Wahrheitswert geschrieben oder verworfen wird. Es wird also nicht wirklich gesprungen, somit ist der Overhead geringer. Deswegen kann man damit kurze IF-Blöcke effizient realisieren.

Aber danke für die Info. Noch eine Frage zu den Registern: Heißt das, dass z.B. ATI Ergebnisse aus Shaderberechnungen eben nur in einer ganz bestimmten Weise in den Registern ablegen kann, oder andernfalls noch einige Zwischenschritte einlegen müsste? Das würde natürlich vorallem mit komplexeren Shader mit starker Registerauslastung zu Performance Problemen führen, richtig ?!?
Wieso bei starker Registerauslastung? Man braucht evtl. zusätzliche MOV-Instruktionen, um die Ergebnisse richtig auf die Kanäle zu verteilen, mehr Register aber nicht.

[Monger]

Wieso bei starker Registerauslastung? Man braucht evtl. zusätzliche MOV-Instruktionen, um die Ergebnisse richtig auf die Kanäle zu verteilen, mehr Register aber nicht.

Verstehe ich nicht. Wenn ich das bis jetzt richtig verstanden habe, ist das Problem doch, dass Rechenergebnisse bei ATI nur auf bestimmte Register gelegt werden können, zumindest innerhalb einer Instruktion. Würde man gar nicht alle Register brauchen, wäre das umsortieren ja auch nicht notwendig, oder?!?

Oder ist jedes Register jeweils für irgendwas spezielles reserviert? Was heißt hier "Kanäle" in dem Zusammenhang?

[Coda]

Nein, das hast du falsch verstanden. Die Register in den Shadern sind Vektoren mit 4 Komponenten.
Mit Swizzle kannst du die Ergebnisse nicht nur in der "normalen" Reihenfolge xyzw reinschreiben, sondern eben in anderen Reihenfolgen.

[Matti@work]

Uhm, sowas nennt man Rendertarget :D

für Raytracing-ähnliche Effekte wäre es sinnvoll, wenn man im Pixel-Shader auch auf Geometrie-Daten zugreifen könnte. Um die Geometrie-Daten zu speichern wären Arrays die flexibelste Lösung. Inwiefern ein Render-Target dafür geeignet ist, kann ich nicht beurteilen, da ich eventuelle Größen- und Zugriffs-Einschränkungen nicht kenne.

[Coda]

Ein Rendertarget/Textur ist der native Input für eine Grafikkarte. Schneller geht's nicht. Ist im Prinzip ja auch nichts anderes als ein Vektorarray.

Größenbeschränkung ist im Moment bei nVidia 4096x4096x4096, bzw 4096x1 bei linearem Zugriff.

[Chris Lux]

Größenbeschränkung ist im Moment bei nVidia 4096x4096x4096, bzw 4096x1 bei linearem Zugriff.
WOWOWOW mal nich so schnell.. 4096x4096 für 2D texturen... 3D texturen sind bei max 512x512x512.

[aths]

Ein Rendertarget/Textur ist der native Input für eine Grafikkarte. Schneller geht's nicht. Ist im Prinzip ja auch nichts anderes als ein Vektorarray.

Größenbeschränkung ist im Moment bei nVidia 4096x4096x4096, bzw 4096x1 bei linearem Zugriff.Ich denk, schon GF3 kann 4096-er, und der NV40 sogar 8192-er Texturen (sowie "non-power-of-2" "fullspeed"?)

[Coda]

Hm nein, auch der NV40 kann nur maximal 4096, deshalb ja auch das 16xSS Limit auf 1024x768.
Hm ja bei 3D Texturen stimmt das mit 512. Macht aber trotzdem nix, weil 4096x4096x4096 kaum in den Speicher passen würde ;)

Und non-power-of-2 gibt's nirgends fullspeed.

[Demirug]

Und non-power-of-2 gibt's nirgends fullspeed.

IIRC hat nVidia das aber mal behauptet. Zumindestenes funktioniert non-power of 2 jetzt immer auf dem NV40. Andere Chips haben da ja Begrenzungen.

[marco42]

IIRC hat nVidia das aber mal behauptet. Zumindestenes funktioniert non-power of 2 jetzt immer auf dem NV40. Andere Chips haben da ja Begrenzungen.

Ich dachte immer die anderen chips koennen nur ARB_texture_rectangle, was ja doch sehr unterschiedlich ist. Wie steht es den mit dem P20?

[aths]

Hm nein, auch der NV40 kann nur maximal 4096, deshalb ja auch das 16xSS Limit auf 1024x768.Hast du NV-Docs, wo das mit den 4096 drinsteht?

[Demirug]

Hast du NV-Docs, wo das mit den 4096 drinsteht?

Selbst wenn die Hardware mehr könnte man bekommt nicht mehr vom Treiber.

[Coda]

Hast du NV-Docs, wo das mit den 4096 drinsteht?Nö, aber ich hab den DX Caps Viewer, der mir 4096 meldet :rolleyes:

Außerdem macht sonst wie gesagt das Limit auf 1024x768 für 4x4 SS keinen Sinn.

[Chris Lux]

Nö, aber ich hab den DX Caps Viewer, der mir 4096 meldet :rolleyes:


glview meldet die werte die ich oben genannt hab für meine 6800er karten (auch mit verschiedenen fw versionen bis hoch zur 75.90)

[Coda]

Argh ich rede nicht von 3D Texturen. Da ist 512 richtig, hab ich doch schon gesagt.

[aths]

Selbst wenn die Hardware mehr könnte man bekommt nicht mehr vom Treiber.Das ist komisch. Ich meine von wichtigen Leuten gehört zu haben, dass der NV40 8192-er Texturen können sollte. Vielleicht kann ich das auf der CeBit in Erfahrung bringen.