PDA

View Full Version : !!VP vs !!ARBVP



MojoMagic
02-27-2004, 08:05 PM
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?

Regards.

MojoMagic
02-27-2004, 08:17 PM
Is there perhaps a ARB_vertex_program2 spec in the pipeline?

chemdog
02-27-2004, 10:37 PM
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.

Korval
02-27-2004, 11:23 PM
Do I have to resort to NV or is there a commonly used way out that I haven't thought of?

Yes. Use Glslang.

Dodger
02-27-2004, 11:25 PM
Or one could use a texture as a lookup table (with the obvious precision problems if using only 8 bits).

MojoMagic
02-28-2004, 02:55 AM
Dang.

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. http://www.opengl.org/discussion_boards/ubb/smile.gif

Thanks for your help guys.

DJSnow
02-28-2004, 03:26 PM
>>suggestions a go while I wait for
>>ARB_vertex_program2
yes....wait for an extension which's release date is completely unknown and "in the stars".
(sorry, i couldn't resist http://www.opengl.org/discussion_boards/ubb/biggrin.gif)

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

MojoMagic
02-28-2004, 05:14 PM
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).

Cheers.

Zengar
02-29-2004, 02:09 AM
Why would you need ARBvp2 if you have glslang???
I'm using it for a while with nvidia cards and it works very well.

Christian Schüler
02-29-2004, 11:01 AM
tsk tsk tsk
transcendental functions in a pixel pipeline ...

what kind of decandence has the world gone into?

Paul Sernine
02-29-2004, 11:44 PM
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.

Paul

jeickmann
03-01-2004, 02:30 AM
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,,

Jan

Zengar
03-01-2004, 05:10 AM
Compilers will became faster and faster with time. Trust me 8:

zeckensack
03-01-2004, 05:25 AM
Sernine,
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);
shader_tail+=strlen(shader_tail);
}
else
{
append_sin_taylor(shader_tail,target,source0);
shader_tail+=strlen(shader_tail);
}

Paul Sernine
03-01-2004, 06:48 AM
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.

Paul

al_bob
03-02-2004, 08:56 PM
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!*/

MojoMagic
03-03-2004, 11:52 PM
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.

Relic
03-04-2004, 12:26 AM
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.

MojoMagic
03-04-2004, 02:02 AM
Relic:

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 http://www.opengl.org/discussion_boards/ubb/smile.gif

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!

http://www.opengl.org/discussion_boards/ubb/smile.gif

Relic
03-04-2004, 02:31 AM
"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.

MojoMagic
03-04-2004, 02:43 AM
Hmmm. That's what I thought. I was hoping someone would say otherwise. Oh well.

Guess I'll be upgrading sooner rather than later.

C'est la vie...

jra101
03-04-2004, 08:55 AM
No current hardware supports reading textures in the vertex program.

JD
03-04-2004, 09:39 AM
I also don't feel that we'll get arb2 when glslang is coming. You might as well code fp to ihv since you'll be doing the same in D3d9. Meaning that now Nv sucks in d3d9 and needs that partial precisions thingy and some other stuff that's coming in next d3d release that favors Nv hw. Look at valve and hl2.

Chuck0
03-04-2004, 10:08 AM
Originally posted by jra101:
No current hardware supports reading textures in the vertex program.
uhm isnt the super buffer extension going to enable rendering vertex data into textures and read data from textures (in an vp)?
if thats the case at least r3xx and nv3x hardware should be capable of doing so, since i guess those will be able to support the extension (as far as i know there are even betadrivers from ati floating around that do expose the superbuffer/uberbuffer extension)

Korval
03-04-2004, 10:27 AM
uhm isnt the super buffer extension going to enable rendering vertex data into textures and read data from textures (in an vp)?

The idea with Superbuffers is that you are rendering to a vertex array. You then use that as a regular vertex array. It doesn't provide for any reading from textures in a vertex program. And no current consumer hardware can do it, even though glslang and HLSL allows for the possibility.


I also don't feel that we'll get arb2 when glslang is coming.

glslang is already here. Which is one reason why we aren't getting a vp2 or fp2.