DOT3_RGBA in register combiners

[bakery2k]

NV_register_combiners can easily do a dot product "tex0 dot tex1", and put this into the r, g and b components of spare0, for example. This is similar to the DOT3_RGB texture env mode.
Does anyone know how, in a single general combiner, to do the dot product and save the results into all 4 r, g, b AND A components of the destination register? i.e. can I do a "DOT3_RGBA" in a single general combiner?

Thanks

Paul

[This message has been edited by bakery2k (edited 01-29-2003).]

[Diapolo]

*wrong infos have been deleted *

Diapolo

[This message has been edited by Diapolo (edited 01-29-2003).]

[bakery2k]

This will not work, since the alpha part of the combiner cannot do dot products. Quote from the spec:

CombinerOutputNV(GLenum stage, GLenum portion, GLenum abOutput, GLenum cdOutput, GLenum sumOutput, GLenum scale, GLenum bias, GLboolean abDotProduct, GLboolean cdDotProduct, GLboolean muxSum);

...

If the <portion> parameter is ALPHA, specifying a non-FALSE value
for either of the parameters <abDotProduct> or <cdDotProduct>,
generates an INVALID_VALUE error.

[Diapolo]

Damn, you are absolutely right, only Mult / Mult / Mux or Mult / Mult / Sum ... sorry then!

Diapolo

[Asgard]

While I was working on a DirectX pixel shader to reg combiners translator for my engine I faced the same problem and couldn't find a real solution (without using another combiner stage that is).
In DirectX pixel shaders the dp3 instruction replicates the result to all four components. The only way to emulate this behavior in my translator was to skip ahead and look for instructions that would read the dp3 result from the alpha component and make those instructions read from the blue component instead.

[bakery2k]

Believe it or not, a pixel shader to register combiners translator is exactly what I am working on!
I also had the same idea to look ahead and read from the blue component, but realised that may cause a problem with a program such as:

dp3 r0.rgba, t0, t1
mul r0.rgb, r0, t2
add r0.a, r0, t3

In this case, reading from the blue component of r0 in the 3rd instruction would be no good, as it has been modified in the 2nd instruction.

[Asgard]

My translator also handles such a case by using another combiner stage to duplicate the dp3 result into the alpha component. I spent a lot of time on it and couldn't find a better way. If you find one, let me know.

You can grab the source of my translator from the CVS repository of my project http://xengine.sourceforge.net.
The translator is in /src/Renderers/RendererOGL13/XFragmentShaderOGL13_DirectXPSA.cpp and /include/Renderers/RendererOGL13/XFragmentShaderOGL13_DirectXPSA.h.
Good luck.

[This message has been edited by Asgard (edited 01-29-2003).]

[vincoof]

In the register combiners, you can map a blue component to the alpha stage.
So, when you compute an RGB doct product into an RGB register, say spare0.rgb, you can use the blue component of that result (ie spare0.b) into the alpha stage in the next combiner stage.

[bakery2k]

Vincoof: That's exactly what we have been discussing above.

Asgard:
Thanks, that's very useful.
Now I need to make a decision.
I am not trying to produce an exact copy of the directx pixel shader functionality, so I have some flexibility.

Either I could code a solution like yours, with the possibility that a dp3 will need more than one combiner and hence some 8 instruction programs will not run.

Or, I could simply state in the language specification that dp3 instructions cannot write to an alpha channel. If the program requires the alpha to hold the results of a dp3, the mov instruction could be programmed explicitly, possibly co-issued with the next instruction. However, this reduces the number of instructions available even in the case where a simple "read from blue" would be adequate. (EDIT: Although I suppose the "read from blue" could be made explicit in the shader instead).

D3D does not do either of these. An 8 instruction program which also would require the extra move instruction works fine.
This, and the fact we have DOT3_RGBA, makes me think the hardware is capable, but the feature is not exposed in the register combiners interface.
(@nVidia: Is this correct?)


[This message has been edited by bakery2k (edited 01-29-2003).]

[vincoof]

Excuse me for insisting, but I don't see why the mapping from blue component is not enough.
For instance in your pixel shader example :

dp3 r0.rgba, t0, t1
mul r0.rgb, r0, t2
add r0.a, r0, t3

it can be done in two combiner stages :
first stage :
- rgb : map t0.rgb to A and t1.rgb to B, and output "A dot B" into r0.rgb
- alpha : discard
second stage :
- rgb : map r0.rgb to 1 and t2.rgb to B, and output "A mul B" into r0.rgb
- alpha : map r0.b to A, one to B, t3.a to C and one to D, and output "AB+CD" into r0.a

and if you want your pixel shader parser to be a line-by-line translator you'll need 3 stages :
first stage : same as above
second stage :
- rgb : same as above's rgb second stage.
- alpha : copy r0.b to r0.a
third stage :
- rgb : discard
- alpha : same as above's alpha second stage.

or maybe I'm missing something, and in that case please pardon me and I'd be glad to know