Windows 7核心图形架构细致分析

深度解读 - Windows 7核心图形架构细致分析

编辑：马志文

时间： 2009-12-29

连接：http://technet.microsoft.com/zh-cn/library/ee921514.aspx

如现在大家所想的那样， Windows7 其实是 Windows Vista 的改进版。 Windows 7 在 Windows Vista 的基础上进行了大量的完善工作，也加入了不少新特性。 Vista 与其上一代 XP 相比，提供了非常大的改进，然而一方面这些改进过于巨大，用户乃至相应软件厂商（如， DirectX 10 应用开发商）一时无法完全接受，另一方面，由于特性的不完全具备， Vista 的表现没有想象之中的那么好。到了 Windows 7 ，包括操作系统本身、软件厂商和用户都已经做好了准备，因此反响比 Vista 更好也就不难理解了。

图形界面一直是 Windows 系统的核心，而从 Windows Vista 开始， Windows 就开始将提供一个富图形化的桌面图形界面作为要目，不仅仅是因为 Vista 和 7 的桌面本身就是一个 3D 应用程序，而是因为 Vista 和 7 可以更好地发挥图形加速硬件的作用。从 Windows Vista 到 Windows7 ，操作系统与 GPU 的结合越来越紧密。

虽然人们经常可以听到 Windows7 的大更新在于一个 DirectX 11.0 API ，然而对于 Windows 系统的图形架构来说，虽然 DirectX 也很重要，不过这还不是全部。一个图形架构包括了如何利用 GPU 加速各种各样的图形应用（ 2D 、 3D 、打印等）、如何显示到最终显示设备上，以及包括设备检测、控制。 Window 7 在图形架构方面的更新主要有如下方面：

WDDM 1.1 ：新的驱动模型
DirectX 11 ：更新的 Direct3D 11 ，以及相关的新 Direct2D API
DXVA-HD ：高清视频回放加速
显示设备连接和配置
色彩管理
高 DPI 输出和可读性
多 GPU 系统
联合显示适配器（又叫联合渲染）

下面，会就这些改进进行简单的介绍。

Windows 7 核心图形架构

Windows 应用程序使用各种如 GDI （ Graphics Device Interface ， 2D 时代系统的主要图形接口）、 Direct3D 、 OpenGL 这样的 API 和系统图形组件通信，而系统组件通过 WDDM （ Windows Display Driver Model ，又名 Longhorn Display Driver Model ）与硬件交互，从 Vista 起， Windows 就采用了和 XP 使用的 XPDM 不同的新的驱动模型： WDDM ，使用的驱动模型在很大程度上决定了一个系统的图形特性。 Vista 使用的 WDDM 版本为 1.0 ，而 Windows7 使用的改进版本为 WDDM 1.1 。

WDDM 1.1 带来的改动挺多的，下面我们先来看看 WDDM 1.0 相对 XPDM 的改动，也就是 Vista 相对 XP 的改动

  
XPDM ：非合成模型

 

WDDM ：合成模型

  在垂直同步之谜 XP/Vista 与 3D 性能测试中，笔者解释过 XP/Vista 的模型的不同之处，在 WDDM 模型下，所有的应用程序生成的显示画面最后会在 DWM （ Desktop Windows Manager ，桌面窗口管理器）内进行合成为单一的最后输出画面，因此获得了更好的显示效果（天生的所有程序垂直同步）、额外效果（缩略图、缩放）以及可以支持更大的左面，不过，原始的 WDDM 1.0 只是实现了这个大架构上的转换，细节上仍未够完美：

  

在 Vista 下， GDI （绘制通常的 2D 窗口的 API ，此外还有很多其他图形操作使用 GDI ）和 DirectX （ 3D 应用 API ）具有着不同的处理方法： Direct3D 是硬件加速的，而 GDI 则不是（ GDI 在 XPDM 时是硬件加速的），因此 Vista 用户在一些图形程序上会感到比 XP 慢；而且 GDI 应用程序先经过 CPU 软件处理到系统内存上，再传输到显卡驱动分配的 GDI 显存区域上（也在系统内存当中），再由 DWM 负责将画面合成输出到显示器

Windows 7 当中， GDI 获得了硬件加速（这个见下面） —— 不过在混合使用 GDI 和 Direct3D API 的时候， GDI 仍然无法硬件加速，不过， GDI 直接输出到驱动的 GDI 显存区域，减少了一个步骤，同时降低了内存消耗（同时对混用的 Direct3D API 也有效）；显然，混合食用 API 来进行图形编程并不是一个好主意（当然，同时使用 GDI 和 Direct3D 意味着这个是一个老的、窗口模式的 3D 应用程序，如 Windows 模式的老 3D 游戏）

老的 WDDM 1.0 处理 GDI 应用程序就如前面说过的一样

而在 Windows 7 WDDM 1.1 模型当中，单独的 GDI 将会通过 WDDM 与 GPU 进行硬件加速，同时经过 GDI 显存区域输出到 DWM ，表现在实际操作上，就是大部分窗口操作都变得比 Vista 更流畅，日常工作更快捷（大部分 2D 应用程序都使用了 GDI API ，因为 GDI 包括的内容太多，因此必须对其保持兼容；关于 GDI ，后面还有相关内容）

Windows XP 的Direct3D/GDI驱动架构

Windows Vista 核心图形架构，比起 XP 来要丰富了很多

Windows 7 核心图形架构，老的 GDI/GDI+ 仍被单独支持，不过， Windows 7 提供了它们对应功能的新的实现方法相比 Vista 带的 DirectX 10 ， Windows 7 自带了 DirectX 11 ，和 WDDM 1.0 到 1.1 的变化不同， DirectX 11 的版本号表示其变化更大一些。 Windows 7 DirectX 11 改变了以往的工作模式，将 Direct3D 10.1 升级到 Direct3D 11 ，同时将以前 Vista 无法硬件加速的 GDI/GDI+ 的工作重新划分、引入新的 Direct2D 和 DirectWrite API 来完成：

以前的图形操作大部分由 Diredt3D 和 GDI/GDI+ 完成（此外还有一个 WIC——Windows Image Component ，管理扫描、打印和图形解码等工作），而在 Vista 当中， GDI 是无法硬件加速的 —— 因此 Vista 显得很慢，在 Windows 7 中， GDI 的工作除了通过 WDDM 模型的改变获得硬件加速之外，它们还按照面向的应用重新划分为 Direct2D （ 2D 加速）、 DirectWrite （文本处理）和 DXGI 1.1 （设备控制），这些新的 API 或者新分配到的 API 具有着硬件加速，例如， Direct2D 就实际上是通过 Direct3D 10 来完成加速：

Direct2D ： 
硬件加速的即时模式 2 维图形 API ，它在 2 维几何图形、位图和文本方面有着较高的性能和质量。 Direct2D API 是设计与 GDI 、 GDI+ 和 Direct3D 之间进行互操作的。

DirectWrite ： 
DirectWrite 提供高质量的文本呈现、具有独立分辨率的轮廓字体、完整的 Unicode 文本以及布局支持。在使用 Direct2D 的时候， DirectWrite 是硬件加速的。

当系统不支持 Direct3D 10 的时候， Windows 7 会通过一个额外的 10Level9 软件层使用 D3D9 来完成工作，显然，为了最好的效率，你需要使用 Direct3D10 的显卡，因为 Windows 7 的 DWM 基于 Direct3D 10

字体抗锯齿： DirectWrite 效果

Direct3D 11

Windows 7 带的 Direct3D 11 是 D3D10 的超集，它的特点是可以同时支持运行在 Direct3D9 和 Direct3D10.1 硬件上，实际上， DirectX 11 会提供 Vista 的支持，而不是像 Direct 10 出来时那样，只支持 Vista 而无法兼容上一代系统，这导致了软件开发厂商们向 DirectX 10 转移的缓慢。 DirectX 11 支持多个硬件平台和多种操作系统的特性让其更容易被接受。同时 Direc3D 11 本身也具有这不少的改进，这一点会有专文讨论（计划中），这里先谈论 Windows 7 对整个图形操作的改进，通过更多地将 GDI/GDI+ 纳入 DirectX 体系获得硬件加速，图形界面的性能会越来越好（当然，这需要软件厂商们使用新的 Direct2D/DirectWrite 进行编写）。微软希望将所有的图形操作都构建在 DirectX 之上。

通过 Vista 中缺失的 GDI 硬件加速纳入到 DirectX 体系中重新获得硬件加速，并且性能要更快；未来显卡厂商们将不再需要提供 GDI 加速

显示技术  

Windows 7 支持一系列的显示技术，包括将数字输出作为原生输出（支持 HDMI 和 DisplayPort ，而老的 VGA 模拟输出被建议弃用）， Windows 7 还原生支持更多的内容来源，如 Blu-Ray 、 JPEG-XR 、 HDR 图片等。

Windows 7 使用默认的 sRGB 色彩空间作为所有设备都统一的工作流，但是精度提升到 30 位 —— 每一个色彩通道都增加了两位； Windows 7 最高支持 48 位的 scRGB 模式，高精度＋扩展范围＋高动态

  
WDDM 1.1 要求驱动支持 BGRA ， BGRA 是最快的色彩格式

显示设备连接和配置  

在 Windows 7 中，所有的应用程序都在一个统一的虚拟桌面中显示，这个虚拟桌面分辨率为 64Kx64K （ 65536x65536 ）

虚拟桌面按照显示器分为不同的视图，每一个视图对应一个适配器；一个适配器并不意味着一块显卡，一块显卡连接多个显示器的时候，它就含有多个适配器，类似地， SLI 或者 CrossFireX 连接的单显示器就意味着其是一个单一的适配器（从 Vista 开始加入，叫做 Linked-Adapter 特性）

不过，在 Vista 下，无法使用多块不同 GPU 厂商的显卡，而 Windows 7 则可以  

在 LDA 配置下，程序界面在不同的输出中漫游基本上是透明的，叫做 Dynamic adapter switching 动态适配器切换

在多显示器下， Windows 7 提供了一个新的全局快捷键功能： Win + P ，可以快速设置多显示器工作状态，这个快捷键本来是特地为了投影仪应用而设计

总的来说， Windows 7 的图形架构比起 Vista 来更加完善，应用也更加方便。最明显的就是 GDI API 的变迁了，现在 GDI 应用程序也获得了硬件加速，就如同 XP 下一样，比其 Vista 下只能处理器来进行处理，因此用户们可以感觉到日常应用会更加流畅。

 

二：

原文链接 : 2D Drawing APIs in Windows

    在 Windows 7 操作系统中，微软花费了很大的力气构建了一套新的 2D 绘图 API。我们称之为 Direct2D ，隶属于 DirectX 家族。这个 API 的开发填补了 Windows 图形平台的一些缺陷。其中非常重要的一点就是普通的 2D 程序渲染不再缺乏硬件加速。而在 Windows Vista 中，我们知道 GDI 是无法进行硬件加速的。微软寄望于开发的这个 API 具备很多现代特性。比如支持抗锯齿和 Alpha Blend 的 2D 渲染，和其它现代图形 API 交互，服务器端渲染，诸如此类。

    为了方便理解微软为何开发 Direct2D ，我们先来回顾一下当初开发 Windows 时的历史。最初的渲染系统叫做 GDI (图形设备接口)，今天仍然存在。它最初为 16 位 Windows 写就，随后升级到 32 位 Windows (Windows 95 和 Windows NT)。因为 GDI 是为很久以前那些计算能力低下的计算机而开发的，所以它并没有诸如抗锯齿之类的特性，大多数 API 亦不支持 Alpha 通道。

    在 Windows 95 期间，DirectX 发布了第一版。DirectDraw 是其中最早的组件之一。当初的本意是在硬件加速启用的情况下，开发人员可以绕过 WinG 允许，直接访问硬件。这样的一个协议堆栈既可以和 GDI 协作，但是又真正处在同一地位。

    随着图形硬件(显卡)演进，GDI 通过 DDI (设备驱动接口) 获得了硬件加速的能力。很多视频卡实现了这些 DDI ，而通过购买一块视频卡来改善你的 Windows 性能亦成为平常之事。接下来，Direct3D 进驻到 DirectX 2 中，当然它也创建了自己的 DDI 集。随之，视频卡开始投入越来越多的精力来使得 3D 图形越来越快，以便维持游戏市场巨大的需求。最后导致诞生了两个不同的领域 : 硬件加速和图形编程。前者围绕于 Direct3D 构建，后者则围绕于 GDI 。

    Direct3D 和 GDI 构建于不同目标，不同位置的事实意味着它们并不能像人们期望的那样能够良好的工作在一起。虽然实现了不少像 GetDC 这样的帮助桥接特性，但是在大量交叉渲染的场景下它们总是存在着或这或那的一些问题。尽管如此，微软并没有移除这些待解决的场景需求。

    到了世纪之交，GDI 的限制越来越显现。微软针对这些功能缺陷做了一个 GDI 扩展，即 GDI+ 。这些扩展提供了诸如位图操作，画笔，抗锯齿和越来越复杂的 Primitive 渲染中不同像素深度格式，Alpha Blend 的支持。同时，GDI+ 亦包括了诸如打开 Png 和 Jpg 格式文件的图像操作支持。然而，GDI+ 新增的全部操作都没有硬件加速支持。

    GDI+ 在托管世界中非常流行，这主要得力于它是 System.Windows.Drawing 命名空间的主力。每一个客户自定义渲染的非常漂亮的 Windows Form 程序都使用 GDI+ 来当此大任。但是，构建于 GDI 之上的 GDI+ 同样继承了与 Direct3D 交互的所有问题。事实上，因为它总是软渲染，在某些场景下，它会变得更糟。

    当时间走到计划研发 Windows 7 时，很明显，微软需要解决很多互操作性的不足，以及不平衡的硬件加速能力。保留现有的 API 且要达到上述目的是相当困难的事情。GDI 有很长的历史，这需要应付海量的应用程序兼容性问题。如果要把 Alpha Blend 支持(举例) 弄进 GDI 核心 API 集合，而且还不得罪现有的客户无异于天方夜谭。因为 GDI+ 构建于 GDI 之上，旧有的陋习同样让它获得硬件加速能力变得难以实现（文中说的GDI没有实现硬件加速是指在Win7之前，Win7已经实现。）。

    解决方案就是创建新的 API 来囊括我们想要的功能和处理互操作性问题。MIL 代码(WPF 处理渲染的原生组件)是一个很方便的起点。它有着我们想要的渲染特性，而且同时提供了软件渲染和硬件加速。

    首先需要做的事情是使渲染代码基于 D3D 10.1 ，而不是 D3D 9 。之所以这样决定是因为有一些构建于这个运行时版本的其它技术把 D3D 10.1 作为基础(10Level9，WARP，D3D Primitive Remoting)。而且我们还可以看到未来的硬件同样构建于这个架构之上。这样就能允许我们来设计 D3D 10.1 互操作性。因此就能允许与其它技术交互，比如 Direct2D 。

    另外一个互操作性工作就是利用窗口管理器和 DXGI ，以确保 Direct2D 和 GDI 能够共同工作。你可以使用 Direct2D 绘图到 GDI 目标，同理，反之亦可。 但是，从性能的角度来看，这些特性并非免费。它只是让那些构建在这两种混合 API 上的应用程序能够平滑过渡到新世界。

    前面所作的工作中很重要的一块就是尽量使得此 API 在性能方面富于表现力。对于开发人员来说，WPF 的好处在于它做了很重要的资源管理工作，但却使得直接控制硬件变得困难起来。这听起来貌似很简单，但是这背后有着大量的设计决定以确保 GPU 内存没有分配给不需要之人，且仍然能够允许人们构造他们之所想。因此遵循了这样一个原则的 Direct2D 设计和资源/线程模型就能够允许服务器端渲染进行合适的伸缩。GDI 却不能。

    此外，对于处理文本和图像可以分别采用 DirectWrite 和 WIC 。这表明了微软 DirectX 家族正更加组件化。Direct2D 以一种互补的方式对 DirectWrite 文本和 WIC 位图操作提供硬件加速支持。

    最后想说的是，我们构建了一个支持硬件加速的 2D 渲染 API (带有软渲染)。它有着现代渲染原语集合，能和以前的 API 进行交互。我们认为它完全可以取代作为大多数应用程序开发场景所使用的 GDI/GDI+ API ，而且也可以作为某些游戏开发场景中 D3D 10.1 的补充。微软构建的这么一套组件化的技术集合完全允许开发人员混合搭配以构造以前难以构造的事物。比如把已定位的文本像素直接渲染到 Direct3D 纹理当中，而不需要任何字体的支持。

http://blog.csdn.net/poem_of_sunshine/article/details/8018533