PDA

View Full Version : quick question about vp (ARB and NV)



V-man
02-14-2003, 11:34 PM
This is about ARB_vertex_program and NV_vertex_program

There is a restriction on the swizzling in ARB.
I'm talking about every register available.

In NV, I think there isn't a restriction. Is that right?

As for the mask, all possible masks can be used for the ARB and NV version. Is this correct?

Asgard
02-15-2003, 01:39 AM
I don't quite understand what you mean, but when you look at the two grammars the rule for swizzling called "swizzleSuffix" is exactly the same for both and is also used in the same context. So swizzling is identical in NV_v_p and ARB_v_p.
And for destination masks, again in the grammar the rules are identical, and yes, all possible masks can be used.

V-man
02-15-2003, 09:53 AM
I think I should have made my question clearer. I don't understand the swizzle rule

From ARB_v_p :
Vector operands can be swizzled according to the <swizzleSuffix> rule. In
its most general form, the <swizzleSuffix> rule matches the pattern
".????" where each question mark is replaced with one of "x", "y", "z", or
"w". For such patterns, the x, y, z, and w components of the operand are
taken from the vector components named by the first, second, third, and
fourth character of the pattern, respectively. For example, if the
swizzle suffix is ".yzzx" and the specified source contains {2,8,9,0}, the
swizzled operand used by the instruction is {8,9,9,2}.

From this, I understood that I can do anything I want, but this line gives and error :

MUL r5.z, r6.xyw, r7.zyx;

In NV_v_p, that same paragraph is near identical except it starts out like this :
Swizzled source register values may arbitrarily swizzle the source
register's components based on the <swizzleSuffix> rule.

Well, what are the rules exactly?

Asgard
02-15-2003, 10:01 AM
The problem with your swizzling is that the swizzle suffix has only 3 components. According to the grammar (both NV_v_p and ARB_v_p) a swizzle suffix must either have exactly 1 or exactly 4 components.

Korval
02-15-2003, 04:14 PM
MUL r5.z, r6.xyw, r7.zyx;

What would that mean, anyway? That r5.z = r6.w *r7.x? It could be more clearly expressed if you just said it that way.

V-man
02-16-2003, 11:21 AM
MUL r5.z, r6.xyw, r7.zyx;

is some garbage I typed to give an example.

This for example, is something I want to do

SUB R1, c[18].w, c[18].z;

but I get errors. I finished the program now but I have 2 instructions that are of this form. What do I do?

Also, from what I understood, there are additional matrices available so I should be able to do

glMatrixMode(GL_MATRIX0_NV);
glTranslate
glRotate

and it also looks like NV and ARB are near identical. What's the difference besides minor differences in the assembly syntax?

jra101
02-16-2003, 11:36 AM
A list of some of the differences between the NV and ARB specs can be found in the ARB spec, look for the "Interactions with NV_vertex_program" section.

For loading matrices, use GL_MATRIX0_ARB, GL_MATRIX1_ARB, etc...

Nutty
02-16-2003, 01:54 PM
This for example, is something I want to do

SUB R1, c[18].w, c[18].z;



You cant access 2 constant registers (c[?]) in the same instruction.

Besides which, if you load the contents of c[18], why dont you just pre-compute c[18].w - c[18].z and store it, instead of doing it per vertex?

constant - constant = constant. Pre-calculate and store!

This is in nv_vertex_program anyway. Not sure about arb_vp.

[This message has been edited by Nutty (edited 02-16-2003).]

Asgard
02-16-2003, 02:04 PM
You cant access 2 constant registers (c[?]) in the same instruction.

True, but in this example only the same constant register is used, which is allowed in NV_v_p.


This is in nv_vertex_program anyway. Not sure about arb_vp.

In ARB_v_p an instruction is allowed to source multiple distinct constant registers.

Nutty
02-16-2003, 02:18 PM
Given that its a constant, you should pre-calculate it and access it, rather than doing it per vertex tho..

V-man
02-16-2003, 09:12 PM
Also the SUB instruction is not available on NV.
I don't care about optimizing for now. I'm trying to find out about the little details.

There is no way to get information on errors on NV?
In ARB, you can do glGetString(GL_PROGRAM_ERROR_ARB);

pbrown
02-19-2003, 08:01 PM
Originally posted by V-man:
Also the SUB instruction is not available on NV.
I don't care about optimizing for now. I'm trying to find out about the little details.

There is no way to get information on errors on NV?
In ARB, you can do glGetString(GL_PROGRAM_ERROR_ARB);

V-man,

FYI -- I believe NV_vertex_program1_1 adds a "SUB" instruction. All NVIDIA devices that support NV_vertex_program support NV_vertex_program1_1. But you do have to have a "!VP1.1" header (or better) for "SUB" to work.

Current NVIDIA drivers don't support queries of GL_PROGRAM_ERROR_STRING_ARB for NV_v_p programs (I added the functionality in NV_fragment_program and carried it over to ARB_vertex_program.) This may change in the future, but that doesn't help you for now.

I don't see anything obviously wrong with

SUB R1, c[18].w, c[18].z;

or

ADD R1, c[18].w, -c[18].z;

I'm assuming the program loads if you take out/comment out such instructions? That's a good debugging tool, as is querying the ERROR_POSITION (which is supported for both ARB and NV programs). The error string is also helpful.

NV_v_p does disallow the use of multiple constants in an instruction, but does allow multiple uses of the same constant.

If you're stuck, send me an email with your program text and I'd be happy to scan it to figure out why it's not working.

Other basic rules that apply to ARB and NV programs:

As far as swizzles go, you always specify four components. ".x" is shorthand for ".xxxx" and a blank swizzle is shorthand for ".xyzw".

Note that writemasks have to enumerate components in order -- R1.xyz is valid; R1.zyx is not.

Hope this helps,
Pat

sanjo
02-20-2003, 12:49 AM
Originally posted by pbrown:

If you're stuck, send me an email with your program text and I'd be happy to scan it to figure out why it's not working.



radeon or not. nvidia's dev support is unbeatable. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Humus
02-20-2003, 03:58 PM
LOL, you concluded that from what exactly?

dorbie
02-20-2003, 04:10 PM
You can't go around saying that now that you work for ATI Humus.

:-)

V-man
02-21-2003, 11:41 AM
I think I got the swizzling and masking part down now. The program works, and I think I got a special use for it.

Never mind what I said about using glGetString. It's easy to make a app that puts the cursor at the error position. Of course, if glGetIntegerv(GL_PROGRAM_ERROR_POSITION_NV, &errorposition);
returned [line number, column number], the app wouldn't be needed, but nevermind http://www.opengl.org/discussion_boards/ubb/smile.gif

The fun starts at VP2.

Ysaneya
02-21-2003, 12:06 PM
You can't go around saying that now that you work for ATI Humus.


Yeah, i have to agree. Now, instead of sending my bug reports to Jeff from ATI's developer relations, i'll redirect all my junk to Humus.

That's what you get for working with the devil.

*Cheers* :)

Y.

vincoof
02-21-2003, 01:36 PM
Humus: not that I agree with the fact that support is better in either ATI or NVIDIA in general, but we can not deny the fact that the current thread got two replies from NVIDIA and none from ATi.

Reply faster next time http://www.opengl.org/discussion_boards/ubb/wink.gif

Humus
02-21-2003, 01:48 PM
Well, but then this is a NV_vp vs. ARB_vp, so it's by it's pure nature more aimed towards NV guys. If there would be a say ATI_VAO vs. ARB_VBO thread I'm certain we would see more ATi replies than NV.

Anyway, I just thought the conclusion that you can't beat NV's devrel can't be made from what he quoted alone. http://www.opengl.org/discussion_boards/ubb/smile.gif

vincoof
02-21-2003, 02:04 PM
LOL I just checked the title again and now understand why so many NVIDIA guys replied, compared to ATi. Anyway *you* replied, so that is one point for ATi. More than enough for a NVIDIA thread ! http://www.opengl.org/discussion_boards/ubb/smile.gif