The problem described in the snip below is exactly the sort of problem solved by hardware SpMT (Speculative Multithreading).

Instead of software having to be rewritten to be parallelized, SpMT has hardware run the parallel parts of the sequential code in parallel.

E.g. if the parallel parts of the sequential code are in separate subroutines, fork-on-call SpMT forks threads at the CALL points and runs them in parallel.

E.g. in different loops, fork-on-loop SpMT runs the different loop iterations of the sequential code in parallel.

I myself have worked on doing SpMT purely in hardware, as has Haitham Akkary, formerly of Intel and now of the American University in Beirut. Haitham called his work DMT, Dynamic Multithreading. March Tremblay worked in doing this in Sun Rock, with a combination of hardware and software, although Rock was cancelled.

This situation - expecting software to be rewritten to be explicitly parallel - is very similar to the situation with RISC and VLIW versus the form of Out-of-Order execution that most modern CPUs employ. We know how that turned out. I wonder if we will repeat this history, or if parallel software will magically happen.

QUOTE: <<even

The second paragraph of the article pretty much sums it all up and, yes, the title is missing the word NOT.

Surely the article states that games do NOT push hardware capabilities. Unless I'm going mad that is I get from this that devs aren't writing code that take advantage of multiple cores and mostly they sit idle and that the potential of DX11 isn't used due to lack of drivers?

So surely the title should be "...DON'T push hardware capabilities".

Seriously guys...