On 08.10.12 18:08, Eric Anholt wrote:
Daniel Vetter <[email protected]> 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
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
