Hi,
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();
}
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 where
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 frames
in 10000 frames when there's no load on the system to 1 lost in 5 frames
when there's load on the X server, e.g. by 'tail -f'ing the log file in
an xterm.
This does not happen with DirectFBGL where matroxfb's FBIO_WAITFORVSYNC
ioctl is used for synchronisation - although mga_driver_vblank_wait()
seems to do basically the same as matroxfb_wait_for_sync().
One interesting detail that strikes me: In the above code snippet count2
is always equal to (count1 + 1) so the DRM_WAIT_ON() in
mga_driver_vblank_wait() seems to be woken up always in time. That means
that there must be a later point in the program flow where the thread
sleeps or is being scheduled. However, I could not find such a point in
DRI or Mesa code.
I've been testing and reading code for almost a week now and have made
no progress; so now my last hope is that someone being familiar with the
code can give me some advice or hints.
FWIW, my test systems are:
(a) Debian testing box with a Matrox G550 [2].
(b) Debian unstable box with a Radeon r250 [3].
I haven't noticed any major difference between the two systems'
behaviour other than the mga being _way_ slower [4].
So please: If you have any suggestions where I could look or what I
could try to find the cause of these hangs - I'd be really grateful for
your ideas.
If there's any further information, config/log files or some example
code I could provide feel free to ask.
Thanks in advance,
Jan
PS: One more weird observation: When switching to [EMAIL PROTECTED] mode on my
mga box, glXGetMscRateOML() reports the frame rate to be correctly 75 Hz
but the glXWaitVideoSyncSGI() calls for consecutive frames return with a
rate of about 50 Hz ?!
[1] Example: The Draw time printed in the loop above varies around
1 ms but it is _never_ greater than 3 ms.
[2] CPU: AMD Duron 800 MHz
Graphics card: Matrox G550
Linux 2.6.16 with CONFIG_PREEMPT=y (Debian source)
X.org 7.0.22 (Debian packages)
Mesa: CVS checkout of the mesa_6_4_branch (few days old)
[3] CPU: Intel Pentium M 1.4 GHz
Graphics chipset: ATI Radeon r250 [Mobility FireGL 9000]
Linux 2.6.17 with CONFIG_PREEMPT_NONE=y (Debian image)
X.org 7.0.23 (Debian packages)
Mesa: CVS checkout of the mesa_6_4_branch (few days old)
[4] Time for drawing one glxgears frame at 800x600:
mga: 10.5 - 10.9 ms
r200: 0.24 - 0.35 ms
Btw: On DirectFBGL the mga took only 2.3 ms for a gears frame.
DirectFBGL uses some Mesa-embedded-2-branch derivate by Ville
Syrjälä from July 2004.
-------------------------------------------------------------------------
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
