5 Replies Latest reply on Mar 10, 2011 12:33 PM by HammerTime

    OpenGL Error when using ARB_get_program_binary and textures.


      '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
      4. Set the GL_PROGRAM_BINARY_RETRIEVABLE_HINT hint to true.
      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.