DirectX 12 & WDDM 2.0: Reworking the Windows Graphics Stack

At a low-level technical perspective, it’s perhaps a bit of a generalization though none the less true that Windows at the kernel is relatively stable and feature complete these days. After the massive reworking for Windows Vista (6.0), Windows finally reached a point where the kernel and other low-level components of the OS supported the necessary features and sported the required stability to drive Windows for generations to come. As a result Microsoft never significantly tampered with the Windows kernel through Windows 7 (6.1) and Windows 8 (6.2/6.3) – making small feature additions where it made sense to – and even the kernel version number of Windows 10 (10.0) is largely arbitrary, with its roots clearly in 6.x.

Which is not to say that Microsoft hasn’t made low-level changes, only that those changes have been more deliberate and driven by specific needs. Case in point (and getting to the subject matter of this section) is DirectX 12 and its underlying driver structure, the Windows Display Driver Model. Even after the release of Windows Vista and its massive overhaul of the graphics stack, Microsoft has continued modifying the stack over successive generations as GPUs have become more flexible and more capable. After a series of smaller changes in Windows 7 and Windows 8, for Windows 10 Microsoft has gone back to make what are the most fundamental changes to the graphics stack since Windows Vista over 8 years ago.

DirectX 12

Microsoft’s changes ultimately reach out and touch several aspects of the OS, but the bulk of these changes are being put in place to support DirectX 12, the next generation of Microsoft’s game & multimedia API. We have covered DirectX 12 in a great amount of detail over the past year, so for deeper coverage we’ll reference the appropriate articles, but in summary here is what DirectX 12 brings to the table and why it is a big deal.

Excerpt from Microsoft Announces DirectX 12

Why are we seeing so much interest in low level graphics programming on the PC? The short answer is performance, and more specifically what can be gained from returning to it.

Something worth pointing out right away is that low level programming is not new or even all that uncommon. Most high performance console games are written in such a manner, thanks to the fact that consoles are fixed platforms and therefore easily allow this style of programming to be used. By working with hardware at such a low level programmers are able to tease out a great deal of performance of this hardware, which is why console games look and perform as well as they do given the consoles’ underpowered specifications relative to the PC hardware from which they’re derived.

However with PCs the same cannot be said. PCs, being a flexible platform, have long worked off of high level APIs such as Direct3D 11 and OpenGL. Through the powerful abstraction provided by these high level APIs, PCs have been able to support a wide variety of hardware and over a much longer span of time. With low level PC graphics programming having essentially died with DOS and vendor specific APIs, PCs have traded some performance for the convenience and flexibility that abstraction offers.

The nature of that performance tradeoff has shifted over the years though, requiring that it be reevaluated. As we’ve covered in great detail in our look at AMD’s Mantle, these tradeoffs were established at a time when CPUs and GPUs were growing in performance by leaps and bounds year after year. But in the last decade or so that has changed – CPUs are no longer rapidly increasing in performance, especially in the case of single-threaded performance. CPU clockspeeds have reached a point where higher clockspeeds are increasingly power-expensive, and the “low hanging fruit” for improving CPU IPC has long been exhausted. Meanwhile GPUs have roughly continued their incredible pace of growth, owing to the embarrassingly parallel nature of graphics rendering.

The result is that when looking at single threaded CPU performance, GPUs have greatly outstripped CPU performance growth. This in and of itself isn’t necessarily a problem, but it does present a problem when coupled with the high level APIs used for PC graphics. The bulk of the work these APIs do in preparing data for GPUs is single threaded by its very nature, causing the slowdown in CPU performance increases to create a bottleneck. As a result of this gap and its ever-increasing nature, the potential for bottlenecking has similarly increased; the price of abstraction is the CPU performance required to provide it.

3DMark 2011 CPU Time: Direct3D 11 vs. Direct3D 12

Low level programming in contrast is more resistant against this type of bottlenecking. There is still the need for a “master” thread and hence the possibility of bottlenecking on that master, but low level programming styles have no need for a CPU-intensive API and runtime to prepare data for GPUs. This makes it much easier to farm out work to multiple CPU cores, protecting against this bottlenecking. To use consoles as an example once again, this is why they are capable of so much with such a (relatively) weak CPU, as they’re better able to utilize their multiple CPU cores than a high level programmed PC can.

The end result of this situation is that it has become time to seriously reevaluate the place of low level graphics programming in the PC space. Game developers and GPU vendors alike want better performance. Meanwhile, though it’s a bit cynical, there’s a very real threat posed by the latest crop of consoles, putting PC gaming in a tight spot where it needs to adapt to keep pace with the consoles. PCs still hold a massive lead in single-threaded CPU performance, but given the limits we’ve discussed earlier, too much bottlenecking can lead to the PC being the slower platform despite the significant hardware advantage. A PC platform that can process fewer draw calls than a $400 game console is a poor outcome for the industry as a whole.

DirectX 12 as a result is the next-generation API that will be providing the basis for graphics going forward in Windows 10. Along with enabling critical improvements in CPU efficiency and scalability in multi-threading, the latest version of Windows’ major graphics API also introduces some other features that further the state of computer graphics. This includes a number of disparate but otherwise “neat” graphics tricks like asynchronous shading to better utilize GPU resources by processing certain classes of rendering tasks in parallel, and explicit multi-adapter functionality that allows the integrated GPUs found on most gaming platforms to be utilized in a meaningful way to contribute to the rendering process, rather than sitting idle as is now the case.

Meanwhile DirectX 12 also introduces some new graphics features that are being rolled out under the feature level 12_0 and 12_1 specifications. These include conservative rasterization for better calculation of pixel coverage, raster order views for better control over rendering order, and even freer resource binding to expand the amount of resources devs can use and how they organize them. And due to the nature of feature levels, most of these benefits are also being exposed in one form or another to the existing DirectX 11 API through DirectX 11.3, though certainly the bulk of their use will be under DirectX 12.

The first commercial DirectX 12 games are expected at the end of this year, with more to follow in 2016. Like so many other elements of Windows 10, ideally Microsoft would like to quickly push development towards this new API, using the free upgrade to quickly build up an established base. With DirectX 11 having taken years to really achieve traction due to the stubborn perseverance of Windows XP, there is a good deal of hope that with the free upgrade there will not be a repeat performance with respect to DirectX 12.

WDDM 2.0

Meanwhile below the API layer, quite a bit of work has gone into Windows at the driver level in order to enable the functionality of DirectX 12. While the full list of these changes are beyond the scope of a simple OS review, perhaps the most important point to take away is that due to these changes, Windows 10 is the biggest overhaul of the Windows graphics stack since WDDM 1.0 in Windows Vista. A big part of this is changes to how virtual memory works, which though largely abstracted from both the user and the developer, is crucial to the performance improvements unlocked by DirectX 12.

However because of these changes, there is a clear division in capabilities between Windows 10 and earlier version of Windows, and for that matter in the drivers for the two OSes. While Windows Vista/7/8 graphics drivers were distributed using a unified WDDM 1.x driver, Windows 10 graphics drivers are being distributed separately as their own WDDM 2.0 build. So much of WDDM 2.0 will be hidden from end users, but this will be one area where though minor, users will notice that something is different.

Memory optimizations and drivers aside, WDDM 2.0 also gave Microsoft the chance to fix some niggling issues in how the graphics stack worked. Quite a bit of effort has been put into multi-display cloning, for example – a feature that never worked quite as well as it should have – with the new WDDM 2.0 stack changing how scaling was being handled so that it’s more useful, more consistent, and works with multiple GPUs. These enhancements are also being deployed to Miracast support, and further improvements are being unlocked there such as support for dynamic resolutions and framerates.

WDDM 2.0 improvements are also an element in enabling Microsoft’s GameDVR feature, which sees game footage recording become an OS-level feature. And for better or worse, WDDM 2.0 also enables some new DRM functionality, which is being deployed as a condition of getting 4K (and above) protected content licensed for use on Windows.

Xbox on the PC Touch-Enabled Office Apps Arrive with Windows 10


View All Comments

  • zman58 - Thursday, October 15, 2015 - link

    "worlds largest and most obnoxious spyware"

    We really don't know exactly what data it sends back on the user and their system(s) do we? The EULA does not detail this for us. In fact, the EULA has you agree to whatever they desire from your system--for improving the product. The spyware option is purely opt-out, for those of us who know what opt-out means and are capable of figuring out how to opt-out.

    Then once you can/do opt-out, how can you be assured you will remain opted-out through upgrades, hot-fixes, patches, and what-not?

    Bottom line is that the vendor decides what and when they want to collect data from your system, you have absolutely no control over them. Read the EULA and consider what it means before you click "I agree". You might not want to click that button...

    Perhaps using an alternative reliable, safe, secure, and private operating system might be a better approach. ...Well hello there Linux.
  • bs grinder - Tuesday, December 26, 2017 - link

  • ddriver - Wednesday, August 26, 2015 - link

    "The privacy concerns are certainly not overblown, but for most people, they will make the trade-off of less privacy if it means an improved experience. The textbook example here is advertising, where in order to deliver relevant ads to the user"

    Ah yeas, I bet the whole world rejoices being able to give up their privacy to be blasted with ads. It is a great trade-off indeed.

    "If you are concerned, the best thing to do is to read the privacy statement and adjust your settings accordingly."

    I bet that's the best you can do, pretending that somehow clicking a button or two magically makes all problems go away

    Also, I see a catch in those "privacy settings". You seem to only be able to turn off "sending MS info", but that doesn't imply that data is still not being mined and sent anywhere else.
  • imaheadcase - Wednesday, August 26, 2015 - link

    You are aware these settings are present in almost almost win OS? The only privacy stuff they collect is related to MS services, onedrive, etc. Just because win 10 gave people options (gasp!) vs win 8 and 7 does not mean those did not, and still do have it. Reply
  • ddriver - Wednesday, August 26, 2015 - link

    No they are not. Especially if you bother to watch what updates you install. For example, MS will try to sneak in the "telemetry" data miner service on your windows 7 as an update, but it is not there to begin with.

    I haven't used and will likely never use a windows version after 7, but in a "clean" windows 7 install none of the win 10 invasions of privacy are present. It doesn't keylog, it doesn't listen to speech, it doesn't analyze text or file content and it doesn't report everything you do back home.

    Oh, and you can also chose not to install certain updates, whereas with the "nice free" windows 10 MS get to deploy on your system whatever it wants - all in the name of your comfort.
  • Michael Bay - Wednesday, August 26, 2015 - link

    Your religious belief in 7 is amusing, at least. Reply
  • ddriver - Thursday, August 27, 2015 - link

    If anyone around here is a believer, that is you, believing MS are trustworthy that is. Reply
  • Gigaplex - Friday, August 28, 2015 - link

    If you don't trust MS, you shouldn't be using any version of Windows. Reply
  • althaz - Thursday, August 27, 2015 - link

    FYI: Windows 7 collects telemetry by default. It was turned off by default in Vista and XP, but most OEMs turned it on for you. So Win 10 is collecting the same information as Windows XP, Vista and 7 (and 8), for most people. Reply
  • yuhong - Friday, August 28, 2015 - link

    Does Win10 really "keylog" outside of search boxes and the like? search suggestions are not new either. There is no evidence that Win10 can read arbitrary files either. Reply

Log in

Don't have an account? Sign up now