Jump to content
  • Advertisement
Sign in to follow this  
vince35

Threads and Vsync

This topic is 3760 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all, I have an application that work just fine. It's made of 2 threads. One does the rendering, the other does various background tasks asynchronously. Currently, my rendering thread has the highest priority (THREAD_PRIORITY_HIGHEST), but still, I can see hicups on my scene and that's caused by the background thread executing whenever the computer decides it's a good time to. Is there any way to have to background thread executing only when the main thread is waiting for the vSync signal (SwapBuffers)? I suppose that way I would be done with interference of the threads. That would almost mean that only one thread would be executing at one time. Thanks.

Share this post


Link to post
Share on other sites
Advertisement
You have other issues with your program. You should be able to run both threads with normal priority and still have the game run smoothly.

I'd start first by tracking the min/max/avg time per frame. It's kind of like a fps counter, but much better. You will probably discover that your max frame time is extremely high, which is the frame causing the stutter. After that, you need some in-game profiling code to identify the offending chunk of code.

Share this post


Link to post
Share on other sites
Thank you for telling me this, but you can't really tell me what my other problems are if you don't even know what my application is doing. I can assure you I'm quite good at optimisation, that my application is quite intense for both CPU and GPU and that I already profiling my code for some time.

What I'm less good at is with threads. So that's why my question is about threads.

Share this post


Link to post
Share on other sites
If you really want that only one thread runs at a given time then it makes sense not to use multithreading at all. The rendering thread should do graphic stuff when the device is ok and do calculation when the device is waiting for a VSync.
It's much more simpler and you avoid the ovrhead of synchronization.

I don't know how to see in OpenGL if the device is waiting a VSync, but in Direct3D is very simple.

If you target multiprocessor pc then you can just have the Render-Worker thread described above and N worker threads (where N is equal to the number of cores-1) that do the calculations on the other cores.

Have a look at this: http://msdn.microsoft.com/en-us/library/ms684251.aspx

That's just an idea...There may be better ways!

Share this post


Link to post
Share on other sites
I was expecting an answer like yours: "why bother have multithreading if only one thread execute at a time?" The reason is quite simple. The background thread is doing a number of things, that might take up to a quite long time to do. It would be extremely hard to manually handle to stop it in the middle of a task to resume rendering after the vsync and to restart it at the right point at the next vsync. That's why I though naturally of threads, where I don't have to bother about it. If I can just start and stop the thread at will, then I'd be good to go.

Regarding setting a thread to a specific CPU, I was looking into it when I received your post. But I'm a bit sceptical as when I tried it a few years ago (with multiple processes though) and it wasn't improving frame time stability, probably because of disk access.

Share this post


Link to post
Share on other sites
What are microthreads??? (In other words, no I haven't considered them since I never heard of them lol)

Share this post


Link to post
Share on other sites
Quote:
Original post by vince35
Thank you for telling me this, but you can't really tell me what my other problems are if you don't even know what my application is doing. ....

Please carefully consider the answers you have already received.

Those include:

* Have you looked at the actual min/max/avg frame rates, to see how long the processing takes for each frame? What kind of results are you seeing?

* Have you done any profiling to determine what areas of the code are your hotspots? What were your results?

* Have you done any profiling to determine what areas of your code dramatically change in processing duration between frames? What were your results?

* Have you honestly evaluated if a single-threaded version of your program, which computes a few slices of this unknown task at a time, would affect the issue? You never really addressed this in detail.

* Have you really considered alternate ways of distributing the processing? Specifically, what were they, and why won't they work?



We can't help you if you simply tell us that we don't understand the problem or that you anticipated those answers. You might want to read this if you don't understand why the responses aren't getting you the results you wanted.

Share this post


Link to post
Share on other sites
Actually frob is spot on. The simple fact that you experience a problem as you described shows that you have a design flaw in your system.

So, there's no direct way to have a thread run on vsync only, and there is no reason to. While waiting for vsync, the GPU and CPU aren't idle. In fact, the former will continue working on its command queue, while the later will already schedule in other tasks. The driver and OS aren't dumb, you know. They won't put the CPU in a polling loop while waiting for vsync.

Now, you have two threads running. A main thread, presumingly doing the rendering and general UI stuff. And a second thread doing heavy background work, which is not time critical. In such a scenario, you should not get any interference on the first thread, unless:

* You are doing some blocking operations on the second thread that throw the scheduler off
* You aren't properly using multithreading
* Your thread priorities are incorrectly set

All this worsens on a single core system, obviously.

Now, you never should have to increase the priority of the main thread. This is very bad practice. In fact, you should rather decrease the priority of your second background thread. This can already help a lot.

If not, then you need to provide a lot more information about what you're actually trying to do.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!