Well, they said so :)

Ok, fair enough, I didn't remember that part of the paper.

Anything to do with the ability of the VPU to read one operand directly from L1? Jawed

In the terminology you use here, are the manual shared memory management and coalescing requirements of CUDA part of the programming model or just of NVs current implementation? Because, as someone who's used both traditional GPGPU and CUDA on HPC problems that's the part of CUDA that I can't see as part of any future more-or-less "mainstream" parallel programming language/model. I also think those should be mentioned before talking about how well CUDA scales -- because a CUDA program that's actually optimized (and when it comes to coalescing and shared memory we're not talking about single-percent type optimizations but potentially orders of magnitude differences) won't come close to porting to another architecture optimally.

It's also interesting (and I haven't seen anyone explicitly mention it in this thread) to see the different programming trade offs between Larrabee and NV GPUs. As I currently understand it, on the former, you get automatic/hardware cache management but no hardware thread scheduling. On current NV hardware it's just the other way round. I'm not yet sure what's preferable, ideally you'd have (the option of using) both.

Slightly related, Larrabee (A many core Intel Architecture for Visual Computing) presentation was apparently *too* popular at IDF Fall 2008, a big portion of press got left outside due lack of space. Due this, the presentation will get another round thursday.

Hopefully they released some more details..

Tech demo vid for us laymen to enjoy would be good!

Tech video on emulated hardware? not exactly exciting :)

just cos samples arnt out till november doesnt mean thay aint got nuthin now?

besides, i like seeing pretty graphics, real time or otherwise.

Coalescing would be implementation. You could relax those rules significantly and (a) existing code would still run without change, and (b) apps that do uncoalesced access would automatically go faster. Whether global memory is cached or not is also in this category.

The on-chip shared memory is part of the programming model. You can implement it with normal cache and good cache eviction policy controls (like Larrabee apparently has). But your code has to be written to deal with it explicitly or you get no benefit, and it affects your algorithms and data structures. So I'd call it part of the programming model.

I wouldn't be upset if shared memory evolved in the Larrabee direction. The important thing is to be able to guarantee very low latency and very high bandwidth to a chunk of data used by a group of cooperating threads. Generic caching isn't good enough, IMHO.