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

Jose Fonseca jfonseca at vmware.com
Wed Oct 31 03:53:22 PDT 2012



----- 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.


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.

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.

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


More information about the Piglit mailing list