Cg 1.3 mit FP-Branching für OpenGL

[Asmodeus]

Latest Cg Toolkit Features

Release 1.3 Beta 2 of the NVIDIA Cg Toolkit includes the following features and improvements:

+ New 'vp40' profile, which enables texture sampling from within vertex programs
+ New 'fp40' profile, which provides a robust branching model in fragment programs, and support for output to multiple draw buffers (‘MRTs’)
...


Könnte das vielleicht jemand mal ausprobieren, da ich selbst nur mit GLSL arbeite. Theoretisch könnte sich dann doch ein Fragmentprogramm (mit Branching relevanten Befehlen), welches mit Cg 1.2 übersetzt wurde syntaktisch in irgend einer Weise von dem Fragmentprogramm, wenn es mit Cg 1.3 übersetzt wurde unterscheiden, oder?
Falls es an dem ist, und jemand das mal ausprobiert, dann könnte er ja hier mal beide Listings posten.

Gruss, Carsten.

[Asmodeus]

In den ReleaseNotes sind die neuen Parameter auch erklärt:


New feature: fp40 profile: branching

The branching support in ‘fp40’ allows some ‘if’ statements and looping constructs to be
implemented with branching. In profiles such as fp30, conditional execution of code
was always implemented with predicated instructions, and loops were always unrolled.
In the GeForce 6800 GPU, there is a cost associated with executing a branch in the
fragment shading engine. As such, it is possible that the cost of the branch will outweigh
the savings from skipping over a block of conditionally-executed code, or of
executing an unrolled loop. (Please refer to the NVIDIA developer web site for more
information about the performance of this and other NVIDIA GPUs.) The fp40
profile, therefore, provides the following options to control whether the compiler should
emit branches or conditionally-executed code for the ‘if’ statements and loops within Cg
shaders:

-ifcvt (all | none | count=N)
Changes if-conversion mode based on the option.
all All 'if' statements will be converted to conditional
writes
none All 'if' statements will generate branching code
count=N Sets if_limit_cost to N "operations"

-unroll (all | none | count=N)
Changes loop-unrolling mode based on the option.
all All loop statements that can be unrolled will be
none All loop statements that can be implemented with
branching will be
count=N Sets loop_limit_cost to ‘N’ operations

Setting both –ifcvt and –unroll to “all” will yield behavior similar to the fp30 profile,
where branch instructions are not available. Using “-ifcvt=none” places burden on the
Cg fragment program author to use ‘if’ statements where they want true branches, and to
use conditional expressions otherwise.


Die CgCompiler Version des neuen BetaTreibers 67.66 ist übrigens identisch. Meine Frage wäre jetzt, gibt es bei der Nutzung von GLSL die Möglichkeit dem treiberinternen Compiler auch diese neuen Parameter zu übergeben, oder sind die übergebenen Parameter festgeschrieben?

Gruss, Carsten.

[Chris Lux]

Die CgCompiler Version des neuen BetaTreibers 67.66 ist übrigens identisch. Meine Frage wäre jetzt, gibt es bei der Nutzung von GLSL die Möglichkeit dem treiberinternen Compiler auch diese neuen Parameter zu übergeben, oder sind die übergebenen Parameter festgeschrieben?

setz doch einfach mal die registry einträge, die den treiber dazu veranlassen das assembly deiner shader auszuschreiben. in diesen files stehen oben in den kommentaren IIRC alle parameter, mit welchen der interne (cg-)compiler aufgrufen wurde.

p.s. mit glview kann man diesen reg eintrag komportabel setzen.

[Asmodeus]

setz doch einfach mal die registry einträge, die den treiber dazu veranlassen das assembly deiner shader auszuschreiben. in diesen files stehen oben in den kommentaren IIRC alle parameter, mit welchen der interne (cg-)compiler aufgrufen wurde.

p.s. mit glview kann man diesen reg eintrag komportabel setzen.

Ja, das habe ich schon ausprobiert. Es werden allerdings nur folgende Parameter verwendet:


# command line args: -q -profile fp40 -entry main -oglsl -D__GLSL_CG_DATA_TYPES -D__GLSL_CG_STDLIB -D__GLSL_SAMPLER_RECT


Meine Frage war nun eher, ob es eine Möglichkeit gibt, diese Parameterliste von außen per Hand noch zu erweitern.

Gruss, Carsten.

[Chris Lux]

Meine Frage war nun eher, ob es eine Möglichkeit gibt, diese Parameterliste von außen per Hand noch zu erweitern.
nope, die gibt es sicherlicht nicht. ich find es auch schade, aber so ist das konzept von glslang, welches durch vendor-spezifische compilerswitches leider wieder keinen portablen code zulassen würde.

[Asmodeus]

nope, die gibt es sicherlicht nicht. ich find es auch schade, aber so ist das konzept von glslang, welches durch vendor-spezifische compilerswitches leider wieder keinen portablen code zulassen würde.

Womit sich wieder die Frage stellt, wie die Branching-Funktionalität überhaupt unter GLSL auf NV40 Karten nutzbar gemacht werden soll. Sicher, ein Weg wäre, dass im nächsten Treiber einfach beim fp40 Profil der Parameter "-ifcvt none" mit in die Aufrufliste für Cgc übernommen wird. Aber das wäre natürlich nicht ideal, da somit eine genaue Spezifizierung wie sie über "count=N" möglich wäre nicht gegeben ist und einfach jedes IF-Statement in Branching-Code umgewandelt wird. Oder eben doch über eine NV-Extension, mit der man z.B. das Vorhandensein von branchingfähiger Hardware abfragen kann und gegebenenfalls dann den Count-Parameter mit einem anderen Befehl von Hand setzen könnte. Außerdem ist die ganze Sache ja nur momentan ein "Nvidia-Problem", Ati wird die Sache ja auch irgendwie lösen müssen, wenn sie irgendwann branchingfähige Hardware anbieten.

Gruss, Carsten

[Chris Lux]

Womit sich wieder die Frage stellt, wie die Branching-Funktionalität überhaupt unter GLSL auf NV40 Karten nutzbar gemacht werden soll. Sicher, ein Weg wäre, dass im nächsten Treiber einfach beim fp40 Profil der Parameter "-ifcvt none" mit in die Aufrufliste für Cgc übernommen wird. Aber das wäre natürlich nicht ideal, da somit eine genaue Spezifizierung wie sie über "count=N" möglich wäre nicht gegeben ist und einfach jedes IF-Statement in Branching-Code umgewandelt wird. Oder eben doch über eine NV-Extension, mit der man z.B. das Vorhandensein von branchingfähiger Hardware abfragen kann und gegebenenfalls dann den Count-Parameter mit einem anderen Befehl von Hand setzen könnte. Außerdem ist die ganze Sache ja nur momentan ein "Nvidia-Problem", Ati wird die Sache ja auch irgendwie lösen müssen, wenn sie irgendwann branchingfähige Hardware anbieten.
full ack...
vielleicht wäre es ja möglich per glslang extensions sowas wie pragmas im code festlegen zu können, was aber wiederum nicht einheitlich wäre. dies könnte man vergleichen mit den config.h files, in denen für jegliche abart von compiler bestimmte sachen eingeschaltet werden... naja ob das so toll werden würde...

ich glaub man muss sich dann wohl oder übel auf den treiberinternen code optimierer verlassen... leider...

[Asmodeus]

...
ich glaub man muss sich dann wohl oder übel auf den treiberinternen code optimierer verlassen... leider...

Ok, und genau das scheint auch schon zu passieren. Ich hatte jetzt extra nochmal nen alten Treiber drauf und die neueren Treiber (66.93 bis 67.66) benutzen das Branching schon selbstständig bei GLSL. Es wird aber nicht die Einstellung "none" verwendet sondern für den "count" Parameter irgend ein fester Wert gesetzt, so scheint es jedenfalls. Mein komplexester Shader wächst dadurch von 80 Instruktionen auf 92 Instruktionen, der aus dem Branching dann resultierende Geschwindigkeitszuwachs fällt aber sehr gering aus.

Gruss, Carsten

[Demirug]

Ob branchin verwendet wird oder nicht entscheidet dabei nicht mal der Compiler sondern der noch tiefer liegende Optimizier. Der entfernt nämlich auch aus DX 3.0 Shader die Branches wenn er meint das sie schlecht gewählt wurden.