You can probably trick it with a vertex shader, loading up N matrix in the constants, and just issuing one call which will select which matrix to use, and transform the vertices accordingly.
glLoadMatrix is generally not too costly, how many calls per frame are we talking about here ?
I would recommend against trying to put N modelview matrices into a vertex program, and then sending more per-vertex data to select one. You’d have to re-base your index lists for this to work – even assuming everything renders with the same material/shader/texture.
It’s common to call LoadMatrix once per mesh instance in most scene graphs. Typically, the cost of this is much less than the cost of setting up textures, blending, lighting etc per mesh instance anyway (where one mesh conceptually consists of one or more calls to DrawElements).
Note: it’s cheaper to draw 10 1000 triangle meshes than to draw 100 100 triangle meshes. That’ll probably never change :-/
Isn’t it more likely that the person will be using glMultMatrix?
If you use glLoadMatrix, that means all your objects are root, but if you have a system of parents and children, then I think glMultMatrix is a nice way to do this.
For me, matrix calls is not what brings down the performance so I dont worry.
Yeah i’d definately agree with you jwatte, generally it’s not worth using that trick. However, think about a case where you have a very big amount of objects made of very few triangles (say, cubes, so 12 triangles each)… then the vertex shader trick might improve your performance a bit.
V-Man: the problem with glMultMatrix is that generally, you have to use a push and pop to save the matrix stack. So it’s actually one glLoadMatrix (basically a copy) compared to three calls (i’m guessing 2 copies with one heavy matrix multiplication).
The scene graph compiles the graph into a linear bunch of geometry sorted after state and geometry. The traversal stage generates the hierarchical mults into a loadable matrix for each geom.
Would I benefit from putting the matrixes into a nvAllocMem area ? Any driver developer who can comment this ?
Would it be feasible for future OpenGL apps to have Matrix array extension ? I am rendering “compiled” sets of trees, 100-500 different types with 100 various combinations of branch sets times number of trees
I can see that initially I gain from multplying the shared geom with the matrix , but when the number of transformed geosets increses , the VAO and VAR gets into trouble. Hard to find a general equilibrium.
Originally posted by ToolTech: Would I benefit from putting the matrixes into a nvAllocMem area ? Any driver developer who can comment this ?
…
I can see that initially I gain from multplying the shared geom with the matrix , but when the number of transformed geosets increses , the VAO and VAR gets into trouble. Hard to find a general equilibrium.
I cant answer your question, but what do you mean by multiplying the shared geom with the matrix? Software or using still using GL?
My understanding is that VAR and VAO are pretty much the best in terms of performance as long you respect the cards limits.
I think 1 or 2 people have said that using immediate mode was actually faster for them instead of VAO. They probably did something wrong.
I have the geometry G1,G2,G3… etc but for each geometry i render M1G1,M2G1,M3G1 etc.
I could of course eliminate the matrixes M1…Mx by create geometries G11=M1G1 G21=M2G1 but that would lead to too much memory allocations and slower performance in ABO etc.
I think I can see that the gzLoadMatrix is not the performance staller. I think it is related to previous vertex array transfers. Am I right to assume that a glLoadMatrix will wait for a previous call to glDrawBuffers to finish ??
Am I right to assume that a glLoadMatrix will wait for a previous call to glDrawBuffers to finish ??
I don’t think so. Unless you call glFinish, or read back some result from the video card (through a glGetXXX function), i wouldn’t expect anything to block. Your glDrawBuffer, then glLoadMatrix calls should be queued up in OpenGL’s rendering command queue and return immediately. At least i don’t see any reason for them to wait.
Well, it doesn’t sound like it would help anymore, but the basic solution to the original problem be to encapsulate calls to LoadMatrix (or whatever state changes necessary) in a display list. It’s a problem if you these get updated frequently.
Sorry ! Wrong again. When I loop 10 times over the loadMatrix I get an increased load in the loadMatrix. Not10 times but at least 3 times more load there compared to the geometry.
It looks like I shall try to use display lists for the matrix anyway. Would that be faster ??
My question about storing the matrix in nvAllocMem memory. Would that be faster ??
I’ve encountered similar results to you, tooltech. glLoadMatrix has become a bottleneck for me too. VTune reports it as a hotspot.
You’ve just gotta sigh and accept that the hit is the lesser of a massive list of evils (texture upload, state changes etc.), I suppose.
Of couse, I occasionally get arrangments in the render list where several meshes under the same transform node just happen to have the same material, and so I check the current matrix pointer against the meshes matrix pointer to save myself a glLoadMatrix call - quite a rare occurance, as you can imagine.
You’ve got to accept that most uses of your scenegraph are going to be moving relatively few geometries around the place, so you should make use of a low priority worker thread that constantly traverses your scenegraph looking for transforms that haven’t changed in X number of frames, and then manually transform all the (non-instanced) mesh vertices under that transform into world space - but then when that transform changes, you’ll have to do an inverse transform on the verts to get them back into local space
[This message has been edited by kieranatwork (edited 03-20-2003).]
What I am doing is to make a scene graph compiler as part of my system. It detects and simplifies the graph when there is no change and optimizes it into just some shared geometry uploads and a whole bunch of glLoadMatrix…
You’ve got to accept that most uses of your scenegraph are going to be moving relatively few geometries around the place, so you should make use of a low priority worker thread that constantly traverses your scenegraph looking for transforms that haven’t changed in X number of frames, and then manually transform all the (non-instanced) mesh vertices under that transform into world space
That would require blowing up all meshes into unique vertex buffers. You’d run out of memory very quickly that way if you have, say, 50 tree models, each instanced 200 times. (You should check out ToolTechs companys demo, btw; it’s quite decent)
Also, I wouldn’t want to traverse the graph in any kind of background manner. If you’re not drawing something, you don’t need to worry about it. Thus, if there’s something you need to do after N frames of rendering equality, I’d probably do that inside by Render function; possibly with logic to re-set the counter if something renders after not having been rendered for a few frames. All of this state can be kept local to each renderable instance, and just requires that the current frame number is passed in as an argument to ::render().
Efficiency Rule #1: only touch data that you need to touch.
Huh? I said “non-instanced” geometry, not all geometry. Obviously I wasn’t talking about instanced geometry (I even stated it), otherwise instancing would be pointless.
Only touch data that you need to touch?
A low priority thread should be scheduled by the OS not to interfere with CPU caching, otherwise what’s the point in having a multi-thread, multi-process operating system? Do you somehow freeze Windows Explorer when your program runs so it doesn’t mess up your CPU cache?
It won’t interfere with your core loops.
Or have I misunderstood something about the way the scheduler works?
I am able to “compile” the scene graph into a sorted bunch of data (states,matrixes and geometry)
In my scenario I now have about 10-50 shared geometries per state and about 50-100 000 matrixes per geometry.
The idea is to build a lot of varying trees etc with the same shared geometries.
I can now see that it is alot more efficient to keep them shared and not premultiply the matrixes. It doesn’t take long before the load to upload various premuliplied geometries gets heavier than uploading matrixes…
What I need is a faster way to upload matrixes. What happens on the CPU when a glLoadMatrix is performed ?
Is there any possibility to use VBO buffer for e.g. matrix data to a VP ?
Is there any extension that allows you to specify an array buffer of modelview matrixes ? like vertex arrays.
I don’t think there’s any way to use video or AGP memory to store matrices with VAO/VBO. I’d expect the same for VAR, but it depends on what the driver is doing with the matrix. It’s possible that it copies it to a system-memory matrix stack (in case you want to glGet it), then sends it to the video card. In that case, using VAR to store the matrix would require the driver to do a video readback which is extremely slow. I think your best bet is to decrease by an order your number of matrix uploads…
Agree. I have been able to make an optimizing utility that measures the load and finds the point when an optimal set of premultiplied geometries can be transferred where the sum of times for glLoadMatrix + the sum of VAR times are minimal.
However I would like an extension where I could upload an array of matrixes instead. This would be very effecient ! Matt ?? Cass ?? Evan ?
