But it solves a very specific problem, given it's programming model, which is essentially mapping Cg (+ pointers) to a single SIMD way ... similar to what Larrabee's shader compiler does in 16-way SIMD. But as-is it would not be suitable for writing the Larrabee renderer. It covers maybe half of the Larrabee ISA.

Still it goes a long way!

Something like LLVM would be cool, but I don't see the necessity. Making a compiler output OpenCL or CUDA or Cg/HLSL is simple enough, just as the first C++ compilers output C. Then each vendor can implement those languages how they like.

I'm sure LLVM will grow to support such use-cases. If the industry settles on PTX then LLVM may get simpler and smaller, but nothing fundamental will become possible that wasn't before. PTX is nice to have, that's all.

The focus should not be on the specifics here, but on the more general problems: how can I easily refactor code so that it runs on a different mix of coprocessors? When my console has 4 scalar cores with 4-way SIMD plus 32 cores of Larrabee plus a 2048-unit GPU, how can I retarget code when I find I need to change my occupancy profile?

The problem is the huge differences in architecture - exemplified by the fact that RenderTris(vertex[], index[], shader()) is implemented in hardware on a GPU but software on Larrabee. PTX covers the shader() part, but implementations of RenderTris, plus the API calls to actually trigger the call, are completely different and must be selected per architecture. It's there that PTX may break down as it may lack access to non-generic features per architecture (e.g. SPU channel registers or special Larrabee opcodes).

Still, food for thought!

OpenCL has the most potential to be the hidden layer between software and compute-device, but it's not about innovation but about money.