Do I have to clean up all DisplayLists, Textures, (Geometry-)Shaders and so on by hand via the glDelete* functions, or does the GPU mem get freed automagically when my Program exits/crashes?
Note: GPU mem refers to dedicated memory on a dedicated Graphics card, not CPU memory.
Free the context, everything else is local to the context (unless you enabled display list sharing) and will go away along with it.
As others mentioned, your OS (in collaboration with the driver resource manager) should release the resources. That's what OSes are for. It's worth noting that this has nothing to do with OpenGL, but is something that is part of the charter of well behaved OSes and their associated drivers. The OS is there to handle all the system resources. OpenGL ones are just but a subset of them, and they are no different from, say a file handle. Now to get more concrete, you should specify which OS you care about.
BTW, This is where I take exception with ChrisF's answer. It should not be up to the driver to decide it needs to do cleanup. OS driver models will have a clear interface between the user-mode OpenGL driver (that shouldn't do actual gfx resource allocation, since it's shared in the machine), the OS (that provides the equivalent of system calls to allocate resources) and the kernel-mode driver (that is merely there to execute the OS orders in a way that is compatible with the gpu). This is at least the case with the WIN2K and WDDM models.
So... if your process crashes or otherwise terminates, in those models, it's the OS responsibility to call the kernel-mode driver to free all the resources that were associated with the process.
Now, whether you should or not is really something that is a little like asking tabs-or-spaces in source code. Different people have different beliefs here. "the OS will do it anyways, quitting immediately is a better end-user experience" vs "I want to know whether I'm leaking memory because if my program is long-running, I really don't want it to hit OOM errors. Best way to do that is to be leak-free throughout" are the 2 main lines of thought I'm aware of.
When your program exits (or crashes) then any memory it currently has allocated should be freed eventually in the same way that main memory is usually freed when a program exits. It may be some time before the GPU "realises" that the memory is available for use again.
However, you shouldn't rely on this behaviour as it may depend on how the graphics card drivers have been implemented. It's far better to make explicit clean up calls when you (as programmer) know that you won't need that memory again.
All your GPU resources will be released when your program exits. An easy way to test is to not delete things, and run your app repeatedly to see if it fails the allocations after a few iterations.
In Opengl, there is no memory to store the drawing information. here, when we execute the opengl program, that time calling draw frame method calling at sequentially. Anyway, if we draw a line or circle means, anytime its calling draw frame method for drawing at specified place.but, opengl does not store that line in memory.
Anytime, its drawing only. but, when we saw, that line is dawned successfully.
Ex:
In Android Opengl es2.0 used this renderer class inside drawframe method(inside draw method) to draw the lines or circles etc..
i used this Opengl es2.0 Program in android autocad app development..
if you want to clear the dawned lines use this method in renderer class inside onDrawframe method
GLES20.glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
GLES20.glClear(GLES20.GL_COLOR_BUFFER_BIT);
GLES20.glClear(GLES20.GL_COLOR_BUFFER_BIT | GLES20.GL_DEPTH_BUFFER_BIT);
Related
I sometimes forgot to do cleanup and afraid if the resources of them resides inside the GPU memory.
Things I use: shader programs, vertex array objects and buffer objects, textures
All OpenGL resources are supposed to be automatically released on destruction of OpenGL context (all shared contexts, to be precise). So practically, there should be no risk in leaking GPU memory when closing OpenGL context with some unreleased objects as far as your application does not trigger some video driver bug.
System will also take care on releasing all resources of closed application, even if some OpenGL contexts have been forgotten to be closed. Otherwise, it would be a total nightmare debugging 3D applications if GPU would keep allocated resources on an application crash.
To prove the idea - just write a simple test application allocating large portions of GPU memory (textures/VBOs) and track memory usage via external tools. Luckily, Task Manager in Windows 10 has been significantly improved and shows detailed GPU memory statistics.
From design point of view, however, it sounds like a bad idea tolerating incomplete clean-ups as the same release procedures used in other renderer code will cause real problems.
All resources you create for an OpenGL context are associated with that context (and any other context that you share resources with). If you destroy that context, all resources associated with it will be freed.
If you don't destroy the context when your program exits, then the OS will clean up after you.
That being said, destroying resources when you're done with them is a good habit to get into.
I use a game engine, as the game goes on, any unused textures, like from past levels, seem not to be cleared automatically. The developers though state that DirectX does not need to clear its textures manually, it simply swaps them out automatically when not used.
However my game seems to increase its memory usage with each different level. I am still testing for leaks and whatnot, however I'd like to use EmptyWorkingSet winapi function to lower the memory usage.
I do have the HWND of the application, how can I get its proccess id and use EmptyWorkingSet to clear the unused memory?
Do NOT do this.
EmptyWorkingSet() is not a magic bullet and it will only cause the memory used by your App to appear lower when queried by Task Manager, however the memory will only have been paged to disk and you'll be getting lots of page faults as a result. (A lose-lose situation)
The only correct way to fix this is to fix your memory leaks. Use valgrind and cachegrind to locate the issue, and make sure you're releasing your memory in all the places it needs to be released.
Also if the memory usage you see going up is Physical Memory in Task Manager, this is not DirectX, as Direct3D will store all texture information in server memory (ie: VRAM)
In OpenGL tutorials I never saw that someone call glDeleteFramebuffers before program finished.
Should I delete FrameBuffer before close application? Or OpenGL driver will do this for me?
P.S. Same question about texture glDeleteTextures.
The driver will free all resources associated with the OpenGL objects of a process when that process exits. You don't have to worry about system wide leaks if an application exits without cleaning up.
Even though the mechanisms are different, the behavior is very much like what happens with memory allocations. If you don't free all your dynamically allocated memory before exiting, all the memory that the application allocated will still be returned to the system. (*)
Still, I think it's generally good style to explicitly clean up all resources before exiting. It can also be helpful if you use tools that detect memory leaks.
(*) I'm talking about modern, full-featured operating systems here like they would typically be used on a desktop computer, a smart phone, or a tablet. I can imagine that this might not be true on minimal operating systems.
When running a simple OpenGL application in windows there are two unknown threads .I want to know what is these threads in application ?are there any documentation about them? our application crash in one of this threads in first step i want to know what is these thread? .
and this is dump of nvoglv64:
Those threads are not something specific to OpenGL; OpenGL doesn't know anything about threads, because technically it's just a piece of text, namely the specification.
However in your case it's very likely that those threads are created by the OpenGL implementation (aka your graphics driver). As you can see those threads seem to be tasked with copying some data. Which suggest they crash, because you either give OpenGL
some invalid pointer
or invalid metrics for the pointer (size of the buffer, stride, etc.)
or you're deallocating / freeing memory in a different thread while OpenGL still access it from the OpenGL context thread.
In either case it's not the threads fault that the program crashes, but your lack of either supplying OpenGL with valid data, or to properly lock/synchronize with OpenGL so that you don't invalidate the buffers in mid-operation.
Update
And this crash happening with Application Verifier suggests, that something about Application Verifier messes up memory used some way by OpenGL. This is very likely a bug in Application Verifier, but I think the best course of action would be to inform NVidia of the problem, so that they can address the problem with a workaround in their drivers.
is it possible to learn the allocated memory range of an OpenGL context? Supposedly this memory range should then be accessed with mmap() from another process. Can this technique work, or are there fundamental problems with it?
Update We're using a GNU/Linux system with a modern X11 installation and can pick the video card manufacturer whose drivers support such a trick.
Well, there are innumerable reasons why it won't work.
First, the "allocated memory range of an OpenGL context" is always changing. OpenGL contexts allocate new memory and deallocate it as it decides to.
Second, I would not trust an OpenGL driver to survive under memory mapped conditions like this. Multiple OpenGL contexts can coexist, but only because they all know about each other and the driver can therefore compensate for them. It is highly unlikely that a context can assimilate changes made by another context.
Third, GPUs often work with graphics memory. Even if you can use mmap on GPU memory (which itself is unlikely), you're probably going to lose a lot of performance when you do. And GPU memory gets shuffled around a lot more than CPU memory.
You appear to be trying to do IPC-based graphics. Your best bet would be to have the graphics system be its own process that you communicate with via IPC methods, rather than trying to talk to OpenGL via IPC.
Depends on the OS and driver. It's possible with an X-server. Although a combination of the X server, display driver and openGL means it could move the memory for a particular object around on the card when it draws it.
An easier way is probably to use an openGL pixel/vertex buffer and get the buffer pointer
is it possible to learn the allocated memory range of an OpenGL context?
I think you're asking for accessing the memory where a OpenGL context keeps its objects and the render output.
No. The OpenGL context is an abstract construct and have it's memory on an entirely different machine and/or architecture.
In addition to that there is no standard or even common memory layout for the contents of an OpenGL context. If you're interested in the rendering outcome only, you could tap the framebuffer device (/dev/fb…), though the performance will be inferior to just read back the framebuffer contents with glReadPixels. Similar goes for tapping the PCI memory range, which is virtually the same as tapping the framebuffer device.