Do games use middleware queues to handle rising h/w parallelism?

g__day

Regular
Just a quick ponderance.

We are moving futher into an age of less rapidly increasing raw speed of hardware, but alot more parallelism to deliver throughput. We are seeing this now in 2 and soon 4 core CPUs and GPUs with 16 - 24 pipelines, and soon we may have PPUs too.

Do we see game engines relying more and more on work queues to abstract how much parallelism a rig has under its hood? If you had an approach (or architecture) where jobs are initiated and placed on a work queue for one or multiple hardware resources to address, then perhaps developers would barely have to know if they are operating on a rig with one big CPU or 1000 little ones or 2 biggish CPUs plus 4 GPUs plus 2 PPUs.

Is this a direction the industry is considering?
 
g__day said:
Just a quick ponderance.

We are moving futher into an age of less rapidly increasing raw speed of hardware, but alot more parallelism to deliver throughput. We are seeing this now in 2 and soon 4 core CPUs and GPUs with 16 - 24 pipelines, and soon we may have PPUs too.

Do we see game engines relying more and more on work queues to abstract how much parallelism a rig has under its hood? If you had an approach (or architecture) where jobs are initiated and placed on a work queue for one or multiple hardware resources to address, then perhaps developers would barely have to know if they are operating on a rig with one big CPU or 1000 little ones or 2 biggish CPUs plus 4 GPUs plus 2 PPUs.

Is this a direction the industry is considering?

Such a piece of technology is in fact rather trivial, no more than a few hundred lines of code.

Although you can't trivially abstract the difference between different processor types without compiling at the point of job submission or conservatively providing versions that can run on either target.

The issue with parallelism is breaking things down to a job level to start with, writing your code so that you are not dependant on immediate answers.
 
Totally agree with your first point - a queue with a simple PUT and GET function is simplicity itself.

In your second point I'd imagine you abstract various categories of queues within either your game or 3d pipeline based on the hardware types you have and at run time the number of h/w assets you find within each class, be it CPU cores or graphics pipelines.

Yes the task of setting an algorithim than can spawn and yet not finish independent jobs is the most challenging part.
 
Back
Top