The role of the Windows Display Driver Model in the DWM
The Problem
Ever since the advent of dedicated graphics processors, even old-school graphics processors that only accelerated GDI blits, the way you would program against them would be similar to how you programmed against the main CPU/memory system before there was virtual memory or interruptible/preemptible processes. That is, you'd have to be sure to directly manage all the video memory yourself, and just count on not being able to have your graphics instructions interrupted. Specifically, DirectX applications have always needed to deal with not getting the video memory they need, or deal with "surface lost" messages from video memory that got kicked out for one reason or another. This puts a major burden on the programmer, and, probably even more importantly, makes for a very poor ecosystem for running multiple video-memory resource intensive applications, because their likelihood of cooperating in a sensible way on resource management is virtually nil.
Well, the DWM is a DirectX application with a couple of unique challenges in this arena:
- The memory requirements on the DWM vary widely. That's because they vary directly with the number of windows the user has open, and while there are known typical usage patterns, the user certainly isn't and cannot be limited to N open windows.
- The DWM operates in an environment where other DirectX applications do operate. Video playback, WPF applications, windowed games (btw, Vista "inbox" games like Solitaire, etc., are now written in DirectX), etc. In fact, the DWM is responsible for the final presentation of those applications. So it's critical that such DirectX applications "play well together" and play well with the DWM.
The above challenges don't mesh well with the DirectX described in the first paragraph.
Enter WDDM
It's the Windows Display Driver Model (WDDM, formerly known as LDDM) that makes all of this viable. WDDM is the new DirectX driver model for Windows Vista and beyond. From the perspective of the DWM it does three main things:
- Virtualizes video memory.
- Allows interruptibility of the GPU.
- Allows DirectX surfaces to be shared across processes.
The surface sharing feature is key for redirection of DirectX applications, but that's the topic of a later post. Here we're going to discuss the first two. There are other motivators for, and certainly a lot more details on the WDDM, but those aren't as immediately relevant to the DWM as what's discussed here.
Virtualizing Video Memory
With the WDDM, graphics memory is virtualized. This means that just like system memory, if there is a demand for memory and the memory is all allocated, then secondary storage is turned to, and the system manages all the paging algorithms and mechanics for faulting in the secondary storage into the primary storage when it needs to be operated on. In the case of video memory, the primary storage is video memory, and the secondary storage system memory.
In the event that video memory allocation is required, and both video memory and system memory are full, the WDDM and the overall virtual memory system will then turn to disk for video memory surfaces. This is an extremely unusual case, and the performance would suffer dearly in that case, but the point is that the system is sufficiently robust to allow this to occur and for the application to reliably continue.
The upshot of all of this is that applications don't need to be greedy to get all the memory they need, since they won't be guaranteed true video memory anyhow, and they can always be paged out. This brings the goal of a cooperative set of DirectX applications much, much closer to reality. It also means that there are effectively no more "surface lost" messages from DirectX, and no failed allocations.
From the DWM's perspective, this is all absolutely key because the DWM can and will allocate memory, and those memory allocations will be done in conjunction with allocations for other applications on the system, putting the "right" surfaces into the true video memory, and paging in and out as necessary. Now, naturally, this is a little bit of a naive viewpoint, since this is the first generation of this virtualizer, but we're observing it to be doing quite well, and it will keep improving.
Interruptibility of the GPU
So, memory's virtualized, that's good, but what about those little computrons that run around the GPU doing stuff? Can one application's GPU commands be preempted by another application? Prior to WDDM, they could not. With WDDM, they can be. This is referred to as WDDM scheduling, and WDDM arbitrates usage of the GPU, giving computation to the different applications requesting it. In order to do this, WDDM must be able to interrupt a computation going on on the GPU and context switch in a different processes operation. WDDM defines two levels of interruptibility to support this.
- Basic Scheduling - this is the granularity of scheduling achievable in DirectX 9 class WDDM drivers and hardware, and means that an individual primitive and an individual shader program cannot be interrupted, and must run to completion before a context switch.
- Advanced Scheduling - this is achievable in DirectX 10 class WDDM drivers and hardware, and here the GPU can be interrupted within an individual primitive and within an individual shader program, leading to much finer-grained preemptability. Note that while DX10 supports advanced scheduling, it's not a requirement for DX10 -- that is, only certain hardware will support it.
The Desktop Window Manager uses DirectX 9, and thus Basic Scheduling. So it's possible that an application that makes errant use of the GPU and uses complex shader programs across large primitives can potentially glitch the DWM. We have yet to see such applications, but there no doubt will be some that either do this unintentionally or are built specifically to do this. Nonetheless, we don't believe that this will be a common issue.
Comments
Anonymous
April 02, 2006
Wow, this is very interesting, it also explains why it is necessary to have a different model, especially with Windows Presentation Foundation being implemented over as DX10 surfaces..Anonymous
April 02, 2006
Ленин и Партия будущей версии Microsoft Windows — Оконный менеджер рабочего столAnonymous
April 02, 2006
Greg Schechter has an interesting write-up on the Role of WDDM in the Desktop Window Manager.Anonymous
April 02, 2006
Could you tell us what we've seen so far? What is used in 5308 and 5342? The flip 3d doesn't look very nice.. No Anti Aliasing and the preview tumbnails they look a bit blurry. Do you have plans to improve this? And what's next?Anonymous
April 03, 2006
Олег Михайлик, ура, ура, ура! Партия и родина тебя на забудет! А про DWM надо читать на TheVista.ru ;-)
Greg Schechter, thanks for this article, very nice story.Anonymous
April 03, 2006
<ul><li> <a href="http://blogs.msdn.com/greg_schechter/archive/2006/04/02/566767.aspx" target="_blank">The role of the Windows Display Driver Model in the DWM</a><br/></li></ul>Anonymous
April 03, 2006
Interesting piece, many thanks. I'd love to have been present at the early "Is this actually do-able" meetings.Anonymous
April 03, 2006
It seems to me there is at least one more challenge not being addressed above : GPU heat. What about Vista DWM on laptops, Tablet PC and other form factors? What about a combined multi-core board with DWM in terms of heat?Anonymous
April 04, 2006
PingBack from http://pcwinvista.com/understanding-wddm-in-the-desktop-window-manager-5.htmlAnonymous
April 05, 2006
The comment has been removedAnonymous
April 05, 2006
What do you mean by "there are effectively no more "surface lost" messages from DirectX"? "effectively" in that sentence looks to me like there are surface lost messages but it only occurs because you allow applications to allocate more memory than can actually be committed somewhere. I hope I am wrong and there is none of this behavior at all.Anonymous
April 05, 2006
PingBack from http://ungroundedoutlet.com/blog/?p=28Anonymous
April 05, 2006
So, the WDDM would allocate a buffer for each window. Sounds simple, but how much memory to allocate? When the window is resized, the requirements would change, and it reallocating the buffer on the fly would be absurd. So... allocate enough space for a fullscreen-sized buffer?
If so, then:
1 window @ 1280x104 x 32bpp = 5.2MB
10 windows = 52MB!
This can't be right.Anonymous
April 05, 2006
It is right... that's why MS didn't try this in the days of 8 MB RAM - Windows 95.Anonymous
April 05, 2006
Aleko: 52MB? It far worse than you think :-)
Background apps don't receive WM_PAINT messages when they are revealed by a window moving above them. This necessitates that the window contents is buffered. For this to buffer to be always available, the application can't render directly to it or you would see incomplete rendering. So each window needs to have 2 buffers - one for rendering, one for the DWM to access. Unless something sneaky is going on involving serialisation of rendering... Greg?
Resizing is an interesting question though. Does Vista allow the window contents to be shown when resizing? Because that sounds hard to do without frequent reallocations or fullscreen buffers. I guess you could fake it by performing an imaging operation to scale the original backbuffer onto the on-screen location whilst resizing. Then you could properly redraw the window using its new size after the resizing drag is completed. That way you only need to reallocate the backbuffer once.Anonymous
April 06, 2006
Eh... the memory is to be expected. If you want the next generation of apps, get the next generation of hardware.Anonymous
April 06, 2006
The comment has been removedAnonymous
April 08, 2006
I'm really enjoying this series of articles. No one else seems to be covering this in such detail so your blog is a unique goldmine of Avalon goodness. Thank you and keep up the great posting!Anonymous
April 09, 2006
Like Stephane Rodriguez points out: what about Laptops? Battery life and heat? Using the GPU when on battery brings my laptop battery life from 3.30 hrs to 1.30...Anonymous
April 20, 2006
Here's a list of topics that I have posted on (with active links) or expect to post on (without links)...Anonymous
May 01, 2006
The comment has been removedAnonymous
May 02, 2006
As mentioned in earlier posts, by far the most important aspect of the DWM is the fact that application...Anonymous
May 02, 2006
Windows Display Driver Model – z tego co rozumiem, ma on możliwość współdzielenia obszaru pamięci DirectX...Anonymous
June 05, 2006
Hello. Seema Ramchandani here, PM of the Avalon 2d &amp; 3D graphics team.
&nbsp;
Many people have...Anonymous
June 07, 2006
When talking about WPF during the Windows Vista ISV Touchdown training a lot of people were interested...Anonymous
June 16, 2006
&nbsp;
I’ve been getting a lot of the same performance questions over the last few months regarding...Anonymous
November 19, 2007
Hello. Seema Ramchandani here, PM of the Avalon 2d & 3D graphics team. Many people have asked meAnonymous
May 31, 2008
PingBack from http://malachi.newsdigestworld.info/mswindowsdisplayistoolarge.htmlAnonymous
January 21, 2009
PingBack from http://www.keyongtech.com/2972972-freecellAnonymous
June 18, 2009
PingBack from http://thestoragebench.info/story.php?id=9743