Hemant Kumar
b9fa30e549
## Description The WinUI Profiler (`tools/WinUIProfiler`) now also records the kernel's GPU memory events for the target process, live and from `.etl` files. Windows writes them in any WinUI build. ### Current Behavior The profiler reads the target's `Microsoft-Windows-XAML` and `Microsoft-Windows-XAML-Profiler` events. Its only GPU memory data was the profiler provider's `GpuMemorySnapshot` event, stored like any other event, and only from WinUI builds with `XamlProfilerEnabled`. #12416 removed that event. The native GPU sampler reads GPU engine utilization, not memory. ### New Behavior - **Events:** `Microsoft-Windows-DxgKrnl` keyword `0x4`: `VidMmProcessUsageChange` (367) and `VidMmProcessBudgetChange` (366), the process's usage and budget per adapter and memory segment group. They carry the values `IDXGIAdapter3::QueryVideoMemoryInfo` returns. The kernel writes them when the usage or budget changes, and writes the current values when the process opens a GPU adapter and when a session requests capture state. - **Matched by the event's `ProcessId` field**, not the event header: the System process writes some of a process's rows, such as those at exit that bring its usage down to 0. That field becomes the event's process ID; the thread ID stays the writing thread. - **Live:** each connection's session also enables DxgKrnl keyword `0x4`, with no process filter, and requests capture state when reading starts, so an attach gets the current usage and budget at once. Both are best effort: a failure is traced as a warning, and XAML events are read as before. - **`.etl` files:** the target's rows are read along with its XAML events. - **Session files** store them with provider `DxgKrnl`. The schema version is unchanged. - **App:** the connection panel's status line adds a "GPU memory" count, and its tooltip a line for it. - **CLI:** `processes` has a DxgKrnl column. For traces it still lists only processes with XAML or XAML-Profiler events, since every process that uses the GPU has GPU memory events; a session file always lists its process. The usage text and messages say "events" instead of "XAML events". - **README:** the provider and its events, how rows are matched, the live behavior, and a `logman` line for the provider. ## Impact and risk Developer tooling only, under `tools/WinUIProfiler`; no product code changes. Low risk. Session files that contain GPU memory rows can't be read by earlier builds of the tool, which don't know the `DxgKrnl` provider; other session files are unchanged. ## How Has This Been Tested? `tools/WinUIProfiler` has no test project yet. I validated with traces of a 1,000-item ListView test app, from a VM without a GPU (WARP) and from a Snapdragon X Elite laptop (integrated GPU), and live on the VM. | Test | Result | | --- | --- | | `dotnet build .\WinUIProfiler.Cli\WinUIProfiler.Cli.csproj -c Release` | Passed, 0 warnings | | `.\scripts\Build-App.ps1 -Configuration Release -Platform x64` | Passed | | CLI, VM trace | The app's 2 rows: usage 0 and budget 50,680,655,872 bytes, the values of the `GpuMemorySnapshot` events in the same trace | | CLI, laptop trace with the app running | 130 usage rows and 1 budget row; usage from 0 to about 22 MB | | CLI, laptop trace through app exit | 255 usage rows and 1 budget row; the last rows bring usage to 0 | | Which process wrote the laptop rows | The System process wrote 2 of the running app's rows and 127 of its exit rows; the app's own threads wrote the rest. Matching by `ProcessId` keeps all of them | | Live attach to a running app (Core live source, elevated) | The capture-state usage and budget rows arrive; 0 lost | | Live launch (same) | 6,230 XAML events and 2 GPU memory rows; 0 lost | | `logman` with the README's provider lines | Records the app's GPU memory rows | | `record`, then `summary` and `dump` of the `.sqlite` | DxgKrnl rows round-trip; a file with only GPU memory rows lists its process | | Status line strings | `EtwFormat` and `EtwDetailsFormat` format with the new arguments. The App UI itself wasn't driven | Not tested: discrete GPUs (non-local memory), machines with two GPUs, Windows 10.
WinUI
About WinUI · Documentation · Release notes
WinUI is a user interface layer that contains modern controls and styles for building Windows apps. The current generation is WinUI 3, which ships as part of the Windows App SDK.
- Modern UI: WinUI embodies Fluent Design to enable intuitive, accessible, and powerful experiences and the latest user interface patterns.
- Developers in control: Use .NET with C# or C++ to write apps that run great on x86, x64 and ARM.
- Optimized for modern experiences & hardware: Create performant experiences with WinUI that are optimized for modern hardware.
- Part of the Windows App SDK: The Windows App SDK is a set of libraries, frameworks, components, and tools that you can use in your apps to access powerful Windows platform functionality from all kinds of apps on many versions of Windows. The Windows App SDK combines the powers of Win32 native applications alongside modern API usage techniques, so your apps light up everywhere your users are.
- Powers key experiences in Windows: Windows experiences and apps are built with WinUI. Its rich control set and styles make it easy to develop high-quality experiences used by millions every day.
📋 Getting started with WinUI
For WinUI, your app's users must be on Windows 10 1809 - Build 17763 or newer (including Windows Insider Previews).
The full documentation of WinUI can be found on Microsoft Learn:
- Get started with WinUI
- Build your first WinUI app
- Migrate from UWP to the Windows App SDK
- Windows Runtime APIs not supported in desktop apps
- WinUI & Windows App SDK samples
🖼️ WinUI 3 Gallery
Make sure to also check out the WinUI 3 Gallery, our interactive sample experience showing everything you can do with WinUI.
📺 WinUI Community Call
The WinUI Community Call is your opportunity to learn about WinUI and to engage with the WinUI team and community. Join us online on YouTube at the Windows Developer channel.
📢 Contributing to WinUI
The WinUI team welcomes your feedback! To understand how we handle incoming feature requests and bugs, please see our contribution handling guidelines.
For information on how to contribute, please see Contributing to WinUI.
Warning
We're not yet ready to accept code contributions, but we are working towards that goal. It is now possible to build the WinUI product binaries, with work in progress to share test code and enabling locally running tests. To get started building WinUI from source and see more details on current limitations, see Getting started with building WinUI. See the WinUI OSS Update post to check the latest status.
For the latest code and updates, use the
mainbranch.
🛣️ Roadmap
For info on the WinUI release schedule and high level plans please see the WinUI roadmap.
🔧 WinUI for UWP
WinUI for UWP (WinUI 2) is a library of controls that provides Microsoft UI controls and features for UWP apps. Learn more about WinUI for UWP here or download the source code here.
You can get the WinUI 2 Gallery on the Microsoft Store and see the source code here.
Data/Telemetry
This project collects usage data and sends it to Microsoft to help improve our products and services. Note, however, that no data collection is performed when using your private builds.
Code of Conduct
This project has adopted the Microsoft Open Source Code of Conduct.
For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.