PDA

View Full Version : ARB_vertex_program: where did they get all the extra constants?



JelloFish
10-15-2002, 05:13 PM
Hi I know under the previous vertex program specifications there were limitations on constants and if you wanted a matrix in the program it was a constant, if you wanted {0.0f,0.5f,1.0f,2.0f} in your program it was a constant, ect. But now it seems like there are many types of contants and according to the spec each one has a minimum of 96 count. Where are all the GF3's and 8500's getting these extra constants from? Software emulation or is this yet untapped hardware potential?

Asgard
10-16-2002, 01:56 AM
Matt pointed out in another thread that they're doing software emulation if your program uses too many constants.

JelloFish
10-16-2002, 06:50 AM
Thats pretty unfortunate that you would have to guess when some hardware would go into emulation mode. Oh well I suppose the spec is already approved.

Asgard
10-16-2002, 06:54 AM
You can query for various NATIVE values, such as PROGRAM_UNDER_NATIVE_LIMITS_ARB, to determine if a program fits within native hardware limits. For more info see the spec.

JelloFish
10-16-2002, 08:28 AM
If a program uses ARL can the proxy mechanism determine if it uses the amount of constants available?

JelloFish
10-16-2002, 08:58 AM
Is there a typo in the arb_vertex_program specification where it says that VertexAttrib's index takes in "The first entry of this array is numbered
zero, and the number of entries in the array is given by the
implementation-dependent constant MAX_VERTEX_ATTRIBS_ARB", but then shortly after it say VertexAttribPointerARB's index takes in "The client may specify up to 5 plus the values of
MAX_TEXTURE_UNITS and MAX_VERTEX_ATTRIBS_ARB arrays"? Would this mean that the immediate mode command is not aliased to the old gl commands, and the vertex array command is aliased?

Asgard
10-16-2002, 09:39 AM
Originally posted by JelloFish:
If a program uses ARL can the proxy mechanism determine if it uses the amount of constants available?

Yes, because you have to declare arrays addressed with ARL before you use them. And there you have to list all the resources you use. You can no longer just index any parameter register, but only a range declared by the PARAM statement.

Asgard
10-16-2002, 09:48 AM
Originally posted by JelloFish:
Would this mean that the immediate mode command is not aliased to the old gl commands, and the vertex array command is aliased?

As far as I understand this, it is implementation-dependent whether or not conventional attribute arrays are aliased to generic attribute arrays. In the ARB_v_p spec somewhere it says that e.g. NVIDIA's implementation aliases attributes.

One thing is certain: You can't use aliased attributes in a vertex program (see table X.2.1 in the spec). So you can't use vertex.normal and vertex.attrib[2] in the a vertex program. However, I don't know what happens if, say, your OpenGL program loads normals into generic vertex attrib 2 and then tries to access it using vertex.normal in the vertex program. Well, actually I know that with NVIDIA drivers this works as I've tried it, but I don't know if it would work on a different implementation.

I'd also like to have some clarification on attribute aliasing in the spec. It's a bit unclear to me. Pat?

JelloFish
10-16-2002, 09:52 AM
Along the sames lines as the previous post. If you can have 16 program attribs that can only be pointed at vertex.information type things shouldnt there be a minimum MAX_VERTEX_ATTRIBS_ARB so that 5 + max textures + max attribs equals at least 16. Right now my GF3 drivers are telling me MAX_VERTEX_ATTRIBS_ARB is 0 which doesnt seem to make much sense.

[This message has been edited by JelloFish (edited 10-19-2002).]

mcraighead
10-16-2002, 11:45 PM
The ARB couldn't agree on aliasing, so it's undefined.

I happen to think that aliasing is a clearly superior behavior, but it wasn't my decision...

- Matt

Asgard
10-17-2002, 01:45 AM
Damn, I thought so reading the spec but wasn't quite sure. Aliasing would have been better IMHO. Also would have made the transition from older code to ARB_v_p easier.
I think the spec should have some clearer explanation of all the aliasing issues. I read the paragraphs about aliasing a couple of times but didn't understand them. Maybe it's just because English isn't my first language...or I was used to NV_v_p too much and didn't want to understand as it means changing a lot of my code ;-)

JelloFish
10-17-2002, 07:15 AM
As much as aliasing isn't supported does the immediate mode command take in a different index than the vertex stream command. Or is both of their maximum values 5 + maxtextures + maxgenericattribs. The way the spec is written it sounds like VertexAttrib can only write data to the genericattribs.

PH
10-17-2002, 02:41 PM
My 8500 reports the following,

GL_MAX_PROGRAM_LOCAL_PARAMETERS_ARB : 65535
GL_MAX_PROGRAM_ENV_PARAMETERS_ARB : 65535
GL_MAX_PROGRAM_INSTRUCTIONS_ARB : 65535
GL_MAX_PROGRAM_TEMPORARIES_ARB : 65535
GL_MAX_PROGRAM_PARAMETERS_ARB : 65535
GL_MAX_PROGRAM_ATTRIBS_ARB : 32
GL_MAX_PROGRAM_ADDRESS_REGISTERS_ARB : 1
GL_MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB : 65535
GL_MAX_PROGRAM_NATIVE_TEMPORARIES_ARB : 65535
GL_MAX_PROGRAM_NATIVE_PARAMETERS_ARB : 65535
GL_MAX_PROGRAM_NATIVE_ATTRIBS_ARB : 32
GL_MAX_PROGRAM_NATIVE_ADDRESS_REGISTERS_ARB : 1

I'm wondering why those natives are that high. Does this make sense or could that be a bug ? I expected 96 ( IIRC ) max native constants, etc.

Asgard
10-17-2002, 04:53 PM
As far as I can tell, it's not really specified precisely what the native values mean in the ARB_v_p spec. So it's valid for an implementation to return higher native sizes than the hardware actually offers.

JelloFish
10-18-2002, 08:35 AM
Wow those number are high. Well the 8500 is supposed to be slightly more programmable than the GF3, I had no idea that much tho. Those numbers seem higher than the DX9 spec even.

PH
10-18-2002, 08:49 AM
Yes, the 8500 is more programmable but not *that* much. This is what EXT_vertex_shader reports,

GL_MAX_VERTEX_SHADER_INSTRUCTIONS_EXT : 65535
GL_MAX_VERTEX_SHADER_VARIANTS_EXT : 32
GL_MAX_VERTEX_SHADER_INVARIANTS_EXT : 65535
GL_MAX_VERTEX_SHADER_LOCAL_CONSTANTS_EXT : 65535
GL_MAX_VERTEX_SHADER_LOCALS_EXT : 65535
GL_MAX_OPTIMIZED_VERTEX_SHADER_INSTRUCTIONS_EXT : 128
GL_MAX_OPTIMIZED_VERTEX_SHADER_VARIANTS_EXT : 11
GL_MAX_OPTIMIZED_VERTEX_SHADER_INVARIANTS_EXT : 192
GL_MAX_OPTIMIZED_VERTEX_SHADER_LOCAL_CONSTANTS_EXT : 192
GL_MAX_OPTIMIZED_VERTEX_SHADER_LOCALS_EXT : 12

JelloFish
10-18-2002, 10:59 AM
Man it would be nice if the GF would support that many emulated constants.

JelloFish
10-18-2002, 01:55 PM
Does anybody know if there is any good reason to support the old vprog extensions?

pbrown
10-19-2002, 05:51 AM
Originally posted by JelloFish:
Is there a typo in the arb_vertex_program specification where it says that VertexAttrib's index takes in "The first entry of this array is numbered
zero, and the number of entries in the array is given by the
implementation-dependent constant MAX_VERTEX_ATTRIBS_ARB", but then shortly after it say VertexAttribPointerARB's index takes in "The client may specify up to 5 plus the values of
MAX_TEXTURE_UNITS and MAX_VERTEX_ATTRIBS_ARB arrays"? Would this mean that the immediate mode command is not aliased to the old gl commands, and the vertex array command is aliased?

Depending on the implementation, the immediate-mode VertexAttrib commands may alias with conventional GL commands.

For vertex arrays, the VertexAttrib and conventional arrays have separate state and enables. But rendering that uses vertex arrays is effectively defined in terms of ArrayElement, which is defined in terms of immediate mode calls. So for example, if you enable both the color array and generic vertex attribute 3 array, there is no guarantee that the color and attribute 3 state set via these arrays does not alias.

So on NVIDIA's aliasing implementation, the vertex attribute 3 array effectively has priority over the color array.

This is the same behavior as in NV_vertex_program, except that (1) aliasing is not required and (2) the generic attribute arrays are not disabled when VERTEX_PROGRAM is disabled.

On item (2), NV_vertex_program has problems involving display lists -- what happens if you compile vertex arrays into a list with VERTEX_PROGRAM disabled? (According to NV_vertex_program, the vertex attribute arrays are disabled, even though you might want to use the list with VERTEX_PROGRAM enabled.)

pbrown
10-19-2002, 05:54 AM
Originally posted by Asgard:
As far as I understand this, it is implementation-dependent whether or not conventional attribute arrays are aliased to generic attribute arrays. In the ARB_v_p spec somewhere it says that e.g. NVIDIA's implementation aliases attributes.

One thing is certain: You can't use aliased attributes in a vertex program (see table X.2.1 in the spec). So you can't use vertex.normal and vertex.attrib[2] in the a vertex program. However, I don't know what happens if, say, your OpenGL program loads normals into generic vertex attrib 2 and then tries to access it using vertex.normal in the vertex program. Well, actually I know that with NVIDIA drivers this works as I've tried it, but I don't know if it would work on a different implementation.

I'd also like to have some clarification on attribute aliasing in the spec. It's a bit unclear to me. Pat?

You can't rely on attribute aliasing across the board. Generic attribute 2 will effectively set a normal on NVIDIA Windows drivers. It will not (I think) on ATI. Or on Apple implementations, including those with NVIDIA hardware.

pbrown
10-19-2002, 05:55 AM
Right now my GF3 drivers are telling me MAX_VERTEX_ATTRIBS_ARB which doesnt seem to make much sense.[/B]

This query was busted in some of our drivers, including possibly the most recent on our web site. The correct answer to that query is 16 for all current NVIDIA devices.

Asgard
10-19-2002, 07:14 AM
Thanks for the clarifications, Pat. Cheers.

JelloFish
10-19-2002, 08:17 PM
I can't seem to get arrays of attribs going (ATTRIB pos[4] = {vertex.attrib[0..3]}; ) is there any way to do this? As well as arrays of temps, (TEMP sums[4]). Neither of these seem to compile for me is it just an unsupported feature? It seems like a usefull feature to allow.

JelloFish
10-19-2002, 08:20 PM
Oh and thanks for the help, ive been kinda assuming that everything worked the way I imagined, your comments solidify that.

JelloFish
10-19-2002, 08:26 PM
Hi again, is there anything that can cause undefined Temp's, ive got exactly 12 of them and the vp is refusing to compile.(The max temporaries is 12)

bashbaug
10-19-2002, 11:05 PM
I can't seem to get arrays of attribs going (ATTRIB pos[4] = {vertex.attrib[0..3]}; ) is there any way to do this? As well as arrays of temps, (TEMP sums[4]). Neither of these seem to compile for me is it just an unsupported feature? It seems like a usefull feature to allow.

You can only have arrays of PARAMs, not ATTRIBs, TEMPs, or OUTPUTs. This is mostly to allow relative addressing and binding to multi-value things like matrices. Out of curiosity, what are you doing where it would be useful to have arrays of attribs or temps?


Hi again, is there anything that can cause undefined Temp's, ive got exactly 12 of them and the vp is refusing to compile.(The max temporaries is 12)

There are things that can cause implicit (I assume that's what you mean by undefined) temps. However, as long as you stay under MAX_PROGRAM_TEMPORARIES, your program should compile and execute, though potentially at lower performance. Have you checked the error string / error position to make sure there's nothing else wrong?

-- Ben

LaBasX2
10-20-2002, 02:09 AM
Originally posted by PH:
My 8500 reports the following,

GL_MAX_PROGRAM_LOCAL_PARAMETERS_ARB : 65535
GL_MAX_PROGRAM_ENV_PARAMETERS_ARB : 65535
GL_MAX_PROGRAM_INSTRUCTIONS_ARB : 65535
GL_MAX_PROGRAM_TEMPORARIES_ARB : 65535
GL_MAX_PROGRAM_PARAMETERS_ARB : 65535
GL_MAX_PROGRAM_ATTRIBS_ARB : 32
GL_MAX_PROGRAM_ADDRESS_REGISTERS_ARB : 1
GL_MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB : 65535
GL_MAX_PROGRAM_NATIVE_TEMPORARIES_ARB : 65535
GL_MAX_PROGRAM_NATIVE_PARAMETERS_ARB : 65535
GL_MAX_PROGRAM_NATIVE_ATTRIBS_ARB : 32
GL_MAX_PROGRAM_NATIVE_ADDRESS_REGISTERS_ARB : 1


Is the Radeon8500 already supporting arb_vertex_program? I have the latest drivers but I can't find that extension on my Radeon9000 (version 6166)...

Thanks
LaBasX2

PH
10-20-2002, 04:45 AM
ATI released some drivers to fix a problem with a game ( don't remember which ).
http://www.rage3d.com/

To the right of the page there are links to the files ( 6193 ). Those are the best drivers to date.

You will also find an important extension, ATI_vertex_attrib_array_object, so you can use ARB_vp with VAO. ATI wasn't ready to release the spec ( I did ask and they said they hoped to have it released later this month ), but you should be able to figure it out by looking at the VAO + ARB_vp specs.

The 6193 drivers have the ARB_vp extension.

[This message has been edited by PH (edited 10-20-2002).]

LaBasX2
10-21-2002, 03:13 AM
Thanks PH!

Unfortunately they are only working for the 8500 and not for the 9000 at the moment, but this will hopefully soon be fixed as the 8500 and the 9000 are pretty similar. SO I will have to wait for the next unified driver release.

LaBasX2

JelloFish
10-22-2002, 09:03 AM
The arrays of attribs are for all the vertex/normal streams in a skeletal animation vp. Eventually if branching was supported relative addressing would be usefull, but for now it would have just been a easier way to specify attribs/temps. Even now it would be nice to have some sort of looping macro for constant loop amounts.

As for the number of temps yes the program compiles as long as i dont use >= 12 temporaries. MAX_PROGRAM_TEMPORARIES is 12. How do I determine when an implicit temp is used?