improved swap/MSC-wait scheduling in DPMS-off state

[Ilija Hadzic]

On Wed, May 1, 2013 at 1:40 AM, Michel Dänzer <michel at daenzer.net> wrote:

> On Die, 2013-04-30 at 22:50 -0400, Ilija Hadzic wrote:
> >
> >
> >
> > On Tue, Apr 30, 2013 at 12:01 PM, Michel Dänzer <michel at daenzer.net>
> > wrote:
> >         On Die, 2013-04-30 at 17:34 +0200, Michel Dänzer wrote:
> >         > On Die, 2013-04-30 at 10:31 -0400, Ilija Hadzic wrote:
> >         > > On Tue, Apr 30, 2013 at 5:16 AM, Michel Dänzer
> >         <michel at daenzer.net>
> >         > > wrote:
> >         > >         On Son, 2013-04-28 at 16:07 -0400, Ilija Hadzic
> >         wrote:
> >         > >         >
> >
> >         > >         > The end result is that regardless in which state
> >         the display
> >         > >         is, the
> >         > >         > application sees the events (time and sequence
> >         numbers) that
> >         > >         progress
> >         > >         > as if the CRTC is running and the events happen
> >         at right
> >         > >         time points
> >         > >         > on the grid determined by the vlbanks (real or
> >         > >         interpolated).
> >         > >
> >         > >
> >         > >         Indeed, looks like DPMS off no longer has any
> >         effect on piglit
> >         > >         results. :) Thanks for working on this.
> >         > >
> >         > >
> >         > >
> >         > > Forgive me if this question is going to make me look dumb,
> >         but given
> >         > > that piglit is a rendering test suite, the behavior you
> >         are seeing is
> >         > > expected. In other words, you are not implying that
> >         something is
> >         > > wrong, are you?
> >         >
> >         > Indeed, I'm not. piglit has a few GLX tests, some of which
> >         could
> >         > previously fail when the monitor was in DPMS off state. Your
> >         series
> >         > fixes that.
> >
> >
> >         Hmm, now I've seen some issues with some
> >         glx/GLX_OML_sync_control/ tests
> >         again even with your patches. Maybe the CRTC went off while
> >         those tests
> >         were running, and that isn't handled quite correctly yet. Can
> >         you look
> >         into that?
> >
> >
> >
> >
> >
> > Is this the kind of error you are seeing?
> >
> >         "glx/GLX_OML_sync_control/waitformsc": {
> >                 "info": "Returncode: 0\n\nErrors:\nglXWaitForMscOML()
> > returned msc of 184744, expected >= 216181\n\n\nOutput:\n",
> >                 "errors": [
> >                     "glXWaitForMscOML() returned msc of 184744,
> > expected >= 216181"
> >                 ],
> >                 "returncode": 0,
> >                 "command":
> >
> "/home/ihadzic/git_sandbox/piglit/framework/../bin/glx-oml-sync-control-waitformsc
> -auto -fbo",
> >                 "result": "warn",
> >                 "time": 0.11738109588623047
> >             },
>
> Yes, though another test was giving a fail for me, not just a warn.
>
>
I left it running overnight repeating only tests that have to do with
synchronization.
I see three types of failures.  In one 'glx-oml-sync-control-waitformsc
-auto -fbo'
fails with some random difference between actual and expected MSC. In
another
the same test fails with off-by-1 MSC (these could be two different causes)
and these
tests are not consistently reproducible (one on 10-20 fails). In the third
test
'glx-oml-sync-control-swapbuffersmsc-return -auto -fbo' fails with SBC off
by some
large value and it's consistently reproducible.

If you are seeing any other error pattern that does not fit the description
above,
please let me know. So far, these three are what I can reproduce and start
debugging.

-- Ilija

--
> Earthling Michel Dänzer           |                   http://www.amd.com
> Libre software enthusiast         |          Debian, X and DRI developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-driver-ati/attachments/20130501/051917e0/attachment-0001.html>