"Intel reckons that this makes Larrabee fully programmable and far more suited to future workloads, but such an approach comes at the inevitable cost of having developers natively code for Larrabee using a C/C++ API. The 'problem' is somewhat mitigated by the fact that coding shouldn't be too different than writing for x86, which, after all, is what Larrabee is based upon.
Being software-based has other intrinsic advantages too, such as driver-updating for newer APIs when they become available. Kind of like adding microcode for your CPU.
DirectX and OpenGL will be supported, of course, and the traditional rendering pipeline can be run through software, but it's not how Larrabee talks best. "
This seems weird statement, first you claim the drawback is that it costs to natively code, then you point out the DirectX OpenGL will be supported .. ipso, facto, DX and OGL games should run without issue since these APIs are supported via the drivers.
In fact, is it not the unique programability of the core architecture that is it's greatest strength, along the lines of CUDA, Larabee has the head start as now all libraries can be utilized with little to no effort, coding is the same within the construct of the x86 ISA, and it opens up a whole new realm of possibilities. Add to the fact that with a full x86 core, Larabee contains all the memory management paged and non paged, coherency, branch predicators, etc. that it would be possible (and possibly likely) that it could run an OS, in fact meld with the platform to produce amazing results across any application. Intel's paper specifically states that Larrabee could run an OS as such.
It is an exciting product, but also a huge gamble... either the chip will be amazing (even if it is barely competitive at first), or the biggest flop since itanium... nonethless, it is intersting to see it turn into a three way race.