40k OpenGL app taking up 112MB of RAM what the smeg is going on?

OK heres a strange one,

I’ve got a simple wee application thats generating a display list out of some vertex data that is being randomally calculated when the app starts up. According to my calculations my geometry data (being stored in arrays) should take up about 3.5 meg max, I’m not using anything more complex than glvertex3f and glcolor3f:
glBegin(GL_TRIANGLES)
loop
glcolor3f()
glvertex3f()
etc…
endloop
glEnd
in my one display list. Yet my application is managing to go from 40Kb (stored on harddisc) to 120000Kb in RAM (According to task manger in Win2k) Does anyone have any idea what the smeg is going on? I can’t see any way for this to be happening unless its something to do with the displaylist, not surprisingly its only running at about 6 FPS on a P3-800 with 256MB RAM & a Gefore256 DDR. The display list is drawing about 250’000 polygons a frame and backface culling is enabled, but my understanding is that a Geforce256 DDR can kick about 10 million polys about per frame so surely 250’000 should not be too much of a problem… I am using a windows shell for OpenGL but surely even windows is not capable of generating that much extra rubbish, it must be something I’m doing (I think) anyone got any ideas?

Cheers,

Daniel

OpenGL tends to be a huge memory hog, but yes, that does sound a bit high.

Delete one thing at a time and see how much each thing is taking?

  • Matt

I suppose Matt would have mentioned it but are you compiling your list using GL_COMPILE_AND_EXECUTE or only GL_COMPILE ?
If you are using the former, switch to the latter (followed by a glCallList).
It seems that somehow, using GL_COMPILE_AND_EXECUTE with nVidia drivers is not a good idea (can’t say for the others…).

Have you tried to switch to MS GDI Generic implementation ? OK, the display will be slow as (put whatever you want here !) but you’ll see if it takes that much memory !

AFAIK, display list implementation depends on the HW vendor. So I suppose the size of a display list varies from one constructor to another… I would have thought nVidia focuses on speed which, in IT, generally means more memory (yes, this one is simplistic but I could explain…).

Could you e-mail me your code for checking ?

Regards.

Eric

I’ve tried removing all the display lists bar one that is drawing using GL_TRIANGLES and it makes no difference to the size of the app or the speed.

I’m using GL_COMPILE to compile the display lists and glCallList to draw them.

Any other ideas?

Cheers,

Daniel

Hi there !

I thought I would give some highlights on what happened here…

Daniel created several display lists: two for displaying his model with points, and two for displaying his model with triangles. I don’t want to go in details in what the app does because I am not sure Daniel wants me to talk about it…

But saying that the model is quite big already explains the huge memory requirements !

Then, the FPS problem was due to the size of the display list for the triangles. I had already read (not long ago) that it is better to have several medium-sized display lists than one huge one…

I took Daniels’app and split the huge display list into two smaller and already had a performance increase (100-200% !). An interesting fact is that then, the application took less memory as well (???) : it went from 112Mb to 97Mb…

Now, the question is (and it is mainly directed to HW vendors…) : how do we size our display lists so that we get the most out of our chips ??? The other problem is that even if nVidia answers (and I am sure they will !), their answer will be different from ATI’s one or 3DFX’s one…

Best regards.

Eric

Cheers Eric!

Thanks for the help! It is interesting how the size of the display lists effects the speed of the app, maybe its something to do with a limited amount of geometry cache on the cards or some other storage requirment that would cause OpenGL to thrash the memory?

I’m off to reoptomize my app using a ROAM like algorithm and some small display lists. I’ll hopefully update my site and demo soon when I get the new version going!

Cheers guys,

Convict@Large