John Wojnaroski wrote:

I will do that...

Your short discussion on timing brought to mind an interesting question.
Since there is some unpredictability to the scheduling algorithms and device
drivers and system calls, can the 60Hz rate really be "locked".

You are right, without taking additional measures, it's not really "locked". The best you can hope for is that if you have enough hardware, and you don't throw too much rendering load at it, you can stay within your time slice limit and draw at 60 hz. You can cheat and if you realize you can't quite do 60hz, you can artificially thottle to some even divisor of that ... i.e. 30hz, 20hz, 15hz, etc. so that you are pretty much guaranteed to be locked at that rate, but you can never erase all certainty.

A more sophisticated systems might be able to detect if you are having trouble sustaining 60hz and can perhaps tell if it's more of a fill rate problem or a geometry overload problem or some other problem, but you almost need a combination of hardware support, scene graph support, and application support to really do that well.

High end sgi's have features where they can lower the pixel resolution of the screen sort of transparently so that you have less fill work to do, and can thus raise the frame rate back up if you are fill rate limited, I believe this can be done automatically at the hardware level. The scene get's blurrier, but your frame rates stay "locked". The scene graph itself might be able to time your rendering phase and stop walking the scene graph when some time limit expires ... if you've sorted your geometry by priority, that might work well. At the application level you could tune texture usage, LOD, and other things to help make sure you hit your rendering speeds. I haven't dabbled much in these things though so I'm not an expert. There are probably other techniques or nuances that I'm not aware of. It's not an easy problem to deal with because performance bottlenecks can come at you from a lot of different direction, and you can't cleanly deal with it only in hardware, or only in the scene graph, or only in your application.

For us poor folks on commodity hardware, we have to live with whatever we can do in the scene graph and application level and make blind assumptions about what the hardware will be able to do in the upcoming time slice.

Short of going to a real-time OS like RTLinux, is this a case of where
getting close is good enough...

Personally, I think it all depends on how you define close, and how you define good enough. :-)

If you can limit your drop outs to one every 60 seconds, that seems pretty close to perfection, is it good enough? Probably for 99.9999% of applications. If you are doing multiple displays, the bigger the gap between the displays, the more discrepancy you can tolerate. If you are edge blending projected displays, you have to have *much* tighter tolerances.

If someone is piecing together some old hardware in their basement for fun and hobby, they might be perfectly happy with their side channels chunking along at 10-15fps, just because the added peripheral view gives them more than the jittery display takes away.

I've been thinking of moving over to RTLinux (there is an open-source GPL'd
version) in 2005. It fits nicely with the structure of the opengc display

RTLinux might give you some additional fine grained timing tools to throw at 
the problem, but it's still a hard problem.  You still have to detect a 
situation where you aren't going to finish drawing in time, reliably identify 
the reason you aren't finishing in time (fill rate? too much geometry?  texture 
thrashing?  running 3 other apps in the background on the machine?) and come up 
with some way to resolve the problem ... are you going to draw less geometry?  
Pull in the far clip plane, go to a lower LOD on some of your objects (which 
ones?)  Your solution needs to directly address the cause of the problem our 
your fix might not help you.  In practice you can probably find some trends and 
narrow the problem scope significantly, but it's still not easy.



Curtis Olson
HumanFIRST Program
FlightGear Project
Unique text:        2f585eeea02e2c79d7b1d8c4963bae2d

_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] 2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to