On Wed, Jul 04, 2018 at 01:38:23PM +0100, Chris Wilson wrote:
> If we allow 5s (+20% systematic error) to construct the fences, we may
> reasonably assume that it will take equally as long to consume them. As
> we only have 10s before the vgem fence times out, there is no margin of
> safety.
>
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> ---
> tests/amdgpu/amd_prime.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/amdgpu/amd_prime.c b/tests/amdgpu/amd_prime.c
> index bb68ccf31..6c64c3af9 100644
> --- a/tests/amdgpu/amd_prime.c
> +++ b/tests/amdgpu/amd_prime.c
> @@ -348,7 +348,7 @@ static void amd_to_i915(int i915, int amd, amdgpu_device_handle device)
> count = 0;
> size = 64 << 10;
> contexts = malloc(size * sizeof(*contexts));
> - igt_until_timeout(5) {
> + igt_until_timeout(2) {
Might be good to put a "need to beat the vgem timeout of 10s" or similar
comment here. Even fancier would be a bit of igt library to create vgem
plugs and later on in the could put an igt_assert_still_plugged() to make
sure we've hit the race fully. Would also be some piece of really nice
self-documenting code.
Either way: Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> if (count == size) {
> size *= 2;
> contexts = realloc(contexts, size * sizeof(*contexts));
> --
> 2.18.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
