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?
Matt pointed out in another thread that they’re doing software emulation if your program uses too many constants.
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.
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.
If a program uses ARL can the proxy mechanism determine if it uses the amount of constants available?
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?
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.
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?
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).]
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
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 
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.
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.
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.
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.
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
Man it would be nice if the GF would support that many emulated constants.
Does anybody know if there is any good reason to support the old vprog extensions?
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.)
Originally posted by Asgard:
[b] 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?[/b]
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.