On Fri, May 13, 2016 at 02:45:09PM +0300, Gabriel Feceoru wrote:
> basic-flip-vs-wf_vblank subtest sometimes fails asserting counted frames to
> be aproximately equal with the estimated number.
>
> This is a false negative, one of the reasons being the precision lost when
> truncating a fractional number.
>
> Fixed this by using floating point arithmetic.
>
> Cc: Jani Nikula <jani.nikula@xxxxxxxxx>
> Cc: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> Signed-off-by: Gabriel Feceoru <gabriel.feceoru@xxxxxxxxx>
> ---
> tests/kms_flip.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tests/kms_flip.c b/tests/kms_flip.c
> index eda2fcc..6ec97d0 100644
> --- a/tests/kms_flip.c
> +++ b/tests/kms_flip.c
> @@ -1182,13 +1182,13 @@ static void check_final_state(struct test_output *o, struct event_state *es,
> /* Verify we drop no frames, but only if it's not a TV encoder, since
> * those use some funny fake timings behind userspace's back. */
> if (o->flags & TEST_CHECK_TS && !analog_tv_connector(o)) {
> - int expected;
> + double expected;
> int count = es->count;
>
> count *= o->seq_step;
> - expected = elapsed / frame_time(o);
int expected = count * frame_time(o);
igt_assert_f(100 * expected >= elasped * 99 && 100 * count <= expected * 101,
"dropped frames, expected %d, counted %d, encoder type %d\n",
elapsed / frame_time(o), count, o->kencoder[0]->encoder_type);
if I understood your concern correctly, as the only loss of precison
there would be from calculating 'expected'.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
