Visual C++ Team Blog

New Channel 9 video on the Visual Studio 3D Starter Kit now online

Jennifer Leaf [MSFT] — Fri, 24 May 2013 17:50:00 GMT

If you’re interested in DirectX development, head on over to Channel 9, where there’s a new video about the Visual Studio 3D Starter Kit. This time, Roberto Sonnino interviews Gokhan Sengun, who’s created the Virtual Experiment Laboratory app, which is the first known app on the Windows Store that was built using the Starter Kit - at least, that wasn’t built by a Microsoft employee. :) Gohkan shares some tips on using the Starter Kit, and also some great demos of the Visual Studio Shader Designer.

To learn more about the Visual Studio 3D Starter Kit, check out our previous introduction to the Starter Kit, the 3-part series on the Visual C++ blog and the accompanying video (part 1, part 2, part 3, Channel9 video), or just download the Starter Kit directly.

If you’re working on an app using the Starter Kit, we’d love to hear from you. Leave us a note in the comments!

Image Processing with C++ AMP and the .NET Framework

Eric Battalio — Tue, 21 May 2013 16:28:00 GMT

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.

Speed up Windows PHP Performance using Profile Guided Optimization (PGO)

Ankit Asthana — Wed, 08 May 2013 17:38:00 GMT

To introduce myself I am Ankit Asthana and I am the program manager for the backend C++ compiler. In my last two blogs I provided an introduction to what Profile Guided Optimization (PGO) is all about and a case study which illustrates how PGO is used to make SAP NetWeaver faster. In this blog I would like to present the story about how PGO is used make official Windows PHP binaries faster. Stephen Zarkos (Program Manager for Windows PHP) has been kind enough for providing the content for this blog.

After reading this blog you folks should be able to further understand and use this case study to introduce PGO for your applications. In addition to this, for experienced PHP users, this blog post should serve as an optimization opportunity to further optimize Windows PHP performance for their specific workloads. So let's get started!

As most of you probably already know PHP is a server side scripting language designed for web development but also used as a general purpose programming language. PHP is heavily used today and it powers millions of websites and webservers. In addition to this PHP is also used to power a plethora of open source content management system (CMS) such as Joomla, WordPress and Drupal.

The effort to PGO'ize the Windows PHP binaries was led by Microsoft Open Source Technology (OSTC) group. OSTC's primary goal is to work with open-source communities to help their software interoperate with or run better on Windows Server and Windows Azure. To be precise, this is not the only group at Microsoft that works with open source but amazingly these days is only one of many. A few examples of projects this group works on are PHP on Windows, Openstack with Hyper-V, CoApp (coapp.org) and the Linux Integration Services for Hyper-V and Azure.

Why Windows-PHP team used Profile Guided Optimization (PGO)?

Over the past several years, Microsoft and its partners have worked diligently with the PHP community to improve the experience PHP developers and users have on Windows Server and Windows Azure. As a result newer versions of PHP (i.e. PHP 5.4) for Windows include dramatic improvements that come from a deep collaboration between the PHP Core Maintainers and Microsoft. One factor attributing to a faster Windows PHP 5.4 and 5.5 is Profile Guided Optimization (PGO). The overall goal with this collaboration is to improve PHP on Windows and enable Windows specific capabilities in a way that provides PHP users the same (or better, if possible) capabilities that they see on other platforms.

After having tested the water with using PGO for Windows PHP 5.3, the team was finally able to incorporate PGO for Windows PHP 5.4. Performance is a primary goal for the Windows PHP team which served as the key reason behind PGO'izing the PHP binaries on Windows. PGO provided an important opportunity to optimize the performance of the PHP interpreter without changing any functional behavior.

What are the 'key steps' performed by the Windows PHP team for PGO'izing Windows PHP binaries?

Revisiting my previous blogs, there are essentially three steps required in PGO'izing an application (Instrument, Train and Optimize). Remember the 'Instrument' and 'Optimize' steps require an 'LTCG:PGINSTRUMENT' and 'LTCG:PGOPTIMIZE' build respectively (for more information please take a look at my last blog post).

The steps to PGO'ize Windows PHP binaries are essentially in-line with PGO'izing any generic application and are as follows:

Creating an Instrumented build of Windows PHP binaries (i.e. the Instrumentation Phase)

For those of you who would like to get some firsthand experience in doing this, creating an instrumented version of the Windows PHP binaries requires user to pass the additional '--enable-pgi' parameter to the PHP configure script. After running the configure script just rebuild with 'nmake snap'. For more detailed instructions on how to set this up take a look at this blog post.
Collecting Training Data (i.e. the Train Phase)

This step can be as simple as setting up PHP with IIS or Apache with your PHP application and then accessing the application via a web-browser. A good training session should exercise workflows that your users will hit most often. The Windows PHP team currently trains by having a number of PHP applications preconfigured, for both IIS and Apache (on Windows) and then exercising these applications via requesting specific pages (usually several times for the most used pages) in order to get wide coverage. As of today, the Windows PHP team trains with every snapshot and release build of PHP binaries.

Snapshot builds can happen multiple times a day (depending on the number of commits on that particular day). Every snapshot for PHP 5.4, 5.5 and the Master branch is automated where the build automation goes through the process of creating the instrumented binary, setting up IIS and Apache, running through a series of applications to produce the training data, copying those back to the PHP build directory and then finally rebuilding the optimized PHP.

The end result of the training phase is the "*.pgc" files which are essentially training data files that contain all the information required by the 'Optimize phase'. You need to copy these files back into your PHP build directory for the next phase of the build.
Building optimized Windows PHP binaries (i.e. the Optimize Phase)

A user can build an optimized version of PHP binaries following the simple steps listed below:
a. Copy the *.pgc files back to your PHP build directory
b. Run the command "nmake --clean-pgo" to clean your build directory (but not the .pgc files)
c. Re-run the configure script, but remove the "--enable-pgi" parameter and instead add the "--with-pgo" parameter
d. Run "nmake" and then "nmake snap" to build the final optimized PHP

This entire process can take several hours, depending upon the speed of your build machine. For best results (i.e higher build throughput and maximum PGO performance gains), use Visual Studio 2012 RTM.

What were the 'key challenges' faced by the Windows PHP team while PGO'izing Windows PHP binaries?

The work for PGO'izing PHP began as a proof of concept exercise. The Windows PHP team did some work several years ago to test PGO and see how they can leverage it for PHP. This exercise was useful in finding the following few key challenges which the team addressed when enabling PGO for PHP 5.4:

How to train the PHP binaries: At first it was difficult for the Windows PHP team to understand how best to train the PHP Windows binaries. In particular, 'what training scenarios to run?', 'how long to train for?' and 'what kind of applications to train with?'
Absorbing longer build times: To save man hours, every part of the 'Windows PHP PGO build process was automated. Adding PGO to the build process was a fairly easy exercise, but the main challenge here was to deal with the additional build times required. Given the Windows PHP has various builds (thread-safe, non-thread, and now x86 & x64 for PHP 5.5) to absorb the additional build times they needed to add more/faster build systems, and improve their build automation to support concurrent builds.
Additional quality assurance required: Validating the effectiveness of your PGO training scenario is essential and plays a major part in obtaining maximum performance gains. Good testing is still the key to the success of PGO in PHP. At the time PHP 5.4 was released the Windows PHP team had pretty good test automation and hence were able to identify issues where using PGO changed the behavior of PHP. These issues observed were then mitigated by the use of #pragma statements.

What are the performance gains received by the Windows PHP team by PGO'izing their binaries?

For testing PHP performance, applications such as Drupal, Mediawiki, Wordpress and Joomla are deployed on IIS and Apache webservers. These applications are then stressed using load agents and various metrics such as transactions per second (TPS) are recorded and reported. To better demonstrate the performance improvements we can see with PGO, the 'TPS' for these applications with/without PGO'ized PHP binaries is listed in the table below:

Table 1: Performance gain for applications leveraging PGO'ized Windows PHP 5.5

As you can see some of these results are pretty impressive! A detailed summary of these results which includes some of the gritty details used to generate these results can be found here.

Wrap up

Although Profile Guided Optimization (PGO) is a complex technology, I hope this blog provides you further evidence on the usefulness of PGO and does a fair job in explaining how the Windows PHP team PGO'ized the Windows PHP binaries. In my future blogs I will go over how PGO works under the hood to provide the performance gains enjoyed by a plethora of products out there.

So stay tuned! Additionally, if you would like us to blog about some other PGO-related scenarios or are just curios and have a few more questions about PGO please feel free to reach out to me. I will do my best to answer them.

NuGet for C++ and the Northwest Hackathon

Garrett Serack, MSFT — Wed, 08 May 2013 17:16:00 GMT

Howdy!

My name is Garrett Serack, I'm not actually part of the Visual C++ team--I actually work as a Senior Software Development Engineer in Microsoft's Open Source Technology Center, which is part of Windows Server. I have a distinctly different job than most here at Microsoft-I work to get Open Source software running better on Windows and Azure.

A little over a week ago, I released the beta version of the CoApp PowerShell tools that let us generate NuGet packages for C and C++ libraries.

Over the next few weeks, I'll try to explain what the heck goes on under the covers when creating packages for Visual C++, how you can exploit all of the power of Visual Studio in C/C++ packages and in the process, explore what it would take to manually create packages without the tools.

Today however, I'm here for a slightly different purpose: We're having an Open Source "Hackathon" here on campus this Friday and Saturday (May 10th and 11th), and I'm offering the opportunity for anyone interested in building C/C++ packages with NuGet to come on out, learn, code and have a good time. I'll be on hand all day and into the evening Friday and Saturday hacking away, and helping out anyone who's interested.

Also, folks from the the NuGet team itself will be around, so if you have questions for them, you know where they will be!

We're gonna have a ton of food, prizes, drinks, and a lot of fun. If you're into Open Source, and are in the area, I'd love to have you come out, hang around and write some code!

Don't forget to register!

Fix: Visual Studio 2012 Update 2 breaks Windows XP targeting with ATL and/or statically linking MFC

Eric Battalio — Tue, 07 May 2013 22:25:00 GMT

Recently, some of our customers reported a bug in Visual Studio 2012 Update 2 that breaks Windows XP targeting with C++ in some scenarios. Specifically, applications using ATL and/or statically linking with MFC will get the following error when run on Windows XP:

"The procedure entry point InitializeCriticalSectionEx could not be located in the dynamic link library kernel32.dll."

This issue has been fixed in Visual Studio 2012 Update 3 RC1. If you encounter this issue, please download and install this update.

NuGet for C++

Jennifer Leaf [MSFT] — Fri, 26 Apr 2013 18:23:00 GMT

The wait is over. NuGet support for C++ projects is here.

Quick Links
• NuGet 2.5 Download page: https://nuget.codeplex.com/releases/view/96733
• CoApp’s Powershell Tools Installer to create C++ NuGet packages: http://coapp.org/releases
• Some C++ NuGet packages to try out: http://nuget.org/profiles/coapp/

Start downloading, then head on back here to learn more about NuGet and how to create and use packages for C++ libraries.

What is NuGet?
From the NuGet website:

NuGet is a Visual Studio extension that makes it easy to add, remove, and update libraries and tools in Visual Studio projects... If you develop a library or tool that you want to share with other developers, you create a NuGet package and store the package in a NuGet repository. If you want to use a library or tool that someone else has developed, you retrieve the package from the repository and install it in your Visual Studio project or solution.

If you’ve used NuGet in other Visual Studio projects (say, for C# or JavaScript development), then you’ll have no additional learning curve using NuGet for C++ in Visual Studio - downloading and installing packages works the same way.

With the NuGet 2.5 release, you can download and add libraries to your C++ projects without having to configure properties for include or library directories, and making sure those properties are set correctly in all of your project configurations. For C++, the way we implement this is by generating files with MSBuild properties and targets, and including those files in the NuGet package. When the package is installed and referenced by your project, the MSBuild files are imported into your project file, so your projects will know how to find and use the contents of the NuGet packages. Packages are cached on a per-solution basis – if you’re using the same library in multiple projects in your solution, they’ll point to a common copy of the package.

Check out this post on the NuGet team blog for a more in-depth look at how NuGet for C++ was designed.

Getting Started
NuGet is included in both Visual Studio 2010 and Visual Studio 2012. You’ll need to update the NuGet extension to version 2.5 in order to use the C++ project integration. The NuGet website (nuget.org) has extensive documentation on how to install and use NuGet. You can use NuGet in any C++ project type – this works for desktop, Windows Store, and Windows Phone 8 applications equally.

The NuGet Gallery on nuget.org is the central package repository used by all package authors and consumers. Since C++ support in NuGet is brand new, there aren’t a lot of packages available in the NuGet Gallery yet. However, the CoApp project has created a few packages from open source libraries which you can use right now to get started. You can find their packages on the NuGet gallery here. To find other packages, try using a search on “tag:native” on the NuGet Gallery (this also works when searching for packages using the VS IDE integration), though be aware that not all packages tagged with “native” are actually C++ projects.

Creating packages
If you’re interested in publishing your libraries via NuGet, you can choose to create the NuGet packages manually. However, there’s an easier way. The CoApp project volunteered to write C++ oriented tools to create NuGet packages, and have released a beta version of their tools on their website. These tools simplify the process of generating the MSBuild files and NuGet packages from existing header and library files – you just need to create a configuration script to describe the contents of the package, and then run the tools to generate the NuGet package.

There are tutorials, reference documentation, and a video on how to use the tools to create NuGet packages. The CoApp project organizers also plan to create and publish packages for several open source libraries into the NuGet Gallery over the next several weeks.

At this time, we’re encouraging people to publish packages with the “native” tag to make it easier to find packages you can use in C++ projects.

The CoApp and Openness@Microsoft blogs have additional information about this project.

Feedback
Please leave us feedback here on the blog – we’d love to hear your experiences trying out NuGet in your C++ projects, and whether there are additional features we could add to make this work even better for you. This is just the start of C++ integration in NuGet – we need your input on where we should take this in the future to make working with C++ libraries in Visual Studio easier.

If you have specific feedback or issues with these tools here are direct links to the project sites:
- NuGet project on CodePlex
- CoApp website

Profile Guided Optimization (PGO) drives next generation SAP NetWeaver Performance

Ankit Asthana — Mon, 22 Apr 2013 05:57:00 GMT

To introduce myself I am Ankit Asthana and I am the program manager for the backend C++ compiler. In my last blog I provided an introduction to what Profile Guided Optimization (PGO) is all about with an exercise which involved PGO’izing the NBody sample application. In this blog I would like to talk about how PGO is used within SAP to power and deliver next generation performance for SAP NetWeaver.

Starting with a little bit of history, the effort to PGO’ize SAP NetWeaver was undertaken and completed by SAPs Microsoft Platforms Group. The SAP Microsoft Platforms Group is responsible for Microsoft Windows specific technology within SAP’s kernel. This effort was in particular led by Mike Gusev and Jason Kafka, both senior members of SAPs Microsoft Platforms Group who were also kind enough to provide content for this blog.

With that said and done, let us get started with building some domain knowledge about SAP NetWeaver before we get into how and why PGO was introduced for SAP NetWeaver.

SAP NetWeaver

SAP NetWeaver is an open platform that offers a comprehensive set of technologies for running mission-critical business applications and integrating people, processes, and information. In addition, SAP NetWeaver serves as the technical foundation of SAP's Business Process Platform offerings by providing capabilities for service provisioning, composition (service consumption), and governance.

At the heart of applications running on SAP NetWeaver is SAP NetWeaver Application Server (AS) which serves as the central foundation for the entire SAP software stack. SAP NetWeaver Application Server (AS) comes in two flavors ABAP and Java. AS serves as an abstraction layer and handles calls from ABAP/Java applications to the underlying combination of operating system and database. Each Application server consists of a set of processes. These processes have one of the following roles (Dispatcher, Worker or Background).

An Application Server has exactly one Dispatcher Process and several Worker processes which are needed for load distribution. The Dispatcher process is responsible for spawning additional processes and dispatching requests from the frontend to free Worker processes. The Background process is a special worker process. Each of these processes share the same application code (i.e. are spawned from the same binary) which is called the SAP Kernel.

Why SAP NetWeaver used Profile Guided Optimization (PGO) ?

The primary data loop of the SAP kernel is single threaded by design. Although there exist dedicated threads for signal handling and high precision timing, the core itself is single threaded. The core consists of several modules which are mainly written in C, spanning several million lines of code. Newer kernel generations are designed differently, especially with multi-core machines in mind. Nevertheless the majority of customer base runs SAP NetWeaver products with the above described kernel architecture. Furthermore, the single threaded kernel, consists of a codebase which is extremely hard to refactor and given the very slow (if at all) growth in single core performance of modern CPU's , using PGO was a logical low cost step moving forward in order to gain more performance without redesigning, and possibly breaking, the current software.

How was Profile Guided Optimization (PGO) incorporated into SAP NetWeaver

Before we get dig deep into the how, let us do a recap of how Profile Guided Optimization (PGO) works. There are essentially three steps required in PGO'izing an application (Instrument, Train and Optimize) as shown in figure 1 below. Remember the 'Instrument' and 'Optimize' steps require an 'LTCG:PGINSTRUMENT' and 'LTCG:PGOPTIMIZE' build respectively (for more information please take a look at my last blog post).

Figure 1: Steps involved in PGO'izing an application

When incorporating PGO as a part of their build process the SAP NetWeaver team had the following two goals in mind:

Maintain the current build process!

The first goal was essential and can be applied generically for any product. The SAP NetWeaver team has a huge developer base which relies heavily on a working kernel with the latest changes which is produced by automated nightly builds. The PGO process was enabled as a part of this nightly build. As a failsafe, if any of the PGO steps were to fail (Instrument, Train or Optimize) the build would revert to provide a /O2 build. Alternatively, if any PGO steps were to fail the build could also be reverted back to an /LTCG build in the process retaining most of the performance when compared to an /O2 build.
Automate! Automate! Automate!

As I mentioned, the PGO process for SAP NetWeaver was encapsulated within the automated nightly build process for the SAP Kernel. Although not required, the SAP NetWeaver team went down the approach of automating the PGO process. The major reasoning behind this was that the SAP NetWeaver team did not want to have a dedicated person/team responsible for training the Application Server and moving the resulting performance profiles (.pgd files) into the build process. Additionally adding weight to this goal was the fact that the build processes were supervised by a different department which was not knowledgeable in the art of compiler/linker error analysis or maintaining application server training scenarios.

Again to clarify unless your code base significantly diverges on a daily basis (i.e. lot of churn in the code base) you are not required to perform 'instrument', 'train' steps in the PGO process. An optimized PGO build can be built repeatedly (without the instrumentation and training step) until the source base has vastly diverged from the last time the application was PGO-trained. For large development teams, an ideal workflow is for one developer doing PGO and checking the training data (.pgd) into the source repository. Other developers in the team should then be able to sync their code repositories and use the training data file to directly build PGO optimized builds. When the counts go stale over period of time, the application is PGO-retrained.

Performance Gains observed with PGO'izing the SAP Kernel

Performance gains observed by PGO’izing an application are directly proportional to how well the application was PGO-trained. In other words, the secret sauce behind getting the most out of PGO is choosing the right training scenario. Good training scenarios are typically modeled after real life performance centric user scenarios. There lies a fine balance between choosing a training scenario which is too specialized or too generalized. If it is too specialized, you will only optimize code used within few use cases, if it is too general you might miss that sweet spot which is relevant for most of your customers.

SAP’s Microsoft Platform group chose one of SAP’s Standard Application Benchmarks as training scenario. The benchmark simulates thousands of users performing typical business transactions in parallel. The benchmark puts a massive CPU intensive workload onto the Application Server and executes the relevant code paths in the SAP kernel in the process PGO-training them.

Performance is measured in SAP Application Performance Standard (SAPS) units, which basically describes how many business transactions could be processed per hour by the Application Server.

Using SAP Kernel built with /LTCG as a baseline for performance comparison and using the VS2010 toolset. The performance gain observed with PGO’izing the SAP kernel was up to 20% and in certain scenarios even higher.

Wrap up

This should provide you folks with an idea on how PGO is used to make the SAP NetWeaver more performant. Again to emphasize if your product’s core performance centric scenarios are native and the bottleneck is CPU bound PGO is worth a shot. In such scenarios PGO results in improved performance for a subset of important user centric scenarios without changing the source code of your application.

In my future blogs I will try to cover more case studies for products using PGO and follow it up with a blog on ‘PGO under the hood’. So stay tuned! Additionally, if you would like us to blog about some other PGO-related content please do let me know.

Finding the Visual Studio Command Prompts in Visual Studio 2012

Jennifer Leaf [MSFT] — Fri, 19 Apr 2013 21:59:00 GMT

If you’re using Visual Studio 2012 on Windows 8, you may be looking for the Visual Studio Command Prompt shortcuts. These shortcuts are installed by Visual Studio to run scripts that configure the command line environment to use particular sets of Visual Studio tools, or to use specific versions of the Visual C++ compiler from the command line.

These shortcuts are installed with Visual Studio 2012, but only the “Developer Command Prompt for VS2012” (which is equivalent to the shortcut for the x86 native tools) is pinned to the Start screen by default. The command prompts for the x64 cross tools, the x64 native tools, and the ARM cross tools are installed but aren’t pinned.

To find these shortcuts, you can search for them at the Start screen (just type “VS2012 command prompt” without the quotes while you’re on the Start screen):

If you want to keep them visible on your Start screen, you can right-click on the tile and choose “Pin to Start”:

(Please note: depending on the version of Visual Studio 2012 you have installed, you may not see the same list of command prompt shortcuts. Not all shortcuts are installed with Visual Studio Express versions.)

Developing an app with the Visual Studio 3D Starter Kit, part 3 of 3

Roberto Sonnino - MSFT — Thu, 11 Apr 2013 23:30:00 GMT

Welcome back to our third and final post on using the Visual Studio 3D Starter Kit! If you read our previous posts in this series (here and here), you’ve got an app that has an animated die, and you’re ready to make the last few changes to get this app to run on Windows RT devices and Windows Phone 8.

If you haven’t read the previous posts, you may want to go through these posts and create an app – we’ll be here once you’re ready.

If you're more of a visual learner, you might prefer following Part 1 and 2 in our new Channel 9 video! In less than 30 minutes you'll go from zero to jumping dice!

Final steps for Windows RT

Since current Windows RT devices have a graphics card with D3D_FEATURE_LEVEL_9_1 and the Visual Studio Graphics tools generate shaders for graphics cards with D3D_FEATURE_LEVEL_10_0 and above, there’s one small extra step that has to be done for this app to run on Windows RT: we need to generate a version of the shaders to be compiled for the correct feature level.

To do that, open your mesh (Die.fbx) and click the cube. On the Properties tool window look for a property called Effect. Click the “+” button to the left of that property and select the (Advanced) value. Finally, click the “…” button to open the shader source for the Phong effect.

What you see now is the default shader that Visual Studio applied to this mesh, displayed in the Visual Studio Shader Designer. The Shader Designer allows you to build complex visual effects without the need to learn a new programming language. To learn more about the Shader Designer, check the documentation and walkthrough on MSDN.

What we want to do with this shader is export it to HLSL in order to be able to re-compile it for Direct3D Feature Level 9 graphics cards. The Starter Kit will automatically look for a fallback shader with the same name as the original in case the device does not support D3D Feature Level 10 or higher.

To export this shader, go to the last icon in the toolbar (Advanced) -> Export -> Export as… (see figure below) and save it as “Phong.hlsl” in your Assets folder. Then, add the file to the project by right-clicking the Assets folder on Solution Explorer -> Add -> Existing item… and selecting the file we just exported.

Finally, we need to tell the HLSL compiler that this file is a Pixel Shader. To do that, right-click “Phong.hlsl” on your Solution Explorer and choose Properties. On the Properties page, make sure the “Configuration” drop down is set to “All Configurations” and the “Platform” drop down is set to “All Platforms”, so that the changes we make are applied to all versions of our app.

Then, on the “HLSL Compiler” page, change the Shader Type property to “Pixel Shader (/ps)” and make sure to enable optimizations (set the Disable optimizations property to "No"), like the figure below:

With this step, everything is ready for Windows RT. This app can now be deployed to your favorite device using the Visual Studio Remote Debugging Tools.

Another change you should make before releasing the app for Windows RT is to make sure snap view and portrait mode work as expected. In this case, all we did was to make sure the camera stayed on the same orientation when we change the view, by deleting the following line on the CreateWindowSizeDependentResource() method on Game.cpp:

void Game::CreateWindowSizeDependentResources()
{
    GameBase::CreateWindowSizeDependentResources();
 
    // (snip) Initialize camera...

    if (aspectRatio < 1.0f)
    {
        ///
        /// portrait or snap view
        ///
        m_graphics.GetCamera().SetUpVector(XMFLOAT3(1.0f, 0.0f, 0.0f));

        fovAngleY = 120.0f * XM_PI / 180.0f;
    }

 // (snip) Lights...
}

You can download the project at this state on CodePlex (direct download link below).

Porting it to the Windows Phone

Using the Starter Kit with support for Windows Phone, porting this app to Windows Phone 8 is a breeze. All you have to do is get the Starter Kit, replace the Game.cpp and Game.h classes by the ones you created for this app, add all your assets (in this case, Die.fbx, DieTexture.png and Phong.hlsl), and change the XAML codebehind to call RollDie() when the screen is tapped. Let’s go over this in a short step by step:

Make sure you have the Windows Phone 8 SDK installed on your PC.
Get the Visual Studio 3D Starter Kit with support for Windows Phone and open it in Visual Studio.
In the StarterKitPhoneComponent project, delete the Shared/Animation folder and delete all the assets from the Shared/Assets folder.
Replace the Game.cpp and Game.h files by the ones you created in this tutorial.
Add all the assets used in your game to the Shared/Assets folder in the StarterKitPhoneComponent project: Die.fbx, DieTexture.png and Phong.hlsl.
For Phong.hlsl, on the Properties page, make sure the “Configuration” drop down is set to “All configurations” and the “Platform” drop down is set to “All Platforms”. Then, on the “HLSL Compiler” page, change the Shader Type property to “Pixel Shader (/ps)” and set the Disable optimizations property to ”No”.
In Direct3DBackground.cpp/.h, remove the unused methods: ToggleHitEffect() and ChangeMaterialColor()

In Direct3DBackground.cpp, add the following to the OnPointerReleased() method:

void Direct3DBackground::OnPointerReleased(DrawingSurfaceManipulationHost^ sender, PointerEventArgs^ args)
{
	m_renderer->RollDie();
}

On MainPage.xaml, remove all XAML related to the counters and app bar.
On MainPage.xaml.cs, remove all unused fields and methods.

Done! You can now run this app on the Windows Phone emulator or on your Windows Phone 8 device. You may want to tweak the camera position and field of view to get a bigger die on your phone screen.

You can download the final project on CodePlex (direct download link below).

For the future

This app is now complete, but there’s still a lot that can be done to make it shine on the Windows Store. Here are some initial ideas:

Change the logo, tile icons and splash screen to match the app theme
Create a cool background, and possibly a “table” where the die is resting
Add shadows, reflections and other realistic visual effects
Make the die customizable, translucent, or add rounded edges
Make the app work with more than one die, or with dice with a different number of sides
Add realistic physics elements, such as bouncing, force-based spinning, and collision detection
Save the dice state when the app is suspended and restore afterwards
Save the history of previous dice rolls
Add sensor support to allow the dice to be rolled by shaking the device
Add sound when the dice are rolled
Use the dice roller to implement a board game or a casino simulator…

Wrapping up

In this blog series you saw how to create a 3D app for Windows 8, Windows RT and Windows Phone with the Visual Studio 3D Starter Kit, sharing all the app logic and assets between all platforms. You also learned a little bit about the Visual Studio Graphics tools, and discovered that creating a 3D app is not a mysterious task – you can start without a deep knowledge of 3D modeling, complex math and HLSL, and learn new concepts at your own pace.

We’d love to hear feedback about this walkthrough, the Visual Studio 3D Starter Kit, or what you’d like to see in the future from Visual Studio for graphics development. Leave us a note in the comments!

Very special thanks to Jennifer Leaf for co-authoring the articles and beta-testing the code. Special thanks to Golnaz Alibeigi for all the help with the video, and Bruno Sonnino and Eric Battalio for reviewing the blog posts.

Profile Guided Optimization (PGO)

Ankit Asthana — Mon, 08 Apr 2013 16:21:00 GMT

PGO is a runtime compiler optimization which leverages profile data collected from running important and performance centric user scenarios to build an optimized version of the application. PGO optimizations have some significant advantage over traditional static optimizations as they are based upon how the application is likely to perform in a production environment which allow the optimizer to optimize for speed for hotter code paths (common user scenarios) and optimize for size for colder code paths (not so common user scenarios) resulting in generating faster and smaller code for the application attributing to significant performance gains.

Getting Started

How to build faster and high performing applications with PGO
PGO Walkthrough
[To be published April/2013: PGO under the hood and case studies]

Best Practices

[To be published April/2013: PGO best practices, tips and tricks]
[To be published April/2013: How to analyze your training scenarios when using PGO]

Video Resources

Community

Learn more about PGO, C++ and related developer and technical topics on the community. We are fortunate to have many vibrant communities and hundreds of smart, helpful members willing to engage.

Follow the Visual C++ team on Facebook and Twitter for tips, tricks, updates, links, questions and other information.
Ask questions (and see what other folks have asked) on the MSDN forums or Stack Overflow.
See what Microsoft C++ MVPs are up to.
Attend a local user group meeting. Attend a conference like //build/.
Ping Ankit Asthana (PGO PM) directly with questions, comments, ideas for future content and any other feedback you might have.