SilverLite : avperf

PDC: Deep Dive into building an optimized graphics-intensive SL app

seemar — Mon, 03 Nov 2008 22:57:00 GMT

Thank you everyone for attending. For those who could not make it, you can check out my talk here on channel9, it was PC06:

In this deep dive session we pull the covers off of the layout, rendering, and media pipelines to discuss how things work and how to optimize your application. This session covers how to set goals with your designer and developer teams, what happens behind the scenes with control visuals, the underlying mechanisms of our media stack, and how to profile your application.

My deck is here, my halo video player is here. The instructions to use xperf are available at this post.

Please fill out an eval after watching. I was honored to do a talk at PDC and I do read and appreciate all feedback.

Cheers, S

XPerf: A CPU Sampler for Silverlight

seemar — Thu, 09 Oct 2008 07:59:00 GMT

For those of you who are a) building graphics-intensive applications or b) trying to debug your performance, I would like to introduce xperf and xperfview. These are two profiling tools which can be used to analyze the performance of any Microsoft technology, including Silverlight.

These tools have existed internally for quite some time, and I'm excited to see that they have been released. I use xperf as my first step for profiling any app -- it's a simple CPU sampler and gives you a peek to why on earth something is taking up so many CPU cycles. XPerf plugs into the Event Tracing for Windows library, and listens to all the internally embedded events that all Windows products trigger. With the publicly available Silverlight symbols, you can see how these events line back to what Silverlight is doing under the hood, while your app is running.

Note: with xperf, managed code (your app code) will show up as samples on the methods that your app code calls. XPerf does not have the capabilities to show CPU cycles in managed code.

With XPerf, one can find answers to questions like:

Is my app asking Silverlight to constantly spin on CPU cycles.
Whether one UI layout or design is more expensive than the other.
Whether the time is spent in drawing (agcore.dll), the plug-in’s interactions with (npctrl.dll), or in compilation/JIT (coreclr.dll)
How much is stretching/blending/rotating that video going to cost in terms of CPU cycles? How about if you encode it differently?

Please note that the tools only work on Vista and Windows Server 2k3. For profiling on a mac, see my previous post on how to use Shark from the Apple CHUD tools.

The first-time instructions are as follows:

1. Install XPerf (formerly xperfinfo) and xperfview (formerly xperf) as available here: http://msdn.microsoft.com/en-us/library/cc305187.aspx

[10/9-9am I updated the above link: download link http://www.microsoft.com/whdc/system/sysperf/perftools.mspx]

Close everything that is not user-specific (close VS, but keep your virus checker, etc).

2. Startup your sample

I personally start up my sample without profiling because the startup sampling is very different from that of the runtime.

3. Open an Administrator-level command prompt. Set your symbol path in the cmd shell:
set _NT_SYMBOL_PATH= srv*C:\symbols*http://msdl.microsoft.com/downloads/symbols

This will set your symbol path to point to the Microsoft symbol server. The symbol server hosts debugging symbols for most all Microsoft products.

[update: cd into C:\Program Files\Microsoft Windows Performance Toolkit]

4. xperf -on base

Run the app for maybe 10 seconds for this initial run. We want to understand what method is taking up the most cycles. At the end of this, you will see a graph of CPU usage over time – so you can use various methods to see where time is going: repeatedly execute a user action (expand/collapse, scroll, etc), let the media play for a while, etc. If you are trying to compare several different options, you can execute different actions at widely-spaced intervals, and compare the graphs for each.

5. xperf –d myprofile.etl

Step #4 will both stop the profile and start the writing of the event trace log (etl) file. This can take a while, depending on the complexity of your application, how many other apps were running, and how long the profile extended.

6. xperfview myprofile.etl

We see now see multiple graphs. We are most interested in that of the CPU cycles, which will look something like this:

In my sample, I have a dual-core machine so you see two lines, one for each CPU. This graph is of a media file playing, which should have an almost steady hit for the CPU. I can drag and select any section of the graph and take a closer look:

7. TraceàLoad Symbols

8. Select the area of the CPU graph that you want to see

Right-click and select Summary Table

9. Accept the EULA for using symbols, expand IExplore.exe (or firefox.exe)

At this point, you’ll see how the time breaks down between the different processes and modules running within windows. Agcore.dll, npctrl.dll, and coreclr.dll are all Silverlight.

10. If the symbols server has correctly been set, you’ll see that you can expand and see the breakdown of time in each method call within agcore.dll:

The way to read this graph is that IE is taking up 40% of the CPU on average, during the selected sample. Within that, 32% of the time is spent in Silverlight core (graphics/decoding/property engine, etc are all represented in agcore.dll), and then of that time, 29% (9.24/32.33) of the drawing time is spent in one method call.

Note: with xperf, managed code (your app code) will show up as samples on the methods that your app code calls. XPerf does not have the capabilities to look at app code.

Now what? Well, with just the above think about how you can answer the questions at the top:

Is my app asking Silverlight to constantly spin on CPU cycles.
Do I see activity when the app does not seem to be doing anything? Where does the summary table say that time is going? Perhaps turn on EnableRedrawRegions and see if there is a draw being forced.
Whether one UI layout or design is more expensive than the other.
When I scroll now, is my average CPU higher or lower than before?
Whether the time is spent in drawing (agcore.dll), the plug-in’s interactions with (npctrl.dll), or in compilation/JIT (coreclr.dll)
How much is stretching/blending/rotating that video going to cost in terms of CPU cycles? How about if you encode it differently?
Are there new methods that you see in the stack, now that you have stretched the media? Blended it? What is the average time for CPU cycles compared to your baseline? I know that it is cheaper for me to embed an icon overlay directly into the video, but what does it really cost in terms of CPU time?

Note: The tools only work on Vista and Windows Server 2k3

For later usage, your usage pattern is quicker:

Set your symbol path in an Admin-level cmd shell:
set _NT_SYMBOL_PATH= srv*C:\symbols*http://msdl.microsoft.com/downloads/symbols
xperf -on base
xperf –d myprofile.etl
xperfview myprofile.etl

The platform code and the CPU samples will change version to version, so please keep that in mind when profiling between upgrades.

See anything interesting? Drop me a note!

Have fun!

.seema.

HW Acceleration of Layered Windows - Good news!

seemar — Mon, 02 Jul 2007 22:05:00 GMT

Good news! A QFE has been released to enable WPF HW acceleration on layered windows on XP:

http://support.microsoft.com/kb/937106/en-us

enjoy!

Layered windows...SW is sometimes faster than HW

seemar — Thu, 26 Oct 2006 03:43:00 GMT

Previously, I had posted that Avalon’s layered windows on XP will be rendered via the software pipeline. One can create a layered window by setting Window.AllowsTransparency="true". I’ve seen a few forum posts about performance issues, and the key takeaway point is that your mileage will vary depending on your video card.

In order to render layered windows via our hardware pipeline, we need to circumvent the fact that DX Present cannot handle a window with transparency. Instead of using DX present, we render via DX, grab the surface (via GetDC) and present with GDI. GDI is not hardware accelerated on the Vista WDDM video driver model. The above results in a chain of bitblits from video memory to system memory to video memory which creates a performance hit on many video cards. However, with a unified memory model (eg. Intel Lakeport 945g), the rendering of layered windows is faster in hardware than in software, as the bitblit goes from system memory to system memory.

To substantiate the performance hit that could arise from the aforementioned bitblit chain with a few numbers, I did a bit of testing on a card without a unified memory model (nvidia geforce 6800, WDDM video driver). My setup is a recent Vista build, Aero Glass theme, 2.5GHz P4, 1.5 GB RAM, single-monitor, single-video card.

Animating the translation
Scenario: Translating a single 50x50 rectangle around a 300x300 semi-transparent window
Observed: Framerate with hardware acceleration was at ~50 frames/sec. With software, ~ 60frames/sec.

Resizing, forcing an entire redraw
Scenario: With the mouse, resizing an empty 300x300 semi-transparent window with no window style to 300x600
Observed: Framerate was ~8 frames/sec when hardware accelerated. With software, ~60 frames/sec.

Frames with sufficiently complex rendering, particularly 3D, can pass the inflection point and will see a boon to having hardware accelerated layered windows. For layered windows with simple 2D content, our hardware codepath has typically a worse framerate than the software rendering codepath on the video cards without a unified memory model. The enabling of layered windows came late in the game for v1, and we’re looking at developing a more refined codepath for rendering layered windows in vNext, stay tuned.

Key takeaway: a semi-transparent window is a particularly complex feature for WPF's rendering system. Figure out early what type of hardware that you expect your app to run on, the performance that is acceptable for your users, and whether you want to use Window transparency.

Avalon Hardware Acceleration & Video Driver Compat

seemar — Tue, 06 Jun 2006 03:51:00 GMT

Hello. Seema Ramchandani here, PM of the Avalon 2d & 3D graphics team.

Many people have asked me about what is this celebrated feature called “Hardware Acceleration”. In this post, “hardware acceleration” refers to harnessing the GPU to render, leaving the CPU free for other calculations.

In Beta 2, Avalon attempts to hardware accelerate rendering on machines with video drivers newer than November 2004. Video drivers are implemented and made available by the video card manufacturers.

Our (my team’s and my) foremost goal is to ensure a stable and performant experience for as large portion of our users as possible. I’ve personally uncovered a few driver bugs in testing Avalon, and we want to make sure that the Avalon experience is not just performant but stable as well. Looking at the machines in my parent’s home, I know that a large portion of users have the same drivers that shipped with the computer. Some of our users with 2 year old video cards may not get hardware acceleration, but they will get a stable experience.

In Avalon, we offload the rendering costs of many features to the video driver, but we first check the date of your video driver and what it can handle. We run a basic rating of the driver from 0-2 and store the value as RenderingCapability.Tier. What Avalon hardware accelerates does not change between XPDM and WDDM, it changes based on how we rate the actual video card: does the card support PixelShader 2.0, have X Mb of RAM, etc…

Check out the SDK article: Graphics Rendering Tiers[1]. Due to the memory virtualization features of WDDM, we do not have a VRAM requirement for WDDM drivers.

POR for Hardware Acceleration

For Beta 2, we accelerate the rendering of Avalon graphics on GPUs with:

- WDDM drivers of all dates

- XPDM drivers more recent than November 2004, regardless of the OS.

For RTM, we might change the Hardware acceleration story, and I will update this posting. Changes would be in response to analysis of crash reports from our Beta release.

What are XPDM and WDDM? Their differences?

- XPDM: The Windows XP Display Driver Model.

- WDDM: The Windows Vista Display Driver Model. [Microsoft.com]: WDDM is a significant evolution of the graphics driver infrastructure and will not be backwards compatible with XPDM drivers.

The WDDM video driver model is only available on Vista machines; XPDM video driver model is available for both Vista, XP, and Server 2003 machines.

The DirectX team and the video card manufacturers have worked hard to bring the WDDM model to fruition, which brings a more reliable and stable graphics environment. For example:

- WDDM virtualizes their video memory: with this feature, your Avalon app is less likely to run out of video memory and fallback to software.

- A larger portion of the WDDM driver code is run in user mode rather than kernel mode (as opposed to XPDM); if the driver crashes in the kernel, the machine blue screens.

3D Anti-Aliasing Story
Avalon only offers 3D-Antialiasing on WDDM drivers. WDDM offers a more stable model and video memory management, both of which are more desirable when using 3DAA.

Avalon 3DAA stresses video drivers in a way that, up to the release of the Windows Driver Kit, has not been heavily tested before. When it came between our XP users’ computers bluescreen or seeing aliased 3d, we chose aliased 3d. More to come on this topic later.

Why do we enforce a driver date check on XPDM drivers?

Standard DX GPU usage, before Avalon, was largely graphics-heavy games. In our testing, we uncovered bugs in older, XPDM drivers that were not seen by users. Most video driver bugs are never detected by the user, but interacting with some can result in rendering artifacts and/or crashing of the video driver.

A kernel level crash is bad news. We do not want users to blue screen.

In November 2004, Microsoft released a new version of the driver testing guidelines; the drivers written after this date offer better stability. Avalon will use the hardware acceleration pipeline for these drivers and will fall back to software rendering for drivers that do not meet this date.

- Most machines released after November 2004 will have an acceptable driver out of the box

- Users can also update their drivers by visiting the video card manufacturer’s website.

How do I find the date of my video card driver?

In a cmd shell, run “dxdiag” and go to the Display tab. Some Vista users will find that their video drivers have not been published yet. J

I think my video driver has a bug, how can I tell?

When you see rendering artifacts of an Avalon application, the bug might be in several layers of the Avalon, DirectX, video driver rendering chain. The first debugging step to take is to see if the bug repros without your video driver involved; try turning off Avalon hardware acceleration[2] and compare the rendering with and without hardware acceleration enabled.

If you see a difference, first visit your video card manufacturer’s website and downloading the latest video drivers for your card. If you still see a rendering difference between your Avalon app with and without hardware acceleration, please report the bug via Microsoft’s ladybug tool and attach:

- Your driver information[3]

- Description of expected and actual rendering

- Simple application that repros the behavior (xaml-only is preferred)

- Screenshots of both behaviors, if possible.

Links of Interest

- Greg Schechter on WDDM & DWM
http://blogs.msdn.com/greg_schechter/archive/2006/04/02/566767.aspx

- Windows Driver Kit
http://www.microsoft.com/whdc/DevTools/default.mspx

- Submitting a bug report to Avalon
http://lab.msdn.microsoft.com/productfeedback/default.aspx

- PCI Express FAQ off of Microsoft.com
http://www.microsoft.com/whdc/device/display/PCIe_graphics.mspx

[1] http://windowssdk.msdn.microsoft.com/en-us/library/ms742196.aspx

[2] To disable HW acceleration for Avalon on a machine, add the following to your registry: [HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics]

"DisableHWAcceleration"=dword:00000001

To re-set HW acceleration, delete the above registry key or replace the above with a 0 value:

[HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics]

"DisableHWAcceleration"=dword:00000000

[3] Run “dxdiag /t” in a cmd window. Save the outputted file “dxdiag.txt” to the bug; this file has the information of your video card manufacturer, the name of your card, the driver date, and the driver version number.