On Mon, 2006-08-28 at 12:06 -0700, Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jan Gukelberger wrote:
>
> > I'm trying to port an application that presents visual stimuli for
> > experiments in neuroscience from DirectFBGL to X/DRI. A main requirement
> > 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.
> >
> > For this purpose I start a graphics thread with SCHED_FIFO scheduler
> > that does basically this:
> >
> > while( !Stopped() )
> > {
> > glXGetVideoSyncSGI( &count1 );
> > time1 = GetTime( CLOCK_REALTIME );
> > glXWaitVideoSyncSGI( 2, ( count1 + 1 ) % 2, &count2 );
> > time2 = GetTime( CLOCK_REALTIME );
> > glXGetVideoSyncSGI( &count3 );
> >
> > if( count3 != prevCount + 1 )
> > Print( "Lost %i frames.", count3 - prevCount - 1 );
> > Print( "Draw time: %f ms. Wait time: %f ms.",
> > time1 - prevTime, time2 - time1 );
> > prevCount = count3;
> > prevTime = time2;
> >
> > glFlush();
> > glXSwapBuffers( dpy, win );
> > DrawFrame();
> > }
>
> This is not the right way to do this. You want to use either
> GLX_MESA_swap_control, GLX_SGI_swap_control, or GLX_OML_sync_control.
> Each of these provides a way for the application to tell the driver the
> maximum buffer swap frequency.
>
> GLX_MESA_swap_control is the flavor supported by most of the open source
> drivers. To achieve the result you want, you'd call glXSwapIntervalMESA
> with a value of 1. For that extension, the default value is 0, which
> means the driver should swap as fast as it can.
Wow! This helped a _lot_!
On the matrox box I now get no lost frames at all when there is no
additional X load; frame intervals are very stable at 13.33 (+/-0.2) ms
with only about 1 in 1000 frames taking at most 6 ms more or less.
When generating load on X by 'tail -f -s 0.1'ing the log file (to which
one line is written for each frame) there remain about 1 in 100 frame
intervals which take more than 50% too long and 1 in 1000 calls to
glXSwapBuffers that hang for more than one VSYNC interval, i.e. the swap
interval is greater than 2*13.3 ms.
On the r200 system I do still get a lot of glXSwapBuffers calls that
take almost 2 VSYNC intervals, followed by a glXSwapBuffers call that
returns immediately compensating for the previous hang.
However, on this system I have yet to test if a PREEMPT kernel can
improve things.
Summary: Improvements by a magnitude.
I'm not sure if the remaining hangs on mga are possibly related to the
SOFTRAP interrupt issue mentioned by Ville Syrjälä?
The timing reliability is now close to usable but still not perfect.
Could somebody give me a clue why the change has such a big impact on
timing, provided glXWaitVideoSyncSGI and GLX_MESA_swap_control both rely
on drmWaitVBlank? Perhaps this could be a hint to the cause of the
remaining hangs?
Anyways, thank you VERY much, Ian.
Any further comments and suggestions would be very welcome.
Thanks,
Jan
PS: For reference, my new drawing thread loop now looks like:
while( !Stopped() )
{
DrawFrame();
glFlush();
glXGetVideoSyncSGI( &count1 );
time1 = GetTime( CLOCK_REALTIME );
glXSwapBuffers( dpy, win );
time2 = GetTime( CLOCK_REALTIME );
glXGetVideoSyncSGI( &count2 );
if( count2 != prevCount + 1 )
Print( "Lost %i frames.", count2 - prevCount - 1 );
Print( "Draw time: %f ms. Swap time: %f ms.",
time1 - prevTime, time2 - time1 );
prevCount = count2;
prevTime = time2;
}
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
