I am in the process of upgrading a legacy OpenGL codebase to run under a context set to the OpenGL 3.2 Core Profile (i.e. no legacy junk). All is going well, except that I have a weird error in glGetTexImage() when trying to extract floating point data from a texture.

The following code reads the single pixel from the highest mipmap level of a mipmap'd GL_RGBA32F texture (log2_size containing the number of mipmap levels):


GLfloat sums[4];

glGetTexImage(GL_TEXTURE_2D, log2_size, GL_RGBA, GL_FLOAT, sums);

For some reason, under the OpenGL 3.2 Core profile, this is resulting in an GL_INVALID_OPERATION, whereas it works without issue in a compatibility context.

There are only two possible sources of an GL_INVALID_OPERATION error, according to the 3.2 Core specification. The first is a format mismatch:

Any of the following mismatches between format and the internal format ofthe texture image will generate an INVALID_OPERATION error:
• format is a color format (one of the formats in table 3.3 whose target is thecolor buffer) and the base internal format of the texture image is not a colorformat.
• format is DEPTH_COMPONENT and the base internal format is not DEPTH_-COMPONENT or DEPTH_STENCIL.
• format is DEPTH_STENCIL and the base internal format is not DEPTH_-STENCIL.
• format is one of the integer formats in table 3.3 and the internal format ofthe texture image is not integer, or format is not one of the integer formats intable 3.3 and the internal format is integer.[/quote]

And I really don't feel that a format of GL_RGBA should trigger a mismatch against an internal format of GL_RGBA32F. The second possibility is a bound PBO:

If a pixel packbuffer object is bound and packing the texture image into the buffer’s memorywould exceed the size of the buffer, an INVALID_OPERATION error results. If apixel pack buffer object is bound and img is not evenly divisible by the number ofbasic machine units needed to store in memory the GL data type corresponding totype (see table 3.2), an INVALID_OPERATION error results.[/quote]
Which also can't be the problem, because I am not using any PBOs in this application.

I have also made sure that the texture is bound to the correct texture unit (texture unit zero, which is the active unit), and have made sure to unbind the FBO which was used to render into the texture. I am not 100% sure that the mimap chain is successfully rendered (I can't read it back to find out), but since they are under the compatibility profile, I don't see any great reason why they shouldn't be here...

Can anyone offer any leads on tracking this down?

Driver bug?

Driver bug?

I am definitely starting to lean that way. The error occurs on a MacBook Air running OS X Lion (NVidia 320m), and I just moved the code to a Windows 7 machine with a Radeon 5770, which doesn't exhibit the same error.

However, it also doesn't fully work under Windows/ATI, which implies that my mipmap chain may not be fully generated, in which case the Mac/NVidia drivers may just be throwing the wrong error when I try to read form a non-existent mipmap level.

My efforts to debug are a little hampered, because Apple's OpenGL Profiler is refusing to show me texture contents, gDEBugger for Mac doesn't yet support Lion, and the current version of gDEBugger for Windows 7 has a bug where it locks up whenever you try to view a texture. *sighs*

If you are doing RTT, then use glReadPixels as an alternative. File a bug report with Apple for the glGetTexImage problem.

If you are doing RTT, then use glReadPixels as an alternative.

Wait... Does that work? I had always assumed that glReadPixels could only read from the front/back buffer, and that it would ignore the texture attached to the currently-bound FBO.

File a bug report with Apple for the glGetTexImage problem.[/quote]
Aye, once I manage to reproduce it in a minimal sample app. The current issue is buried in a 10,000 line implementation of histopyramid extraction :/

A texture attached to a FBO is just a standard buffer. glReadPixels can read from it as long as the FBO is bound. If you bind FBO 0, then glReadPixels reads from the backbuffer.