I am using Windows XP, Panda 1.5.3, and Python 2.5.
The code below demonstrates a problem with inconsistent framerate.
On my machine this code will print values ranging from 0.03 to 0.07
around 10 times a minute. The delta times printed match a visible
stutter in all my applications.
A friend on irc could not reproduce the problem using Linux.
Is this a known problem?
#from psyco.classes import __metaclass__
from direct.showbase.DirectObject import DirectObject
from direct.task.Task import Task
from pandac.PandaModules import *
self.gameTask = taskMgr.add(self.main, "main")
def main(self, task):
dt = globalClock.getDt()
print 'dt was', dt
if __name__ == '__main__':
w = World()
Here you’ve hit the nail on the head: it’s a problem with all your applications. This should tell you that it’s the operating system taking away time from your applications.
There’s only so much Panda can do if the operating system doesn’t give it enough CPU to run smoothly every frame.
Why is the OS doing that? We’d have to guess–there are several possibilities. One is that there is another application, or maybe a low-level driver program, which is periodically stealing CPU cycles away. Another is that you don’t have enough RAM, and the system is swapping little bits to disk from time to time. Another possibility is that the system is getting interrupted to handle I/O and isn’t recovering in a timely manner.
Whatever the problem, it has little to do with Panda itself. Windows has always been really bad at scheduling.
All the applications I have written using Panda3D, including the example.
Not all the applications on every Windows machine I’ve ever used.
It may be that process priority needs to be increased.
Whether or not this is normal for Windows games I do not know.
Ah, I see. My misunderstanding, sorry. Still, the point remains: it is not a problem with Panda per se, but a problem with scheduling time by the OS.
Panda applications are different from most other Windows applications, in that they require constant CPU time in order to maintain performance. Most traditional Windows applications, by contrast, are event-driven and don’t mind if the CPU time they get between user clicks is consistent or not.
There are some things you can do to improve smoothness. One is, yes, increase the priority on your own process, but that will have to be done via direct Windows calls; you’d have to look that up. You can do it interactively via the Task Manager, just to test what effect it would have.
You also want to go into your system Performance settings, and make sure you check “Programs” for both Processor scheduling and Memory usage. Also, turn off any power management in your power management settings; these affect CPU usage too.
Try alternatively disabling or setting sync-video in your Config.prc file. In some drivers, setting this to 1 guarantees the smoothest frame rate; in others, you get your best results with it set to 0.
Also, it may make a difference whether you are rendering anything meaty, or just staring at a blank screen.
Increasing the process priority solves the problem.
Other Windows games I have investigated do not do this.
Well, what can I say? Is there some magic to working with the Windows process scheduler that we Panda designers just don’t understand? It’s certainly possible.
Panda is just a program that does a lot of computations, and makes a lot of demands on your video hardware, as fast as possible. Sometimes the OS doesn’t give Panda a full timeslice. What should we do about that?
If other games don’t have the same problems, perhaps they are not making the same number of computations, or perhaps they are not demanding the same of your video hardware.
Or perhaps they are running in different modes. Have you tried changing the sync-video setting?
Yes, sync-video #f allows a higher frame rate but still stutters.
Hmm, here’s a thought. There are really two different phenomena you’re talking about. (1) you observed a perceptible stutter during gameplay. (2) you wrote a Python snippet to measure inconsistent framerate, and got some surprising results.
The obvious assumption is that the two phenomena are the same thing. But perhaps they’re not. Perhaps the inconsistencies you’re measuring in (2) are actually too small to be perceived, and are unrelated to the perceptible stutter you observe in (1).
In fact, if you’re looking for the causes of (1), perceptible stutter during gameplay, you don’t have to look that closely. There are several known causes of stutter in Panda, which can cause chugs of a hundred milliseconds or more. Chugs of this size are definitely perceptible, while chugs of 30 ms may or may not be. My running theory is that all CPU-intensive applications on Windows XP are subject to periodic chugs of 30 ms or so, but you don’t notice these so much in other applications. You wouldn’t notice them in Panda, either, except that you can write code that can measure them.
On the other hand, the really big chugs of 100+ ms are unique to Panda, and it is these chugs you are perceiving.
The single biggest cause of 100+ ms chugs in Panda is texture loads. The way to avoid these chugs is to call prepareScene(), but that call might be broken at the moment. There’s another workaround, which is to temporarily set an OmniBoundingVolume over the scene. There’s another recent thread discussing that.
Raising the priority of applications is a bad idea, because it makes certain Windows background tasks never actually get time to run, and sometimes they are needed for housekeeping reasons. High-priority threads should be I/O bound and only need the priority for latency reasons. A graphics application is latency sensitive, but not I/O bound.
What could it be on your system that takes the CPU every so often? Who knows? Are you using a third-party firewall or virus scanner? Are you using any overclocking or thermal polling applications? Sometimes, calling the BIOS to read motherboard or graphics card temperatures will steal the CPU for several milliseconds at a time, which will certainly cause stalls in low-latency graphics applications.
The test code showing approximately 10 instances of stutter per
minute allows me to easily match a “bad” printed delta time to a
clearly visible stutter when nodes are actually being drawn.
This does not happen when using similar code in other engines.
This does not happen if I port the entire game to other engines.
This does happen on multiple Windows machines, XP and Vista.
Does anyone reading this thread have any ideas?
i’m getting those tiny lags,too. here on ubuntu linux 8.04 32bit (dell Inspiron notebook 1720).
never noticed them when running my panda apps. but the snippset above showed it. usual results where around 0.02 and 0.04 .
from what it looks its not OS-related (thought one would need more test-data to confirm).
just out of the blue. but maybe itts something like speedstep technology or something simmilar. which might be able force the cpu to sleep a few ms until switching frequencies is is done. have no idea,thought. just a guess.
Do the stutters coincide with Python garbage collection?
No, they happen regardless of whether or not python gc is enabled.
i only get stutters when eggs or textures load other wise its always runs smoothly. On linux i found that top, or other process monitoring tools are very CPU hungry for very short amount of time. I think its the kernel that does some of this process look up so its gets the top priority too.
The fact that the stutters go away when the task priority is elevated strongly indicates that it is indeed competition from other processes, and not particularly something within the panda process itself.
Here’s one idea. Put the following in your Config.prc:
These should ensure that all the places that Panda might be yielding the timeslice are disabled, which in turn should guarantee that the Panda process consumes 100% of the CPU no matter how much or how little it is rendering. Does this have any effect on the chugs?
The other thing to check is to simply bring up the task manager, similar to treeform’s suggestion about top, and switch it to the Processes tab, and sort it by in descending order by CPU utilization, so that python sits at the top. Then watch the other processes for a little while. Are there some other processes that are jumping in and stealing some CPU time? What processes are they?
Windows does of course have a pre-emptive scheduler, so there’s no guarantee you get 100% of the CPU to Panda – but those changes will at least make it so that Panda doesn’t volountarily yield the CPU, so that any yielding is due to effects outside of Panda.
That being said, if you get a better experience by raising the main application priority a smidgen, then go ahead and do that, and hope nothing bad happens. As long as you don’t use 100% of the CPU (and thus there is some CPU left for background tasks), I imagine it will work fine.