[Bug 106125] [CI] igt at gem_wait@wait-default - fail - Failed assertion: wait.timeout_ns > 0

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106125

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Martin Peres <martin.peres at free.fr> ---
(In reply to Chris Wilson from comment #5)
> Warning be silenced:
> 
> commit f772d9a910130b3aec8efa4f09ed723618fae656 (HEAD, upstream/master)
> Author: Chris Wilson <chris at chris-wilson.co.uk>
> Date:   Wed May 2 12:11:26 2018 +0100
> 
>     igt/gem_wait: Relax assertion for wait completion
>     
>     When waiting for a finite batch, all that we require is that the batch
>     completes. If it takes the full second (or longer) for us to wake up and
>     notice the completed batch is immaterial, so only assert that we don't
>     report an infinite timeout afterwards.
>     
>     Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>     Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> 
> We can still get a timer error if the spin_set_timeout() doesn't fire within
> 1s (target is 0.5s), but we no longer trigger a warning (as in this case)
> when we don't wake up within 1s (due to whatever scheduling latency) but
> have detected the completed batch (or we wouldn't wake up at all... except
> stray signals?)

That makes sense, thanks!

However, is this delay something we would like to reduce for our users? I know
that Linux is not an RTOS, but this 1s before realising a batch buffer has
executed sound terrible, especially since it is something mesa would need.

What's your take on this?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180522/f15205ae/attachment.html>