Unterlagen zur Shaderprogrammierung

[thewulf]

Hallo,

Hat vielleicht irgendwer Links zu einer Beschreibung der OpenGL Vertex Shader Befehle? Auf der OpenGL Seite ist nur die Spezifikation der Shading Language zu finden, ich brauch aber die Beschreibung der Assembler-ähnlichen Variante. Bei NVidia hab ich nur eine Auflistung der Befehle gefunden, nicht aber deren Bedeutung.

Vielen Dank schon mal!


Bei NVidia hab ich jetzt doch eine Beschreibung der einzelnen Befehle gefunden, allerdings ist die für die NV, nicht für die ARB Extension. Ich nehm mal an, dass da nicht allzuviel Unterschied ist...

[Chuck]

da das ganze eine extension ist ist die spezifikation dazu auch in der extension registry zu finden :)
hier ein kleines link (ist halt wie alle ext spezifikaitonen ein wenig anstrengend zu lesen, aber es sind alle befehle beschrieben und gibt sogar ein paar bsps)

http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_program.txt

[ChrisChiu]

Eventuell hilft da www.shadertech.com weiter.

Spricht eigentlich irgendwas gegen eine Hochsprache wie Cg? Cg kann nämlich auch in ARB Extensions kompilieren und funktioniert somit auch mit ATI Hardware (R3xx und höher) bzw. mit allem was ARB_fragment_program und ARB_vertex_program unterstützt.

(Man glaubt es kaum, aber Cg ist nicht NVIDIA-spezifisch, auch wenn das so oft geglaubt wird... hab vor kurzem einen Vortrag gesehen wo das auch behauptet wurde, anscheinend wissen die meisten Leute nicht in welcher Abstraktionsebene Cg jetzt tatsächlich ist, nämlich überhalb sowohl der APIs als auch der spezifischen Extensions sowie Hardware).

[cypher]

Spricht eigentlich irgendwas gegen eine Hochsprache wie Cg? Cg kann nämlich auch in ARB Extensions kompilieren und funktioniert somit auch mit ATI Hardware (R3xx und höher) bzw. mit allem was ARB_fragment_program und ARB_vertex_program unterstützt.


kann nach eingehender beschäftigung mit Cg z.Zt. leider wirklich nur davon abraten, vor allem im Zusammenhang mit so einer Übung. Der Compiler ist nach wie vor nicht zuverlässig und macht (vor allem beim kompilieren in das ARB-Profil) teilweise wirklich wilde Fehler, die dann sehr mühevoll und zeitaufwändig nachvollzogen werden müssen - da man sich spätestens dann die kompilierten ARB_fragment_programs ansehen muss, kann man es auch gleich dort coden :). Ausserdem optimiert der Compiler sehr stark auf die NV-Architektur, so dass die Programme auf ATI-Chips recht langsam und recht schnell auch gar nicht mehr laufen (z.B. keine Berücksichtigung der tex-nodes restriction sprich Zusammenfassung der Texture-Zugriffe, Optimierungen hauptsächlich auf Register ausgerichtet etc.).

Andere Fehler in den Libraries waren leider nicht so "einfach" nachzuvollziehen, und haben dann einfach plötzlich funktioniert, wenn ich es ohne das Cg-Kit gelöst habe.

Vor allem aber wird Cg nicht mehr wirklich aktiv weiterentwickelt, da nvidia inzwischen selbst auf Microsofts HLSL setzt, die aber nur unter DirectX läuft.

Würde also eher auf die GLSlang warten ...

[ChrisChiu]

kann nach eingehender beschäftigung mit Cg z.Zt. leider wirklich nur davon abraten, vor allem im Zusammenhang mit so einer Übung. Der Compiler ist nach wie vor nicht zuverlässig und macht (vor allem beim kompilieren in das ARB-Profil) teilweise wirklich wilde Fehler, die dann sehr mühevoll und zeitaufwändig nachvollzogen werden müssen - da man sich spätestens dann die kompilierten ARB_fragment_programs ansehen muss, kann man es auch gleich dort coden :). Ausserdem optimiert der Compiler sehr stark auf die NV-Architektur, so dass die Programme auf ATI-Chips recht langsam und recht schnell auch gar nicht mehr laufen (z.B. keine Berücksichtigung der tex-nodes restriction sprich Zusammenfassung der Texture-Zugriffe, Optimierungen hauptsächlich auf Register ausgerichtet etc.).

Andere Fehler in den Libraries waren leider nicht so "einfach" nachzuvollziehen, und haben dann einfach plötzlich funktioniert, wenn ich es ohne das Cg-Kit gelöst habe.

Vor allem aber wird Cg nicht mehr wirklich aktiv weiterentwickelt, da nvidia inzwischen selbst auf Microsofts HLSL setzt, die aber nur unter DirectX läuft.

Würde also eher auf die GLSlang warten ...

Hm, schade, denn vom Prinzip her find ich Cg als API-unabhängige Hochsprache ziemlich attraktiv. Vor allem auch in Anbetracht dessen, dass sich damit auch ein paar Renderpfade (speziell für NV2x) vermeiden lassen würden.

[thewulf]

Danke an alle, jetzt hab ich wieder was zu lesen http://hades.gothic.at/iforum/images/smilies/wink.gif. Mal schaun, ob ich damit meine Schwierigkeiten lösen kann.

[cypher]

Hm, schade, denn vom Prinzip her find ich Cg als API-unabhängige Hochsprache ziemlich attraktiv. Vor allem auch in Anbetracht dessen, dass sich damit auch ein paar Renderpfade (speziell für NV2x) vermeiden lassen würden.

ja, deshalb hab ich mich damals auch für Cg entschieden ... die Möglichkeit, die Shader-Programme zur Laufzeit neu für das jeweilige System kompilieren zu lassen, ist wirklich sehr nett.

schade vor allem, dass nvidia die nervigsten Bugs in der neuesten Version noch immer nicht behoben hat. Aber wie David Kirk im Interview selbst zugab, konzentriert man sich inzwischen halt auf die HLSL ...

Bin auch noch nicht ganz schlüssig, was ich in Zukunft machen werde - bei der GLSlang stört mich halt, dass man den übersetzten Code nicht mehr zu Gesicht bekommt. Und nachdem ich beim "handoptimieren" von übersetztem Cg-Code nicht selten einen Speedup um einen Faktor 10-20 (!) erzielen konnte, bleib ich z.Zt. lieber mal bei den ARB_fragment_programs - zumindest solange, bis die ARB-Shader-Programme so unübersichtlich und lang werden, dass das den Wechsel auf eine Hochsprache wieder rechtfertigt.