Re: Unreliable timing of glXWaitVideoSyncSGI

[Ville <sy...@sc...>]

On Sun, Aug 27, 2006 at 07:36:31PM +0200, Jan Gukelberger wrote:
> Hi,
>=20
> I'm trying to port an application that presents visual stimuli for
> experiments in neuroscience from DirectFBGL to X/DRI. A main requiremen=
t
> is reliable timing of the drawing code, i.e. on every VSYNC a new frame
> must be ready in the back buffer so that the buffers can be swapped.
>=20
> For this purpose I start a graphics thread with SCHED_FIFO scheduler
> that does basically this:
>=20
> while( !Stopped() )
> {
> 	glXGetVideoSyncSGI( &count1 );
> 	time1 =3D GetTime( CLOCK_REALTIME );
> 	glXWaitVideoSyncSGI( 2, ( count1 + 1 ) % 2, &count2 );
> 	time2 =3D GetTime( CLOCK_REALTIME );
> 	glXGetVideoSyncSGI( &count3 );
>=20
> 	if( count3 !=3D prevCount + 1 )=20
> 		Print( "Lost %i frames.", count3 - prevCount - 1 );
> 	Print( "Draw time: %f ms. Wait time: %f ms.",=20
> 		time1 - prevTime, time2 - time1 );
> 	prevCount =3D count3;
> 	prevTime =3D time2;
>=20
> 	glFlush();
> 	glXSwapBuffers( dpy, win );
> 	DrawFrame();
> }
>=20
> Now my problem is: While all the drawing and buffer swapping and
> printing works "quite deterministic" [1] the glXWaitVideoSyncSGI call
> seems to "hang" from time to time, i.e. there are some occurrences wher=
e
> it takes between 20 and 50 ms to return instead of the normal say 15-16
> ms (@60Hz).
> The number of these "hangs" increases drastically from a few lost frame=
s
> in 10000 frames when there's no load on the system to 1 lost in 5 frame=
s
> when there's load on the X server, e.g. by 'tail -f'ing the log file in
> an xterm.

I think I saw this same issue on my G400 some time ago. It seems to be=20
caused by the SOFTRAP interrupt misbehaving. For some reason the=20
interrupt only works when there's some accelerator activity. My plan was=20
to see enabling status data writeback (PRIMPTR) would fix it, but I got=20
sidetracked and forgot the whole issue.

--=20
Ville Syrj=E4l=E4
sy...@sc...
http://www.sci.fi/~syrjala/