please clarify oh mighty experts on memory and performance

Performance Tuning
#1

I was working on a refactored version of a 3d engine of mine and for some odd reason performance seemed to be suffering when I would render a few objects with high poly counts. The previous version performed well in this respect, so I found it odd.

I boiled it down to my old engine had a model importer so when I had high poly counts I would have lots of indice, lots of vertices, and lots of normals. In my new version I only simulated high poly counts by duplicating the indices over and over again while the vertices and normals would remain at around 6-20. When I finally got a model loader for my new engine and loaded identical models, the new one performed better (oh joy!).

Anyway, I was wondering exactly why having a duplicate indices that would redraw the exact same vertices would have much lower performance than the equivalent number of indices with a more standard set of accompanying vertices.

Thanks,

#2

Just have a look on some resources manager written for Java, this will certainly resolve your problem! With large number of objects Java needs as in C languages to respond quickly to virtual memory de/allocations a.k.a Heap Memory Space in Java.
Roughly meant, you will be asked to build a dynamic Map of your Objects that will clear unused Objects at a regular rate. I use an extended WeakHashMap for my own that always keep the current used Objects alive, while the others are cleared off the Virtual Memory Space, as well as the Objects are loaded from their known Source as needed. Moreover I’ve managed to get the Objects Serializable as far as they can be declared so. Thus those Serializable are stored onto HDD by the manager as they’re added to the Map. This allows me to get all the needed loaded in time and ready to be used thereafter.
::slight_smile:
There's a SoftCache written by some Kodak dev's at Koders.com! :smiley:

#3

These were direct buffers resident on the graphics card, the java heap probably wasn’t the cause of any slow down. The frame rates were incredibly stable for a given scene and the entire mesh data totaled about 200 - 600 kb.

#4

You dont actually know if they were resident on the gfx or not. The driver might tell you that it is, but it might be in RAM and is being shunted back and forth…

Also, there is a limit on the number of indices that is optimal for graphics card. GL_MAX_ELEMENTS_INDICES available in OpenGL1.2 shows that value. I think its 1024 for NVidia’s 6 and 7 series…

DP :slight_smile:

#5

That’s true but it was a 128 mb card and I wasn’t using any textures so I’m pretty sure there would be room on it, but I didn’t know about the max optimal element indices. However the meshes that performed well were roughly the same size as the meshes that were performing badly. My thought was that for the slow ones, constantly looping through the exact same 6 indices might thrash the memory and slow things down.

#6

It’s so simple… massive overdraw!

If you have z-culling on, your ‘true geometry’ will get culled all over the place, yet when drawing the same triangle over and over again, all pixels have to be drawn (when using GL_LEQUAL which is probably the one you chose).

#7

Very true, initially I had thought of something similar but disabled the depth test with make “fake geometry” and saw no performance difference so I dismissed that as an option. But you probably got it right.

#8

Even then… in screenspace, most triangles of the true geometry usually take very little space, while fake-geometry triangles always take the same (large?) chunk of screenspace.

Further… rendering a zillion triangles at the same index (all vertices at 0,0,0 for example) performance totally drops to nothing. If has no pixels to render, but apparantly the hardware chokes on it. (ATi)