Andy

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!

And often, there is no natural name for a function that traverses multiple control structures. The denotation is the most informative name. What would you name a function that lifts a function into two nested functors, is partially applied, and is then lifted up into another functor? This kind of stuff happens quite a bit. And my code is easy to read, because nearly invisible glue code connects two concepts in a relationship that makes sense (typically in terms of products or direct sums implemented via functors).

Consider the expression: (num_shirts_in_factory_a + num_shirts_in_factory_b). Which parts of that expression are the informative ones? Obviously, it is the "num_shirts" variables. And there is only one "sensible" way to put those quantities together. Now push this idea to its limit. It is more than there just being one sensible way to write glue. There is exactly one glue function between glue-able types.

On the other hand, I have used some type classes to move some of the more repetitive glue away. I have classes like:

class Monic a b where inject :: a -> b -- to represent monic morphisms
class Epic a b where surject :: a -> b -- to represent epic morphisms

You can easily have a class like

class Glue a b where
glue :: a -> b

and hide all the line noise in there. And then your client code will look like

blah :: StateT (MaybeT IO) (Integer) (Maybe Integer)
blah = glue . parseInt . glue . getLine
-- or
blah = glue $ parseInt $ glue $ getLine

This is how "line noise" glue code looks to me. Except line noise is more maintainable. *fnord* Note that these glue functions would each require their own distinct type class instance.

The nicer the client code looks, the more complexity you have to shovel into the Glue instances. But you are merely transferring complexity -- not creating or destroying it. Complexity is created by data type definitions being glued. There is the potential for a combinatorial explosion, since you can have unused Glue instances, whereas you cannot have unused "line noise" glue code.

Mathematicians don't care about mathematical symbols. They care about the things the symbols join, because the semantics of joining "things" is dependent on -- and usually determined by -- the things being joined.

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

I agree. To get a DSL to a usable productised form is not a minor hurdle. I believe the best approach is to focus on a limited vertical slice, and expand sideways as you can demonstrate your utility. Allowing incremental adoption will always be a important factor to take into account.

To pick something tangible, I think OptiX is a good example of the DSL approach. It is effectively a compiler, but delivers a reusable graphics technology that would be very hard to express by any other means.

Impact: real-time graphics quality is starting to get stuck. We aren't moving much further, I don't think. I think that there is a problem of getting more programmable hardware, and actually being able to program the hardware. There is a problem that as you add more visual effects, there is a combinatorial explosion, because effects need to work together.