The following warnings occurred: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Warning [2] Undefined array key "lockoutexpiry" - Line: 94 - File: global.php PHP 8.1.31 (Linux)
|
FPS fluctuations with GL2 - Printable Version +- Forums (https://www.vdrift.net/Forum) +-- Forum: Project (https://www.vdrift.net/Forum/forumdisplay.php?fid=4) +--- Forum: Development (https://www.vdrift.net/Forum/forumdisplay.php?fid=9) +--- Thread: FPS fluctuations with GL2 (/showthread.php?tid=1735) |
FPS fluctuations with GL2 - NaN - 07-02-2013 Just wanted to do some profiling on the sky code and noticed some rather large FPS oscillations (150 - 30 FPS), independent of the sky code. FPS: 155 ai: 0.731045 us car: 133.517 us physics: 888.772 us render1: 132.376 us render2: 4783.22 us render3: 282.884 us scenegraph: 292.133 us sound: 6.03939 us FPS: 35.8 ai: 5.99526 us car: 1373.12 us physics: 12048 us render1: 292.763 us render2: 12581.9 us render3: 540.867 us scenegraph: 754.979 us sound: 51.723 us Can someone confirm this? PS: We really need to move physics into separate thread... RE: FPS fluctuations with GL2 - NaN - 07-02-2013 This seems to be an interesting problem: INFO: gfxframe: 1048 simframe: 1502 1/dt: 166 INFO: gfxframe: 1049 simframe: 1502 1/dt: 142 INFO: gfxframe: 1050 simframe: 1503 1/dt: 166 INFO: gfxframe: 1051 simframe: 1504 1/dt: 142 INFO: gfxframe: 1052 simframe: 1504 1/dt: 142 INFO: gfxframe: 1053 simframe: 1505 1/dt: 166 INFO: gfxframe: 1054 simframe: 1506 1/dt: 76 INFO: gfxframe: 1055 simframe: 1508 1/dt: 47 INFO: gfxframe: 1056 simframe: 1510 1/dt: 38 INFO: gfxframe: 1057 simframe: 1512 1/dt: 38 INFO: gfxframe: 1058 simframe: 1515 1/dt: 38 INFO: gfxframe: 1059 simframe: 1518 1/dt: 32 The game can clearly make 160 fps. In this case we are doing 0-1 simulation updates, graphics are faster than physics. As soon as the time delta between graphics and physics is large enough it can happen that another simulation update is squeezed into the frame, simulation runs at fixed 90 fps. This slows down current frame and forces three simulation updates for the next frame, so that the simulation stays ahead of graphics. Which kills framerate quite effectively, here by a factor of five. I need to check whether this is only a simulation issue though. Three times more physics(+logics) causing five times lower framerate sounds fishy. RE: FPS fluctuations with GL2 - Timo 6 - 07-02-2013 Well I have a crap GPU, so I start with 30fps with shadows off I do get oscillations (varies on track) but I always assumed it was due to my set up. FPS: 26 ai: 3.66517 us car: 574.403 us physics: 2131.78 us render: 35246.5 us scenegraph: 381.893 us sound: 29.7774 us FPS: 12 ai: 6.45575 us car: 1092.48 us physics: 4319.82 us render: 79684.2 us scenegraph: 400.67 us sound: 52.9047 us RE: FPS fluctuations with GL2 - NaN - 07-02-2013 I assume this is with car standing still, rendering the same scene? Then it is the same issue. I need to do some more profiling to get an idea how to deal with it. In the end, we will have to run the simulation in a separate thread to get a more stable frame rate, I guess. RE: FPS fluctuations with GL2 - CrystalH - 07-06-2013 Is it maybe because of VSync and particles ? Probably not. Anyway a while ago I moved simulation to 2nd thread (but in Stunt Rally). And I did it even so that both threads aren't even synchronized (no mutex lock). We used boost but I'm sure the SDL threads are ok too. My main reason was to have more cpu time for graphics (draw calls are on cpu) and have graphics independent of simulation time (we have 160Hz on game thread, doesn't slow down because the game is gpu bound on drawing). We did get few fps more on graphics. I also had to separate the camera code. Here is what I did. I made a structure for car position data (can be just position and rotation for start). Then a simple array of eg. 8 of those structs (can't use std::queue since its not thread safe) also an int for current index (so graphics thread knows which data from array is last valid and meant for render). In sim thread when new data is computed it is filled in next position in this array, and then the index is increased. This operation is atomic, can be done from both threads without sync. So just for reference, from OgreGame.h: Code: const int CarPosCnt = 8; // size of poses queue Code: /// store new pos info in queue _________ Code: int q = iCurPoses[c]; // c is car index RE: FPS fluctuations with GL2 - NaN - 07-09-2013 After profiling a bit more (now comes the somewhat embarrassing part) it turned out to be the power save mode of the machine I've been testing on. Switching to balanced mode fixed the fluctuations, giving me stable fps. Oh my... |