Back to General and Gameplay Programming

Vsync messing with my job system

Sebastian Ahlman · 2017-02-21T14:37:43

Hey guys, I have been investigating a weird slowdown in my project that turned out to be Vsync causing my job system to perform poorly. I am not sure why this is happening though, so I ask for ideas. I have a simulation running where particle systems are updated on the job system. The job system is fairly standard, it uses a pool of threads and gives those threads jobs to do. In addition, you can add dependencies to a job and have the main thread wait until the job is complete. In the case with the particle systems causing problems, each particle system's update function is thrown on the job system and the main thread waits for all of the update jobs to complete before continuing. In practice this is implemented with Win32 events and the main thread is using WaitForSingleObject() to wait for the depencency linked to all the update jobs. This works fine when the frame rate is unlocked, and it even works fine when the main thread is limiting the framerate through code (by spinning in the beginning of the frame until the desired delta time has been reached). However, when turning on VScync to limit the framerate (in this case to 60FPS) the WaitForSingleObject() call starts taking anywhere between 1ms-500ms. With VSync off I can happily throw hundreds of particle systems on the job system and it performs fine. With VSync on the multithreaded update of particle systems causes the framerate to vary wildly (as previously mentioned). However, if I update the particle systems serially on the main thread the system works farily ok (although a bit slower since it does not benefit from the job system) even with VSync on. So in short, having Vsync on makes the job system dependency waiting perform very poorly. Any idea what might cause this? Literally the only different in my engine between having VSync on/off is passing 1 or 0 as the first parameter to IDXGISwapChain::Present(). I am using DX11 for rendering and the swap effect has been set to DXGI_SWAP_EFFECT_DISCARD. The tests have been done in window mode. With VSync on I presume the call to Present() sleeps until it is time to present the content on screen. Is it possible that the machine does some weird context switching because of this, causing my threads to jump around and cause this behavior? Thanks!

General and Gameplay Programming Programming

Started by GuyWithBeard January 04, 2017 05:52 PM

33 comments, last by Ryan_001 7 years, 1 month ago

GuyWithBeard

1,932

Author

January 09, 2017 04:59 AM

Try off?

Same deal.

GuyWithBeard

1,932

Author

January 09, 2017 05:28 AM

I didn't catch that your rate limiter used a busy wait, sorry. How is that implemented?

This is run at the start of every frame:


if(!mTimer.isStarted())
{
    mTimer.start();
}

mTimer.update();

Profiler::beginFrame();

double dt = mTimer.getTimeSinceLastUpdate();

// Spin if FPS gets too high.
if(RenderOptions::getBool(RenderOptions::OPTION_FRAMERATE_CAP) && mMaxFramerate > 0)
{
    double minDeltaTime = 1.0 / (double)mMaxFramerate;

    while(dt < minDeltaTime)
    {
        mTimer.update();
        dt += mTimer.getTimeSinceLastUpdate();
    }
}

This is bizarre so you're probably going to have to share some job system code to find the problem.

Well if you want to look at my ugly scribblings then here you go. http://www.sourcedrive.net/basis_job_system.zip

The engine is organized into sub categories, each in their own folder. I am giving you the jobsystem and threading folders. The jobsystem code depends on the threading code in this case. The code should be fairly self explanatory I hope. Feel free to point out any gnarly things you find.

As for the problematic case. This is how I update the particle systems in their own jobs and finally wait for the job group to be finished:


for(ParticleSystem* ps : mUpdateList)
{
    ps->updateInJob(time, mUpdateJobGroupHandle);
}

bool success = JobSystem::waitForJobGroup(mUpdateJobGroupHandle, 10000);
BASIS_ASSERTD(success, "The particle system update job(s) timed out.");

ParticleSystem::updateInJob() looks like this:


void ParticleSystem::updateInJob(const Time& time, JobGroupHandle jobGroupHandle)
{
    mCurrentDeltaTime = (float)time.deltaTime;

    updatePendingStateChange();

    if (mState == ParticleSystem::StatePlaying)
    {
        JobSystem::scheduleJob(Basis::MakeDelegate(this, &ParticleSystem::updateJob), jobGroupHandle);
    }
}

I have plans to support adding multiple jobs to the system in one go instead of having to do loops like that, locking/unlocking the job system internals on every iteration. But then again, the system performs really well as long as I don't use VSync, so who knows how big of a problem it is.

I appreciate the help!

GuyWithBeard

1,932

Author

January 09, 2017 05:52 AM

One more thing. When the PS update jobs are run there are no other jobs running in the system. There are a few jobs that run each frame but they are started after the PS jobs have run and they are waited for too. Also, in the test case I don't use any job priorities other than JobPriorityDefault.

Eklipse

294

February 21, 2017 09:27 AM

It seems like it might be something with the particles code. Can you replace that with something else simpler to test it?

Is all the particle memory on the CPU only? Your not doing any kind of lock or anything from the GPU before updating the particles?

Ryan_001

3,477

February 21, 2017 02:37 PM

Have you tried replacing WaitForSingleObject() with a simple atomic flag/spin loop? If it is truly the cause of the problem, removing it entirely should indicate that.

Vsync messing with my job system

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Vsync messing with my job system

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines