[Piglit] [PATCH v4] GL3.2 GL_ARB_sync: Test for valid return values from ClientWaitSync

[Ian Romanick]

On 10/28/2013 01:57 PM, Chad Versace wrote:
> On 10/21/2013 02:11 PM, Nicholas Mack wrote:
>> v2: Fix comments, initialize variables.  Still need to figure out if
>> GPU commands
>>      needed before testing these.
>>
>> v3: Rewrite test cases, fix comment and config block and add to all.tests
>>
>> v4: Make test work with POSIX_CLOCKS and some other minor changes
>> ---
>>   tests/all.tests                              |   1 +
>>   tests/spec/arb_sync/CMakeLists.gl.txt        |   1 +
>>   tests/spec/arb_sync/ClientWaitSync-returns.c | 183
>> +++++++++++++++++++++++++++
>>   3 files changed, 185 insertions(+)
>>   create mode 100644 tests/spec/arb_sync/ClientWaitSync-returns.c
> 
> 
> Ken, Eric, Ian, I want your opinion on this GL_ARB_sync testcase.
> 
> It sets up a simple draw call, does *not* call glFlush, inserts a fence
> with a one second timeout, waits for the fence to signal, then verifies
> that the elapsed time is approximately the timeout value.
> 
> The testcase's intent is to verify that fence's correctly timeout.

For this to work, the work implied by the draw call needs to be very
large.  You can't assume that the driver won't start immediately
executing commands as soon as you call glDrawArrays (or whatever).  To
do this, you'd need to figure out how long some work should take:

	glFinish();
	start = piglit_get_microseconds();
	draw_something();
	glFinish();
	end = piglit_get_microseconds();

	// We can guess that draw_something takes about (end - start).
	// Set the timeout to be less than that.
	timeout = (end - start) / 2;

Of course, you have to handle the case where timeout is epsilon (or
less!) and scale the amount of work done by draw_something() accordingly.

There are tests in... eh-hem... another test suite that have, in the
past, had similar issues. :(

> Of course, i965 fails this test because have a stupid implementation of
> glClientWaitSync. For glClientWaitSync, i965 flushes, waits for the
> batch to complete,
> then returns.
> 
> Test case #1 below currently reports PIGLIT_FAIL on i965.
> i965 conforms to a strict interpretation of the GL_ARB_sync, but I don't
> want to the test to simply pass. It really feels like i965 is cheating, so
> I want the test to report PIGLIT_WARN.
> 
> What's your opinion?
> 
> 
>> +    /* Test Case 1: Verify that fence times out correctly after set
>> time */
>> +
>> +    /* queue a draw command */
>> +    piglit_draw_rect(-1, -1, 2, 2);
>> +
>> +    /* create fence sync */
>> +    fence1 = glFenceSync(GL_SYNC_GPU_COMMANDS_COMPLETE, 0);
>> +
>> +    /* get initial time */
>> +    start = piglit_get_microseconds();
>> +    if (start == -1) piglit_report_result(PIGLIT_SKIP);
>> +
>> +    /* check fence status */
>> +    status1 = glClientWaitSync(fence1, GL_SYNC_FLUSH_COMMANDS_BIT,
>> +                    ONE_SECOND);
>> +
>> +    /* draw call should not be complete since glFlush() wasn't called */
>> +    if (status1 != GL_TIMEOUT_EXPIRED) {
>> +        printf("Expected: status1 == GL_TIMEOUT_EXPIRED\n"
>> +            "Actual: status1 == %s\n",
>> +            piglit_get_gl_enum_name(status1));
>> +        pass = false;
>> +    }
>> +
>> +    /* check time elapsed */
>> +    end = piglit_get_microseconds();
>> +    if (end == -1) piglit_report_result(PIGLIT_SKIP);
>> +    seconds_elapsed = (end - start) * .000001;
>> +    if (seconds_elapsed < 1) { //TODO: check if significantly longer
>> than 1 second
>> +        printf("Expected: Test Case 1 wait >= 1 second\n"
>> +            "Actual: Test Case 1 wait = %f seconds\n",
>> +            seconds_elapsed);
>> +        pass = false;
>> +    }
>> +
>> +    /* clean up */
>> +    glFlush();
>> +    glDeleteSync(fence1);