Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Hi All, what about that one: Instead of stamping the current time timestamp a second time past the sleep, we could just add the desired time we intended to wait to that timestamp. This way the current loop might start a bit too late, but the sleep time of the next step will be that amount shorter we have sleped too long in this step. We cannot really control when the current steps frame gets ready (we cannot either because we do not know when computations/rendering will have finished), but we can have a much more constant framerate this way. Can somebody test? Maybe apply? Greetings Mathias On Mittwoch 09 März 2005 16:51, Curtis L. Olson wrote: > Time out here! > > There are two reasons two throttle frame rate. > > 1. Conserve CPU time and leave more cpu time for other tasks. Using > sleep() calls you can put FG asleep for a short time if it gets done > drawing a frame early, leaving those cycles for other tasks. > > 2. Accurately control frame rate. Here you want to run at a fixed > precise frame rate to achieve smooth, jitter free rendering. For > instance, if you can't quite sustain 60hz consistanty, you might want to > throttle back to 30hz. > > The problem is that this new patch throws away the second reason in > favor of the first. When I throttle to 20hz, I get 19hz. When I > throttle to 30hz I get, ohh ... 28 or 29 depending. Putting the > application to sleep does terrible things to timing accuracy, because > typically the application can only wake up during a kernel trap, and if > you miss the vertical refresh by even 1 millesecond, you drop a frame > and get animation jitters. > > Maybe we need to figure out how to satisfy both needs, but we can't just > blindly dispense with reason #2 when a new need comes along. > > Maybe we need separate options, such as > --cpu-friendly-inaccurate-throttle-with-sleep-hz= and > --frame-rate-accurate-throttle= > > Thoughts? I think we need to tread a bit more carefully on this one, > especially since I have a side project that employs this option (well, > used to employ this option) :-( to achieve accurate frame rate timing > and smooth animation. > > Curt. > > Erik Hofman wrote: > >Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main > >In directory baron:/tmp/cvs-serv28989 > > > >Modified Files: > > main.cxx > >Log Message: > >Frederic Bouvier: > > > >Norman Vine wrote : > >>Frederic Bouvier writes: > >>>Quoting Andy Ross: > * Hopefully in a CPU-friendly way. I know that older versions of > the NVidia drivers did this by spinning in a polling loop > inside the driver. I'm not sure if this has been fixed or not. > > >From my experience, the latest non-beta Windows NVidia driver seems to > > eat CPU > >>> > >>>even with sync to vblank enabled. The CPU usage is always 100%. > >> > >>Buried in the PPE sources is a 'hackish' but portable way to limit CPU > >> usage if the desired framerate is met > >> > >> /* > >> Frame Rate Limiter. > >> > >> This prevents any one 3D window from updating faster than > >> about 60Hz. This saves a ton of CPU time on fast machines. > >> > >> ! I THINK I MUNGED THE VALUE FOR ulMilliSecondSleep() NHV ! > >> */ > >> > >> static ulClock *ck = NULL ; > >> > >> if ( frame_rate_limiter ) > >> { > >>if ( ck == NULL ) > >>{ > >> ck = new ulClock ; > >> ck -> update () ; > >>} > >> > >>int t_ms = (int) ( ck->getDeltaTime() * 1000.0 ) ; /* Convert to ms > >> */ > >> > >>if ( t_ms < 16 ) > >> ulMilliSecondSleep ( 16 - t_ms ) ; > >> } > > > >I implemented the method pointed out by Norman. It works great on windows > > and saves me a lot of CPU cycles. This way, I can get the same framerate > > in moderately populated areas and have CPU idle 50% of the time instead > > of wildly looping in the NVidia driver while waiting to sync on vblank. > > > >It has been tested on Linux by Melchior. He saw the same gain in CPU > > cycles. > > > > > >Index: main.cxx > >=== > >RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v > >retrieving revision 1.193 > >retrieving revision 1.194 > >diff -C2 -r1.193 -r1.194 > >*** main.cxx 5 Jan 2005 05:45:38 - 1.193 > >--- main.cxx 9 Mar 2005 15:12:01 - 1.194 > >*** > >*** 223,226 > >--- 223,228 > > SGCloudLayer::enable_bump_mapping = > > fgGetBool("/sim/rendering/bump-mapping"); > > > >+ bool scenery_loaded = fgGetBool("sim/sceneryloaded") || > > fgGetBool("sim/sceneryloaded-override"); + > > // Update the elapsed time. > > static bool first_time = true; > >*** > >*** 231,241 > > > > double throttle_hz = fgGetDouble("/sim/frame-rate-throttle-hz", > > 0.0); ! if ( throttle_hz > 0.0 ) { > > // simple frame rate throttle > >! double dt = 100.0 / throttle_hz; > > current_time_stamp.stamp(); > >! while ( current_time
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
X-Plane opens in a 1024x768 borderless window, which doesn't fill my laptop display at 1400x1050. However, when I reduce and restore windows, I can tell that the X-Plane process preempts the windows processes because the windows open slowly. X-Plane still yields some time to the windows, though, unlike what happens if I increase the priority of FlightGear. BTW, this patch with the Sleep calls still doesn't seem to be working for me...when I increase flightgear's priority it still completely takes over the system. Is there another thread that might be doing this? Drew On Wed, 09 Mar 2005 13:53:36 -0600, Curtis L. Olson <[EMAIL PROTECTED]> wrote: > Drew wrote: > > >I don't know the answer to this. My computer has 512 megs, which is a > >lot more than FlightGear uses. > > > >I'm not really interested in how other 3D apps, including games, > >work...I have a specific application, and I want to optimize the code > >for this purpose, regardless of what the status quo is. FWIW, I've > >tried an interface with x-plane, and it doesn't have the same problem. > > Too bad it isn't open-source. > > > > > > Doesn't X-Plane run full screen, or does it now support running in a > window. If you are running x-plane full screen you are probably > comparing apples to oranges here. > > Regards, > > Curt. > > -- > Curtis Olsonhttp://www.flightgear.org/~curt > HumanFIRST Program http://www.humanfirst.umn.edu/ > FlightGear Project http://www.flightgear.org > Unique text:2f585eeea02e2c79d7b1d8c4963bae2d > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
> It seems to me that you have gone backwards: you picked a favorite > "fix" before knowing what the problem is. The bottom line is that > performance analysis is really complicated. You can't cook it down to > a single number like CPU usage (or "load" -- a equally flawed Unix > favorite) if you really want to fix a problem. Hey Andy, I know for a fact that FlightGear uses every available processor cycle. I also know that if I increase the priority of FlightGear, it takes cycles away from other processes. In my application, I need FlightGear to run at 640x480 res at 30 Hz (the output is a TV), but I've seen FlightGear run well at 1400x1050 and 60 Hz. Therefore, I *know* FlightGear is using much more CPU cycles than it needs, and I know that if there's a way to free up these extra cycles, I can run FlightGear at a higher priority without interrupting other processes. Does this not seem like a rational train of thought? I admit, I'm new to this type of performance optimization. What do *you* think the problem is? Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Curtis L. Olson wrote : Frederic, I've been hacking on your patch a bit more and I see that we rarely oversleep by more than 2ms. So backing off by 2ms (instead of 1ms) seems to work pretty well here. I also switched to doing all the math in microseconds rather than milleseconds (and converting at the latest possible moment) in hopes that it would be slighty more accurate. This is only tested on the 2.6.x kernels. I suspsect that usleep() will be much less accurate on 2.4.x kernels. I don't know if anyone else is using the frame rate throttling feature so it may not matter? Do you want to check it that way or do you want separated behavior : exact framerate vs CPU friendly ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: > I'm not really interested in how other 3D apps, including games, > work...I have a specific application, and I want to optimize the > code for this purpose, regardless of what the status quo is. And the proper way to do that optimization is to figure out what the actual symptom is. Which requires testing a hypothesis ("is it due to CPU usage?") by changing one parameter ("open a window" vs. "run a looping perl script") at a time in order to isolate the symptom ("complicated window system interaction" vs. "pure CPU usage"). It seems to me that you have gone backwards: you picked a favorite "fix" before knowing what the problem is. The bottom line is that performance analysis is really complicated. You can't cook it down to a single number like CPU usage (or "load" -- a equally flawed Unix favorite) if you really want to fix a problem. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Frederic, I've been hacking on your patch a bit more and I see that we rarely oversleep by more than 2ms. So backing off by 2ms (instead of 1ms) seems to work pretty well here. I also switched to doing all the math in microseconds rather than milleseconds (and converting at the latest possible moment) in hopes that it would be slighty more accurate. This is only tested on the 2.6.x kernels. I suspsect that usleep() will be much less accurate on 2.4.x kernels. I don't know if anyone else is using the frame rate throttling feature so it may not matter? Regards, Curt. Frederic Bouvier wrote: I wrote: Maybe it is doable to sleep for a millisecond less than computed and achieve the targeted framerate with the loop. Could you try this patch : cvs -z4 -q diff -u main.cxx (in directory I:\FlightGear\cvs\FlightGear\src\Main\) Index: main.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v retrieving revision 1.194 diff -u -r1.194 main.cxx --- main.cxx9 Mar 2005 15:12:01 - 1.194 +++ main.cxx9 Mar 2005 16:53:34 - @@ -233,12 +233,11 @@ double throttle_hz = fgGetDouble("/sim/frame-rate-throttle-hz", 0.0); if ( throttle_hz > 0.0 && scenery_loaded ) { -static double remainder = 0.0; - // simple frame rate throttle -double dt = 100.0 / throttle_hz + remainder; +double dt = 100.0 / throttle_hz; int wait = dt / 1000; -remainder = dt - ( wait * 1000.0 ); +if ( wait > 0 ) +wait -= 1; current_time_stamp.stamp(); int t_ms = (int) ( ( current_time_stamp - last_time_stamp ) / 1000 ) ; /* Convert to ms */ @@ -246,6 +245,9 @@ ulMilliSecondSleep ( wait - t_ms ) ; } current_time_stamp.stamp(); +while ( current_time_stamp - last_time_stamp < dt ) { +current_time_stamp.stamp(); +} } else { // run as fast as the app will go current_time_stamp.stamp(); ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: I don't know the answer to this. My computer has 512 megs, which is a lot more than FlightGear uses. I'm not really interested in how other 3D apps, including games, work...I have a specific application, and I want to optimize the code for this purpose, regardless of what the status quo is. FWIW, I've tried an interface with x-plane, and it doesn't have the same problem. Too bad it isn't open-source. Doesn't X-Plane run full screen, or does it now support running in a window. If you are running x-plane full screen you are probably comparing apples to oranges here. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
> I don't wonder, though, if that isn't due to locking inside GDI (or VM > swap -- how much memory do you have?) and not CPU usage. Applications > doing 3D rendering don't coexist well with things that need to draw to > the screen. > > Can you try something "purely" CPU intensive (like a perl script that > counts to a few million) and see if you can notice the same behavior? > My guess is that tuning FlightGear's CPU usage isn't going to get us > much. > > Conversely, can you compare FlightGear to other "spin on the cpu" 3D > applications like games? Do they exhibit the same issues? I don't know the answer to this. My computer has 512 megs, which is a lot more than FlightGear uses. I'm not really interested in how other 3D apps, including games, work...I have a specific application, and I want to optimize the code for this purpose, regardless of what the status quo is. FWIW, I've tried an interface with x-plane, and it doesn't have the same problem. Too bad it isn't open-source. Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: > The program runs great, it's just that FlightGear gets interrupted > easily by other programs, and is jumpy in my particular application. > If you open and close a window, you can see how FlightGear freezes > momentarily. I don't wonder, though, if that isn't due to locking inside GDI (or VM swap -- how much memory do you have?) and not CPU usage. Applications doing 3D rendering don't coexist well with things that need to draw to the screen. Can you try something "purely" CPU intensive (like a perl script that counts to a few million) and see if you can notice the same behavior? My guess is that tuning FlightGear's CPU usage isn't going to get us much. Conversely, can you compare FlightGear to other "spin on the cpu" 3D applications like games? Do they exhibit the same issues? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Thanks for the quick response. > I have a specific application that requires better timing than sleep() > can provide, so I need the original busy-wait solution or something very > close to it. I don't mind adding a sleep() based throttling mechanism > as well, but people who use it need to realize it's limitations. I understand that. I'm not looking to change the FlightGear baseline...just a solution that does what I need. How precise is the timing of the naitive-gui ? If I have my simulation use a blocking socket to receive messages, this can provide the interrupt to schedule my simulation. The only problem there would be that if a packet is dropped, the simulation will miss a frame (unlikely if they're on the same PC). Does native-gui run in its own thread, or is it limited to FlightGear's frame rate? I'm just brainstorming here...I still don't know what my ideal solution is. Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: I don't think anyone suggested there was a bug...I'm just trying to improve performance. I'm writing a simulator that interfaces with FlightGear, using FlightGear as the scenery generator on the same PC. The program runs great, it's just that FlightGear gets interrupted easily by other programs, and is jumpy in my particular application. If you open and close a window, you can see how FlightGear freezes momentarily. Hi Drew, Typically, operating systems run their windows manager and user interface stuff at a high priority (which makes the operating system seem snappy and responsive.) So opening/closing windows, resizing them, moving them, etc. will kill performance of anything else you are running. That's usually ok and you never notice it if all you are doing is running email and web browsing and word processing type apps, but it's a killer if you are expecting to sustain performance of a real time 3d application at the same time. What I want to do is bump up the priority of FlightGear so that it is more robust. The problem I'm having is that once I do, everything else comes to a screeching halt. Therefore, I want FlightGear to be more conservative with its processor usage, so I can increase its priority without adversely affecting other processes. The proposed sleep() based frame rate throttling patch may help with that because it puts FG to sleep every frame (which should automatically yield the CPU to anything else in the run queue.) However, the proposed patch also messes up the consistancy of frame rates because the way sleep() is implimented, you can't actually sleep() for the exact time you want. You never sleep less than the requested amount but you often/usually sleep somewhat longer than the requested time. So if you are trying to eliminate frame rate jitter, this is not going to help you reach a perfect solution (but it may improve things under certain circumstances for certain people.) I don't understand what you mean about 'using them or let them go to waste'. If it takes FlightGear 10 ms to execute a frame, and I only need a frame time of 33 ms, what gain is there in FlightGear hijacking those other 23 ms, even if it is just idle time? Just because it's taking those cycles doesn't mean it's using them productively. The issue is that FG needs to hijack these CPU cycles to do precise timing and to know when to move on to work on the next frame. If you don't mind dropping frames right and left, a sleep() based solution will free up those cpu cycles for other apps to use, but you may sacrifice consistancy of frame rate (or at least you will never be able to achieve perfectly consistant frame rates.) I have a specific application that requires better timing than sleep() can provide, so I need the original busy-wait solution or something very close to it. I don't mind adding a sleep() based throttling mechanism as well, but people who use it need to realize it's limitations. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
> Wait, that's not a bug report about processing time available for > other proceses at all. That's a bug report about the total CPU usage > being at 99%, which is irrelevant. If the CPU is available, then of > course FlightGear should use it all; you can't save up cycles -- > either use them now or let them go to waste. I don't think anyone suggested there was a bug...I'm just trying to improve performance. I'm writing a simulator that interfaces with FlightGear, using FlightGear as the scenery generator on the same PC. The program runs great, it's just that FlightGear gets interrupted easily by other programs, and is jumpy in my particular application. If you open and close a window, you can see how FlightGear freezes momentarily. What I want to do is bump up the priority of FlightGear so that it is more robust. The problem I'm having is that once I do, everything else comes to a screeching halt. Therefore, I want FlightGear to be more conservative with its processor usage, so I can increase its priority without adversely affecting other processes. I don't understand what you mean about 'using them or let them go to waste'. If it takes FlightGear 10 ms to execute a frame, and I only need a frame time of 33 ms, what gain is there in FlightGear hijacking those other 23 ms, even if it is just idle time? Just because it's taking those cycles doesn't mean it's using them productively. Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
I asked: > What is the application that needs extra CPU, and are we sure that > it's not being performance limited in some other way? Aha! Drew wrote: > In Windows, adding this code did absolutely nothing to the > processing time...it remains at 99% usage whether I throttle back to > 60, 30, or 1 Hz. [...] Once iit was compiled in 'debug' mode, the > throttle_frame_rate actually yielded some processing ttime for other > processes. It runs better, but still not ideal. Wait, that's not a bug report about processing time available for other proceses at all. That's a bug report about the total CPU usage being at 99%, which is irrelevant. If the CPU is available, then of course FlightGear should use it all; you can't save up cycles -- either use them now or let them go to waste. Which app are you running that is going too slow, and how much CPU do you think it needs? Those are the important questions. Your OS (yes, even windows) has an elaborate scheduler which is designed to make sure that all processes get the CPU they need to do their job. Sometimes you need to tweak things, but those circumstances are rare. I strongly suspect we're chasing a ghost on this one. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Curtis L. Olson wrote: > Maybe we need separate options, such as > --cpu-friendly-inaccurate-throttle-with-sleep-hz= and > --frame-rate-accurate-throttle= > > Thoughts? I think we need to tread a bit more carefully on this one, > especially since I have a side project that employs this option (well, > used to employ this option) :-( to achieve accurate frame rate timing > and smooth animation. What was the original bug report? Currently, FlightGear will look CPU-limited to the OS, which means that short running or I/O bound processes will get priority anyway. What is the application that needs extra CPU, and are we sure that it's not being performance limited in some other way? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Curtis L. Olson wrote: Frederic, Your patch helps, but typically the semantics of sleep() commands is they will sleep at least as long as the requested time (up to the kernel trap timing resolution) so I am still seeing dropped frames, although not nearly as bad. If the kernel timing resolution is different than the monitor refresh resolution with no convenient multiples (i.e. 60hz vs 100hz), it's always going to be imperfect. Here is some additional data. I note the requested sleep time, then measure the actual sleep time. If the sleep time is greater thanTimes are in milleseconds ... requested = 5 actual = 6.898 requested = 6 actual = 7.998 requested = 6 actual = 7.269 requested = 5 actual = 6.358 requested = 2 actual = 3.230 requested = 7 actual = 8.972 So it looks like at least on the linux kernel-2.6.x you can get pretty fine sleep resolution, but it's always a few milleseconds more than you asked for. Usually the sleep overshoot is 1,2, or even 3 milleseconds, but I did some tracking and saw it as high as 17 milleseconds on occasion. Backing off and sleeping 1 ms less than the target helped, but you'd probably have to back off 2-3 for more consistant results, and at least 17ms for perfect results. I don't think is possible to do accurate millesecond timing with a sleep command on consumer operating systems. You can get close, but not close enough, because if you drop even one frame a second, your eye can spot it and notice the animation jitter. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Sorry to borrow this thread for my own purpose, but I'm trying to achieve goal 1 with as little impact on goal 2 as possible. I tried this patch with mixed results. In Windows, adding this code did absolutely nothing to the processing time...it remains at 99% usage whether I throttle back to 60, 30, or 1 Hz. However, in an effort to debug this problem, I switched the compiler flags (VisualStudio) from 'release' to 'debug' mode. Once iit was compiled in 'debug' mode, the throttle_frame_rate actually yielded some processing ttime for other processes. It runs better, but still not ideal. Anyway, does anyone have any hypotheses as to what's causing this difference? BTW, I was going to suggest having a 'cumulative' target time that gaurantees an average frame time rather than a minimum frame time, but it appears Fredric beat me to the punch. :) Drew On Wed, 09 Mar 2005 09:51:47 -0600, Curtis L. Olson <[EMAIL PROTECTED]> wrote: > Time out here! > > There are two reasons two throttle frame rate. > > 1. Conserve CPU time and leave more cpu time for other tasks. Using > sleep() calls you can put FG asleep for a short time if it gets done > drawing a frame early, leaving those cycles for other tasks. > > 2. Accurately control frame rate. Here you want to run at a fixed > precise frame rate to achieve smooth, jitter free rendering. For > instance, if you can't quite sustain 60hz consistanty, you might want to > throttle back to 30hz. > > The problem is that this new patch throws away the second reason in > favor of the first. When I throttle to 20hz, I get 19hz. When I > throttle to 30hz I get, ohh ... 28 or 29 depending. Putting the > application to sleep does terrible things to timing accuracy, because > typically the application can only wake up during a kernel trap, and if > you miss the vertical refresh by even 1 millesecond, you drop a frame > and get animation jitters. > > Maybe we need to figure out how to satisfy both needs, but we can't just > blindly dispense with reason #2 when a new need comes along. > > Maybe we need separate options, such as > --cpu-friendly-inaccurate-throttle-with-sleep-hz= and > --frame-rate-accurate-throttle= > > Thoughts? I think we need to tread a bit more carefully on this one, > especially since I have a side project that employs this option (well, > used to employ this option) :-( to achieve accurate frame rate timing > and smooth animation. > > Curt. > > Erik Hofman wrote: > > >Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main > >In directory baron:/tmp/cvs-serv28989 > > > >Modified Files: > > main.cxx > >Log Message: > >Frederic Bouvier: > > > >Norman Vine wrote : > > > > > > > >>Frederic Bouvier writes: > >> > >> > >> > >>>Quoting Andy Ross: > >>> > >>> > * Hopefully in a CPU-friendly way. I know that older versions of > the NVidia drivers did this by spinning in a polling loop > inside the driver. I'm not sure if this has been fixed or not. > > From my experience, the latest non-beta Windows NVidia driver seems to > eat CPU > > > >>>even with sync to vblank enabled. The CPU usage is always 100%. > >>> > >>> > >>Buried in the PPE sources is a 'hackish' but portable way to limit CPU > >>usage if the desired framerate is met > >> > >> /* > >> Frame Rate Limiter. > >> > >> This prevents any one 3D window from updating faster than > >> about 60Hz. This saves a ton of CPU time on fast machines. > >> > >> ! I THINK I MUNGED THE VALUE FOR ulMilliSecondSleep() NHV ! > >> */ > >> > >> static ulClock *ck = NULL ; > >> > >> if ( frame_rate_limiter ) > >> { > >>if ( ck == NULL ) > >>{ > >> ck = new ulClock ; > >> ck -> update () ; > >>} > >> > >>int t_ms = (int) ( ck->getDeltaTime() * 1000.0 ) ; /* Convert to ms */ > >> > >>if ( t_ms < 16 ) > >> ulMilliSecondSleep ( 16 - t_ms ) ; > >> } > >> > >> > >> > >> > > > >I implemented the method pointed out by Norman. It works great on windows > >and saves me a lot of CPU cycles. This way, I can get the same framerate in > >moderately populated areas and have CPU idle 50% of the time instead of > >wildly looping in the NVidia driver while waiting to sync on vblank. > > > >It has been tested on Linux by Melchior. He saw the same gain in CPU cycles. > > > > > >Index: main.cxx > >=== > >RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v > >retrieving revision 1.193 > >retrieving revision 1.194 > >diff -C2 -r1.193 -r1.194 > >*** main.cxx 5 Jan 2005 05:45:38 - 1.193 > >--- main.cxx 9 Mar 2005 15:12:01 - 1.194 > >*** > >*** 223,226 > >--- 223,228 > > SGCloudLayer::enable_bump_mapping = > > fgGetBool("/sim/rendering/bump-mapping"); > > > >+ bool scenery_loaded = fgGetBool("sim/sceneryloaded") || > >fgGetBool("sim/sceneryloaded-override"); > >+ > > // Update the elapsed time. > > stati
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Frederic, Your patch helps, but typically the semantics of sleep() commands is they will sleep at least as long as the requested time (up to the kernel trap timing resolution) so I am still seeing dropped frames, although not nearly as bad. If the kernel timing resolution is different than the monitor refresh resolution with no convenient multiples (i.e. 60hz vs 100hz), it's always going to be imperfect. Regards, Curt. Frederic Bouvier wrote: Could you try this patch : cvs -z4 -q diff -u main.cxx (in directory I:\FlightGear\cvs\FlightGear\src\Main\) Index: main.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v retrieving revision 1.194 diff -u -r1.194 main.cxx --- main.cxx9 Mar 2005 15:12:01 - 1.194 +++ main.cxx9 Mar 2005 16:53:34 - @@ -233,12 +233,11 @@ double throttle_hz = fgGetDouble("/sim/frame-rate-throttle-hz", 0.0); if ( throttle_hz > 0.0 && scenery_loaded ) { -static double remainder = 0.0; - // simple frame rate throttle -double dt = 100.0 / throttle_hz + remainder; +double dt = 100.0 / throttle_hz; int wait = dt / 1000; -remainder = dt - ( wait * 1000.0 ); +if ( wait > 0 ) +wait -= 1; current_time_stamp.stamp(); int t_ms = (int) ( ( current_time_stamp - last_time_stamp ) / 1000 ) ; /* Convert to ms */ @@ -246,6 +245,9 @@ ulMilliSecondSleep ( wait - t_ms ) ; } current_time_stamp.stamp(); +while ( current_time_stamp - last_time_stamp < dt ) { +current_time_stamp.stamp(); +} } else { // run as fast as the app will go current_time_stamp.stamp(); ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
I wrote: > Maybe it is doable to sleep for a millisecond less than computed and achieve > the > targeted framerate with the loop. Could you try this patch : cvs -z4 -q diff -u main.cxx (in directory I:\FlightGear\cvs\FlightGear\src\Main\) Index: main.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v retrieving revision 1.194 diff -u -r1.194 main.cxx --- main.cxx9 Mar 2005 15:12:01 - 1.194 +++ main.cxx9 Mar 2005 16:53:34 - @@ -233,12 +233,11 @@ double throttle_hz = fgGetDouble("/sim/frame-rate-throttle-hz", 0.0); if ( throttle_hz > 0.0 && scenery_loaded ) { -static double remainder = 0.0; - // simple frame rate throttle -double dt = 100.0 / throttle_hz + remainder; +double dt = 100.0 / throttle_hz; int wait = dt / 1000; -remainder = dt - ( wait * 1000.0 ); +if ( wait > 0 ) +wait -= 1; current_time_stamp.stamp(); int t_ms = (int) ( ( current_time_stamp - last_time_stamp ) / 1000 ) ; /* Convert to ms */ @@ -246,6 +245,9 @@ ulMilliSecondSleep ( wait - t_ms ) ; } current_time_stamp.stamp(); +while ( current_time_stamp - last_time_stamp < dt ) { +current_time_stamp.stamp(); +} } else { // run as fast as the app will go current_time_stamp.stamp(); ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Quoting "Curtis L. Olson" : > Time out here! > > There are two reasons two throttle frame rate. > > 1. Conserve CPU time and leave more cpu time for other tasks. Using > sleep() calls you can put FG asleep for a short time if it gets done > drawing a frame early, leaving those cycles for other tasks. > > 2. Accurately control frame rate. Here you want to run at a fixed > precise frame rate to achieve smooth, jitter free rendering. For > instance, if you can't quite sustain 60hz consistanty, you might want to > throttle back to 30hz. > > The problem is that this new patch throws away the second reason in > favor of the first. When I throttle to 20hz, I get 19hz. When I > throttle to 30hz I get, ohh ... 28 or 29 depending. Putting the > application to sleep does terrible things to timing accuracy, because > typically the application can only wake up during a kernel trap, and if > you miss the vertical refresh by even 1 millesecond, you drop a frame > and get animation jitters. > > Maybe we need to figure out how to satisfy both needs, but we can't just > blindly dispense with reason #2 when a new need comes along. > > Maybe we need separate options, such as > --cpu-friendly-inaccurate-throttle-with-sleep-hz= and > --frame-rate-accurate-throttle= > > Thoughts? I think we need to tread a bit more carefully on this one, > especially since I have a side project that employs this option (well, > used to employ this option) :-( to achieve accurate frame rate timing > and smooth animation. Maybe it is doable to sleep for a millisecond less than computed and achieve the targeted framerate with the loop. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Time out here! There are two reasons two throttle frame rate. 1. Conserve CPU time and leave more cpu time for other tasks. Using sleep() calls you can put FG asleep for a short time if it gets done drawing a frame early, leaving those cycles for other tasks. 2. Accurately control frame rate. Here you want to run at a fixed precise frame rate to achieve smooth, jitter free rendering. For instance, if you can't quite sustain 60hz consistanty, you might want to throttle back to 30hz. The problem is that this new patch throws away the second reason in favor of the first. When I throttle to 20hz, I get 19hz. When I throttle to 30hz I get, ohh ... 28 or 29 depending. Putting the application to sleep does terrible things to timing accuracy, because typically the application can only wake up during a kernel trap, and if you miss the vertical refresh by even 1 millesecond, you drop a frame and get animation jitters. Maybe we need to figure out how to satisfy both needs, but we can't just blindly dispense with reason #2 when a new need comes along. Maybe we need separate options, such as --cpu-friendly-inaccurate-throttle-with-sleep-hz= and --frame-rate-accurate-throttle= Thoughts? I think we need to tread a bit more carefully on this one, especially since I have a side project that employs this option (well, used to employ this option) :-( to achieve accurate frame rate timing and smooth animation. Curt. Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main In directory baron:/tmp/cvs-serv28989 Modified Files: main.cxx Log Message: Frederic Bouvier: Norman Vine wrote : Frederic Bouvier writes: Quoting Andy Ross: * Hopefully in a CPU-friendly way. I know that older versions of the NVidia drivers did this by spinning in a polling loop inside the driver. I'm not sure if this has been fixed or not. From my experience, the latest non-beta Windows NVidia driver seems to eat CPU even with sync to vblank enabled. The CPU usage is always 100%. Buried in the PPE sources is a 'hackish' but portable way to limit CPU usage if the desired framerate is met /* Frame Rate Limiter. This prevents any one 3D window from updating faster than about 60Hz. This saves a ton of CPU time on fast machines. ! I THINK I MUNGED THE VALUE FOR ulMilliSecondSleep() NHV ! */ static ulClock *ck = NULL ; if ( frame_rate_limiter ) { if ( ck == NULL ) { ck = new ulClock ; ck -> update () ; } int t_ms = (int) ( ck->getDeltaTime() * 1000.0 ) ; /* Convert to ms */ if ( t_ms < 16 ) ulMilliSecondSleep ( 16 - t_ms ) ; } I implemented the method pointed out by Norman. It works great on windows and saves me a lot of CPU cycles. This way, I can get the same framerate in moderately populated areas and have CPU idle 50% of the time instead of wildly looping in the NVidia driver while waiting to sync on vblank. It has been tested on Linux by Melchior. He saw the same gain in CPU cycles. Index: main.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v retrieving revision 1.193 retrieving revision 1.194 diff -C2 -r1.193 -r1.194 *** main.cxx 5 Jan 2005 05:45:38 - 1.193 --- main.cxx 9 Mar 2005 15:12:01 - 1.194 *** *** 223,226 --- 223,228 SGCloudLayer::enable_bump_mapping = fgGetBool("/sim/rendering/bump-mapping"); + bool scenery_loaded = fgGetBool("sim/sceneryloaded") || fgGetBool("sim/sceneryloaded-override"); + // Update the elapsed time. static bool first_time = true; *** *** 231,241 double throttle_hz = fgGetDouble("/sim/frame-rate-throttle-hz", 0.0); ! if ( throttle_hz > 0.0 ) { // simple frame rate throttle ! double dt = 100.0 / throttle_hz; current_time_stamp.stamp(); ! while ( current_time_stamp - last_time_stamp < dt ) { ! current_time_stamp.stamp(); } } else { // run as fast as the app will go --- 233,250 double throttle_hz = fgGetDouble("/sim/frame-rate-throttle-hz", 0.0); ! if ( throttle_hz > 0.0 && scenery_loaded ) { ! static double remainder = 0.0; ! // simple frame rate throttle ! double dt = 100.0 / throttle_hz + remainder; ! int wait = dt / 1000; ! remainder = dt - ( wait * 1000.0 ); ! current_time_stamp.stamp(); ! int t_ms = (int) ( ( current_time_stamp - last_time_stamp ) / 1000 ) ; /* Convert to ms */ ! if ( t_ms < wait ) { ! ulMilliSecondSleep ( wait - t_ms ) ; } + current_time_stamp.stamp(); } else { // run as fast as the app will go *** *** 422,427 } - bool scenery_loaded = fgGetBool("sim/sceneryloaded") || fgGetBool("sim/sceneryloaded-override"); - // flight model if ( global_multi_loop > 0) { --- 431,434 ---