On Thu, Sep 15, 2016 at 06:25:13PM -0400, Robert Foss wrote:
> 
> 
> On 2016-09-15 04:32 PM, Chris Wilson wrote:
> >On Thu, Sep 15, 2016 at 02:40:11PM -0400, robert.f...@collabora.com wrote:
> >>From: Robert Foss <robert.f...@collabora.com>
> >>
> >>This subtest verifies that waiting on fences works properly.
> >>
> >>Signed-off-by: Robert Foss <robert.f...@collabora.com>
> >>Reviewed-by: Eric Engestrom <e...@engestrom.ch>
> >>---
> >> tests/sw_sync.c | 38 ++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 38 insertions(+)
> >>
> >>diff --git a/tests/sw_sync.c b/tests/sw_sync.c
> >>index fcb2f57..3061279 100644
> >>--- a/tests/sw_sync.c
> >>+++ b/tests/sw_sync.c
> >>@@ -81,6 +81,41 @@ static void test_alloc_merge_fence(void)
> >>    close(timeline[1]);
> >> }
> >>
> >>+static void test_sync_wait(void)
> >
> >These are not testing waits but busy queries.
> 
> test_sync_wait refers to sw_sync_wait, which may or may not be
> meaningful to refer to.
> Do you still prefer test_sync_busy?

Yes. Querying the busy status (i.e. !signaled) is a common activity, and
quite distinct to waiting.

> >Another test would be to then
> >
> >seqno = 0;
> >for (i = 0; i < n_primes; i++) {
> >     seqno += primes[i];
> >     sw_sync_timeline_inc(timeline, primes[i]);
> >     igt_assert_eq(sw_sync_timeline_get_seqno(timeline), seqno);
> >}
> >
> 
> This looks like a good addition, but primes has not previously been
> defined. Do you have preference for primes or would any increment,
> like random be ok?

random would be ok, but for fun I just added
igt_next_prime_number(x) and for_each_prime_number(prime, N). There are
advantages to using primes and advantages to using random(), and
advantages to using highly structured input.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to