is updating uniforms quite slow?

[zed]

--not an important question--

is updating uniforms quite slow?
*this example animates a field of grass thus each 'mesh' contains only a few vertices, but theres thousands of meshes.
currently im doing the vertex deformation calculations myself

eg

for ( int i=0; i<10000; i++ )
[
..
glVertex3fv( vert0 + vertice_offset.. )
..
]now im thinking this is something a vertexshader would be ideal at so i do something like


int loc = glGetUniformLocationARB( the_shader, "friemel_origin" );
for ( int i=0; i<10000; i++ )
[
.....
glUniform3fvARB( loc, 1, origin );
....
....
glVertex3fv( vert0 )
..
]but its a lot(~3x) slower, from testing it seems to be the glUniform3fvARB(..) function that is causing the slowdown.
is updating a uniform really so slow?
ie u dont want to update them if the object contains only a few vertices (though its a different story though if an object contains thousands of vertices)

[Relic]

You're rendering 10000 grass blades and set the origin of each with a uniform? Not good.
Just put it into another vertex attribute which you send once for each set of vertices describing one blade.
I guess animating the blades can be done completely in the vertex shader and the whole geometry of all blades should be put into one single vertex array to remove the immediate mode overhead.

[zed]

"of each with a uniform? Not good."

thanks thus setting uniforms is quite slow (im starting to get to grips with glsl), ill be better to chuck the origin info in a color/normal etc.
though the other method would be even better (if all the blades were the same)

[evanGLizr]

Originally posted by zed:
"of each with a uniform? Not good."

thanks thus setting uniforms is quite slow (im starting to get to grips with glsl), ill be better to chuck the origin info in a color/normal etc.
though the other method would be even better (if all the blades were the same)You are probably using an NVIDIA card. NVIDIA cards are known to embed uniforms as immediate constants inside the fragment program (details are in their fragment program extension), so changing the value of an uniform actually means recompiling the program. Maybe they do the same for vertex programs.

There's no reason why this cannot be made fast (just patch the immediates in the hw-dependent binary and resend the program or just the modified instructions) but my guess is that they haven't bothered optimizing it yet.

[barthold]

Setting a uniform value is never going to be as fast as setting a vertex attribute. At the minimum there's bounds checking and type checking that the driver needs to do before loading a uniform. Depending on the HW and underlying software implementation more work might actually happen. If you have data that changes every few vertices, stick it in a (generic) vertex attribute instead. Every IHV heavily optimizes the vertex API.

Barthold
3Dlabs

[Korval]

Setting a uniform is a state change. It is the equivalent of turning on/off lights, blending, material properties, etc. As such, you should minimize the number of times you need to do this.