AMD makes GPU compute a reality with hQ -- Heterogeneous Queues make GPUs a full peer in compute

semiaccurate.com ^ | Oct 21, 2013 | by Charlie Demerjian

[Ernest_at_the_Beach]

Heterogeneous Queues make GPUs a full peer in compute

AMD is finally talking about hQ or Heterogeneous Queuing, the final step in the Fusion integration of CPU and GPUs. hQ itself is more of a mechanism for software to utilize the hardware that is in Kaveri, but it will carry over in to much much more.

Conceptually speaking hQ is a pretty simple idea to explain because at its most basic level all it does is allow the GPU to send tasks to the CPU. Of course this simple thing to explain has a lot of tech behind it, simplicity is usually the product of a lot of hard work. Before hQ the CPU could place tasks on to the GPU’s queue but not the other way around. Schematically it looked like this.

[Ernest_at_the_Beach]

Getting interesting.

Will Games be the first app to implement this?

[Marine_Uncle]

RE: "Will Games be the first app to implement this?"

Good question.

[Nervous Tick]

>> Heterogeneous Queues

Had to read that one a couple times, carefully.

[Ernest_at_the_Beach]

You could try this one:

Homogeneous Embedding....

[ShadowAce]

[pierrem15]

Almost all of the hQ work is done in userspace with only minimal work done in the kernel. This minimizes transitions and the overhead they bring and also allows apps to do what they need to do without costly privilege escalation. Once again the idea is to minimize any performance sapping overhead that doesn’t need to be there in any way possible and it sounds like AMD did a pretty decent job of it too.

Sounds suspicious to me-- what manages GPU contention between different user space apps? Isn't that what you need a kernel/scheduler for? If so, aren't you back having to pass msgs through the kernel?

[GeronL]

I don’t even know what the headline means

[Svartalfiar]

What do you end up with? In APUs at least a CPU can work on a program for the serial portions and then simply pass it to the GPU in the middle of a running task. Nothing gets interrupted from the user perspective and the latency is minimal. Parallel portions can then run on the GPU and then it can pass the thread back to the CPU when the parallel portions are done.

And here we are back at threading issues. This is the same problem with quad- or octo-core processors. They are extremely under-utilized because the extra threads can only be utilized under two conditions:
The tasks cannot be linear. They have to be parallel. The program has to be designed for multiple threads.

I don't think the utilization of this is going to be useful for most people, as CPUs are already plenty powerful and multi-cored. The main beneficiary of this will be, as the first couple posters mentioned, gamers. The primary benefit I see, at least in the short term, is passing graphical processing over to the CPU.

[Ernest_at_the_Beach]

If the app (Think Games ) basically owns the Graphics card....then the app is responsible for managing how the graphics GPU is being used.

[Neidermeyer]

We had a customer do the opposite to us back around 1985 ,, had MVS handle most of his user programs operations to avoid having SMF record the actual cputime needed for his job to run. Having the OS handle the datasort and such was very inefficient.. lots of overhead.