Parallel Programming in Native Code

Image Processing toolkit for .NET framework using C++ AMP

Boby George (MSFT) — Tue, 21 May 2013 18:31:57 GMT

Manipulation of images is an excellent scenario for GPU computation. Apart from Aviary, we were pleased to know that PrecisionImage.NET SDK also uses C++ AMP for their GPU computation. Their blog post, Image Processing with NVidia's GTX Titan, delineates the benefits of GPU computation by comparing the runtime performance of C++ AMP code on GTX Titan and GTX 460 against a six-core AMD Phenom II. CoreOptical graciously agreed to document their experience using C++ AMP and attached below is a blog post detailing their experiences (also cross posted in VC++ team blog).

Image processing is a computational task that lends itself very well to GPU compute scenarios. In many cases the most commonly used algorithms are inherently massively parallel, with each pixel in the image being processed independently from the others. As a result, image processing toolkits have been early adopters of the new GPGPU programming model. Many of these mass-market toolkits, however, can be more accurately described as image manipulation packages that offer "image-in, image-out" capabilities; in other words, for each operation there is an input image and a resulting output (manipulated) image. In contrast, an image processing workflow differs from this in that the goal is usually the portrayal or extraction of analytical information which is determined after some multi-step processing workflow. These workflows are commonly employed in scientific and technical industries like medical imaging.

For the last two years, Core Optical Inc. has been building an image processing toolkit for the .NET framework called PrecisionImage.NET. Internally it centers around two separate execution branches, one targeting multicore CPUs and the other targeting GPU execution. While the CPU branch is a fully-managed CLS-compliant implementation leaning heavily on the .NET framework's excellent built-in thread pool, the GPU branch is implemented using Microsoft's brand new C++ AMP compiler.

We had two requirements when choosing the GPGPU tool we would use for that branch of our toolkit. First, the generated code needed to be vendor agnostic so that a decision to use our SDK wouldn't overly restrict our customer's choice concerning graphics hardware. The current minimum platform for C++ AMP is DirectX 11, a version that will soon be ubiquitous among modern GPUs from Intel, Nvidia and AMD. Secondly, since we focus on the Microsoft developer stack we needed something that would play nicely with the .NET framework. Obviously C++ AMP is the best bet in this regard since it's produced by Microsoft.

For a v1 product we've found C++ AMP to be both solid and easy to program to. Although Microsoft doesn't produce an official managed wrapper, accessing AMP in .NET was a straight forward matter of P/Invoking from our existing C# code base. To keep the surface area between the two to a minimum, we stuck with our managed code for the CPU fallback and condensed the various operations of the SDK into hundreds of compact AMP kernels compiled in combinations of single/double precision and 32/64-bit implementations. In almost all cases we found the simpler untiled model readily met our speedup goals. When this wasn't the case, we were able to produce a tiled version that met our performance objectives with minimum drama.

To demonstrate the performance of the GPU branch we decided to compare the speed of two operations running on a 6-core CPU (multithreaded managed code) versus the C++ AMP version running on two different GPUs from Nvidia. The first operation was chosen as an ideal case for GPU implementation and consisted of a 2D convolution using a large kernel implemented using AMP's simple untiled model. The second was chosen as for its unsuitability to GPU processing and was implemented using the tiled model. Even when including the overhead of marshalling arguments from managed to native code, and memory copying to/from the GPU, we saw huge gains (60x) in the first test case. Perhaps more surprising were the gains achieved in the second, less suitable, test case – up to 7x – an indication of the quality of the AMP compiler. Based on our experience to date, if you are a developer considering using AMP from a managed code base we can recommend it without reservation.

Currently, one aspect of C++ AMP imposes a performance limitation (acknowledged by Microsoft) for our particular use cases: redundant memory copying between CPU and GPU. This is partly imposed by hardware and partly by software. Since our SDK is designed to allow the easy assembly of processing chains, the overhead of these redundant memory copies can add up quickly. Microsoft has stated that this behavior needs improvement, and all our AMP kernels are using the array_view abstraction to take advantage of the improvement when it arrives. This will be a welcome enhancement to the AMP implementation, especially given AMD's recent announcement of their hUMA architecture initiative. With both the hardware and software pieces falling into place soon, we should see a whole new generation of image processing software with unprecedented power and flexibility.

Addendum to CMA’s Case Study

Boby George (MSFT) — Thu, 09 May 2013 19:41:18 GMT

We are delighted to announce that CMA wrote an addendum to C++ AMP case study, detailing their problem and how they used C++ AMP. For context, we do recommend reading the C++ AMP case study, Financial Data Leader Shortens Time-to-Market, Increases Speed with Right Tools. This goes without saying, we are very thankful to Moody Hadi and CMA for providing this addendum (which is quoted verbatim below)

"Business Case:

CMA needs to build multiple interest rate curves per currency that have relationships amongst them within the same currency. In the cases, when market inputs are volatile due to illiquidity in a section of the curve or due to genuine volatility, the analysts have to intervene in order to validate that the moves are genuine and if not rely on other sources in order to accurately derive that segment of the curve. This process is highly iterative where the analyst needs to try different market inputs and regenerate the curves and then check the impact of the changes they made on the entire set of curves. A change in a market input can have a ripple effect on other curves in the same set. The time window for the analysts to perform this process is short (~20minutes) daily and they have to validate multiple asset classes and currencies as well. Thus, the user experience for every analyst needs to be kept to as close to instantaneous as possible.

Technical Solution:

Algorithm:

The set of relationships that exist amongst each curve set within the same currency translate to a number of constraints that ensure those relationships exist after deriving the curves from market inputs. In addition, each individual curve has to satisfy a number of constraints to ensure smoothness, some degree of locality and monotonicity. Finally, all the generated curves need to been consistent with all the market inputs used to generate them. The algorithm needs to generate the curves that satisfy these constraints.

A multidimensional gradient based root searching algorithm is used that has to solve for approximately 20 degrees of freedom and satisfy all the constraints to reach a solution. The algorithm itself is iterative and so is dependent on the input instrument selection. We used C++ AMP to remove the bottlenecks in cases when the instruments require more processing time, the gains we get there are compounded as each iteration requires much less time to converge.

Hardware:

Intel Core i7-860

16GB RAM

Nvidia GTX-570

Windows 8 Professional 64bit

The machine is used to process multiple currencies and asset classes as well. As such, we are trying to use the same hardware as efficiently as possible. During the analyst validation period there is a high degree of concurrency of requests coming into the machine, so if a certain set of curves have expensive instruments they can delay the processing of other requests.

Improvements:

We were able to reduce the processing time for curve groups from ~20 to 30 seconds (single threaded) to ~10 to 15 seconds (CPU multi threaded) to less than 5 seconds (GPU multi threaded)

An additional benefit is that with the use of GPU we are able to achieve a good degree of load balancing during critical time periods and not experience delay due to high processing requests whether they are due to incongruent market inputs or due to expensive instruments. Requests that can be processed quickly on the CPU are sent there and expensive requests can be simultaneously sent to the GPU to process thereby giving all users a fast and consistent experience.

The C++ AMP API was easy to use and allows us to quickly deploy and address bottlenecks without having to resort to more complicated APIs or perform major re-writes to the existing code base. The use of lambdas and STL like library made the entire coding process much easier and thus we were able to deploy our solution quickly, with a good degree of re-usability and without needing proprietary GPU API specific knowledge."

Moody Hadi

C++ AMP used for GPU Benchmarking

Boby George (MSFT) — Tue, 23 Apr 2013 20:43:00 GMT

Continuing with our series on how C++ AMP is being used, we are happy to highlight how C++ AMP is used for GPU Benchmarking. SystemCompute is an in-house benchmark developed by Dr. Ian Cutress of AnandTech. Once we came to know that the GPU version of this benchmark was written in C++ AMP, we reached out to Dr. Cutress for a blog post. Please find below the guest blog post detailing his experience.

"My Experience with C++ AMP

My first foray as a non-computer scientist but computer enthusiast into multi-threaded programming led to OpenMP. I was always fascinated by all the different BOINC projects, and how they were able to use the resources around them to brute force compute everything around them – the embarrassingly parallel tasks afforded such methods and were welcomed with open arms. During my undergraduate I donated a lot of my CPU PC time to helping these projects, then eventually GPU time. By the time I started my Computational Chemistry PhD, I was neither a competent programmer nor an optimized one; my masters thesis was computational yet written in Visual Basic .NET and thus amazingly slow. However moving to C/C++ and looking at OpenMP gave the research group a good deal of speedup, especially when all around me people were only using one core of a quad core machine (albeit four simulations running at once). It was at this point I casually remarked how interesting it would be to program GPUs. The situation took a lucky turn as one of my friends studying Computational Finance on Facebook linked me up to his supervisor, who was starting the CUDA course at Oxford. After a crash course lasting a week with no IDE and Linux (I was totally out of my depth), I set forth with CUDA knowledge and pains. What followed was the three years of my PhD using CUDA to publish several papers and get to grips with what programming on a parallel device really entails – the intricacies of making sure kernels are register light and rearranging operations or formula to use the least amount of cycles and get the results quicker.

Since leaving academia, I am now a hardware reviewer (which is a nice logical progression from chemistry… not J) for AnandTech.com, a well known hardware technology review website. As the Senior Motherboard Editor, I have the chance to dice and tumble with a lot of hardware, especially on the CPU and motherboard side. This means not only the consumer level kit, but also some workstation builds and dual processor setups. While nothing to do with GPU programming, I enjoyed reading about CUDA developments, and what OpenCL was bringing to the table. Reading about them put me squarely in the higher-level CUDA camp – OpenCL looked very daunting and somewhat confusing without an instructor telling you what to do!

During all this time I am an avid competitive overclocker – the dark art of making computer hardware run faster for small amounts of time to prove to the world you can make hardware run faster than anyone else. I enjoyed some minor success, becoming UK number one in the enthusiast league at HWBot.org for a couple of years, before moving on to the UK Team. The way to determine whether you are better than someone else (in terms of speed and efficiency) is to run one of the benchmarks supported by the league, such as SuperPi or wPrime for CPUs or 3DMark for GPUs. The system is always looking for better benchmarks, and the lack of a compute benchmark for GPUs always irked me. So as part of my reviewing, and also the overclocking scene, I set out to write one.

I cannot remember explicitly how I came to [hear] about C++ AMP. In order to write a benchmark for the overclockers it had to be GPU vendor agnostic, so CUDA was out of the picture, and as I mentioned before, OpenCL looked confusingly daunting (even with a step-by-step manual in front of me). Though I did come across C++ AMP, and the Native Concurrency blog, and started reading about it. I very quickly picked up the C++ AMP book by Gregory and Miller and started to work through it along with the code examples posted on the Native Concurrency blog.

My first thought was that C++ AMP was incredibly simple. I mean amazingly so. For simple kernels there was no need to worry about allocating memory, although I was initially confused with array and array_view given that I had not performed any matrix mathematics in the past. I had no prior knowledge of lambdas (in actual fact I doubt I could describe one to you now), but using a combination of monkey see and monkey do, I was able to port a good deal of the basic structure of my PhD research code into C++ AMP. All in all I probably saved 75%+ lines of code as well. The only thing that bugs me is making all my code work for multi-GPU setups, as it only works for single GPUs right now.

My final result was twofold – a benchmark for reviews (GPU version featured in Ryan Smith's GTX Titan review, CPU version featured in my Dual Sandy Bridge-E and Upgrading from Westmere reviews) and a potential benchmark for overclocking. The GPU version is purely C++ AMP, and the CPU version takes more bites from OpenMP due to efficiency.

If I was learning how to program on GPUs today, from scratch, I would advise newcomers to look at C++ AMP first. It seems quicker to get off the ground than CUDA, and not too overly confusing if you are familiar with C++ and a Windows environment. CUDA does have its advantages, being the more optimized, being the older language and the clout of NVIDIA behind it, but C++ AMP offers that unrestrictive element of AMD GPUs and widens the hardware base of whatever software you are creating.

The thread for the software can be found over at overclock.net. Basic code snippets can also be found in my Dual Sandy Bridge-E review."

--Dr Ian Cutress.

Please do note that we are working with Dr. Cutress to get his software made available to the community.

Verity Software’s integrating C++ AMP into their GEMStone software

Boby George (MSFT) — Thu, 11 Apr 2013 19:02:42 GMT

Verity software is a software company providing flow cytometry analysis software and we are pleased to learn that they are currently integrating C++ AMP into their high end application called GemStone. You can learn more about how GemStone works by watching this youtube video, where a GemStone model (used to analyze B-Cell maturation in bone marrow samples acquired with flow cytometry) is reviewed.

Since GemStone models are computational intensive, verity software wants to leverage C++ AMP to enhance the performance of reviewing the models. Up till now, the hardest part they have encountered while integrating C++ AMP, was the need to rework some of the algorithms so that they are naturally parallel. This is in line with our expectations that developers will have to rethink their sequential code to fit to C++ AMP (or any other parallel language technology) programming model. Further many of the data structures in the application also needed change. As a part of Parallel Patterns Library, we do offer Parallel Containers and Objects to alleviate some of the needs for concurrent data structures.

Some of the comments specific to C++ AMP included, to quote:

"….As far as the nuts and bolts of [C++] AMP is concerned, it seems very straightforward to me. I really like the idea of exploiting the lambda expression concept to run code on a GPU and not having a lot of very messy GPU specific code to deal with. Other than changes to our data structures, the other issue that is taking some time is writing nice looking code that runs on all the platforms that we support. Since our Mac versions of the software will not work with the amp.h and associated library, it's a bit tricky to have easily maintainable code that works for all these platforms…. I also probably don't need to tell you that it is a pain to have to decide whether you are going to debug the GPU or CPU before launching the program".

With intend of addressing cross platform support for non-Microsoft platform by our ecosystem partners, C++ AMP team did release the open specification. The support of mixed mode debugging across CPU and GPU is something we would address in future releases. This is the third post on the series detailing C++ AMP customer experience.

Aviary’s Photo Editor SDK for Windows 8 is using C++ AMP

Boby George (MSFT) — Mon, 01 Apr 2013 18:12:13 GMT

Aviary is a photo editing SDK Company that "provides developers with a robust, customizable photo editor that can be plugged into applications on iOS, Android, Windows Phone, HTML5 and Windows 8 in minutes". We are delighted that Aviary is using C++ AMP inside their Photo Editor SDK for Windows 8. Needless to say, we are excited that through this SDK, the benefits of C++ AMP will be available to millions of Windows 8 customers.

Aviary's simple yet powerful photo editing capabilities is used by more than 35 million monthly Aviary users across 3500+ partners. Apart from releasing the SDK, they also released a Windows store app, Aviary Photo Editor and half-dozen of their partners have released apps (Rowi, Memorylage, MyFrames, Photo Annotater, Selektiv, Volet by Volevi).

The use of C++ AMP is mentioned in both Aviary and AMD's blog posts. To quote

Aviary Blog mentions "….We've achieved significant performance improvements by implementing filters and effects through the new heterogeneous compute language C++ AMP. Computations are performed on the highly parallel graphics processing unit (GPU) cores inside the AMD APU instead of the more serial central processing unit (CPU) cores. Applying CAMP allows for processing of our complete range of filters and effects instantaneously – on average 16x faster than comparable processors, according to benchmark studies conducted by AMD"

AMD's blog mentions "…Since the target was to design a Windows Store app, we used C++ AMP to process the filters and effects on the graphics engine where it can be done much faster than processing on the traditional CPU cores. The end result is a super-fast experience that will delight consumers. "

This is the second post in the series of posts detailing the use of C++ AMP by our customers. As always, we would love to hear how C++ AMP is being used by our customers.

Kinect Fusion Runs on C++ AMP

Boby George (MSFT) — Fri, 29 Mar 2013 18:51:32 GMT

We are happy to announce that the newest feature, Kinect Fusion in the Kinect for Windows SDK 1.7 runs on C++ AMP. Kinect Fusion is a tool that uses Kinect for Windows sensor to create highly accurate 3-D renderings of people and objects in real time.

Using C++ AMP for GPU based reconstruction allows Kinect fusion to provide customers with real time and interactive frame rates on both NVidia (GeForce GTX560) and AMD (Radeon 6950) graphics cards. The below picture, obtained from Kinect for Windows product blog the 3D rendering of a person created using Kinect Fusion.

The MSDN documentation on Kinect fusion shows how within a few seconds Kinect fusion is able to create a 3D reconstruction of a static scene.

In the coming weeks, we will posting a series of blog posts listing how some of our customers are using C++ AMP in their products. So stay tuned!

C++ AMP CPU fallback support now available on Windows 7

Boby George (MSFT) — Tue, 26 Mar 2013 19:40:00 GMT

We recently announced the availability of C++ AMP GPU debugging on Windows 7 and Windows Server 2008 R2 platforms. Now that the RTM version of Windows 7 platform update has been released, we are happy to announce the availability of one more feature: C++ AMP CPU fallback support on Windows 7. So what does it mean?

Earlier, on a Windows 7 machine with no C++ AMP capable graphics card, if you try to enumerate over all the accelerators using accelerators::get_all() function you would have gotten the following output:

As you are familiar, CPU accelerator cannot be used for computation (not yet), while Software adapter (or direct3d_ref) is a single threaded software emulator. While you can run C++ AMP code on the direct3d_ref accelerator, this accelerator corresponds to the DirectX reference rasterizer and is very slow. It is meant to be used for driver validation and for debugging when GPU hardware debugging is not present. So for all practical purpose, there are no accelerators available in Windows 7 other than hardware GPUs. In fact if you run the sample code provided in the C++ AMP book by Kate Gregory and Ade Miller, you will get the message "No accelerators found that are compatible with C++ AMP".

When you install the platform update or Internet Explorer 10, apart from debugging support, you will get the CPU fallback support also. To install the platform update, select the appropriate file to download (based on your machine's architecture) and proceed through the series of steps to complete the installation. Restart the computer when prompted. Run the same code again and you will notice a difference

Apart from ref, there is one more software Adapter present, direct3d\warp. You can learn more about WARP, which stands for Windows Advanced Rasterization Platform (WARP), on this MSDN page. With this update, WARP now support DirectX11 DirectCompute 5.0, thereby enabling support for running C++ AMP code. Please do note that WARP does not have double precision support. As always, any feedback or comments are welcome either below or at the forum.

Using C++ AMP in financial service industry – A Case Study

Boby George (MSFT) — Tue, 12 Mar 2013 17:13:00 GMT

We would like to give a shout out to a C++ AMP case study we released couple of months ago. The case study talks about how CMA, a company that develops pricing solutions and financial data services, used C++ AMP to deliver a faster pricing mechanism without sacrificing accuracy. CMA has been an excellent example where C++ AMP was able to provide a significant advantage to our customers. To quote Moody Hadi, Research Director in CMA “By using C++ AMP, we can generate fast, accurate pricing with less strain on our resources, which is a key differentiator in our segment and helps us provide greater value to our clients”.

Please read CMA’s fascinating story at Microsoft Case Studies Site. The case study is titled Financial Data Leader Shortens Time-to-Market, Increases Speed with Right Tools. We will continue to blog about how our customers are using C++ AMP. So stay tuned!

Update: In response to comments, CMA folks have written an addendum to this case study, which is published in Addendum to CMA's case study blog post.

Harmless DXGI warnings with C++ AMP

Łukasz Mendakiewicz — Tue, 19 Feb 2013 15:00:00 GMT

If you have tried to run C++ AMP program in Visual Studio 2012 on Windows 8 in debug configuration, you might have noticed that after a successful execution there are DXGI warnings reported in the output window. Long story short – there is nothing to worry about; these warnings may be safely ignored. If you are interested in the background, read on for more information.

Fig. 1. Visual Studio 2012 with DXGI warnings visible in the output window.

DXGI

The DXGI acronym stands for Microsoft DirectX Graphics Infrastructure. It is a low-level layer used by DirectX to communicate with the kernel-mode GPU driver. As you may know, C++ AMP implementation provided by Microsoft builds on top of the DirectX stack, thus by extension, on top of DXGI. What is crucial here, is that Windows 8 introduces a new version, DXGI 1.2.

DXGI warnings

When you are working on Windows 8 and running your program in in debug configuration even the simplest code using C++ AMP will result in DXGI warnings being reported in the Visual Studio output window. They will look similar to the following:

DXGI WARNING: Process is terminating. Using simple reporting. Please call ReportLiveObjects() at runtime for standard reporting. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Producer at 0x006C4820, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x006CBB18, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x006E9328, Refcount: 1. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object : 2 [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Process is terminating. Using simple reporting. Please call ReportLiveObjects() at runtime for standard reporting. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Producer at 0x006E9A28, Refcount: 2. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x006EBE50, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object : 1 [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Process is terminating. Using simple reporting. Please call ReportLiveObjects() at runtime for standard reporting. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Producer at 0x00716688, Refcount: 2. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x00718A00, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object : 1 [ STATE_CREATION WARNING #0: ]

To explain the conditions, reporting “live objects” is a part of the debugging capabilities added to DXGI 1.2. You can register for receiving these messages yourself using IDXGIInfoQueue interface or you can rely on them being printed to Visual Studio 2012 output window, which is automatically enabled when you are using DXGI (and by extension, C++ AMP) in the debug mode.

The reported warnings are last chance messages printed during DXGI shutdown. They include all DXGI objects being alive (meaning not released) at that point of time.

Does it mean that C++ AMP runtime is not freeing these objects? Yes. Is it harmful? No, since:

There is a fixed number of such cached objects (consuming small amount of resources), and their count never goes up during the application lifetime.
The resources associated with these objects are automatically reclaimed by the operating system at process exit.

Diving into a deeper explanation

To go a little deeper, the C++ AMP runtime caches some DXGI objects in its static structures to improve performance. For example this includes IDXGIAdapters underlying Direct3D accelerator objects. At a higher level, both the C++ AMP runtime and DXGI are dynamic libraries, where the first is a dependency of any C++ AMP program and the latter is a dependency of the runtime DLL. So far so good, static dependencies of DLLs aren’t the problem, however the situation complicates a little bit when we add truly dynamically loaded (i.e. using LoadLibrary) libraries to the equation. As it happens, the order of their unloading is not defined against other dynamic libraries. And actually they are quite common in C++ AMP programs, e.g. all driver DLLs are currently dynamically loaded by the DXGI. Going back to the C++ AMP runtime implementation, given that we cannot tell whether our DLL is being unloaded before or after the dynamically loaded driver DLL, we cannot safely release any object from it. But as I explained before, it’s not a problem, since the operating system is going to reclaim it anyway.

One solution would be not to cache DXGI objects. That’s a big no-no for us because caching buys us performance, and we (and you) like performance. The other workaround would be to suppress these messages. Unfortunately there is no way to selectively do so, and we do not want to inhibit this mechanism altogether, as some users might be creating DXGI objects themselves for their own use and might benefit from learning about extraordinary leaks.

Remote GPU Debugging on Nvidia Hardware

Paul Maybee - MSFT — Wed, 06 Feb 2013 20:04:00 GMT

The GPU debugger in Visual Studio 2012 (VS2012) can be extended by hardware vendors to debug directly on GPU hardware rather than on a software emulator. Nvidia has built such an extension and has made it publicly available as part of Nsight 3.0 (Nsight Visual Studio Edition 3.0 Release Candidate 1 is available here. It requires you to first register and login to the Nsight Visual Studio Edition Registered Developer Program here).

Once you have downloaded the Nsight 3.0 installer, you can follow the instructions below to begin debugging using Nvidia’s GPUs. Debugging on Nvidia hardware requires two machines: one local machine to run Visual Studio and one remote machine (running Windows 7 or Windows 8) with an Nvidia (Fermi or Kepler) GPU to use as a debugging target.

For debugging purposes, because of current limitations in the driver, the remote machine must be configured with only one GPU card enabled.

Local Installation

1. Run the Nsight 3.0 installer on a local machine with an existing VS2012 installation. Once you have accepted the license terms you will be presented with a feature installation summary that looks something like this.

2. Select “Customize” to install the C++ AMP VS extension to VS2012. The custom setup page allows you to individually select those features you want to install. The item you need is “Nsight C++ AMP Debugger”. Select it, hit Next, and let setup continue.

Remote Installation

On the remote machine a similar installation process is required. Again you run the installer and select “Customize”. This time the item to install is “Nsight C++ AMP Target Support for MSVSMON”.
Disable Tdr (Timeout Detection and Reset) on the remote machine:

Under key HKLM\System\CurrentControlSet\Control\GraphicsDrivers, add TdrLevel (REG_DWORD) and set its value to 0.

Reboot the remote machine so that the new Tdr setting takes effect.

Debugging

Now that the Nvidia extension is installed you can start debugging an application. The general instructions for remote debugging are in the blog post Remote GPU Debugging in Visual Studio 11. The following changes are required:

In Step 1, you cannot use a Remote Desktop Connection to log into the remote machine, you must log into a display that is physically connected to the machine before you run msvsmon.exe.

In Step 2, you will need to:

Set “Debugging Accelerator Type” to “NVIDIA GPU”

Now place your breakpoint, hit F5 and enjoy! Remember that while you are stopped at a breakpoint the GPU is really stopped, so the display will be frozen until you continue.