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
