[Piglit] [PATCH 2/2] EXT_texture_integer/api-drawpixels: Make this test for the GL 3.0 behavior.

[Eric Anholt]

See the giant comment in the test file for rationale.
---
 tests/spec/ext_texture_integer/api-drawpixels.c |   54 ++++++++++++++++++++++-
 1 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/tests/spec/ext_texture_integer/api-drawpixels.c b/tests/spec/ext_texture_integer/api-drawpixels.c
index adf311e..c5ba408 100644
--- a/tests/spec/ext_texture_integer/api-drawpixels.c
+++ b/tests/spec/ext_texture_integer/api-drawpixels.c
@@ -26,6 +26,34 @@
  * @file api-teximage.c
  *
  * Tests GL_EXT_texture_integer's error behavior with glTexImage2D().
+ *
+ * The GL_EXT_texture_integer spec doesn't specify how glDrawPixels
+ * with an integer format is supposed to work.  glDrawPixels generally
+ * generates fragments for a fragment shader with the gl_Color from
+ * the immediate data in the DrawPixels call.  However, with
+ * GL_EXT_texture_integer formats, the immediate data is now integer
+ * despite gl_Color being a floating-point vec4, and the spec for
+ * other cases of possible integer-versus-float conflicts resolves
+ * that the results are undefined.  It doesn't specify any particular
+ * conversion specific to drawpixels.
+ *
+ * In particular, in order for glDrawPixels of integer to be actually
+ * useful to a user, it needs to put integer values into the fragment
+ * shader without conversion, and there's no defined way to map the
+ * DrawPixels input to some user-defined (integer) fragment shader
+ * input.
+ *
+ * The GL 3.0 specification adds the following additional text in
+ * section 3.7.4 ("Rasterization of Pixel Rectangles) on page 151 of
+ * the GL 3.0 specification:
+ *
+ *     "If format contains integer components, as shown in
+ *      table 3.6, an INVALID OPERATION error is generated."
+ *
+ * The NVIDIA driver, which exposes both 3.0 and
+ * GL_EXT_texture_integer, follows this behavior.  Resolve that this
+ * behavior is a correction to the GL_EXT_texture_integer
+ * specification and check that impleentations follow that.
  */
 
 #include "piglit-util.h"
@@ -36,16 +64,38 @@ int piglit_window_mode = GLUT_RGB | GLUT_ALPHA | GLUT_DOUBLE;
 enum piglit_result
 piglit_display(void)
 {
-	static const float black[4] = {0, 0, 0, 0};
+	static const int black[4] = {0, 0, 0, 0};
 	static const float green[4] = {0, 1, 0, 0};
 	bool pass;
 
+	/* We don't have to do an integer FBO for this test, because
+	 * no error is specified in the non-integer FBO case:
+	 *
+	 *     "Results of rasterization are undefined if any of the
+	 *      selected draw buffers of the draw framebuffer have an
+	 *      integer format and no fragment shader is active.  "
+	 */
 	glClearColor(0.0, 1.0, 0.0, 0.0);
 	glClear(GL_COLOR_BUFFER_BIT);
 
+	glDrawPixels(1, 1, GL_RGBA_INTEGER_EXT, GL_UNSIGNED_INT, black);
+	piglit_check_gl_error(GL_INVALID_OPERATION, PIGLIT_FAIL);
+
+	/* The text in GL 3.0 specification banning
+	 * glDrawPixels(integer format) precedes the restriction from
+	 * GL_EXT_texture_integer which is still included in that
+	 * section:
+	 *
+	 *     "If format is one of the integer component formats as
+	 *      defined in table 3.6 and type is FLOAT, the error
+	 *      INVALID ENUM occurs."
+	 *
+	 * Based on this, we test for GL_INVALID_OPERATION even for FLOAT.
+	 */
 	glDrawPixels(1, 1, GL_RGBA_INTEGER_EXT, GL_FLOAT, black);
-	piglit_check_gl_error(GL_INVALID_ENUM, PIGLIT_FAIL);
+	piglit_check_gl_error(GL_INVALID_OPERATION, PIGLIT_FAIL);
 
+	/* Make sure that we really didn't render anything. */
 	pass = piglit_probe_rect_rgba(0, 0, piglit_width, piglit_height, green);
 
 	return pass ? PIGLIT_PASS : PIGLIT_FAIL;
-- 
1.7.7.3