Jump to content
  • Advertisement
Sign in to follow this  
phr34k9

Task Parallism - Gpu affinity

This topic is 2515 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

The past days I've been attempting to (re-)implement a task based scheduling implementation because current capabilities don't meet the ability to have certain tasks to have affinity to a sub-selection of processors or rather said threads (i.e. dispatching gpu tasks). The former scheduling algorithm supports LIFO task scheduling and implements the so called task-stealing paradigm.

Most of the rendering is constrained to opengl and this imposes a limit that gpu-centric tasks can only be dispatched to worker-threads have the context set. As far as I know the same context cannot be activated simultaneously from different threads, so this implies that all gpu-centric tasks have to be routed to the same thread (unless context sharing for multi-cpu resource allocation, but it still affects render state).

Task distribution with affinity certainly isn't impossible but from a small-scale prototype (using lockfree algorithms where available) I'm not really satisfied with all the contention it raises. Right now i have the impression it is more of an 'trial-and-rejection' solution i.e. which thread steals the task rather than a system that through heurestics imposes maximum processor utulisation.

Are there any particulair approaches/patterns that solves this problem that are somewhat populair?

Share this post


Link to post
Share on other sites
Advertisement
OGL stuff needs to be done on same thread, simple as that.

Are there any particulair approaches/patterns that solves this problem that are somewhat populair?[/quote]

If more than 1 CPU is available, assign one thread to do nothing but OGL, the rest may do anything.

If trying to squeeze a bit more out of it, ignoring potential temporal aliasing issues, then make OGL thread work something like this:while (thread_running) {
if (has_stuff_to_render) {
render();
} else {
process_single_task();
}
}
Downside of such approach is that if OGL thread dequeues a long task, it will impact rendering time. In some situations, it may cause aliasing effects (render, render, task, render, render, task, render, ...), such as frames having latency of 1, 2, 1, 2, 1, .... frames, causing visual stutter.

If feeling bold, then it's possible to reorganize the above in such a way that any thread may become OGL thread. Or, making each thread worker look something like this:
if (nobody_is_rendering && has_stuff_to_render) {
become_OGL_thread();
render();
} else {
process_task();
}
}

This may cause certain complications if rendering requires some other API or OS functionality which may also be bound to a specific, usually creator's thread. Hence most prefer to just use main thread for that. This approach doesn't necessarily solve aliasing issues, something that cannot be done without ability to correctly interrupt a task being processed.

affinity[/quote]

Affinity doesn't really do much on non-real-time OS. It merely adjusts some priorities, but doesn't solve fairness problem or maximize utilization.

Share this post


Link to post
Share on other sites
A Phaser or Cyclic Barrier may help in what you are trying to do.

What I've done myself is create 1 Display thread for the OpenGL Context and N-1 Logic Threads. On my quad core that leaves me with 4 active threads running in parallel. The logic threads add their tasks for the next display frame and then swap their queue with another queue at the end of the cycle/phase. Basically the Display thread is always showing the frame the logic threads previously worked on. However, to do it right you have to double up on any memory variables that are shared since you don't want the Logic Threads changing the previous frames Display Variables.

You're going to come to a point where you'll have to decide if you want efficiency of processor use, or waist memory to increase processor utilization.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!