Would you kindly share your C++ AMP experiences (if they exist)

Denizens of Beyond3D, I come to you cap in hand with an inquiry which seeks to exploit your vast knowledge. Keeping a long story short, I am undertaking an effort to understand how / if C++ AMP is used in the compute / rendering field. This understanding would be useful in (possibly) shaping future iterations of the product that serve actual needs as opposed to assumed ones. As such, it would be useful if you were so kind as to share:
1) your experiences with C++ AMP (including some context e.g. employer/field of work/project);
2) how you feel about it by comparison with alternatives such as CUDA / OpenCL / DirectCompute / RenderScript etc.;
3) what you really like (if there is anything);
4) what you utterly hate (if there is anything);
5) what made you adopt it / is blocking your adoption;
6) what you would love to see included in the programming model.
If you feel uncomfortable publicly sharing details, send me a PM so that we can setup a more formal conversation via email. Thank you!

Full disclosure: I hold a role as a Software Engineer at Microsoft and I work on C++ AMP. The information you provide will (possibly) be used to shape future iterations of the product.

 

I have to admit I didn't get beyond the Hello World sample 3 years ago.

I'm afraid to say the apparent lack of low level control, e.g. which bits of memory are allocated, re-used and de-allocated precisely on my terms, seemed like a strong demerit. But I didn't engage with it seriously enough to discern whether that control was actually lacking.

It was my assumption that routing via Direct Compute, thence to IHV compilers, would result in a severe lack of control. Somewhat like D3D11-itis (over-abstracted grappling of an unwieldy virtual machine). Which is what D3D12 is about solving.

Also, by that time I was already heavily engaged with OpenCL in various projects and wasn't looking for an alternative.

---

In one of the OpenCL/SPIR-V sessions from GDC (with SYCL as a topic) there was talk of compute becoming more deeply embedded within a near-future iteration of the C++ standard. I dare say I thought of C++ AMP at that point and it seems inevitable that C++ will eventually build upon AMP and SYCL in some way, while at the same time taking a long-term view. There's proper language-design philosophy there, broader than the GPU-led R&D seen in AMP/SYCL.

 

Hey @Rys you should use the list notices system to nudge folks in the direction of these kinds of polls.

 

I picked the 4th option although inaccurate, I know there's overlap with opencl, directcompute.. what I don't know is why I'd use it instead. I've just been getting back into graphics programming again but I always seem to be busy to the point where I don't even know why I'd take the time to look into using AMP vs the other options. Maybe you could point me to summary or post something here. Not that my opinion counts for anything but I figured I'd at least bump this thread since the lack of responses makes me sad and its worthy of one.

 

I sent my lengthy answer by email a few weeks ago. Recap:

I do like C++ AMP a lot, mainly because it integrates to C++11 code so well (kernels as lambdas allow call site optimized shader permutation compilation, existing type support, including template support). You get all the benefits of existing tools (such as intellisense code completion, external C++ refactoring/validation tools, symbol peeking / jump to definition, see types when hovering mouse, syntax highlight, etc). Debugger is also fully integrated to Visual Studio and you can step into GPU code from the CPU code.

Main downside is the limited platform support. As a game developer, we need to support Xbox One and PS4. Mobile devices have compute APIs as well nowadays (Metal on iOS and OpenGL ES 3.1 on Android). If C++AMP had backends on all these platforms, We would definitely use it for professional projects. Currently I have only used it for some hobby projects at home.

 

sorry i'm not a programmer at all. Mostly just fix hardware and network stuff at work. But I hope you get the feedback you need

 

From the bottom's up - fair point about the references. Something that is relatively close to the idea of a summary is what Daniel Moth, the former PM for C++ AMP (and a great guy overall) put up on the team blog some time ago: http://blogs.msdn.com/b/nativeconcurrency/archive/2012/08/30/learn-c-amp.aspx. I will note that in its current form C++ AMP is not an alternative to a graphics API (nor has it tried to), but can rather be thought of as a replacement for e.g. DirectCompute.

Everyone else, thank you for your feedback, please keep it coming. And don't be shy - if you want to say mean things, don't hold back

 

Thanks for the link I'll read it when I get the chance, still reading rys's article at techreport.
To everyone else who gave AlexV feedback, if possible could you post your impressions in this thread, I enjoy and learn by reading from more experienced/smarter people than myself... Thanks.

 

>1) your experiences with C++ AMP (including some context e.g. employer/field of work/project);
I bought a book on it. Compiled some samples. investigated keeping data in GPU side buffers and directly rending them.
I have a hobby open source opencl solar system simulation.

>2) how you feel about it by comparison with alternatives such as CUDA / OpenCL / DirectCompute / RenderScript etc.;
Different people interpret GPGPU in different ways.
Some see it as being useful for multimedia, visualization and game physics acceleration. They don't care for double precision or the accuracy of floating point operations and get excited about fp16.
Others ,scientists and I suspect visionary engineers in graphic card companies , see it as useful for serious computation.
I'm for "serious computation" with a vision of the possibilities of it becoming a commodity item available to all. For my program, I'd like quad precision.

Show me the part of C++ AMP specification that matches chapter 7, "OpenCL Numerical Compliance" of the opencl CL C Specification V2.0 (https://www.khronos.org/registry/cl/specs/opencl-2.0-openclc.pdf)

>4) what you utterly hate (if there is anything);
It runs on top of DirectCompute and is in practice a windows only technology.
It is a "me too" effort. You should be supporting open standards by including the opencl icd with windows and improving windows base openGL support.
Do you see C++ Amp running on a android tablet say? It running reliably and fully supported under linux?

>5) what is blocking your adoption;
Locking myself into windows only.
My program (a Solar System Simulation) does compile and run under Ubuntu. But in practice is much slower due to x-windows and cpu scheduling under linux.
Due to Nvidia's lack of support for opencl and the much lower performance under linuix, I have given serious thought to moving to C++ AMP.
Lack of confidence in its long term future, numerical precision, and performance stop me.

 

I presume you have found chapter 9, "Math functions", from: http://download.microsoft.com/downl...E-93344241D56C/CppAMPOpenSpecificationV12.pdf, insufficient for your needs? The good news is that the C++ AMP implementation that runs on top of OCL should be a precise 1:1 match to your needs. The one that is done on top of HSA will match that respective spec. The bad news is that the one that runs on top of DirectX shall never be a 1:1 match, given differences between those two APIs. I do find that there are certain details missing from the open-spec, i.e. details for the basic operators - perhaps this is something that you would appreciate?

The implementation that Microsoft ships does indeed run on top of DirectCompute. The rest of the first statement about being "windows only" is false, and has been so for a long time, see:
https://bitbucket.org/multicoreware/cppamp-driver-ng/wiki/Home. That is reasonably reliable at this point (obviously still in development) under Linux. In effect, it is a superset of what is provided in Visual Studio / Windows at the moment. If you have worked with it and found issues, the team developing it appears quite open to feedback, so please share it! Beyond that, I will point out that I fail to see the open standard that extends C++ towards being a viable GPU / heterogeneous compute platform, three years after the introduction of C++ AMP, which makes me believe that it was unavailable three years ago as well. I would rather avoid the religious discussions about languages, but the "C++" part in "C++" AMP was a fundamental design decision, not an afterthought.[/QUOTE]

Please see above. Perhaps, depending on time, you could experiment with your application and the Multicoreware / AMD C++ AMP stack, which runs on Linux? Insight such as yours is very valuable, and practical experience is an excellent way to guide future development efforts. For example, it would be appreciated if you could detail the performance concerns further - is there some particular scenario you have verified, which showed troublesome differences?

Overall, thank you for taking the time to provide extensive feedback, please keep it coming!

 

I'm genuinely interested in it, if it has good CPU & GPU support as my main interest is to write once to run on both targets depending on the computer.
Rumor is that the CPU version isn't fast, so I haven't bothered converting code, not even to test performance.

 

Thanks I went looking for the DirectCompute spec, seeing how it runs on top of it.

So does it conform to its precision spec under windows or not.[/QUOTE]

How do I do OpenGL interop?
It exists for directx under windows (http://blogs.msdn.com/b/nativeconcu.../sample-of-2d-triangle-rotation-in-c-amp.aspx)
Or do you expect me to write two different versions one using directX under windows and another using opengl under linux... is there opengl interop under linux...

At the moment I have one set of source code that compiles and runs directly under all three environments (Apple,Linux and Windows)
Further more I can use exactly the same IDE (http://codelite.org/) on all three. The IDE also happens to be fully 64 bit under windows (VS is 32 bit).
So
Compute api (opencl) the same - tick
Graphics api (opengl) the same - tick
Windowing api (wxWidgets) the same - tick
Development IDE (Codelite) the same - tick

Perhaps if Multicoreware ports it to windows (and apple) and adds Opengl Interop on all platforms It would be more interesting.

With my application, the data is transferred to the GPU and never comes back (except to persist to disk during a save). All, and I mean all, of the maths is done on the graphics card. The data is also directly rendered on the graphics card.
All the CPU does is queue up instructions to the GPU. They run completely asynchronously to the CPU. The only sync point is between OpenCL and OpenGL and that is a cross API issue.
Is all that possible under C++AMP?

>And don't be shy - if you want to say mean things, don't hold back
It's just for me, I'd rather spend the time coding more functionality than porting between platforms.

 

I am sorry for having chosen confusing wording, in the future I will seek to provide less room for the equivocal (albeit I must admit that I am surprised that you find the table open to interpretation, some amount of effort was invested in making it rather clear - unless you assume that the table is mere jest, which I assure you it is not). To make it adequately clear:
1) the Microsoft implementation, which is part of Visual Studio, and runs on top of DirectX, matches the latter's precision specification, as outlined in the C++ AMP open specification;
2) the MCW implementation, as far as I am aware, matches the precision specification of the underlying infrastructure, which can be OpenCL {1.2, 2.0} or HSA1.0 - you appear well versed in the OpenCL spec, and I believe the HSA foundation provides adequate documentation in this area, which will help elucidate any remaining uncertainties.

In Windows, with the Microsoft implementation, with care and a bit of effort, coupled with a performance penalty. I shall not delve into this particular area as it goes well beyond the scope of this thread. Speaking of which, I fear that a slight misunderstanding might have crept in: neither myself, nor anyone else, expects you to write anything - that would be rather rude. The purpose of this thread is to gather feedback and insight from those that have analysed and experimented with C++ AMP, and who are gracious enough to share it. There is no other expectation, nor is it intended to provide a tl;dr abbreviation of AMP and how various programming tasks can be achieved in it. That is a separate discussion.

I believe that right at the top of the MCW C++ AMP page they explicitly outline that they offer OS X support, perhaps a more careful parsing of their materials is opportune?

Your application is very impressive indeed, but this usage case is rather straightforward and quite fundamental for any heterogeneous compute programming interface / language. It follows that it is not only possible, but also trivial in C++ AMP. Now, with all due respect, I must point out that it might be opportune to invest more time in your analysis of AMP, and go beyond the "this is just evil Microsoft fighting against Open*". I understand that given the complexity of your project time constraints are in place, but at least going through the basics of C++ AMP and writing some code in it might be a worthwhile endeavour. Of course, it's fair game to choose not to, but at that point it is difficult to have much of a discussion in what regards improving and evolving it, beyond what we have already shared. The "you should just do Open* and stop trying to explore any alternatives" suggestion is interesting, however I fear that it is somewhat out of scope, but a perfectly fine topic for a separate discussion about the future of heterogeneous compute programming interfaces in general. Please do not get me wrong, your feedback is heard and understood, but my humble opinion is that taking this conversation to the next level might require a fraction of your time which you may not be willing to invest.

 

>1) the Microsoft implementation, which is part of Visual Studio, and runs on top of DirectX, matches the latter's precision specification, as outlined in the C++ AMP open specification;
Yes, but where exactly is the latter's precision specification?
Do you perform conformance testing of numerical precision as a part of WHQL testing on the graphics drivers?
Please point out the relevant section (http://download.microsoft.com/downl...dows8-1-hardware-cert-requirements-device.pdf)
Or is there a C++AMP conformance testing that goes beyond the WHQL testing to include the numerical precision?

 

>Or is there a C++AMP conformance testing that goes beyond the WHQL testing to include the numerical precision?
Sorry I understand now.
precise_math is a library that uses native functions or operators to achieve the numerical precision given in the C++Amp standard