!!VP vs !!ARBVP

Hi all,

As far as I can tell from the specs, of the following vertex program standards (ARB_vertex_program, NV_vertex_program, NV_vertex_program1_1, NV_vertex_program2), only NV_vertex_program2 supports SIN/COS functions.

These are extremely important commands. I find it hard to believe that people put up with not having them in the ARB spec.

Do I have to resort to NV or is there a commonly used way out that I haven’t thought of?


Is there perhaps a ARB_vertex_program2 spec in the pipeline?

Sine and Cosine can be approximated using LIT and ADD instructions. You can generate the terms of the taylor series using 3 instructions per term. One can also get the other value in few instructions, using known trignometric transforms.

Otherwise, you’ll have to wait.

Do I have to resort to NV or is there a commonly used way out that I haven’t thought of?

Yes. Use Glslang.

Or one could use a texture as a lookup table (with the obvious precision problems if using only 8 bits).


Oh well. I guess it’s good to finally have some confirmations.
I’ll give your suggestions a go while I wait for ARB_vertex_program2.

Thanks for your help guys.

>>suggestions a go while I wait for
yes…wait for an extension which’s release date is completely unknown and “in the stars”.
(sorry, i couldn’t resist )

[This message has been edited by DJSnow (edited 02-28-2004).]

Just curious…

What Is the status of this extension?
Has there been ANY talk about it at the ARB?
Is it mentioned in the ARB meeting notes? (sorry, I’d check it myself but I have to run to an appointment).


Why would you need ARBvp2 if you have glslang???
I’m using it for a while with nvidia cards and it works very well.

tsk tsk tsk
transcendental functions in a pixel pipeline …

what kind of decandence has the world gone into?

ARB vp2 are desirable over GLSLang when you
have to compile your programs on the fly.
Some people have to do that.
For instance, in my engine, source code strings are dynamically concatenated and programs are compiled, depending on a kind of graphical state (number of light sources, type for each light sources, precision for each light source,multitexturation, gloss maps…).
The number of possible programs is very high and prevents the precomilation of a complete set.

ARB vp is close enough to the hardware assembly code to offer hi speed compilation
(less than 20ms).
GLSlang (or Cg) compilation is very slow.

As far as I read, there is nothing in the ARB meeting notes concerning an ARB vp2.
And I do not want to use specifics from NVidia or ATi (they provide “options” to extend ARB vp with their specific instruction sets).

So I will have to go DirectX.


As far as I can see, you are combining code snippets depending on some states. Can’t you use glslang functions and have them precompiled, so you only have to compile a small shader that uses them and link it?
Or is this slow as well?

Just wondering,


Compilers will became faster and faster with time. Trust me 8:

if it’s really about sin/cos, why not just do an explicit Taylor series expansion if NV_vertex_program isn’t supported, and a proper SIN opcode when it is?

DX Graphics does just the same thing. Well, it’s supposed to anyway. I seem to recall a bug that prevented a SIN macro from becoming a SIN opcode, even on hardware where that would be possible. Ie, you’d always get an explicit Taylor, even on NV3x.
I can’t understand why that could be a reason to make an API switch.

if (gl_caps.nv_vertex_program)
sprintf(shader_tail,“SIN %s,%s;”,target,source0);

To be more accurate, it is not about sin/cos.

I am especially interested in reading textures from a vertex program.

This is possible with GLSLang, with DX HLSL and will be possible with DX vp3.0.


Or one could use a texture as a lookup table (with the obvious precision problems if using only 8 bits).

You can’t do accelerated texture lookups from vertex programs (yet).

I find it hard to believe that people put up with not having them in the ARB spec.

Sad, but true. Here’s a code snipet to compute SIN with reasonable precision in a vertex program:

PARAM one_over_pi = 0.1591549;
PARAM pi = 3.1415926;
PARAM two_pi = 6.2831853;
PARAM inv_3_fact = 0.1666666;
PARAM inv_5_fact = 0.00833333333;
PARAM inv_7_fact = 0.00019841269841269;

/* Convert to [-pi…+pi] period */
MAD res.x, x, one_over_pi, 0.5;
FRC res.x, res;
MAD res.x, res, two_pi, -pi;

/* Scale input to compensate for prec error */
MUL res.x, res, 0.98;

/* Compute SIN(res.x), using a Taylor series /
MUL temp.x, res.x, res.x; /
x^2 /
MUL temp.y, temp.x, res.x; /
x^3 /
MUL temp.z, temp.y, temp.x; /
x^5 /
MUL temp.w, temp.z, temp.x; /
x^7 /
MAD res.x, temp.y, -inv_3_fact, res.x; /
x - x^3/3! /
MAD res.x, temp.z, inv_5_fact, res.x; /
x - x^3/3! + x^5/5! /
MAD res.x, temp.w, -inv_7_fact, res.x; /
x - x^3/3! + x^5/5! - x^7/7!*/

Hi guys!

Thanks for all the help. It’s been really great. I’ve learnt stacks!

… I’m currently interested in loading values from a texture during vertex (not fragment) processing.
I can’t find any reference to this in any ARB or NV spec. Am I right in thinking I’ll have to wait for ARB_vertex_program2 or GlSlang to become available on NVidia Hardware?

BTW. Will GlSlang be available for GF4 level hardware or only GF-FX+?

Thanks again.

First, it’s not the language which defines what works. You need to wait on hardware which can do texture accesses on vertex level.
GF4 Ti has no fragment programs, it can only use the vertex programs in hardware.
On GF4 MX not even that.
Time to upgrade.


I’m aware that what I can achieve is limited more by the hardware than just the drivers… (I’ve been around longer than that).

I am also aware of the difference between the differing generations of cards. And yes. The term GF4MX is a bit of a misnomer

I have a GF4Ti. It doesn’t, and never will, support fragment_shaders.
However it is my understanding that some cards/APIs/extensions/whatever support reading texture data from within a VERTEX program (or equivalent process).

For example, the GlSlang spec specifically states that texture lookups may be performed from within a vertex-shader. The only limitation is that MipMaps may not be used. I think this is due to the fact that LOD is calculated on triangulation (ie: between vert and frag steps).

I was initially wondering a) How (if at all) others deal with this limitation and b) WHat hardware level GlSlang is aimed at.

Will it work on a GF4Ti (albeit only the vertex processing part) and hence give me access to my beloved texture lookups? Or Will it be a GFFX+ standard (This is more likely). If this is so I guess I’ll have to invest in a new card… I’m a gadget junky so this’ll happen eventually anyway.

Sorry if some of my questions seem a bit naive at first. I sometimes ask a question even though I might have a hunch about what the answer is just incase someone answers in a way I didn’t expect.
This thread is a prime example of that. I had no idea how to calculate a Taylor series to approximate SIN/COS before 2 days ago!

“Will it work on a GF4Ti (albeit only the vertex processing part).”

I suppose so.

“and hence give me access to my beloved texture lookups?”

No, why should it? I’d expect such a shader to simply fail compilation.
That is what I meant with NOT the language specifies what is possible.