FBO and wglMakeCurrent... strange slowdown every 10frames

Hi All,

Just want to ask if anyone else has had this happen… Most people would of course be creating their GL context and thats it for the run of the program, however I’m writing a 3D editor with 4 viewports, separated by splitter windows… MFC doc/view architecture.

Anyway, its been working like a dream for over 2 years with this method:

-Create GL context on a HDC from CMainFrame
-When a CView OnDraw is called I would call: wglMakeCurrent(pDC->GetSafeHdc(), hGLRC) then do all my GL drawing. NOTE: I’m not changing my GL context, because I only have one. I’m changing the DC the context will draw to.

This ran fine with everything I threw at it, pixel shaders, stencil shadowing, AA, AF etc.

Now I added FBO support, and suddenly I’m getting this happening:

-I have 2 FBO’s, one unique texture to each as a color buffer.
-I draw the scene into a texture (copytexsubimage2d).
-draw into FBO1, reading the scene texture

-draw into FBO2, reading FBO1’s color buffer
-draw into FBO1, reading FBO2’s color buffer

-Draw to window system framebuffer (0), from FBO1’s color buffer.

If I run the above loop more then once, every 10 frames I’ll get a ONE SECOND pause (as timed by QueryPerformanceCounter) when calling;

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, m_FrameBuffers[fb]);


In between (the other 9 frames) it’ll run as you’d expect with however many of the above loops I’m calling. NOTE: I dont get ANY GL errors, or FBO errors.

I’ve finally narrowed it down to wglMakeCurrent. If I only call it once and keep drawing to that same HDC with my GLRC, the slowdown doesnt happen.

The moment wglMakeCurrent is called however, it’ll have the pausing happen from then on, no matter what else changes.

I’m using a Geforce 6800GT, and this happens on 77.x and 78.01 drivers.

So to me it looks like theres something either wrong in nvidias drivers, or theres some limitation theyre not telling us about when it comes to context switches. The EXT_framebuffer_object spec doesnt mention anything like this causing a problem…

Oh, and wglMakeCurrent’s documentation (MSDN) says you can switch between DC’s as long as they point to the same device, which mine do, theyre all windows drawn on the same desktop… and I’m not changing RC’s, only the DC I’m drawing to.

Anyone? Anyone? Bueller? Bueller? :slight_smile:

I’ve seen exactly the same thing on Linux using the 7667 drivers and a 6800.

Every 10 frames or so, It might take 4 seconds to bind the fbo. Looks like a driver bug to me.

Is there any way to do context switches in GLUT? It might be useful to knock together a cross platform example.

NO way!! On linux? thats a pretty impressive cross-platform bug then :slight_smile:

glut seems to have support for multiple windows but I dont know how it handles it… it must call wglMakeCurrent (or the linux version) to do it…

I was trying with glut earlier but didnt get into the multiple window thing. Might be enough to create an app that draws into a PBuffer first… but thats not available on linux is it?

I experienced something like this in windows on several driver-versions. As it turned out, you need to allocate all FBO-buffers BEFORE textures, vertex-data, displaylists and other onboard-data. Switching my allocation to do FBOs before everything else solved the problem.

I remembered this from a talk Richard Huddy gave a couple of years back on rendertargets in dx, so I guess this is not a new issue - or one that is likely to go away easily.


I’ve tried to find the article you mentioned, but no luck. Do you have a link?

Thing is, it’d be easy to make sure FBO’s are allocated first, but I reallocate them if the window size changes, and it can change often when people are resizing the views! This way I dont think I can force FBO’s to be allocated first :frowning: Unless… maybe once its created you can resize the texture and call glFramebufferTexture2DEXT again. I guess I have nothing to lose by trying!

Well it was a live one :slight_smile: You might find it on ati.com though.

Wouldn’t you usually create a maximum-size rendertarget, and simply render to more or less of that instead? In any case, it would remove you current problem.

<edit> oh, the following quote from an email I got from Mark Harris (nvidia) recently might be helpful:

In general, you should allocate all render targets (D3D speak) or FBOs (OpenGL speak) first. You should sort the allocation order by decreasing pitch (pitch = width * bits per pixel), and within each pitch group by frequency of use. (If you have some render targets that are very infrequently used, you might try allocating them last even if they have higher pitch than others.)

After render targets, allocate vertex buffers and textures.



Did you solve the problem ?

I have the similar problem with FBOs. It goes like this:-

Dual AMD Opteron CPUs / 2GB RAM
Dual 7800 GTX cards / 256MB each / 77.77 drivers

  1. Create 7 FBOs.
  2. Bind FBO and create textures and attach each texture to the corresponding FBO. (Together all the textures amount to 90MB)
  3. I do this on both the GPUs, each has a separate DC & RC

I see a performance drop every 10 frames. Now If I reduce the number of textures it works fine.

  1. Is there a limit on how many FBOs I can create ?
  2. Is it the drivers that put a limit on how much texture memory each GPU can use ? Also the driver must be smart enough to recognize that each GPU is using only 90MB not 180MB total ?
  3. Is the FBO implementation buggy ?

im seeing a problem with FBO also (nv3x 77.72)
what happens is my opengl window freezes for ~0.3 seconds, works for ~0.3seconds, freezes for ~0.3 seconds etc. is this what yous are seeing?

this happens when only im using FBO (no gl errors reported btw)
this happens if im running some apps in the background (eg ShadeView that was on www.opengl.org news a couple of days ago, ok ild expect something strange to happen if i was running ShadeView with a 3d window, but the problem occurs even if the dialog is displayed + nothing else)

i assume this is just teething troubles with FBO


How much texture memory are you using ?

My application freezes infrequently if I reduce the amount of textures and FBOs that I am creating. I bet it’s something in the drivers.

thats sounds like a reasonable assumption
ive got an agp card 128mb perhaps im using all the memory + its having to use system memory (god bless intel with their agp standard, 1 slot on the MB, i remrember my 2nd agp card had as much mem as my pc!)

ive got the stats in for how much texture memory my app uses
but havent (yet) added DL/VBO ussage
or FBO usage
any idea of how to go about calculating minium FBO mem usage
is it just fbo size * buffer depth * number buffers or are their other things i need to worry about?

Hi all. This is a known bug that’s been fixed in release 80 drivers.

Sorry for the inconvenience.

Thanks -

Sorry I havent replied for a while…

Well i fixed it by simply moving ALL of my stuff back to pbuffers. The other main reason I did that was because I needed stencil support, and FBO’s dont do that at the moment.

I was going to try hornets suggestion but figured it’d be pretty impossible anyway because I’m allocating texture objects with my pbuffers (I needed one pbuffer because of stencil, was going to use FBO for post processing)… so I couldnt have realy allocated things in a set order - fbo, textures, verts like hoprnet suggested.

Cass: When can we expect the 80.x driver? :slight_smile: Oh and how about stencil support? eh? eh? :wink:

Originally posted by cass:
[b]Hi all. This is a known bug that’s been fixed in release 80 drivers.

Sorry for the inconvenience.

Thanks -
Thanks Cass!

When will the series 80 drivers be out ? I tried the 81.84 Beta but my old programs are not running. I can’t set my display devices in horizontal span mode anymore.

81.85 is available on www.nvidia.com. It should support EXT_packed_depth_stencil and fix the stutter-every-ten-frames issue some people have run into.

Originally posted by dimensionX:
When will the series 80 drivers be out?

Originally posted by ChiefWiggum:
…I needed stencil support, and FBO’s dont do that at the moment.

81.85 breaks my usage of FBO on a quadroFX 3000.
Flashing blocks of red instead of what previously rendered perfectly…
Ah well.

Originally posted by knackered:
81.85 breaks my usage of FBO on a quadroFX 3000.
Flashing blocks of red instead of what previously rendered perfectly…
Ah well.

Hi knackered,

Can you contact me offline about a repro case?

Thanks -

Isn’t 81.85 driver for Geforce series cards ? How will it work for Quadro series cards ? What am I missing here ?

OK so here’s mine not entirely on topic 2 cents.
When I install any of the officially available 80 series driver, my system hangs during installation or on next boot-up. I’ve e-mailed the manufacturer of the card and they stated that the problem must reside in the driver itself. Of course they also advised me to roll back to 75 series driver. But as the 80 series drivers are the only ones that should support EXT_packed_depth_stencil (and this feature is of utmost importance to me) I have good reason to complain. I can e-mail precise system specs to anyone interested in helping me solve this problem.
Once again, I am sorry for being off-topic.