[Piglit] [PATCH] arb_clear_texture: add a trivial test

[Ilia Mirkin]

On Fri, Mar 7, 2014 at 2:38 PM, Eric Anholt <eric at anholt.net> wrote:
> Ilia Mirkin <imirkin at alum.mit.edu> writes:
>
>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>> ---
>>
>> This is my first foray into piglit test-writing. Let me know if I missed
>> anything (except for better tests -- I know that this is very limited).
>>
>> This mechanism of transferring the texture to the screen is pretty poor -- it
>> entirely defeats the point of ARB_clear_texture, which is to allow one to
>> clear even non-renderable-to textures. I guess I need to create a shader that
>> uses the texture? Is there an example of a test that does this?
>>
>> For all its simplicity, this allowed me to debug my impl of this extension on
>> nv50, which is now no longer completely broken.
>
>> +enum piglit_result
>> +piglit_display(void)
>> +{
>> +     const float clearColor[3] = { 0.0, 1.0, 0.0 };
>> +     GLuint fbo;
>> +     GLenum status;
>> +     bool pass = true;
>> +
>> +     /* Clear texture with glClearTexImage() */
>> +     glClearTexImage(texture, 0, GL_RGB, GL_FLOAT, clearColor);
>> +
>> +     glGenFramebuffers(1, &fbo);
>> +     glBindFramebuffer(GL_FRAMEBUFFER, fbo);
>> +     glFramebufferTexture(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, texture, 0);
>> +     status = glCheckFramebufferStatus(GL_FRAMEBUFFER);
>> +     if (status != GL_FRAMEBUFFER_COMPLETE) {
>> +             printf("Framebuffer Status: %s\n",
>> +                    piglit_get_gl_enum_name(status));
>> +             return PIGLIT_FAIL;
>> +     }
>> +
>> +     glBindFramebuffer(GL_DRAW_FRAMEBUFFER, piglit_winsys_fbo);
>> +     glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo);
>> +     glBlitFramebuffer(0, 0, piglit_width, piglit_height,
>> +                       0, 0, piglit_width, piglit_height,
>> +                       GL_COLOR_BUFFER_BIT, GL_NEAREST);
>> +
>> +     if (!piglit_check_gl_error(GL_NO_ERROR))
>> +             pass = false;
>
> Instead of making an FBO and using BlitFramebuffer, I'd just draw the
> texture to the screen using texture sampling.
> tests/spec/ext_unpack_subimage/ext_unpack_subimage.c has some very easy
> code to copy from for the shader and the draw call.
>
> I do really like that you're drawing to the screen.  It's important for
> people debugging drivers, and I wouldn't want to see it go away.

OK, so I assume that you hate the v2 that I sent, which instead uses
piglit_probe_texel_rect_rgb to probe the texture directly. I'll look
at the test that you suggested. This will have the advantage of being
able to test MS textures, which (from reading the docs),
piglit_probe_texel_rect_rgb wouldn't be able to do.

>
> Other than that, this is a nice simple test.  We're going to want an
> all-the-formats testcase before we land clear_texture in Mesa, but this
> is a good start.

Absolutely. And testing glClearTexSubImage too (where the visual
representation may become more interesting). And an api-errors style
test. And I want to test various widths/heights, in case e.g. POT
works but NPOT doesn't. I'm thinking that 32 and 33 actually cover
most cases.

Should I make these into subtests, or is it fine to just have the one
test? Long-term, should this 'simple' test go away entirely in favor
of a all-formats test that does it all?

Thanks,

  -ilia