Hi Ville,

On Sun, 2006-08-27 at 23:39 +0300, Ville Syrjälä wrote:
> On Sun, Aug 27, 2006 at 07:36:31PM +0200, Jan Gukelberger wrote:
> > 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.
> 
> I think I saw this same issue on my G400 some time ago. It seems to be 
> caused by the SOFTRAP interrupt misbehaving. For some reason the 
> interrupt only works when there's some accelerator activity. My plan was 
> to see enabling status data writeback (PRIMPTR) would fix it, but I got 
> sidetracked and forgot the whole issue.

Hmm, is there a way for me (not knowing what all this
SOFTRAP/PRIMPTR/fence stuff is all about) to test this? Is there some
place I can glean by what this interrupt is triggered and what it is
used for? 
What would break if I patched mga_irq.c to not enable MGA_SOFTRAP?

Note that I'm observing the same behaviour on radeon, is it possible
that this driver has similar issues?

Thanks for your time,
Jan


-------------------------------------------------------------------------
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

Reply via email to