[Intel-gfx] Improvements and fixes for Intel ddx swap scheduling/timestamping.

[Mario Kleiner]

On 08.10.12 18:08, Eric Anholt wrote:
> Daniel Vetter <daniel at ffwll.ch> writes:
>
>> On Sun, Oct 07, 2012 at 08:38:07AM +0200, Mario Kleiner wrote:
>>> Hi,
>>>
>>> a series of three patches to improve the dri2 swap scheduling
>>> and timestamping for the current intel ddx.
>>>
>>> The first one enables proper OML_sync_control timestamping
>>> while triple-buffering is enabled and XOrg 1.12+ with DRI2SwapLimit
>>> support is in use. So far, timestamping was unuseable with
>>> triple-buffering, only worked with double-buffering.
>>>
>>> The second one repairs the broken pageflip swap scheduling, which
>>> is apparently in a frightening state for timing sensitive apps
>>> since a year, due to a tiny but really ugly bug. In a perfect
>>> implementation of Murphy's law, the same commit that broke the
>>> scheduling also disabled the builtin correctness checks that
>>> were supposed to catch such bugs.
>>>
>>> The third one proposes to revert 'SwapBuffersWait' to its old
>>> behaviour where it didn't affect pageflipping. I just can't
>>> think of a case where the current behaviour makes any sense, not
>>> even for benchmarking? But maybe i'm overlooking something.
>>>
>>> All patches were tested against an Intel 945-GME gpu.
>>>
>>> I don't really care about the 'SwapBuffersWait' patch one way
>>> or the other, but the first two are crucial to make the intel
>>> ddx useable in a painless and safe way again for users of
>>> timing sensitive applications.
>>
>> This kind of regressions suck. Are there no tests (in piglit) that check
>> OML buffer swap and timestamping behaviour at least internally? Or could I
>> volunteer you to create that? Toghether with the new kernel flip tests
>> this should catch any further such regressions ...
>
> I posted a first couple of tests that try to just hit the API for the
> most part, but I don't test the MSCs or wall-time timing behavior.
>

I will also have a look at piglit at one of the next weekends and see 
what i can do. I haven't tried piglit yet, but that would make sense if 
it can catch bugs before a driver release. My own toolkit has some 
builtin online tests for the bugs or limitations that are so far known, 
but that can only catch driver bugs after a broken driver is released. 
Here is what i currently test for, starting at the line in the link 
(paranoia at work):

<https://github.com/kleinerm/Psychtoolbox-3/blob/master/PsychSourceGL/Source/Linux/Screen/PsychWindowGlue.c#L1098>

-mario