sgsrules's picture

Problems with improper resource cleanup

I recently added multiple render targets to my engine, i also use 16x multisampling. Everything works fine until i quit and try to restart the app. If i enable multisampling i get a opengl error dialogue box that says:

Your hardware configuration does not meet the minimum specifications needed to run the application. The application must close.
please visit etc....

Eventhough it worked fine on the first run. At this point if i restart my pc i can get it working again, until i quit and try to run it again. So i'm guessing that by restarting my pc i'm clearing out the video ram or anything else that still might be resident so the cause of the issue is improper resource cleanup. Ii've made sure i deleted all my textures, framebuffers, vbos, vaos etc etc. And whouldn't the driver clean up any leftovers when the glcontext is destroyed anyways? I'm manually calling glcontext.Dispose(); after resource cleanup.

All my buffers reports that they are complete and without errors.
Another note of interest is that i only get this error when i render to more than one buffer at once using gldrawbuffers and if i use 16x msaa, if i use 8x msaa or lower or just render to one target there are no errors.

I


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kanato's picture

You are probably running into a bug within your video driver. You should try updating your drivers to make sure they are the latest.

sgsrules's picture

I already tried updating to the latest nvidia drivers dated 6/15/10. same issue.
i'm deleting my buffers and other stuff by using

GL.DeleteFrameBuffers(1, fboid);

where fboid: int[] fboid = new int[1];

Which i'm sure is correct. and i'm not doing this from a finalizer i'm making all the delete calls myself.

Hortus Longus's picture

I have had such a problem before two or three years, with a uptodate system (windows), with uptodate drivers (nvidia) and some opengl-apps, not self-written. With some other opengl-apps (self-written or not) these problem was not existing.
From one day to another day, without changing something (so far as I know), these problems are gone. :-?
But that is not a great help for you, I know.
Is there a difference if you let run your app under different conditions (with/without ide, debug/release)?

the Fiddler's picture

If you are using OpenGL 3.x+, you should call GL.GenFrameBuffers to create buffer ids.

Other than that, try running with the debug version of OpenTK.dll, which will check and inform you of any OpenGL errors (that may otherwise go unnoticed). This is a great time saver for complex applications.

You can find the debug version under opentk-1.0/Binaries/OpenTK/Debug.

sgsrules's picture

I'm using GL.GenFrameBuffers to create my ids. Can you set opentk to debug mode when you create your context? I use the following to create my context:

private void CreateGLContext()
        {
            GraphicsMode t = new GraphicsMode(32, 24, 0, 0, 0, 2); // what does the samples parameter do? is it used with MSAA?
 
            nWindow = new NativeWindow(DisplayWindowWidth, DisplayWindowHeight, "OpenGl Window", GameWindowFlags.Fullscreen, t, DisplayDevice.AvailableDisplays[1]);
            nWindow.Location = new System.Drawing.Point(DisplayDevice.AvailableDisplays[0].Width);
            GlContext = new GraphicsContext(t, nWindow.WindowInfo, 3, 2, GraphicsContextFlags.Default);
            GlContext.MakeCurrent(nWindow.WindowInfo);
            (GlContext as IGraphicsContextInternal).LoadAll();
        }

will changing
 GlContext = new GraphicsContext(t, nWindow.WindowInfo, 3, 2, GraphicsContextFlags.Default);
to
 GlContext = new GraphicsContext(t, nWindow.WindowInfo, 3, 2, GraphicsContextFlags.Debug);

do the same thing as using the debug version of opentk? How is this different than using glgeterror or checking buffer completeness?

the Fiddler's picture

GraphicsContextFlags.Debug is related to the concept of "debug" contexts. It was added in OpenGL 3.0 but AFAIK AMD is the only one to actually support this (via the AMD_debug_output extension).

The debug version of OpenTK adds extra debugging information and compile-time GL.GetError() checks to all OpenGL calls. It's useful as a debugging aide during application development (i.e., are you checking GL.GetError() during resource cleanup? You might be getting some error that confuses the driver.)

In all likelihood, this is a driver bug. Does this issue appear on different hardware?

Edit: what video card, OS and drivers are you using? Is your app running in 32bit or 64bit mode?

sgsrules's picture

Here's some info on my setup:
Windows 7 64bit
nvidia gtx260
257.21 nvidia drivers
intel quad core 3.2 ghz
4gb ram
Opengl 3.2 core profile.

I'm compiling in 64bit mode. The fbos i'm creating are:
1920x1080 16xMSAA RGBA16f with two attachments. this is used for my initial pass.
I've also got another 1920x1080 no msaa RGBA16f with 3 attachments to resolve the msaa and for postprocessing and then there's some smaller sized fbos but i turned those off for now for debugging.

If i turn the resolution down i don't get any errors but unfortunately my final renders have to be at 1080p with 16xMSAA.

BTW once again thanks for all your help, i'm going to check for errors during resource cleanup as you suggested .

**Edit** checked for errors using debug mode(Man i wish i would have know about that before); i ran into one invalid enumerator but it was unrelated. I traced through my whole code and it looks like it is able to render one frame with msaa on but the second time it makes a call to GlContext.SwapBuffers(); it crashes. here's some of my code:

msaa fbo setup:

      public static void CreateMSAAFBO()
        {
            MSAAFBO = new int[1];
            Samples =16;
            colorBuffer = new int[1];
            dataBuffer = new int[1];
            depthBuffer = new int[1];
 
            GL.GenTextures(1, colorBuffer);
            GL.BindTexture(TextureTarget.Texture2DMultisample, colorBuffer[0]);
            GL.TexImage2DMultisample(TextureTargetMultisample.Texture2DMultisample, Samples, PixelInternalFormat.Rgba16f, 
                                     ScreenWidth, ScreenHeight, false);
 
            GL.GenTextures(1, dataBuffer);
            GL.BindTexture(TextureTarget.Texture2DMultisample, dataBuffer[0]);
            GL.TexImage2DMultisample(TextureTargetMultisample.Texture2DMultisample, Samples, PixelInternalFormat.Rgba16f,
                                     ScreenWidth, ScreenHeight, false);
 
            GL.GenTextures(1, depthBuffer);
            GL.BindTexture(TextureTarget.Texture2DMultisample, depthBuffer[0]);
            GL.TexImage2DMultisample(TextureTargetMultisample.Texture2DMultisample, Samples,
                                     PixelInternalFormat.DepthComponent24, ScreenWidth, ScreenHeight, false);
 
            GL.GenFramebuffers(1, MSAAFBO);
            GL.BindFramebuffer(FramebufferTarget.Framebuffer, MSAAFBO[0]);
            GL.FramebufferTexture(FramebufferTarget.Framebuffer, FramebufferAttachment.ColorAttachment0, colorBuffer[0], 0);
            GL.FramebufferTexture(FramebufferTarget.Framebuffer, FramebufferAttachment.ColorAttachment1, dataBuffer[0], 0);
            GL.FramebufferTexture(FramebufferTarget.Framebuffer, FramebufferAttachment.DepthAttachment, depthBuffer[0], 0);
            GL.BindFramebuffer(FramebufferTarget.Framebuffer, 0);
        }

I Then Bind the fbo with

    public static void BindMSAAFBO()
        {
            GL.BindFramebuffer(FramebufferTarget.Framebuffer, MSAAFBO[0]);
            Renderer.Viewport(ScreenWidth, ScreenHeight); // changes gl viewport state
            GL.DrawBuffers(2, new[] { DrawBuffersEnum.ColorAttachment0, DrawBuffersEnum.ColorAttachment1 });
        }

normally i draw my scene but i turned all that off for debugging.
unbind fbo and swap buffers:

 
GL.BindFramebuffer(FramebufferTarget.Framebuffer, 0);
GLContext.SwapBuffers();  // this is where it crashes

I then normally resolve the samples in a shader and apply post processing etc but i stripped all that out for debugging. Thats pretty much everything i've got code posted for my glcontext creation above.

the Fiddler's picture

Can you please post the stacktrace for the crash? Use the debug version of OpenTK.dll *and* OpenTK.pdb (found in the same folders) to obtain line numbers. Maybe this could shed some light into the issue.

sgsrules's picture

Does the .pdb file get loaded when i load the debug opetk.dll? I don't get a stacktrace when it crashes, just the nvidia driver error dialogue box pops up i hit ok and it closes my app and stops the debugging. I did notice a few weird things in my debug window when i normally open and close it:

The thread 'vshost.LoadReference' (0x131c) has exited with code 0 (0x0).
'ML3D.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\ML3D\ML3D\bin\x64\Debug\ML3D.exe', Symbols loaded.
'ML3D.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\ML3D\ML3D\bin\x64\Debug\OpenTK.dll', Symbols loaded.
A first chance exception of type 'System.DllNotFoundException' occurred in OpenTK.dll
A first chance exception of type 'System.TypeInitializationException' occurred in OpenTK.dll
Detected configuration: Windows / .Net
A first chance exception of type 'System.DllNotFoundException' occurred in OpenTK.dll
DisplayDevice 1 (primary) supports 165 resolutions.
DisplayDevice 2 (secondary) supports 192 resolutions.
Creating default GraphicsMode (32, 16, 0, 0, 0, 2, False).
Creating GraphicsContext.
    Creating GraphicsContext.
        Device context: -1308554263
        Selecting pixel format... GraphicsMode: Index: 11, Color: 24 (8880), Depth: 0, Stencil: 0, Samples: 0, Accum: 64 (16161616), Buffers: 2, Stereo: False
        IWindowInfo: Windows.WindowInfo: Handle 66778, Parent (Windows.WindowInfo: Handle 66776, Parent (null))
        GraphicsContextFlags: Default
        Requested version: 1.0
        Loaded opengl32.dll: 8791410606080
        OpenGL will be bound to handle: 66778
        Setting pixel format... 11
        Creating temporary context for wgl extensions.
        Load extensions for OpenTK.Platform.Windows.Wgl... 50 extensions loaded in 72 ms.
        Load extensions for OpenTK.Platform.Windows.Wgl... 50 extensions loaded in 1 ms.
        Using WGL_ARB_create_context... success!
        success! (id: 131072)
    Selecting pixel format (ARB)... success!
    Disposing context 131072.
    Destroying window: Windows.WindowInfo: Handle 66776, Parent (null)
    GraphicsMode: Index: 56, Color: 32 (8888), Depth: 24, Stencil: 0, Samples: 16, Accum: 64 (16161616), Buffers: 2, Stereo: False
    IWindowInfo: Windows.WindowInfo: Handle 66772, Parent (Windows.WindowInfo: Handle 721876, Parent (null))
    GraphicsContextFlags: Default
    Requested version: 3.2
    OpenGL will be bound to handle: 66772
    Setting pixel format... 56
    Using WGL_ARB_create_context... success!
    success! (id: 196608)
Load extensions for OpenTK.Platform.Windows.Wgl... 50 extensions loaded in 1 ms.
Loading extensions for OpenTK.Graphics.OpenGL.GL... 1900 extensions loaded in 329.6829 ms.
'ML3D.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\PresentationFramework.Aero\v4.0_4.0.0.0__31bf3856ad364e35\PresentationFramework.Aero.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'ML3D.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\ML3D\ML3D\bin\x64\Debug\MIDI.dll', Symbols loaded.
Delegate Queue Thread: 1 Started.
Delegate Queue Thread: 2 Started.
Delegate Queue Thread: 3 Started.
System.Windows.Data Error: 4 : Cannot find source for binding with reference 'RelativeSource FindAncestor, AncestorType='System.Windows.Controls.ItemsControl', AncestorLevel='1''. BindingExpression:Path=HorizontalContentAlignment; DataItem=null; target element is 'TreeViewItem' (Name=''); target property is 'HorizontalContentAlignment' (type 'HorizontalAlignment')
System.Windows.Data Error: 4 : Cannot find source for binding with reference 'RelativeSource FindAncestor, AncestorType='System.Windows.Controls.ItemsControl', AncestorLevel='1''. BindingExpression:Path=VerticalContentAlignment; DataItem=null; target element is 'TreeViewItem' (Name=''); target property is 'VerticalContentAlignment' (type 'VerticalAlignment')
Delegate Queue Thread: 1 Finished
The thread 'Delegate Queue Thread: 1' (0x1160) has exited with code 0 (0x0).
Delegate Queue Thread: 2 Finished
The thread 'Delegate Queue Thread: 2' (0x4d8) has exited with code 0 (0x0).
Delegate Queue Thread: 3 Finished
The thread 'Delegate Queue Thread: 3' (0x628) has exited with code 0 (0x0).
Disposing context 196608.
The thread 'vshost.RunParkingWindow' (0x112c) has exited with code 0 (0x0).
The thread '<No Name>' (0x1134) has exited with code 0 (0x0).
[Warning] Failed to release device context 1543572434. Windows error: 0.
[Warning] INativeWindow leaked (OpenTK.Platform.Windows.WinGLNative). Did you forget to call INativeWindow.Dispose()?
The program '[4844] ML3D.vshost.exe: Managed (v4.0.30319)' has exited with code 0 (0x0).

these last two warnings:

[Warning] Failed to release device context 1543572434. Windows error: 0.
[Warning] INativeWindow leaked (OpenTK.Platform.Windows.WinGLNative). Did you forget to call INativeWindow.Dispose()?

Seem to indicate that it's not releasing the context.

**Edit **
I added a call to INativeWindow.Dispose() and that got rid of the warnings but i'm still having the same problem. I also noticed that now it started crashing after msaa has been on for a while, it renders a few frames and then i get the driver error

sgsrules's picture

This is definitely a driver issue. I ran the app on another machine running windows xp and a 8800gtx, no problems. Ran the same app on the same machine with windows 7... nvidia driver crash. At this point i'm kinda wishing i would've never switched to windows 7 because of all the driver issues i've been having, stuff like texturesize and texelfetch didn't even work until the latest driver revision i had to use the developer opengl 3.3 drivers. So until nvidia fixes this issue i'm stuck with 8x msaa or rendering stuff on my xp machine. How does one go about reporting something like this to nvidia and more importantly will it really matter?