[Bug 103355] [CI][SHARDS] igt at kms_cursor_legacy@cursor-vs-flip-* - fail - Failed assertion: shared[0] > vrefresh*target / 2

[bugzilla-daemon at freedesktop.org]

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

--- Comment #22 from anusha <anusha.srivatsa at intel.com> ---
(In reply to Arek Hiler from comment #21)
> (In reply to anusha from comment #20)
> > I dont think that will work. The test checks that a certain amount
> > (targeteted amount) of cursor updates happens between vblanks and that flip
> > do not affect vblank counter. The subtest already sets the targetted cursor
> > updates to a pretty low value, despite that the test fails.  We need to
> > understand -
> > 1. how the flips are affecting the vblanks
> > 2. why particularly in ICL we are not able to do that many number of cursor
> > updates. (that is assuming this test was passing on non ICL systems). I plan
> > on seeing the behaviour on my KBL system.
> > 
> > Also, just out of curiosity I did change the target value to see if at any
> > point the test passes. it doesnt. Regardless of how less we set the cursor
> > update, we fail to achieve that in the given interval.
> 
> Hey,
> 
> Just to be sure that I understand the test correctly:
> 1. we fork and do DRM_IOCTL_MODE_CURSOR in a "busy" loop
> 2. we wait for 30 flips (vrefresh/2, vrefresh=60)
> 3. we check how many MODE_CURSOR have succeeded
> 4. we compare the number of times we managed to call the IOCTL vs our
> target*30
> 
> Currently the "target" comes from get_cursor_updates_per_vblank() which from
> the number of MODE_CURSOR ioctl we manage to squeeze in between two vblanks
> divided by 8.
> 
> We have seen a lot of failures where the target was not hit, but still all
> of them managed to do about 1.5k cursor updates in that time, which means
> about 3kHz cursor update rate, which is plenty.
> 
> That would mean if we have over 500 updates in that 30 frame window (0.5s)
> we would hit the 1kHz requirement.
> 
> What am I missing in this reasoning?

Yes. that is how I have understood it too. In the D stepping that I am using,
we are  doing only about 1350 updates max. I tried to play around with reducing
the threshold just to see at what point the test passes and the lesser we
reduce the  threshold value to, the lesser updates we are doing. Which is very
weird....

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