GlClear () gives GL_OUT_OF_MEMORY on Intel HD 4000 (GL 4.0), but not GeForce (GL 4.2) ... why?

Question

Now this is a very strange behavior.

TL DR - in the texture rendering setting when changing the window size (framebuffer 0), only the very next glClear call (GL_COLOR_BUFFER_BIT) for the associated framebuffer 0 (window client area) gives GL_OUT_OF_MEMORY on only one of the two GPUs, however, the rendering is performed correctly and correctly.

Now all the details:

So, this is on a Vaio Z with two GPUs (which can be switched using the physical switch button on the machine):

• OpenGL 4.2.0 @NVIDIA Corporation GeForce GT 640M LE / PCIe / SSE2 (GLSL: 4.20 NVIDIA via Cg compiler)

• OpenGL 4.0.0 - Build 9.17.10.2867 @Intel Intel RR HD 4000 (GLSL: 4.00 - Build 9.17.10.2867)

My program is in Go 1.0.3 64-bit under Win 7 64-bit using the 64-bit version of GLFW.

I have a pretty simple and straightforward mini rendering texture pipeline. Firstly, the usual three-dimensional geometry is visualized using the simplest shaders (no lighting, nothing, just textured triangular grids, which are just a few cubes and planes) for the framebuffer, which has both depth / screen rendering and depth / stencil embedding , and texture2D as a color attachment. For texture, all filtering is disabled, as are mip cards.

Then I present a full-screen square (actually one “oversized” full-screen tri), simply taking a sample from the mentioned framebuffer texture (color binding) using texelFetch (tex, gl_FragCoord.xy, 0), so no packaging is used.

Both GPUs make it just fine, both when forcing the main profile, and in the case when I do not. GL errors are never reported for this, everything also looks as expected. Except when I resize the window when using the Intel HD 4000 GPU GL 4.0 rendering (both in the Core profile and in the Comp profile). Only in this case, one resizing will cause the GL_OUT_OF_MEMORY error to be written immediately after the very next call to glClear (GL_COLOR_BUFFER_BIT) in framebuffer 0 (screen), but only once after resizing, and not in each subsequent iteration of the loop.

Interestingly, in fact, I don’t even make any distributions when resizing! I temporarily disabled ALL logic that occurs when the window is resized, that is, right now I just completely ignore the window resize event, which means the RTT framebuffer, and its resolution for depth and color image does not even change / not recreate. The value of the next glViewPort will still use the same dimensions as when you first created the window and GL context, but any error occurs on glClear () (not earlier, only after, only once - I checked twice and three times).

Will this be a driver error, or can I do something wrong here?

Answer 1

An interesting glitch in the HD GL driver is as follows:

When I switched to setting the rendering to texture, I also set the depth / stencil bits when creating the GL context for the main framebuffer 0 (i.e. the screen / window) as 0. This is when I started to see this error and the frame rate became pretty sluggish compared with the previous ones.

I experimentally set the (strictly speaking, unnecessary) bit depth to 8, and both of these problems disappeared. It seems that the current version of the HD 4000 GL 4.0 driver just doesn't like the 0 value for its depth buffer bits when creating the GL context.