The other point is: FPS is an old value. It is ok for single threaded games. But for multi-threading, this only shows you how many frames the graphics device can render a scene. In background, the game can run the speed it wants and perform much complex things. The more complex a scene becomes, the more important multi-threading will be.

Multithreading the graphics pipeline is nothing new to directx. DX9 had some parallel ability that many game companies made use of.

Why go to all of the dev and test effort to make a parallel API if no one wants it? Well, people do want it, game companies want it. DX10 had no multithreading abilities and many many requests came in asking for it. So lets look at some of the reasons why.

Object creation is slow. It can stall your rendering thread any time your app discovers that it needs to create a new object. These calls are slow enough that MS, ATI, NVIDIA all wrote white papers telling developers to avoid creating and destroying resources during the application runtime. The API supports multithreaded creates so that you can defer to the driver to pick the best times to create objects -- for instance when it has a few spare cycles -- which allows your rendering thread to continue its work -- which is to get stuff drawn to the screen.

Next, DX11 supports deffered contexts. These allow multiple threads to build command lists at the same time and for the DX runtime to preform validation on separate threads in advance. DX10 was an API redesign where one of the many goals was to reduce CPU overhead of the API calls. CPU overhead was a huge problem for DX9 -- and many many game companies were limited in what they could get on screen just because the API ate too much CPU. So DX10 reduce that cost significantly, in some places by an order of 10-100. However there are some calls that were difficult to trim down because the validation was necessary, or perhaps the driver had a lot of work to do. Being able to build command lists on separate CPU threads allows some of that work to take place in parallel and in advance of trying to actually draw the data. Several game studios are already taking advantage of deffered contexts and are seeing improvements in performance, even when using the CPU fallback for lack of driver support.

So, DX9 would allow roughly 2000 API calls per frame before the API would become a bottle neck, DX10 is around 12000, DX11 should be even higher when using deffered contexts. These are call limits based on using the whole API to do actual work, not just calling some API like SetPrimitiveTopology() x number of times. The trouble is that studios are trying to put more and more stuff on the screen and would surely take advantage of anything that could be provided performance wise.

Plus your engine has to do a lot of CPU work anyway to make draw calls. It has to build matrix transformations, sort objects and draw calls, make all sorts of decisions on what to draw and how to draw it. All of this could be done in parallel with big wins -- provided that your app actually has enough work to do that these things become bottle necks.

A consumer won't need high end hardware to take advantage of multithreading. It's all about preventing the GPU from being starved of data to crunch.

I don't think that there are many drivers out yet that fully support the multithreading APIs yet. This feature requires a lot of effort to get right and is a huge test burden -- but they will come out eventually.

The DX10.1 feature level supports hardware multithreading. This means that there is a reasonable sized slice of hardware out there already that can support this stuff once drivers arrive.

AAA Games take 2-4 years to develop - about the time span you pointed out required to adopt a new technology. Interesting how that works.

Vendor lock in is not an insurmountably problem for developers. The reality is that there are lots of game engines that wrap the graphics system into a layer so that they can run on xbox, or PC, or Playstation. These problems have been solved over and over again and are just part of reality. These same game engines have multithreaded deffered contexts built in because it makes a difference. DX11 gives them a way to map their engine API more closely to the hardware which results in a bigger win. There's no reason why an API should really lock you to any vendor if you layer your software. You want to support someone else, then target them too.

GPU tools and languages have been getting better and better over the years. Sure it's not as ideal as native tools, but it's getting there. With the spreading use of DX, compute, CUDA, opencl, etc. more and more people invest in GPU technologies which means that the whole infrastructure continues to improve. Lack of perfect tools shouldn't stop you from leveraging the amazing power of the GPU -- though I admit there are areas of debugging that are still frustrating but they will get better. People with a lot of practice writing shaders can actually get a lot done. It's not python, but it's also not asm.

A new API or hardware rev will always be ahead of the install base at launch time. This is not new.

Not all of the available API's are needed by every developer. Multithreading probably falls into one of those categories of optimization -- why do it if you don't have a problem. Granted multithreading normally requires a lot more forethought in code design, but I guarantee that if you're not seeing a win, it's because you're not running a scenario that it was designed to fix -- which is CPU and DX API bottle-necking.