The answer to your question is in this blog post and the links it points to: http://blogs.msdn.com/b/nativeconcurrency/archive/2012/02/26/divisibility-requirement-of-tiled-extent-in-c-amp.aspx

If you still have questions after reading those, please post to our forum: http://social.msdn.microsoft.com/Forums/en-US/parallelcppnative/threads

posted by Daniel Moth

CUDA, OpenCL, and C++ AMP all have comparable performance, so your opening statement is not quite true, sorry. The advantage of the latter two is that the they support executing on hardware from multiple vendors. The further advantage of C++ AMP is that it is a more productive environment to code in.

Please watch the other videos in this series (e.g. start with this and that) and if you still have questions we welcome them in the forum, as per the link above. If you are familiar with the other approaches we also have learning guides for OpenCL and for CUDA to get you started.

posted by Daniel Moth

@Elad:Thanks, glad you found it interesting. Yes I leave the time measurement to you so you can explore the benefits on your specific hardware

posted by Daniel Moth

posted by Daniel Moth

posted by Daniel Moth

Our feeling is that once you have watched all those, you should be perfectly comfortable to download and explore the more involved samples on your own (without a video/screencast accompaniment) – please pick your favorite from the C++ AMP samples list. BTW, every sample has a dedicated blog post describing it, so if you have questions around understanding a specific sample, please leave a comment on the specific blog post for the sample, or ask in the C++ AMP support forum. Thanks for watching!

posted by Daniel Moth

posted by Daniel Moth

posted by Daniel Moth

An even simpler example of showing how productive you can be with C++ AMP is our "Hello World" example. We also have learning guides for those familiar with other programming models, please get them here: CUDA, OpenCL, DirectCompute. 

The performance is comparable between all these approaches, and in our tests is not a factor for choosing one over the other, even now that the product is in Beta and we are still tuning the bits. Once we RTM, we invite anyone to measure the performance difference between C++ AMP and any other approach and share their workloads and results on a variety of hardware for comparison.

posted by Daniel Moth

posted by Daniel Moth

posted by Daniel Moth

Shared memory is where a lot of the hardware is heading. C++ AMP is designed well for shared memory architectures:

• the array_view type does not have explicit copy requirements, and instead performs implicit on demand copying for you.
• kernel invocation (parallel_for_each) does not explicitly describe any copying of data at all - it is all done through the subtle capture of data types in the lambda, so in future releases it will be very easy to allow capturing additional data types without changing the API.
• for repeated copies we also offer the staging arrays feature (see our blog).
• finally, the restriction model has a versioning story that is described in an appendix of the C++ AMP open spec http://blogs.msdn.com/b/nativeconcurrency/archive/2012/02/03/c-amp-open-spec-published.aspx 

Having said all that, while the *design* caters for it, the Microsoft *implementation* in v1 does not offer sahred memory support – we simply run out of time to implement that under the covers. For shared memory hardware, this means that we still perform a copy through DirectX, but since the memory is not on discrete hardware, the performance copying penalty is not as large. Other implementers of the C++ AMP open specification can offer this capability as they see fit.

It is important to note that, even with shared memory, some scenarios will still benefit from explicit allocation and copying when primary access is from the CPU or the GPU (shared memory may still have non-uniform characteristics). So we believe that the basic ability to associate arrays with an accelerator will retain value into the foreseeable future.

posted by Daniel Moth

@n0x30n: While there will be no built-in .NET way of achieving this, we have documented how easy it is to interop from .NET to C++ and C++ AMP to utilize the GPU. The samples are not updated to Beta yet, but the techniques are the same: http://www.danielmoth.com/Blog/NET-Access-To-The-GPU-For-Compute-Purposes.aspx

@Sonicflare: You probably already know this, but Beta is out http://blogs.msdn.com/b/nativeconcurrency/archive/2012/02/29/visual-studio-11-beta-get-it-now.aspx

posted by Daniel Moth

@Matt_PD: It's runtime overhead (but we have optimized this as much as we can). Although we have enabled this feature, we have not come across any real world cases that have taken advantage of it yet, so if you use C++ AMP for >3 dimensions, please let us know.

posted by Daniel Moth

posted by Daniel Moth

@Freeman: For VS 11 timeframe, our recommendation is interoping from .NET as per the blog post you found. For future releases, we may consider adding this capability directly to the .NET Framework based on customer feedback, but it is not in any plans right now.

posted by Daniel Moth

posted by Daniel Moth

http://channel9.msdn.com/posts/Daniel-Moth-Blazing-fast-code-using-GPUs-and-more-with-C-AMP

posted by Daniel Moth

posted by Daniel Moth

posted by Daniel Moth

So the answer to your original question is that to use arrays as indices, you would have to do exactly what you did in your code... there are no other provisions... Feel free to contact me offline to talk about those.

posted by Daniel Moth

posted by Daniel Moth

posted by Daniel Moth

posted by Daniel Moth

posted by Daniel Moth