|08-15-04, 10:58 PM||#1|
Join Date: Jun 2003
delays calling glXGetVideoSyncSGI
I'm writing a program that needs to display data synchronized with the vertical retrace. My development
machine, a Dell Precision workstation 360, has a Quadro FX 500, and I'm using build 6106 of the
nvidia drivers, on a Red Hat supplied 2.6.7 kernel. The application is unusual: the video data is going
to some custom external hardware, instead of a monitor.
I originally tried using the glXWaitVideoSyncSGI () call, but that can sleep, and the underlying OS
latency when awakening is too long -- I'll get out of sync every so often, which produces unsightly
display artifacts. Then I tried using spinning in a loop, polling glXGetVideoSyncSGI. This works well,
and _never_ goes to sleep as far as I can tell; provided that the process is running with a sufficiently
high static (real time) priority. But, while a typical call to glXGetVideoSyncSGI might take, say, about
9 microseconds, I get the some calls that take about 1300 microseconds. I'm measuring all this using
the "rdtsc" instruction; the mystery delays are definitely happening inside glXGetVideoSyncSGI, and
there are no mystery delays elsewhere in my main loop. For that matter, I can go for thousands of
consecutive frames with no mystery delays, only to get thrown off by one of these 1.3msec things.
Is this a known issue? Are there better ways to sync (very tightly, and very robustly) to the vertical
retrace? Thanks for any help or ideas you can provide!
Adam Greenblatt ( agreenbl _at_ aol _dot_ com)
PS. I don't frequent these forums, emailing me directly is best. I'll gladly summarize my findings here.
|Thread||Thread Starter||Forum||Replies||Last Post|
|Huge GTX570 overstock delays GTX660 until August||News||Archived News Items||0||06-17-12 09:40 PM|
|Blizzard delays Diablo III real-money auctions indefinitely||News||Archived News Items||0||05-25-12 01:20 PM|