• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

102 Neutral

About mshafey

  • Rank
  1. [quote name='mhagain' timestamp='1329344027' post='4913484'] On reconsidering this, memory usage starting low, followed by an increase then stabilize is probably nothing to be worried about. It's where the stabilize part doesn't happen that you need to start worrying (that's a real leak - stabilization isn't a leak, it's just using resources). What's actually happening would be internal driver behaviour so we're reduced to guessing here, but going by your final stripped down program a reasonable and plausable guess would be that the driver is buffering up geometry used by immediate mode calls - it may for example be writing them into a dynamic VBO and then issuing real draw calls behind the scenes from that. [/quote] Thanks. We realized this is true. From [url="http://www.opengl.org/wiki/FAQ#Memory_Usage"]here[/url]: [quote] [b] Memory Usage[/b] [color=#000000][font=sans-serif][size=3]It seems to be common to think that there is a memory leak in the OpenGL driver. Some users write simple programs such as this[/size][/font][/color] [color=#000000][font=sans-serif][size=3] glClear[color=#008000]([/color]...[color=#008000])[/color][color=#008080];[/color] SwapBuffers[color=#008000]([/color]...[color=#008000])[/color][color=#008080];[/color][/size][/font][/color] [color=#000000][font=sans-serif][size=3]and they observe that their memory usage goes up each time their Display function is called. That is normal. The driver might allocate some memory space and since the driver is basically a black box, we don't know what it is doing. The driver might be doing some work at optimizing in a secondary thread or preparing some buffering area. We don't know what it is doing, but there is no memory leak.[/size][/font][/color][/quote] The problem is, in our application we're dealing with many OpenGL contexts at once (up to 30). For Windows XP on the same hardware, OpenGL memory is small compared to Windows 7. So in a day my application memory goes up to 1.5 GB on Win 7, but stays at 500 MB on XP. We'll either require more memory or reduce the number of contexts used. Thanks for the useful input everyone.
  2. No. I'm finding the same behavior with QGLWidget (not using GLUT). Also, VLC with OpenGL output seems to have this memory increase problem as well.
  3. [quote name='mhagain' timestamp='1329248389' post='4913090'] [quote name='mshafey' timestamp='1329247414' post='4913082'] Thanks for the suggestion. I've tried your code, it works, but it doesn't fix the leak. I'm still seeing memory leaking at the same rate on the affected platforms. [/quote] That's interesting. Let's try to pin down which call is causing it. What happens if you comment out the glTexSubImage2D call? And if you comment out the glMapBuffer block (but leave glTexSubImage2D in and coming from the PBO)? [/quote] gDEBugger with the code I posted in the first post. Upon application exit it says [b]"Checking for memory leaks - Context 1 deleted. Memory Leak: 2 object(s) are leaked in GL Context 1 [Leak Size: 2,400KB]"[/b]. Here are Process Explorer graphs for the original code running for a few minutes. GPU graph: [url="http://i.imgur.com/KgXix.png"]http://i.imgur.com/KgXix.png[/url] Performance graph: [url="http://i.imgur.com/bD9RH.png"]http://i.imgur.com/bD9RH.png[/url] I took out glMapBuffer()/glUnmapBuffer() block. Leak persists. Same for the glTexSubImage2D() call. Took them both out and still. Which lead me to remove everything except just basic calls to draw a rectangle switching colors. I'm sorry I sent everyone in the wrong direction here. It seems like even the most basic GL code causes Windows 7 machines to leak memory. I trimmed it down to this and it still leaks. [code] void paintGL(); void timerCallback(int value); void changeSize(int w, int h); unsigned char c = 255; int main(int argc, char **argv) { glutInit(&argc, argv); glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA); glutInitWindowPosition(300, 300); glutInitWindowSize(640, 480); int windowHandle = glutCreateWindow("Window"); glutDisplayFunc(paintGL); glutReshapeFunc(changeSize); timerCallback(0); glutMainLoop(); glutDestroyWindow(windowHandle); return 0; } void paintGL() { c = c? 0 : 255; glColor3ub(c, c, c); glBegin(GL_QUADS); { glVertex3f(-1, 1, 0); glVertex3f(1, 1, 0); glVertex3f(1, -1, 0); glVertex3f(-1, -1, 0); } glEnd(); glutSwapBuffers(); } void changeSize(int w, int h) { glViewport(0, 0, w, h); } void timerCallback(int value) { glutPostRedisplay(); glutTimerFunc(5, timerCallback, 0); } [/code] I might add that in some runs, this code starts off at about 18 MB and goes up to and then stabilizes at 40 MB in a 5-6 minutes.
  4. [quote name='mhagain' timestamp='1329245602' post='4913072']@OP: have you tried this using glBufferSubData instead of glMapBuffer? It would be interesting to know if the same symptoms are observed with that. The following should be equivalent: [code]void mapAndCopyToBuffer(char* img1) { glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB, pixelbufferHandle); glBufferSubData (GL_PIXEL_UNPACK_BUFFER_ARB, 0, w * h * s, img1); glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, w, h, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, 0); }[/code] Oh - and make sure that the value of s is 4. ;) [/quote] Thanks for the suggestion. I've tried your code, it works, but it doesn't fix the leak. I'm still seeing memory leaking at the same rate on the affected platforms.
  5. [quote name='Yours3!f' timestamp='1329240914' post='4913038'] seems like you don't free your mappedBuf after using it. you need to do this if you want to really free some memory: [/quote] But we didn't allocate any memory here. What I understand is that after the call to glMapBuffer(), mappedBuf should be treated as GPU memory, so it's not up to us to free it. We copy the texture into this mapped memory, then call glUnmapBuffer() to indicate to OpenGL that we're done copying/modifying that buffer (the buffer that belongs to the driver, not us). Just to be sure, I tried to delete[] mappedBuf now (before the statement where I set it to NULL). It crashes.
  6. Hi. I have been experiencing a memory leak when using pixel buffer objects to update textures. The leak seems to only occur on certain platforms with certain operating systems, and so we began to suspect the leak is occurring inside the Intel HD Series Windows 7 driver. Below is a summary of our testing on different platforms. Can anyone tell if I'm doing something wrong in the code, or if this is potentially a driver leak? Series 4 Chipset (Lenovo SL300), Windows XP SP3: [b]No Leak[/b] Series 4 Chipset (Lenovo SL300), Windows 7: [b]Leaks ~500 kB/min[/b] Intel HD Series (Lenovo X1), Windows 7: [b]Leaks ~500 kB/min[/b] Intel HD 3000 (11" MacBook Air) Mac OS 10.7.3: [b]No Leak[/b] Nvidia Quadro NVS, Windows XP: [b]No Leak[/b] Here is a stripped down version of the code to reproduce this issue (VS2008 project at [url="http://www.viionsystems.com/Intel_HD_Series_Win7_Leak_Test_Case.zip"]http://www.viionsyst...k_Test_Case.zip[/url]). Extensive testing of this code shows no memory leaks detectable by VS2008's memory leak detector, yet GPU memory seems to grow indefinitely (according to ProcessExplorer). I would appreciate any thoughts from the community on this issue. [code] #include <stdio.h> #include <windows.h> #include "GL\GLee.h" #include "GL\freeglut.h" unsigned int w = 640; unsigned int h = 480; unsigned int s = 4; char* img = NULL; char* texData1 = NULL; char* texData2 = NULL; char* mappedBuf = NULL; GLuint pixelbufferHandle; void timerCallback(int value); void initializeTextureBuffer(); void mapAndCopyToBuffer(char* img1); void paintGL(); void changeSize(int w, int h); GLuint errorCode; #define checkForGLError() \ if ((errorCode = glGetError()) != GL_NO_ERROR) \ printf("OpenGL error at %s line %i: %s", __FILE__, __LINE__-1, gluErrorString(errorCode) ); int main(int argc, char **argv) { texData1 = new char[w * h * s]; texData2 = new char[w * h * s]; memset(texData1, 85, w * h * s); memset(texData2, 170, w * h * s); img = texData1; glutInit(&argc, argv); glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA); glutInitWindowPosition(300, 300); glutInitWindowSize(w, h); glutCreateWindow("Window"); glutDisplayFunc(paintGL); glutReshapeFunc(changeSize); initializeTextureBuffer(); timerCallback(0); glutMainLoop(); glDeleteBuffers(1, &pixelbufferHandle); delete[] texData1; delete[] texData2; return 0; } void initializeTextureBuffer() { glGenBuffers(1, &pixelbufferHandle); checkForGLError(); glBindBuffer(GL_PIXEL_UNPACK_BUFFER, pixelbufferHandle); checkForGLError(); glBufferData(GL_PIXEL_UNPACK_BUFFER, w * h * s, 0, GL_DYNAMIC_DRAW); checkForGLError(); // initialize and upload the texture glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, w, h, 0, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, 0); checkForGLError(); // Specify filtering and edge actions glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR); glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR); glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_CLAMP); glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_CLAMP); img = (char*) glMapBuffer(GL_PIXEL_UNPACK_BUFFER, GL_WRITE_ONLY); if (img == NULL){ return; } memset(img, 0, w * h * s); glUnmapBuffer(GL_PIXEL_UNPACK_BUFFER); } void mapAndCopyToBuffer(char* img1) { glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB, pixelbufferHandle); mappedBuf = (char*) glMapBuffer(GL_PIXEL_UNPACK_BUFFER, GL_WRITE_ONLY); memcpy(mappedBuf, img1, w * h * s); glUnmapBuffer(GL_PIXEL_UNPACK_BUFFER); mappedBuf = NULL; glBindBuffer(GL_PIXEL_UNPACK_BUFFER, pixelbufferHandle); glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, w, h, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, 0); } void paintGL() { if (img == texData1) img = texData2; else img = texData1; // swap images mapAndCopyToBuffer(img); glMatrixMode(GL_MODELVIEW); glPushMatrix(); glDisable(GL_BLEND); glDepthMask(GL_FALSE); glDisable(GL_CULL_FACE); glDisable(GL_DEPTH_TEST); glEnable(GL_TEXTURE_2D); glEnable(GL_MULTISAMPLE); glBegin(GL_QUADS); { glTexCoord2f(0,0); glVertex3f(-1, 1, 0); glTexCoord2f(1,0); glVertex3f(1, 1, 0); glTexCoord2f(1,1); glVertex3f(1, -1, 0); glTexCoord2f(0,1); glVertex3f(-1, -1, 0); } glEnd(); glMatrixMode(GL_MODELVIEW); glPopMatrix(); glutSwapBuffers(); } void changeSize(int w, int h) { glViewport(0, 0, w, h); } void timerCallback(int value) { glutPostRedisplay(); glutTimerFunc(5, timerCallback, 0); } [/code]