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

[Brian Paul]

On 12/01/2011 09:28 PM, Eric Anholt wrote:
> 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;


Reviewed-by: Brian Paul <brianp at vmware.com>