Forums

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...

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.

Well I have a crap GPU, so I start with 30fps with shadows off Sad

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

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.

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

    // This list holds new positions info for every CarModel

    PosInfo carPoses[CarPosCnt][8];  // max 8 cars

    int iCurPoses[8];  // current index for carPoses queue

and in UpdatePoses.cpp, sim thread after tick, when new poses are available

Code:
        ///  store new pos info in queue  _________

            PosInfo pi;

            pi.bNew = true;  // new data

            // .... fill pos, rot, etc.

            int qn = (iCurPoses[c] + 1) % CarPosCnt;  // next index in queue

            carPoses[qn][c] = pi;

            //  update camera

            if (carM->fCam)

                carM->fCam->update(time, pi, &carPoses[qn][c], &pGame->collision);

            iCurPoses[c] = qn;  // atomic, set new index in queue

        }

and in graphics update just read the current index

Code:
    int q = iCurPoses[c];  // c is car index

    carM->Update(carPoses[q][c], time);

// and inside it just check if there are new positions available

    if (!posInfo.bNew)  return;  // new only

    posInfo.bNew = false;

Hope it helps anyhow.

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...

NaN

NaN

Timo 6

NaN

CrystalH

NaN