[Piglit] [PATCH] tests/spec/arb_robustness/draw-vbo-bounds.c: add clipping

[Ian Romanick]

On 10/31/2012 03:53 AM, Jose Fonseca wrote:
>
>
> ----- Original Message -----
>> On 10/29/2012 05:34 PM, Roland Scheidegger wrote:
>>> Am 30.10.2012 00:22, schrieb Brian Paul:
>>>> On 10/29/2012 05:05 PM, sroland at vmware.com wrote:
>>>>> From: Roland Scheidegger<sroland at vmware.com>
>>>>>
>>>>> Make sure clipping is needed sometimes, and more often use small
>>>>> index
>>>>> counts,
>>>>> to expose issues and excercise more paths in mesa's draw module.
>>>>> ---
>>>>>     tests/spec/arb_robustness/draw-vbo-bounds.c |    4 ++--
>>>>>     1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/tests/spec/arb_robustness/draw-vbo-bounds.c
>>>>> b/tests/spec/arb_robustness/draw-vbo-bounds.c
>>>>> index 4351ac9..c780a3a 100644
>>>>> --- a/tests/spec/arb_robustness/draw-vbo-bounds.c
>>>>> +++ b/tests/spec/arb_robustness/draw-vbo-bounds.c
>>>>> @@ -95,7 +95,7 @@ random_vertices(GLsizei offset, GLsizei stride,
>>>>> GLsizei count)
>>>>>
>>>>>         for (i = 0; i<  count; ++i) {
>>>>>             GLfloat *vertex = (GLfloat *)(vertices + offset +
>>>>>             i*stride);
>>>>> -        vertex[0] = (rand() % 1000) * .001;
>>>>> +        vertex[0] = (rand() % 1000) * ((rand() % 1000) ? 0.001 :
>>>>> 1.0);
>>>>>             vertex[1] = (rand() % 1000) * .001;
>>>>>         }
>>>>>
>>>>> @@ -145,7 +145,7 @@ static void test(void)
>>>>>         vertex_count = 1 + rand() % 0xffff;
>>>>>
>>>>>         index_offset = (rand() % 0xff) * sizeof(GLushort);
>>>>> -    index_count = 1 + rand() % 0xffff;
>>>>> +    index_count = rand() % 10 ? 1 + rand() % 0xffff : 1 + rand()
>>>>> %
>>>>> 0x7ff;
>>>>>         min_index = rand() % vertex_count;
>>>>>         max_index = min_index + rand() % (vertex_count -
>>>>>         min_index);
>>>>>
>>>>
>>>> Randomness in tests can be OK, but in this case wouldn't you want
>>>> to
>>>> explicitly test some specific coordinates and indexes to make sure
>>>> the
>>>> corner cases are hit?
>>>>
>>>> -Brain
>>>
>>> Well I'm not sure it's worth the trouble note the test is run 1000
>>> times
>>> so probability is very very high that these cases are hit anyway.
>>
>> What happens when one of us gets a bug report that this test fails,
>> but we're unable to reproduce it?
>
>> If I had been paying attention, I
>> would
>> have already objected to the initial use of rand in this test...
>
> I'm not sure if the main objection here is rand itself, or random data at all.
>
> We could use some predictable pseudo number generator instead rand.

I think having:

1. A predictable sequence generator in piglit is a good idea.

2. Any test that uses it should have a way to specify a seed value.

3. Any test that uses it should log the seed value as part of its output.

Few things are more frustrating that not being able to reproduce a failure.

> But the purpose of this test was precisely to stress the driver by throwing random data.
>
> Note that it is not part of any test lists, never was, and does not need to be. I do understand the drawbacks of random data.

Ah.  I didn't realize that.  Still, tests should be reproducible.

> But on the other hand, one cannot honestly claim to have a robust driver without doing random tests. Hand written test cases will never be enough unless one commands the hands of an army of energetic monkeys.
>
> I think he appropriate would be to have a separate "stress" test list for this sort of tests.

Agreed.  And we should have more of them.

> If you don't want random tests on piglit tree at all then I'll happily move them elsewhere. I just thought that being an opengl test and piglit a gl test suite, it would be the right home for it. But it barely depends on piglit infrastructure, so really don't care much where the source is.
>
>
> Jose