Deploying apps built with C++ AMP

This blog post addresses what has very quickly become an FAQ in the last few days: “What must I deploy on customer machines for my app that uses C++ AMP to function?”


Beyond the optional Visual Studio tooling support, C++ AMP consists of compiler enhancements (they are baked into the Visual C++ compiler), a library (mostly in <amp.h>), and a runtime (vcamp110.dll).

So at runtime your app that uses C++ AMP needs to find vcamp110.dll. You cannot statically link to the C++ AMP runtime, so your app has to somehow find that DLL on the machine where it executes, i.e. only dynamic linking is supported.

Note that vcamp110.dll has a dependency on the MS C runtime libraries (msvcr110.dll and msvcp110.dll). In Beta, the vcamp110.dll used the static version of these libraries and hence did not require them to be available. For RTM, it uses the DLL version of the C runtime libraries.

Also note that, as per the typical pattern, there is a debug version (vcamp110d.dll) which you probably wouldn’t be deploying unless you wanted to perform remote debugging.

Deployment Mechanism

The deployment story is the same as for any C++ application, and as documented on this MSDN page for deployment of C++ apps in VS2010.

In other words, vcamp110.dll (and its dependencies) are part of the “Microsoft Visual C++ 11 Redistributable Package” aka “VCRedist”.

Quick Dirty Deployment Test

To test a deployment to a specific machine, that does not rely on the VCRedist, you can try the from here. To test a machine to see if it has a capable card, you can try the utility from here.

Comments (5)

  1. Paul says:

    Thanks, Daniel.  One follow-up question.  What target OS platforms can I deploy on?  Will C++ AMP apps run on Windows XP or Vista?

  2. DanielMoth says:

    Hi Paul, Microsoft’s implementation supports Windows 7 and Windows 8 and the equivalent server versions (and any products building on these client and server versions). So, no there is definitely no support for Windows XP and we did not test on Windows Vista (even though in theory it should work there, but we definitely do not support it). Thanks for the question.

  3. axelriet says:

    "For RTM, we are considering changing to use the DLL version of the C runtime libraries."


    Whipping 1 additional DLL is fine, even better if we can put it exactly where we want like vcompXX.dll (thanks to _OPENMP_NOFORCE_MANIFEST).

    What NOBODY wants is to be forced to ship the C/C++ redistribuable and offer end-users one more way to break our apps.

  4. John Schroedl says:

    I'm in favor of including vcamp110.dll as part of vcredist. We already install vcredist with our application and one less extra thing to remember is good.

  5. We did realize the additional dependencies this introduces but me made a trade-off to avoid duplicating CRT global data structures in the process address space, and reducing the C++ AMP runtime DLL’s executable size. Also, it protects us against changes in layouts of STL types that are passed across C++ AMP runtime DLL boundary (at least when the client app itself links to the DLL versions of the CRT).

    You are correct about OpenMP not depending on CRT DLLs but they had good reasons to make that choice – they do not use the CRT heap and just use very few functions from the CRT which led them to choose linking in the static lib versions of the CRT. However, there are other precedences of the a redist component being dependent on another redist component – the STL DLL (msvcp110.dll) depends on the msvcr110.dll.

    With every decision there are tradeoffs involved, and while we may think we made the right ones, we always look for feedback so thanks for sharing.