[Mesa-dev] GL 3.0 glDrawPixels(integer format)

Eric Anholt eric at anholt.net
Sun Nov 27 18:08:02 PST 2011

While looking into MapRenderbuffer for glDrawPixels, I ended up
looking at integer again.  It looks like GL 3.0 has added sanity to
drawpixels for integer, which is to say that they've disallowed it.

I don't think there was any way to usefully use drawpixels of integer.
Assuming you want to output to an integer FBO, you have to have a
fragment shader bound.  You would also need to have the input to that
fragment shader be integer, or you're going to lose your precision.
But how does the glDrawPixels() input data get bound to some
user-defined shader input?

The fbo-integer-precision-drawpixels testcase currently binds a shader
that does gl_FragColor = gl_Color.  But if the output to an integer
FBO is written through a floating-point shader output, the result is
undefined (from GL_EXT_texture_integer):

   "The color components used for per-fragment operations and written into a
    color buffer are undefined:

      * for fragment shaders that write floating-point color components to an
        integer color buffer, or..."

What should we do with that testcase?  If pre-3.0
GL_EXT_texture_integer allows drawpixels for integer, what behavior
would we actually want for making use of the user's shader?  (I'm
assuming that testcase passed for whatever code it was supposed to
test because that code just no-opped the shader.  Imagine the shader
doing some actual math on the color instead.).  I'm inclined to adopt
3.0 behavior generally, and assume that the 3.0 wording was a
correction after someone noticed that making drawpixels for integer
actually work was hopeless.

More information about the mesa-dev mailing list