OpenGL Error when using ARB_get_program_binary and textures.

Discussion created by avasquez on Mar 8, 2011
Latest reply on Mar 10, 2011 by HammerTime

'm having another strange issue that seems to be related to GL_ARB_get_program_binary. The symptom that shows up is a GL_INVALID_OPERATION error after a glDrawElements call. The odd thing is that this error only occurs when attempting to use a sampler2D in a shader. Draw calls using shaders that only access positions and color vertex attributes for example, do not result in an error.

First off, here are my Catalyst stats:

Driver Packaging Version    8.821-110126a-112962C-ATI   
Catalyst Version    11.2   
Provider    ATI Technologies Inc.   
2D Driver Version   
2D Driver File Path    /REGISTRY/MACHINE/SYSTEM/ControlSet001/Control/CLASS/{4D36E968-E325-11CE-BFC1-08002BE10318}/0002   
Direct3D Version   
OpenGL Version   
Catalyst Control Center Version    2011.0126.1749.31909   

Primary Adapter       
Graphics Card Manufacturer    Powered by AMD   
Graphics Chipset    AMD Radeon HD 6800 Series   
Device ID    6738   
Vendor    1002   
Subsystem ID    2305   
Subsystem Vendor ID    1787   
Graphics Bus Capability    PCI Express 2.0   
Maximum Bus Setting    PCI Express 2.0 x16   
BIOS Version   
BIOS Part Number    1134965469   
BIOS Date    2010/11/03   
Memory Size    1024 MB   
Memory Type    GDDR5   
Core Clock in MHz    900 MHz   
Memory Clock in MHz    1050 MHz   
Total Memory Bandwidth in GByte/s    134.4 GByte/s

I am running in OpenGL with a 4.1 context with the forward compatible and debug bits set in the core profile. I have tried this also in a 3.3 context which similar results.

My application is drawing a full screen quad with a single texture on it. If I load the shader from a raw source string, the application will successfuly draw the texture to the screen. However, if I load the shader from a binary program created by my machine using the functionality in the GL_ARB_get_program_binary extension, I get a GL_INVALID_OPERATION error from the glDrawElements call for the full screen quad render.

This is the GLSL vertex shader I am using:

#version 150
uniform mat4 modelViewProjectionMatrix;

in vec3 in_position;
in vec2 in_texCoord0;

out vert2frag

   out vec2     texCoord0;
} OUT;

void main()

   OUT.texCoord0 = in_texCoord0;
   gl_Position = modelViewProjectionMatrix * vec4(in_position.xyz,1.0);



// This is the GLSL fragment shader I am using:
#version 150
uniform sampler2D diffuseTexture;

in vert2frag

   vec2     texCoord0;
} IN;

out vec4 out_fragColor0;

void main()

   out_fragColor0 = texture2D(diffuseTexture, IN.texCoord0);


This is the basic flow I'm using when compiling a shader with the GL_ARB_get_program_binary extension:
1. Compile raw shader sources with glCompileShader
2. Setup all of my vertex attribute locations with glBindAttribLocation
3. Setup all of my fragment output locations with glBindFragDataLocation
5. Link the shader.
6. Retrieve the shader with glGetProgramBinary

Then I load the compiled shader with:
glProgramBinary and the same binary format as was provided during the compilation.

I do not receive any gl error messages when loading the binary programs from disc. I've even gone so far as to do the compilation, save to a memory buffer, and then load directly from the memory buffer as a test to rule out any file handling miscalculations.

One thing to note is that if I avoid the texture sample in the shader, I do not receive the error from glDrawElements (and the screen output is what I would expect). In other words, I change the last line of the fragment shader to:
out_fragColor0 = vec4(IN.texCoord0.x, IN.texCoord0.x, 0, 1);

This is what leads me to believe it is a sampler state issue.

I have enabled the functionality provided with the GL_AMD_debug_output extension to try to get some sort of clarification on the error. This is the information that the debug callback proc provides:

ID: 1000
Category: API
Severity: HIGH
Message: glDrawElements has generated an error (GL_INVALID_OPERATION)

(as a side note, not the most helpful error message...)

Addtionaly, I have ensured that I am meeting all of the requirements of the spec associated with that error. Namely, I'm not using geometry shaders and none of my buffer objects are currently mapped.

I would like to create a simple test program to provide to you, but it could take a bit of work to do so. I'm hoping that the ID provided by that callback would mean something to the driver developers and I could perhaps get a bit more context as to what the error is.

Thank you for any insight you might be able to provide.