VS 11 Developer Preview gotchas with C++ AMP

Now that the VS 11 Developer Preview is available for download, if you want to work with C++ AMP there are some things you should know and to save yourself some pain and frustration trying to figure them out, I have listed them below.

VS 11 Express

If you want to build non-Metro-style apps, i.e. you want to build desktop or server apps that run on Windows 7 and on Windows 8, then the Express edition is NOT the one you want. Please download the Ultimate edition instead (which also allows the building of Metro-style apps, but in addition lets you build desktop and server apps too).

If you do want to build in the Express edition Metro-style apps that use C++ AMP, you can! The one gotcha is that you cannot use our two enum classes (accelerator_restriction and queuing_mode), as you’ll get a linker error. This will be fixed for Beta.

The GPU debugger also doesn’t work in Express, but there is a workaround: To enable the GPU debugger, please run this script.

VS 11 Ultimate on Windows 8

If you install Ultimate on Windows 8, you have full debugging support without having to run any scripts.

The gotcha for Metro-style apps described above still applies.

However, when you try to run your C++ AMP apps on your DirectX11 hardware, you will require a Windows 8 driver for that hardware (debugging uses an emulator, so it has no such requirements). The availability of a Windows 8 driver for a specific card depends on your hardware vendor, so please check with them about availability. Some cards work fine, and others don’t yet.

VS 11 Ultimate on Windows 7

If you install Ultimate on Windows 7, your hardware will no doubt have a driver, so you are good to go for running your C++ AMP apps on your DirectX 11 cards.

However, GPU debugging is not supported on Windows 7 (and there is no workaround, other than installing on Windows 8).

Furthermore, on Windows 7 you should not even build your project in debug mode, if it uses C++ AMP and also you are using const array (or array_view<const T,N>). In that specific scenario, building in debug mode and then running your app will result in a (fairly cryptic) runtime exception.

D3D11: ERROR: ID3D11DeviceContext::Dispatch: The Shader Resource View in slot 0 of the Compute Shader unit is a Structured Buffer while the shader expects a typed Buffer. This mismatch is invalid if the shader actually uses the view (e.g. it is not skipped due to shader code branching). [ EXECUTION ERROR #2097394: DEVICE_SHADERRESOURCEVIEW_BUFFER_TYPE_MISMATCH ]

So always build in release mode on Windows 7 with the Developer Preview (this will be fixed for Beta). If you must build in debug mode, e.g. because you want to debug the CPU portion of your code, you have three options

  • separate the C++ AMP portion into its own project so you can build that in release configuration and the rest in debug.
  • Or, do not use const array or array_view<const… though this will have negative impact on performance
  • Or, the actual fix
    • find the one or two occurrences of D3D11SDKLayers.dll on your installation and rename them to D3D11SDKLayers.dll.bad or some other such name. The dll is under %windir%\System32 and on a 64 bit system also under %windir%\SysWOW64\D3D11SDKLayers.dll.
    • install the DirectX SDK from June 2010 (the only file you need is the version of the D3D11SDKLayers.dll file that it has, which is older than the one VS 11 Developer Preview installs, and does not have the bug that the newer version has). To save you disc space and time, note that you only need the first option checked ("Install DirectX Runtime") so you can ignore the other 6 "DirectX…" options.


Feedback and questions

Once you are using C++ AMP, please post your feedback and questions at our MSDN forum: http://social.msdn.microsoft.com/Forums/en/parallelcppnative/threads

Comments (9)

  1. petke says:

    Quick question. How do I know if I have express or Ultimate? The about menu says neither.

  2. dmccrady says:

    It's not as easy as it should be, but one way is to do a "File / New Project".  If the only thing you can do is create a Metro-style app, you've got express.  Otherwise, you have Ultimate.

  3. Alex says:

    I see the UmsThreadDefault constant is declared deprecated in VC 11 Developer Preview.

    What is the reason? Is that because Windows 8 will automatically use UMS on supporting configurations or you throw this scheduler away? If this is the latter, then why? The main idea of using UMS threads, if I understand it correctly is that if you task gets blocked in Windows Kernel (that is, not using the cooperative blocking), the scheduler can reuse the context to do other work?

  4. Hi Alex,

    We are retiring the UMS scheduler for the upcoming versions. The concurrency runtime will not take advantage of the UMS threads. Going forward, we will internally map requests for UMSThreadDefault to ThreadScheduler.  

    >>if tasks gets blocked in Windows Kernel

    You are right, and that is one of the uses of UMSThread. However, note that

    a) We have made C++ standard mutexes and sync primitives concrt aware – so if your app used a C++ sync primitive, the runtime would still deliver on the same behavior you expect from UMS.  

    b) When it comes to things like network and file i/o, the automatic oversubscription of threads at the user task level ends up hurting performance in many cases. Also note that, in the upcoming release, we are promoting async tasks and continuation style programming to deal with network and file i/o.

    c) For other valid uses of working around win32 blocking APIs, our recommendation is to be deliberate and call context::oversubscribe as needed.

    Note that there are also other good uses of UMS threads. One is that context switch overhead is significantly reduced. However, we observed that any app, whose performance is significantly dominated by context switch overhead has to redesign their apps.

    Are you using UMSThreadDefault today? If so we’d love to hear from you to understand how and where you use it.


  5. Alex says:

    First of all, I would like to say that Concurrency Runtime is very very GREAT! We have utilized PPL task groups, parallel algorithms and containers, asynchronous agents and message blocks in new version of our application.

    In various areas we got almost linear scaling. Even in complex algorithms that cannot be parallellized by themselves we managed to get up to 30% performance boost by splitting work and using agents to carry work chunks in parallel.

    Most performance improvements are noticeable by a naked eye on a modern hardware and this is without rewriting core application algorithms. That is IMPRESSIVE!

    To sum, Concurrency Runtime and its APIs provide high-level yet very efficient mechanism for C++ program to utilize modern multi-core performance. The coding experience is very raw and easy for an average C++ developer. Some difficulties exist when you have to cooperate with Windows synchronisation, especially when you need to return to GUI thread, but this is all solveable.

    Now to UMS scheduler. I think some performance measurements are required to see if our application wins anything in using it compared to standard one. I can post results here later.

    Anyway, it is sad to see that you are retiring it. UMS threads low-level API in Windows 7 looks quite challenging and verbose and I doubt anyone would ever manage to create a wrapper with such great API as Concurrency Runtime.

  6. Alex,

    That’s great to hear! Thanks for taking the time to provide the feedback. I would really love to chat with you over an online meeting to capture some of your success stories and any improvement feedback you may have for us.

    [My email is r_ a_ h_ u_ l   d o t    p_ a_ t_ i_ l    a t    m_ i_ c_ r_ o_ s_ o_ f_ t_ . c_ o_ m  (delete all underscores and spaces; replace d o t with the character "." ).]


  7. Bobby says:

    When is windows 7 debugging going to be supported? Will stick with OpenCL until that happens.

  8. Jamie Richardson says:

    Will debugging be supported any time soon in windows 7? Eager to work with C++ Amp but I cannot use Windows 8 because our office is not going to move to it.

  9. bobyg says:

    Hi Jamie,

    Thanks for your feedback. We do acknowledge the need for debugging support in Windows 7 and when we mitigate that hindrance, we will definitely have a blog post on the topic.

    In the meanwhile, the best workaround (using a remote win8 machine) continues to be blogs.msdn.com/…/remote-gpu-debugging-in-visual-studio-11.aspx