/* the flags to pass to SDL_SetVideoMode */
videoFlags = SDL_OPENGL; /* Enable OpenGL in SDL */
videoFlags |= SDL_GL_DOUBLEBUFFER; /* Enable double buffering */
videoFlags |= SDL_HWPALETTE; /* Store the palette in hardware */
videoFlags |= SDL_RESIZABLE; /* Enable window resizing */
//videoFlags |= SDL_FULLSCREEN;
/* This checks to see if surfaces can be stored in memory */
if ( videoInfo->hw_available ) { videoFlags |= SDL_HWSURFACE; }
else { videoFlags |= SDL_SWSURFACE;/* printf( "No HWSURFACE \n"); */}
/* This checks if hardware blits can be done */
if ( videoInfo->blit_hw ) { videoFlags |= SDL_HWACCEL; }
/* Sets up OpenGL double buffering */
SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER, 1 );
/* get a SDL surface */
screen = SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, videoFlags );
This Can't Be Right (SDL+OpenGL = 140MB mem?)
Author
So i've been working on this SDL+OpenGL demo for the last two months. Okay... i just peaked at the memory usage on my system monitor and it's used memory sucks up 140 MB! I tracked it down and it seems to come from SDL:
are you compiling it in Debug mode or Release mode?
Debug applications have a lot of extra information in them that the debugger can use to figure out connections to where you are in the source, which adds a lot to 1) the size of the executable, 2) the speed at which the application runs, and 3) the amount of memory it takes up during runtime.
[edited by - void* on May 30, 2004 9:02:45 PM]
Debug applications have a lot of extra information in them that the debugger can use to figure out connections to where you are in the source, which adds a lot to 1) the size of the executable, 2) the speed at which the application runs, and 3) the amount of memory it takes up during runtime.
[edited by - void* on May 30, 2004 9:02:45 PM]
That does not sound right at all, and I really hope it''s not the case. It''s probably something to do with the way Linux reports "used" memory, but I''m afraid I don''t know enough about that stuff to explain it.
Author
i''m compiling with GCC of course, and i''m using the -O3 optimization flag. Makes no difference.
.
.
It''s probably your driver pre-allocating all kinds of buffers and surfaces. The bad news is that there''s likely not much you can do about it. The good news is that it''s probably just virtual memory, and unless it actually gets touched, it won''t actually matter.
How are you checking the memory usage? Some methods (using ps, in particular) are known to be pretty inaccurate.
What you''re probably falling foul of is measuring mapped video memory as system memory usage (which it isn''t).
Some video drivers will be mapping the video memory into the game''s process - so that textures etc, can be more easily be moved into it.
This is seen by Linux as just another section of memory which is mapped (albeit with some flags) and counted like any other.
It''s generally very difficult to measure actual memory usage of programs on operating systems which support virtual memory. This is because two or more programs can share memory (and often do). Worse still, the same program can be using the same bit of memory twice, and thus have it counted twice.
Are you looking at the "VM size" in "top" ?
This is simply the *total* amount of memory that the process has mapped. It says little about actual RAM usage, as a lot of that will be shared libraries, mapped video memory etc.
Mark
Some video drivers will be mapping the video memory into the game''s process - so that textures etc, can be more easily be moved into it.
This is seen by Linux as just another section of memory which is mapped (albeit with some flags) and counted like any other.
It''s generally very difficult to measure actual memory usage of programs on operating systems which support virtual memory. This is because two or more programs can share memory (and often do). Worse still, the same program can be using the same bit of memory twice, and thus have it counted twice.
Are you looking at the "VM size" in "top" ?
This is simply the *total* amount of memory that the process has mapped. It says little about actual RAM usage, as a lot of that will be shared libraries, mapped video memory etc.
Mark
Disc cache memory is not accounted to individual processes; it is shared between all processes.
Linux only generally uses memory for disc cache if it isn''t in use for anything more important; modern versions of Windows do this too (95+). It''s just Linux used to do it before Windows did, so Windows users get all worried about that extra memory
Mark
Linux only generally uses memory for disc cache if it isn''t in use for anything more important; modern versions of Windows do this too (95+). It''s just Linux used to do it before Windows did, so Windows users get all worried about that extra memory
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
