用于具有多重图形子系统、减少的功率消耗模式的计算装置的驱动程序架构、软件和方法

摘要

现今许多的计算装置也许包含二个或更多个图形子系统。多重图形子系统可以具有不同的能力，并且可以例如消耗不同数量的电力，因为一个子系统较其它的子系统消耗更多的平均功率。较高的功率消耗图形子系统可以耦接到装置，并且此外可以用来取代较低的功率消耗图形子系统，导致较高的性能或额外的能力，但是增加总功率消耗。藉由从使用之较高的功率消耗图形子系统转变至较低的功率消耗图形子系统，同时设置该较高的功率消耗图形子系统于较低的功率消耗模式，则减少总功率消耗。处理器执行应用程序软件和驱动程序软件。驱动程序软件包含第一和第二驱动程序组件用来分别控制该第一和第二图形子系统之操作。其它代理器驱动程序组件根据该第一和第二图形子系统之哪一个是在使用中而路由呼叫(例如，API/DDI呼叫)至该第一和第二驱动程序组件其中之一。

说明书

本申请案主张于2007年12月13日提出申请之美国临时专利申请案序号61/013,527，案名“用于具有多重图形子系统、减少的功率消耗模式之计算装置之驱动程序架构，软件和方法(DRIVER ARCHITECTURE FOR COMPUTING DEVICE HAVING MULTIPLE GRAPHICS SUBSYSTEMS，REDUCED POWER CONSUMPTION MODES，SOFTWARE AND METHODS)”之优先权，该案发明人为Phil Mummah和Paul Blinzer，而所有权人为本案受让人，该案之全部内容由此结合本案作为参考。本申请案亦相关于2006年5月30日提出申请之美国专利申请案序号11/421,005，和2007年5月30日提出申请之美国专利申请案序号11/755,625，该二个申请案之内容结合本案作为参考。

技术领域

本发明大体上系关于计算装置，尤系关于具有多重图形子系统、和关联之软件驱动程序之装置。于一个态样中，本发明亦系关于用来降低此等装置中功率消耗的方法。

背景技术

许多电子装置，譬如习知的计算装置现在包含图形子系统能够描绘二或三维图形；译码和编码动式视讯：等等。欲提供这些特征和所希望之处理速度，现代的图形子系统包含持续增加数目之晶体管。毫不奇怪的，增加晶体管数量已导致由图形子系统所造成之对应较高的电力消耗。

结果，最快的和最富特征的图形子系统已大部分预留给能够符合增加功率要求之装置。譬如膝上型、个人数字助理、视频和音频播放器、手机、等等之可携式计算装置通常已装备成受到功能限制，但是具有电性效率(亦即，低功率)之组件。

时常这些图形子系统整合于其它的计算组件中，譬如处理器互连接电路(时常称之为“芯片组”)。

最近，有提供用于可携式装置之图形特征和性能以对抗静止式计算机之那些功能之倾向。往往，此藉由允许附加视情况选用之外部的高功率图形子系统于可携式装置而达成。例如，PCI快捷(PCIe)标准考虑PCI快捷之互连接兼容图形卡，包含图形子系统，作为至膝上型计算机装置之外部组件。

于存在之多重图形子系统中，时常希望切换计算装置之操作状态使用一个或另一个图形子系统而不须重新起动(例如，重新开机(rebooting))计算装置。

不幸的是，一些操作系统之软件架构仅仅考虑使用单一的图形驱动程序。于是，于存在之多重图形子系统中，此单一驱动程序需要控制所有的多重子系统之操作。此也许是不切实际的，尤其是如果子系统由不同的制造者所提供时。

因此，需要可以使用多重图形驱动程序之软件和装置。

发明内容

现今许多计算装置可以包含二个或更多个图形子系统。该多重图形子系统可以具有不同的能力，以及可以例如消耗不同数量之电力，因为一个子系统较其它的子系统消耗更多的平均功率。较高的功率消耗图形子系统可以耦接到装置，并且此外可以用来取代，或附加至较低的功率消耗图形子系统，导致较高的性能或额外的能力，但是增加总功率消耗。藉由从使用之较高的功率消耗图形子系统转变至较低的功率消耗图形子系统，同时设置该较高的功率消耗图形子系统于较低的功率消耗模式，则减少总功率消耗。

处理器执行应用程序软件和驱动程序软件。驱动程序软件包含第一和第二驱动程序组件用来分别控制该第一和第二图形子系统之操作。其它代理器驱动程序组件依于该第一和第二图形子系统之哪一个是在使用中而路由呼叫(例如，API/DDI呼叫)从该应用程序软件至该第一和第二驱动程序组件之其中之一。

习知使用上，此代理器驱动程序组件表现单一接口至操作系统和应用程序软件，同时允许使用二个分离的驱动程序组件。此代理器驱动程序组件可以是窗口维斯塔(Windows Vista)用户模式驱动程序(user mode driver，UMD)组件和/或核心模式驱动程序(kernel mode driver，KMD)组件。

依照本发明之态样，提供一种电子装置。该电子装置包括：第一图形子系统，用于绘成图形；第二图形子系统，用于绘成图形；至少一个显示器，与该第一图形子系统和该第二图形子系统之至少其中之一通信通信；处理器，执行应用程序软件和驱动程序软件，该驱动程序软件包括第一和第二驱动程序组件用来分别控制该第一和第二图形子系统之操作，和代理器驱动程序组件用来依于该第一和第二图形子系统之哪一个是在使用中而路由呼叫从该应用程序软件至该第一和第二驱动程序组件之其中之一。

依照本发明之另一个态样，提供一种电子装置，包括：第一图形子系统，用于绘成图形；第二图形子系统，用于绘成图形；显示器，与该第一图形子系统和该第二图形子系统二者通信；处理器，执行应用程序软件和驱动程序软件，该驱动程序软件包括第一和第二用户模式驱动程序组件用于分别控制该第一和第二图形子系统之操作，和用户模式代理器驱动程序组件用来依于该第一和第二图形子系统之哪一个是在使用中而路由呼叫从该应用程序软件至该第一和第二用户模式驱动程序组件之其中之一；第一和第二核心模式驱动程序组件，用来分别控制该第一和第二图形子系统之操作，以及核心模式代理器驱动程序组件，用来依于该第一和第二图形子系统之哪一个是在使用中而路由呼叫从该用户模式驱动程序组件其中之一至该第一和第二核心驱动程序组件之其中之一。

依照本发明之又另一个态样，提供一种操作电子装置之方法，该电子装置包括用于绘成图形的第一和第二图形子系统。该方法包括下列步骤：接收来自软件应用程序之驱动程序呼叫或执行于该电子装置之操作系统；依于该第一和第二图形子系统之哪一个是在使用中而路由来自软件应用程序之驱动程序呼叫至用来分别控制该第一和第二图形子系统之操作之第一和第二软件驱动程序组件之其中之一。

于查阅本发明之特定实施例结合所附图式之下列说明，本发明之其它态样和特征对于熟悉此项技术而言将变得很清楚。

附图说明

于仅以举例方式例示之图形中，本发明之实施例：

图1为本发明之范例实施例，计算装置之简化示意方块图；

图2为本发明之范例实施例，计算装置之简化示意方块图；

图3为习知软件之简化功能方块图；

图4为于图2之计算装置范例软件之简化功能方块图，包含本发明之范例实施例之驱动程序软件；

图5为本发明之范例实施例，于图2之装置由软件所实施之详细步骤之流程图；

图6示意地显示于图4之软件中API/DDI呼叫。

图7为本发明之范例实施例，于图2之装置由软件所实施之详细步骤之流程图；

图8为图2之计算装置之进一步简化示意方块图；

图9为本发明之范例实施例，于图2之装置由软件所实施之详细步骤之流程图；

图10为本发明之另一范例实施例，计算装置之部分之进一步部分简化示意方块图；

图11为本发明之范例实施例，于图10之装置由软件所实施之详细步骤之流程图；

图12A和12B为例示图10之装置之操作之简化方块图；

图13为本发明之另一范例实施例，计算装置之部分之进一步部分简化示意方块图。

具体实施方式

图1为电子装置10之简化、高阶层方块图，包含二个图形子系统30和40、和显示器26。如将变得很清楚，各图形子系统30和40包含特殊化之电子电路能够绘制计算机图形，于一个或多个之2D图、3D图、译码动式视讯、等等之形式。

一个图形子系统40可能消耗较其它的图形子系统30为高的平均功率。典型的情况是，图形子系统40消耗较高的平均功率，而具有较图形子系统30为大的图形绘制能力。图形子系统40例如也许能够较消耗较低之平均功率之图形子系统以较高之帧率(frame rate)绘制2D或3D图形。同样情况，图形子系统30、40不需具有相同的能力。图形子系统40较图形子系统30典型包含更多的功能区块。

图形子系统30和40二者可以被实体或逻辑耦接至相同的显示器26，于此显示器上显示绘制之图形。本发明之范例实施例，装置10可以从较高的功率消耗模式(于此模式至显示器26之图形由较高功率消耗之图形子系统40绘制成)切换至较低的功率消耗模式(于此模式至显示器26之图形由较低功率消耗之图形子系统30绘制成)，并且图形子系统40被部分、完全或实质上禁能。

习用上，可以用动态方式将高功率消耗模式转变至低功率消耗模式，而不需要装置10循环供电(亦即，电源切断和重新起动)，并且可以于软件控制下由处理器12生效。如此情况，软件可以包含应用程序软件、韧体、装置驱动程序、BIOS、等等。

本发明可以形成包含二个图形子系统之实际上任何电子装置之部分。就此种情况，装置10能够采取桌上型计算装置、可携式计算装置(包含膝上型计算机、PDA、移动式电话、视频和音频播放器、媒体中心、等等)之形式。

于下文说明之范例实施例中，本发明之实施例揭示为形成移动式(膝上型)计算装置之部分。

详言之，图2为本发明之范例实施例，特定的移动式计算装置10之简化方块图。图1中显示描绘之装置10为根据习知的英特尔x86计算机架构之计算装置。然而，熟悉此项技术者将容易了解到本发明可以是具有其它架构，譬如，功率PC(PowerPC)架构、AMD x86、或其它已知的架构之计算装置之实施例。

如所例示，范例装置10包含形成为中央处理单元(CPU)之处理器12、主存储器14、和全都透过整合之接口电路16和18(亦称之为北桥16和南桥18)互连接之周边装置。所有这些装置可以形成在主机板上。

接口电路16为高速接口，其藉由高速扩充总线20之方式而与CPU 12、内存14、和周边装置互相连接。接口电路16进一步互连接CPU 12至低速接口电路18。一个或多个周边扩充凹槽22可以藉由高速扩充总线20之方式互连接至接口电路16。范例高速扩充总线20为PCI快捷(PCIe)总线，其具有频宽每秒千兆位组范围，并且允许于此频宽资料转移读取和写入。

接口电路16进一步包含第一图形子系统30，具体实施为整合图形处理器(integrated graphics processor，IGP)，适合用来产生视频讯号显示在显示器26上，该显示器26可以是于监视器、LCD面板、电视、等等之形式。

额外的第二图形子系统40形成装置10之部分。于此范例实施例中，图形子系统40被具体实施为形成在周边扩充卡46上之外部图形处理器。周边扩充卡46亦藉由于扩充总线20上之扩充凹槽22之方式连接至接口电路16。如将变得很清楚，藉由设置第二图形子系统40，装置10可以提供扩大的图形能力，此能力在其它情况不表现于装置10中。由第二图形子系统使用为帧缓冲器之图形内存50可以包含在周边扩充卡46上。同样情况，与图形子系统40通信之功率控制器60可以视需要选择形成于扩充卡46上，并且可以控制图形子系统40之操作。详言之，功率控制器60可以调节由图形子系统40之组件所使用之时脉，譬如内存和像素时脉；禁能(或者断接)图形子系统40之功能区块；降低施加到图形子系统40之部分之电压；或者不然设置子系统40于其中功率消耗以已知方式减少之一个或多个模式中。

另一个视需要选用之功率控制器70可以与第一图形子系统30通信，并且可以调节由图形子系统30之组件所使用之时脉，譬如内存和像素时脉；禁能(或者断接)图形子系统30之功能区块；降低施加到图形子系统30之部分之电压；或者不然设置子系统30于其中功率消耗以已知方式减少之一个或多个模式中。

虽然例示的图形子系统40形成在周边扩充卡46上，但是熟悉此项技术者将容易了解到图形子系统40仅能够容易形成在装置10之主机板上，或其它地方。

接口电路18互连接较低速度周边装置和互连接，譬如光驱28、和藉由整合IDE/SATA埠(未显示)方式于硬盘机形式之永久储存内存34、和列表机，以及藉由并联或USB埠(未显示)方式之其它的周边装置。又其它的周边装置可以藉由较低速度扩充总线24之方式互连接，例如遵从已知的PCI或ISA标准。譬如声卡网络接口(未显示)之其它组件可以同样地藉由低速度扩充总线224之方式，或其它方式互连接至接口电路18。

如所提示的，装置10可以方便地形成为于膝上型或较小计算装置形式之可携式计算机装置。如此情况，单一外壳可以包含DC电源38、显示器26、和上述主机板和组件。第二图形子系统40可以附加至容装计算装置之剩余部分之单一外壳，或者可以形成扩展坞之部分，该扩展坞当装置10实体互连接至其上时仅形成装置10之部分。

装置10可操作于至少二种功率消耗模式：较高功率消耗模式和较低功率消耗模式。于所描述之实施例中，当装置10藉由连接到AC(主)供电之电源36供电时，装置10可假设在该较高功率消耗模式；当装置10藉由使用一个或多个电池、燃料电池、等等DC电源38供电时，可以假设在该较低功率消耗模式。或可选择使用，功率消耗模式可以根据例如用户喜好、执行软件应用程序之类型、电池之位准、等等，而由用互选择、软件控制。

于所描述之实施例中，装置10执行储存于系统内存内之软件200，如图4中所例示。系统内存包含永久储存内存34和主存储器14(图2)，并且可以进一步包含额外的随机存取内存、只读存储器和光盘储存内存之适当的组合，由装置10所使用以储存和执行软件200。范例软件200能够例如储存于只读存储器中，或者从譬如光驱28(图1)之外部周边、或者经由计算机网络(未显示)加载。

于所例示之实施例中，软件200系基于微软维斯塔(Vista)平台。然而，于本发明之范例实施例方式之软件操作装置10不需要根据此平台。取而代之，范例软件可以结合其它已知的计算机操作系统(譬如Linux、MacOSX、或其它的操作系统)工作。用不同的操作系统，软件架构可以与图4中所描绘之软件架构在材料方面不同。

于窗口维斯塔操作系统环境中，硬件组件(譬如图形子系统30、40)之低阶层控制典型由一般称之为驱动程序之软件组件所执行。各硬件组件之操作由一个或多个此种组件所控制。

驱动程序架构，于窗口维斯塔操作系统情况被称之为窗口装置驱动程序模型(Windows Device Driver Model，WDDM)，并且更详细说明于微软窗口驱动程序备份工具软件应用程序接口(Microsoft Windows Driver Kit API)。详细说明可以于下列网址获得：http://www.microsoft.com/whdc/devtools/WDK/AboutWDK.mspx和http://msdn2.microsoft.com/en-us/library/aa480220.aspx，该说明之内容由此加入作为参考。

在解说图4中所例示之软件200之操作之前，适合先说明习知的窗口维斯塔(Windows Vista)架构。欲达此目的，图3描绘根据窗口维斯塔操作系统之习知的软件200’。如所例示，软件200’包含应用程序软件202’、数个属性、操作系统图形组件204’、206’、208’、210’(称之为运作时间(run-time)组件)；以及数个硬件特定图形装置驱动程序组件220、222、和224，定义装置驱动程序用于图形子系统，像是子系统30和40。而且，亦说明显示加载器模块218’、窗口维斯塔核心216’、和窗口图形装置接口(GDI)软件214’。

如将了解到，于窗口维斯塔操作系统下之驱动程序软件能够运作于用户模式或核心模式其中任一情况。用户模式驱动程序(User-mode driver，UMD)组件执行于由处理器12所支持之非优先的模式，并且仅被允许限制存取于内存、缓存器、等等。于图2中，组件220和222为UMD组件。其它的软件，包含应用程序软件202’，亦执行于此模式。UMD组件220和222和应用程序软件202’不能获得直接存取至低阶层系统资料。他们同样不能够存取内存之所有的区域、所有的缓存器、等等。然而他们可以呼叫至执行于核心模式之软件。

相比之下，核心模式驱动程序(kernel-mode driver，KMD)组件执行于与该操作系统核心相同的处理器模式，而因此一般已释放存取至装置10之内存、缓存器、和其它资源。UMD组件可以呼叫KMD组件，以获得较低阶层存取至计算装置10之资源。组件224为UMD组件。KMD驱动程序架构进一步详细说明于2006年5月10日提出申请之“用于核心模式驱动程序框架之样本驱动程序(Sample Drivers for the Kernel Mode Driver Framework)”，可以从下列网址获得，http://www.microsoft.com/whdc/driver/wdf/KMDF-samp.mspx，以及于WDM导论，网址为http://msdn2.microsoft.com/en-us/library/aa4490246.aspx。

UMD组件和KMD组件具有不同的结构、不同的登录点、和不同的系统接口。装置是否需要UMD或KMD，依于装置之类型和于操作系统中已经对其提供之支持而定。用于图形子系统(譬如图形子系统30、40)之驱动程序典型上包含至少一个运作于核心模式之组件。再者，于窗口维斯塔操作系统中，KMD组件被加载于系统初始化(亦即，升高供电)，而UMD组件当需要时可经要求而加载。

详言之，于窗口维斯塔架构中，为了获得低阶层存取于由这些子系统所使用之资源，用于图形子系统之KMD组件与对应之KMD组件通信。典型的情况是，各KMD组件提供装置驱动程序接口(device driver interface，DDI)，对于对应之UMD组件为已知。DDI可以包含功能呼叫、目标(包含方法)、输入/输出控制(input/output control，IOCTL)呼叫和关联之数据结构。如将了解的，功能呼叫透过其时常组构于此种数据结构中之功能/方法参数接收资料。此数据结构之正确性质特定于DDI定义中。

于描述之实施例中，操作系统图形组件204’、206’、和208’为由操作系统制造商(如此情况为微软公司)所提供之运作时间组件；而于UMD和KMD组件形式之硬件特定图形装置驱动程序组件220、222、和224可以由第三方制造商(譬如图形子系统30或40之制造商)提供。

操作系统图形组件包含运作时间3D图形运作时间组件204’(直接3D运作时间)、硬件加速图形接口运作时间组件(DXVA)206’、3D开放式图形库(Open Graphics Library，OpenGL)运作时间图形组件208’。对应之硬件特定UMD组件220和222提供对应于直接3D、DXVA、和开放式GL API之API硬件呼叫之硬件特定执行。

运作时间组件204’、206’、208’和UMD组件220、和222提供联合的图形应用程序软件规划器接口(API)，由应用程序软件202’和操作系统之剩余的部分使用。详言之，API提供功能呼叫、目标、等等，其引起于UMD组件220’和222’或于运作时间组件204’、206’、208’中驱动程序软件例程(例如，功能或方法)之执行，如由微软公司详细说明。API呼叫可以藉由部分之操作系统(例如，模块204’、206’、208’)，或藉由其它的驱动程序由应用程序软件200’完成。UMD组件220和222对应于API呼叫依次执行软件码(典型于功能、或目标方法之形式)。由D3D、DXVA和开放式GL UMD组件220和222所提供之功能和回呼详细说明于窗口驱动程序备份工具软件：显示装置窗口维斯塔显示驱动程序模型参考(Display Devices Windows Vista Display Driver Model Reference)，其可从微软研发之网络(Microsoft Developer’s Network)(网址：www.msdn.com)取得，该软件内容由此结合入本说明书作为参考。

详言之，于UMD组件220、222或KMD组件224由操作系统之加载例程加载后，定位该驱动程序组件登录点-著名的驱动程序登录()(DriverEntry())(用于核心模式驱动程序)或者DII主要()(DIIMain())或者否则其它方面(例如，开放式适配器()(OpenAdapter()))用于UMD组件220、222。UMD/KMD组件220、222、224包含从OS接收已熟知的结构功能，该OS由在UMD/KMD组件220、222、224之登录点之码所填满，指向在执行所期望之性能之UMD/KMD组件220、222、224内之功能。这些名称由DDI规格所定义，并且透过所称为之定义档案来执行。

例如，KMD组件224接收驱动程序_初始化_资料(DRIVER_INITIALIZATION_DATA)结构，该结构包含一组用于其为DDI之驱动程序执行功能组之部分之多种操作之功能指针。当需要时，UMD组件220、222之剩余的部分可以呼叫这些功能以起始在驱动程序中之适当的操作，该驱动程序于许多情况(但是并非需要全部)将引致存取至硬件(通常藉由呼叫一些其它的KMD驱动程序内部功能)。

UMD组件220和222可以形成为动态链接库(dynamic linked library，DLL)，并且顺应WDDM。就此种情况，各UMD组件220、222依照WDDM之IOCT提供收集之功能和目标。概略而言，各驱动程序组件包含定义的登录点驱动程序登录(DriverEntry())、定义的目标等级、驱动程序登录点、定义的功能和回呼叫。加载各驱动程序后，于其登录点之软件码被执行DriverEntry()，并且定义之驱动程序例程被暂存于预期的结构中。

DIIMain()登录点用来分配和初始UMD组件之基本数据结构，或者当卸载UMD时于控制之机构卸除这些组件。

于WDDM UMD组件之情况，OpenAdapter()于与DriverEntry()呼叫KMD组件相似之方式呼叫工作。也就是说，OpenAdapter()呼叫接收具有一组UMD组件220、222填满指向UMD组件内适当功能之功能指针之数据结构。

在UMD内名称和支持之功能/目标和关联之码地址藉由此结构方式因此被返回至操作系统之剩余的部分。此外，由D3D、DXVA和OpenGL UMD组件220和222支持之UMD功能和结构被详细说明于窗口驱动程序备份工具软件：显示装置窗口维斯塔显示驱动程序模型参考，其可以从微软研发之网络“supra”取得。

于是，于加载各UMD组件220、222之结束，API功能/目标，和IOCTL对于应用程序软件202’和操作系统软件之剩余的部分为已知。API目标可以由应用程序软件200藉由于相同的地址创造目标之例子而引证。能够执行功能/方法和IOCTL于他们的对应地址。

操作系统图形模块进一步包含核心模式图形核心软件组件210’(称之为于窗口维斯塔操作系统中直接X核心(DirectX Core))、和KMD组件224。图形核心软件组件210’提供API用于UMD组件220、222，允许这些UMGLD组件220、222获得核心模式存取至装置10之资源。核心模式图形核心软件组件210’可以进一步包含视频内存管理器、排程器、和转换(或编辑)某API/DDI呼叫用于兼容性之例程。KMD组件224可以符合窗口驱动程序模型，或窗口驱动程序框架，如上述详细说明。如此情况，KMD组件224包含定义的目标等级、功能和结构，提供DDI。

像UMD组件220和222，KMD组件224包含初始例程、驱动程序登录()，该驱动程序登录()典型藉由名称和内存地址返回目标等级、功能和结构之识别符，提供所需的DDI用于KMD组件224。如所提及的，KMD组件224典型于系统起动被加载(和初始化)。

此外，KMD组件224可以包含DDI未明确已知或报告于操作系统之剩余的部分，但是已知于互补的UMD组件220或222。

软件200被层化，具有较高阶层层使用较低层提供某些功能。那么，应用程序软件202藉由制作呼叫至运作时间操作系统图形组件204’、206’、208’、或UMD组件220、222、或GDI 214’而典型使绘制图形。图形模块204’、206’、和208’仅包含属性、共享于所有第三方视频驱动程序之硬件独立码。运作时间组件204’、206’、208’依次可以制作API/DDI呼叫至UMD组件220和222。定义于数据结构之已知的参数例如藉由至所存在的结构之适当的指针而被递送至UMD组件220和222。UMD组件220、222包含硬件特定码、和结构。然而，如所提及，UMD组件220、222仅仅具有用户阶层存取。UMD组件220、222与KMD组件224通信，直接使用由KMD组件224提供之已知的API/DDI，或者透过核心模式图形核心软件组件210’。

KMD组件224依次包含功能、目标、等等，其能够传递适当的低阶层指令至位于下方硬件(例如，图形子系统30或40)。可以进一步排列多重呼叫至KMD组件224。低阶层指令依次可以由位于下方硬件执行。举例而言，低阶层指令可以包含可执行指令等之图形处理器。

不像许多其它已知之操作系统，窗口维斯塔仅允许加载单一显示驱动程序KMD组件224’。其它补助的应用程序软件用作为显示驱动程序加载器218’。加载器218’一般依于起动而执行，但是亦可以于起动后执行。加载器218’加载第三方KMD组件(例如，组件224’)，并且将其初始化，用来由图形核心软件组件210所存取。虽然可以使用加载器218加载/卸载核心模式驱动程序组件，像是KMD组件224’，但是一个图形KMD组件224之加载，需要另一个驱动程序之卸载。

现在，于存在之二个图形子系统中，像子系统30、40(第1图)，UMD组件220和222以及KMD组件224可以控制二个图形子系统之操作，并且允许选择性地切换该二个图形子系统之间之操作。至驱动程序组件220、222、和224之API呼叫可以确认多个子系统之哪一个将被寻址。然而，单一UMD/KMD提供支持多个图形子系统之要求引入限制。举例而言，对于单一驱动程序支持很多项之不同的适配器那是不切实际的。若子系统由不同的制造商提供则恶化了此问题。

图4因此显示了本发明之范例实施例之软件和图形模块。再者，范例软件描绘于窗口维斯塔环境之情况。如此情形，形成操作系统之部分之模块和组件相同于描绘于图3中者，并且因此于图4中用相同的数字(但是并没有(’)符号)描述，而将不作进一步之详细之说明。

然而，值得注意的是，UMD组件220和222以及KMD组件224(图3)已经各被代理器驱动程序组件取代--UMD代理器组件320、322和KMD代理器组件324。如将变得很清楚，UMD代理器组件320、322和KMD代理器组件324出现于操作系统之剩余的部分，单一组之APIs/DDI，以及表现为单一图形驱动程序。如此情况，运作时间组件204、206、208、应用程序软件202、和操作系统之剩余的部分可以请求(或呼叫)图形API功能/目标，如图3中所示。

也对附加的功率控制应用程序软件201的功能加以描述。可清楚了解，功率控制应用程序软件201可以控制图1之图形子系统30、40之全部功率消耗状态。功率控制应用程序软件201可以是独立执行之应用程序软件，或者可以形成全部用户/图形子系统控制和组构应用程序软件--譬如触媒控制中心应用程序软件(可以从ATI/AMD公司构得)之一部分。

UMD代理器组件320和322以及KMD代理器组件326依次路由呼叫此种图形功能至多个个别硬件特定UMD图形驱动程序组件340、342、350、352、以及KMD图形驱动程序组件370和372。详言之，UMD代理器组件320路由呼叫至UMD组件340或342；UMD代理器组件322路由呼叫至UMD组件350或352；以及KMD代理器组件324至KMD代理器组件360或KMD代理器组件362，如下文之详细说明。

UMD组件340、350和342、352为对应于图形子系统30和40之硬件特定UMD组件，该图形子系统30和40像UMD组件220包含功能、目标、IOCTL、等等，该等功能、目标、IOCTL等为硬件特定--分别至图形子系统30和40。KMD组件360、362同样相似于KMD组件224，并且包含功能、目标、IOCTL、等等，设计于核心模式与图形子系统30和40互动。

举例而言，UMD组件340、350和KMD组件360可以分别提供用户模式DirectX驱动程序软件、OpenGL驱动程序软件、和核心模式驱动程序软件组件用于第一图形子系统30；同时UMD组件342、352和KMD组件362可以提供用户模式驱动程序软件、OpenGL驱动程序软件、和核心模式驱动程序软件用于第二图形子系统40。习用上，组件340、350、和360(或者组件342、352、362)可以是习知的，于此习知的组件中他们可以由图3中所描绘之操作系统直接加载，取代图形UMD/KMD组件220、222、和224。

于此种方式，各UMD/KMD组件340、342；350、352；360、362可以实施低阶层图形功能，并且以特定于包含之图形硬件之方式存取图形硬件。

习用上，UMD代理器驱动程序组件320、322和KMD代理器驱动程序组件324一方面表现一致的API/DDI于操作系统之剩余的部分，另一方面，路由呼叫、IOCTLs、请求、存在目标、等等(集体API/DDI呼叫)至硬件特定UMD/KMD驱动程序组件340、350、和360，或者342、352、和362。

于操作中，UMD代理器驱动程序组件320、322和KMD代理器驱动程序组件324由操作系统之剩余的部分加载。

一旦加载UMD代理器驱动程序组件320、322，则执行其登录例程(例如，DIIMain()/OpenAdapter())。如将变得很清楚，UMD代理器驱动程序组件320、322之登录例程加载UMD组件340、342之一者或二者，并且提供至维斯塔操作系统之剩余的部分，期望的数据结构确认于UMD代理器驱动程序组件320、322中支持之API/DDI呼叫与UMD组件222和224所作非常相同的方式。再者，期望之API/DDI之地址以地址之形式藉由预期之结构之方式提供至功能、目标、IOCTLs。

UMD组件340和342由UMD代理器驱动程序组件320内之软件码所加载，如更详细说明于图5中方块步骤S500中。详言之，于方块S502，加载譬如UMD组件340或342之UMD驱动程序组件，典型作为动态链接库。其次，可以藉由UMD代理器驱动程序组件320呼叫新加载UMD组件340或342之驱动程序初始化例程DIIMain()/OpenAdapter()、等等。于方块S504中，新加载UMD组件340或342之驱动程序初始化例程返回返回支持功能、IOCTLs等之名称和地址(于与UMD组件220、222返回此等名称、地址等相同的方式)至UMD代理器组件320。其次，于方块S508中，UMD代理器驱动程序组件320形成表示将由负载之UMD组件340或342所支持之目标等级、功能、IOCTLs、等等之间一致性之数据结构。

举例而言，UMD代理器驱动程序组件320被设计成支持DXVA功能呼叫和目标，并且因此形成此种已知DXVA功能呼叫和目标与在加载之UMD组件340或342内他们的登录点之间之一致性。于方块S506之结论，UMD代理器驱动程序组件320可以形成于内存中结构，该内存中设有对应于由UMD代理器驱动程序组件320所支持之各支持之DXVA功能、目标、IOCTLs等之于UMD组件340或342中之地址。

可以藉由UMD代理器驱动程序组件320和322或有需要时动态地加载特定的UMD组件340或342、350或352。尤其是，若任何图形子系统30和40未使用，则其对应之UMD驱动程序组件不需被加载。

对于待由UMD代理器驱动程序组件320加载之各UMD驱动程序340或342可以实施对应于方块步骤S500之软件。步骤S500由用作为用于UMD组件350和352之代理器驱动程序组件之UMD代理器驱动程序组件322以类似方式实施。

而且，亦在KMD代理器驱动程序组件324之初始化后--典型为系统起动时，实施方块步骤S500。KMD代理器驱动程序组件324执行KMD驱动程序组件360和362(例如，OpenAdapter())之初始化例程。

一旦已藉由各UMD代理器驱动程序组件320、322和藉由用于各支持之驱动程序组件(例如，UMD组件340、342；UMD组件350、352；和KMD组件360、362)之KMD代理器驱动程序组件324实施方块步骤S500(或者他们的相等步骤)，则UMD/KMD代理器驱动程序组件320、322和324将已经加载特定于图形子系统30、40之UMD/KMD组件，并且将已确定于加载之UMD组件340、342、350、352，和KMD组件360、362中支持之功能、IOCTLs、等等之对应之内存地址/登录点。

为了提供系统支持信息至操作系统之剩余的部分之目的，仅仅KMD代理器驱动程序组件324将可直接看到和可安装于二者子系统30、40。可以合并用于二者子系统30、40之驱动程序特定登录项目，因此代理器驱动程序组件可以读取和暴露该等登录项目至UMD组件340、350；342、352。

UMD组件340、350；342、352亦可以返回由UMD代理器组件320、322所聚集和调整之许多的特质，以确保返回之特质与用来与多个图形子系统互动之单一驱动程序一致。这些特质可以由UMD代理器驱动程序组件320、322传递至操作系统。举例而言，视频内存蓄积(Video memory heap)、GPU引擎特质、DMM形态、等等也许需要由UMD代理器组件320、322结合。

作为另一个替代者加载UMD/KMD组件340、342；350、352；和360、362，当这些组件被建立时，这些组件能够以统计方式链接至UMD代理器驱动程序组件320、322，和KMD代理器组件324。此当然将需要存取至用于UMD/KMD组件340、342；350、352；和360、362，或者可链接目标模块之来源码。

结果，UMD代理器组件320、322，和KMD代理器组件324加载/链接驱动程序UMD组件340、342；350、352；和360、362，UMD代理器驱动程序组件320、322，和KMD代理器324现在可以依于哪一个图形子系统30或40正由应用程序软件202或操作系统之剩余的部分寻址，而路由API/DDI呼叫至UMD/KMD代理器组件320、322和324至个别的UMD/KMD组件340或342；350或352；和360或362。此以图形方式例示于图6中。

由UMD代理器320、322和KMD代理器324所支持之API/DDI呼叫之细节可以藉由存在具有路由例程之细节用来支持API/DDI呼叫之数据结构而暴露于剩余的应用程序和操作系统，该API/DDI呼叫由UMD组件340、342；350、352；和KMD组件360、362实际实施。

API/DDI呼叫可以藉由这些路由功能(或目标)而路由在UMD/KMD代理器驱动程序组件320、322和324内。各路由例程之地址或UMD/KMD代理器驱动程序组件320、322和324之目标与待路由之特殊的API功能/呼叫/目标/IOCTL、等等相关联而可以暴露于操作系统和其它的应用程序软件。各路由例程或目标依次路由呼叫至UMD/KMD驱动程序组件之其中之一，对于该驱动程序组件该代理器驱动程序组件用作为代理器。于此种方式，API/DDI呼叫至代理器驱动程序组件320、322和324可以被路由至在UMD驱动程序340、342或350、352或KMD组件360、362中对应之驱动程序功能/呼叫/目标/IOCTL。

详言之，如图7中所例示，各API/DDI呼叫可以根据在UMD组件中对应之功能/呼叫/目标/IOCTL之地址而由UMD/KMD代理器驱动程序组件320、322和324仅仅被重新路由，对于该地址对应之登录点于方块步骤S700中于方块S508中已经被决定。详言之，于方块S702中，依于步骤S700之执行，UMD/KMD代理器组件320、322或KMD代理器组件324决定哪一个UMD/KMD组件(例如，UMD组件340、342；350、352；或KMD组件360、362)将处理该API/DDI呼叫。此情形例如可以藉由剖析该API/DDI呼叫或者关联之资料以确认有关的图形子系统，或者仅仅藉由决定多个图形子系统之哪一个现在正在使用而实施。如下文之详细说明，现在正在使用之图形子系统30或40可以根据装置10而取决。现在正在使用之子系统典型绘成待显示和由终端用户观看之图形/视讯。

一旦已经确认了有关的驱动程序，则UMD/KMD代理器驱动程序组件320、322或KMD组件324决定关于形成于方块S706中方块508中一致结构之API/DDI呼叫之地址。一旦已经决定了该地址，则可以作成在有关的UMD/KMD组件340或342；350或352；360或362内之API/DDI呼叫。然后UMD/KMD组件执行对应于该API/DDI呼叫之码。

值得注意的是，至UMD驱动程序340、342或350、352之呼叫可以制造其它的API/DDI呼叫。这些可以导致API/DDI呼叫至KMD代理器组件324。KMD代理器组件324，像UMD代理器组件320、322路由DDI呼叫至适当的KMD组件360、362，如图7中详细说明。KMD代理器组件324可以决定KMD组件360、362之哪一个组件，核心模式API/DDI呼叫将被路由与UMD代理器组件320、322制造评估非常相同的方式--亦即，依于呼叫之性质或者依于现时主动的图形子系统。

对于伴随着资料之呼叫(例如，透过创造之目标、或者藉由功能参数之方式)，可以藉由UMD代理器组件320、322或KMD代理器组件324递送指向资料之指针至决定之UMD组件340、342、350、352或者KMD组件360、362。若资料不能被递送为指针，则该资料传隧至对应之资料节构。

一些API/DDI呼叫可以不被操作系统之剩余的部分知道，并且根据初始化(例如，依于执行之DllMain()或AdapterQpen())情况而不返回到UMD代理器驱动程序组件320、322或KMD代理器驱动程序组件324。此情况对于譬如KMD组件360、或362之KMD组件也许尤其显著，该KMD组件360、362与例如由单一制造商/供货商提供之譬如UMD组件340、342之互补UMD组件互动。虽然可以支持DDI呼叫，但是他们不需要暴露于操作系统。此种呼叫能够典型不由KMD代理器驱动程序组件324路由，而没有进一步之知晓。欲避免此情况，各KMD组件360、362将报告所有支持之API/DDI，该API/DDI例如可以包含于用于操作系统排程器情况切换和寻呼请求通信之一般操作系统中，反应于执行驱动程序初始化例程。在此为不可能之情况下，KMD组件360、362可以进一步包含询问例程以返回关于将由KMD代理器驱动程序组件324要求之API/DDI呼叫之信息。

代理器驱动程序组件亦将接收来自UMD/KMD组件之呼叫，该UMD/KMD组件对API/DDI呼叫处理以确保其能够追踪影响图形子系统30和40之任何状态改变。

图8显示图2之装置10之部分之进一步简化方块图，于此图中可以使用图4之软件200(以及尤其UMD代理器组件320、322和KMD代理器组件324)。如所例示，接口电路16互连接中央处理器12和系统内存14。图形子系统30(具体实施为在接口电路16上之图形处理器)包含图形引擎32、内存控制器72、显示器接口74、和总线接口78。

图形引擎32为能够绘成2D图形或3D图形译码视频、等等之功能的区块。如将了解到，图形子系统30可以包含多个图形引擎。

内存控制器72允许图形子系统30提供存取至图形内存和主存储器14。于所描绘之实施例中，由图形子系统30所使用之图形内存形成主存储器14之部分。然而，熟悉此项技术者将容易了解到，图形子系统30可以包含或者结合其自己的局部内存。总线接口78致能子系统30经由总线20通信。

如将了解到，显示器接口74可以是用来转变显示于由埠78互连接之显示装置26上缓冲器内资料之任何适合的接口。举例而言，显示器接口74可以采用随机存取内存、数字至模拟转换器(RAMDAC)之形式。一个或多个视频连接器允许图形子系统30互连接至一个或多个显示装置，譬如LCD面板、监视器、电视机、等等。输出埠78可以是在VGA埠、混合的视频埠、DVI埠、LVDS埠、DVO埠、SDVO埠、等等之形式。

图形子系统40(例如，形成在图2之周边扩充卡46上)亦藉由在高速扩充总线20上之扩充槽之方式连接至接口电路16。图形子系统40包含图形引擎42、内存控制器52、总线接口58、和显示器接口54。图形子系统40包含图形内存50，或者与图形内存50通信。

图形引擎42，像图形引擎32，为能够绘成2D图形或3D图形译码视频、等等之功能的区块。如将了解到，图形子系统可以包含多个图形引擎。可能的情况是，图形引擎42可以提供不仅由图形引擎32所提供之功能。

内存控制器52允许图形子系统40存取内存50和主存储器14。总线接口58致能图形子系统40经由总线20通信。

显示器接口54藉由内存控制器52之方式取样于图形内存50中之帧缓冲器，并且表现图像于视频连接器。于此种方式，可以显示由外部的图形引擎42绘成于内存50中帧缓冲器中之图像。视频连接器可以直接连接至外部显示器，或者至装置10之主机板，此处视频讯号可以路由至整合的显示器，或者用来附加外部显示器至装置10之连接器。再者，显示器接口54可以是任合适合的接口，用来转变在缓冲器内的资料用来显示于显示装置32上，譬如RAMDAC、单端或不同的发送器、等等。

如所提及的，功率控制器60系与图形子系统40通信，并且使用习知的功率消耗技术，譬如时脉和电压调节、降低供电、或者不然禁能所有的或一些的该等组件，来控制显示器接口54、内存控制器52、图形引擎42、总线接口58、和图形内存50之各个或某些和其中的一个或多个之功率消耗。功率控制器60可以藉由于总线20上的讯号或者其它的方式控制，并且例如可以与ACPI标准兼容。

图形子系统30与图形子系统40以非常相似的方法操作。如此情况，图形子系统30使用内存控制器72存取保持于主存储器14或者于图形子系统30之局部之内存中之帧缓冲器。此帧缓冲器由显示器接口74取样，并且图像表示于视频输出连接器，该连接器能够直接连接至显示器。在致力于提供价廉之整合的组件情况，图形子系统30提供有限的功能。举例而言，图形子系统30之分辨率、内存、图形处理器速度、3D图形能力、等等也许相当地受限制，并且也许较图形子系统40之外部图形处里器42操作更慢。

藉由图形子系统40而更有效地实施譬如三维图形、游戏图形、等等之计算密集图形。因此在装置10内附加图形子系统40之使用允许终端用户经验最新的图形密集应用程序，譬如游戏、计算机辅助设计软件、动画软件、绘成软件(rendering software)、等等。方便来说，可以由终端用户选择附加上的图形子系统40，并且当需要时被取代和保持现用。在过去，额外的图形计算能力仅在工作站计算装置可取用。于移动式计算装置上扩充槽问世后，现在此种计算能力能够于譬如膝上型计算机之可携式计算机之拥有者所使用。当然，使用在图形子系统40上较高(或不同)性能图形引擎42增加装置10之全部功率消耗。此增加之功率消耗在由电池电源供电之计算装置上也许不足以支撑。

同时，在具有图形引擎42之额外的图形子系统40存在的情况下，则图形子系统30也许是多余的。举例而言，若多个实体显示器未连接至装置10，则图形子系统30也许不会发挥作用。图形子系统30因此可以被禁能。或可取而代之，在控制图形子系统30之操作之存在之功率控制器70中，当图形子系统30未使用时，其也许亦被设置在较低功率模式。再者，功率控制器70可以禁能或断接部分之图形子系统30，或者图形子系统30之时脉或电压调节部分。

本发明之范例实施例，软件200(图4)用来允许装置10选择性地禁能存在于子系统30中之一个较高的功率图形子系统40。

欲达此目的，以及如图8中所示，计算装置10进一步包含开关56。开关56接收由子系统40和子系统30于第一和第二输入所产生之视频讯号。开关56可以是任何适当的视频开关，譬如多功器，并且用于表示在其视频输出连接器之在其二个讯号输入之习知的视频讯号其中之一。表示之视频讯号于开关56之输入可以是习知的视频讯号，譬如数字讯号(譬如LVDS或TMDS格式等)或者模拟讯号(譬如VGA格式)。若组构开关56以接收数字和模拟输入讯号，或者提供视频于任一的输出，则开关56可以包含格式转变器。而且，开关56可以包含一个或多个视频输出，使可以连接数字和模拟显示装置32其中任一者或者二者。

开关56进一步包含控制输入(CNTRL)。此控制输入控制哪一个讯号输入被提供于开关56之视频输出。于所描绘之实施例中，控制输入由处理器12反应于所要求或希望之装置10之功率模式中侦测或决定改变，藉由一般目的输入输出(general purpose input output，GPIO)接口(未显示)之方式切换。如将变得很清楚的，若装置10正操作于较低功率消耗模式，则开关56组构成使得选择由图形子系统30所产生的习知的视频讯号。反之，若装置10正操作于较高功率消耗模式，则选择由较高性能外部图形子系统40所产生的视频讯号用于显示。同样情况，可以减少或禁能提供至图形子系统40或图形子系统30之功率。切换可以动态地实现，同时计算装置10是在使用中，而不需要装置10重新起动(亦即，冷或热起动)。

欲完成此目的，计算装置10亦可以包含至少一个上述之功率控制器60。于此描述之实施例中，功率控制器60形成装载图形子系统40之周边扩充卡46之部分。然而，功率控制器60仅亦能够形成计算装置10之主机板之部分，或者作为接口16之部分。若功率控制器60形成扩充卡46之部分，则其可以具有较大的弹性控制子系统40之操作。若功率控制器60形成计算装置10之部分，则其可以仅具有禁能供电至图形子系统40之能力。

为了组构和控制开关56和功率控制器60，使用在系统内存12内之软件200。图9因此为流程图，例示本发明之范例实施例中范例软件方块步骤S900用来切换装置10于二个有效的功率消耗模式之间。

现在，本发明之范例实施例，当装置10被起始供电时，评估装置10之功率状态。当需要时，功率控制应用程序软件201组构图形子系统30和40和开关56，以及如下之详细说明。

可以藉由处理器12于系统内存10内功率控制应用程序软件201之控制下实施本发明之范例实施例软件方块步骤S900。每次装置10经历状态改变可以实施方块步骤S900，对于此改变将因此配置图形子系统30和40。如所例示，于方块S902中功率控制应用程序软件201决定是否装置10将假定其较高功率消耗模式，或其较低功率消耗模式。

应用程序软件201(图4)可以维持指示图形子系统30、40之哪一个系用于特定图形功率状态之较佳装置之表。各用户功率状态映对至图形子系统30、40，并且对应用于该子系统之状态。用于个别图形子系统30、40之功率状态可以操作现时主动图形子系统30或40之参数，譬如时脉速度、内存速度、像素时脉速度、绘成能力、等等。

于范例实施例中，当装置10正由AC电源36操作时，可以使用较高功率消耗模式；当装置10由DC电源供应器38之方式操作，而当DC电源38为低、或等等时，可以使用较低功率消耗模式。于较高功率消耗模式，图形子系统40为主动的。于较低功率消耗模式，图形子系统30为主动的。

若装置10再开始(或者转变至)其高功率消耗模式，则执行方块S904至S910。于方块S904若子系统40尚未设置于其全操作(高功率消耗)模式，则将其设置在此模式。此可以藉由适当的驱动程序呼叫实施--(对于AMD或ATI图形子系统可以使用习知的ATPX ACPI方法，可以使用相似的方法或功能于驱动程序用于来自其它制造商之图形子系统)，藉由处理器12提供适当的讯号至功率控制器60。其次，于方块S906致能子系统40。此可以藉由使用于组构管理器(Configuration manager)中窗口PnP呼叫(Windows PnP call)致能子系统40实施。一旦子系统被致能，则操作系统可以列举所有的装置以获得新的装置名称。为了此目的可以使用窗口列举显示装置()API功能(Windows EnumDisplayDevices()API function)。其后，可以使用窗口改变显示设定EX()API呼叫(Windows ChangeDisplaySetting()API call)创造具有二种装置之扩充的桌上型计算机。应用程序软件201现在可以感知适配器之数目已经改变(例如，藉由接收WM_DISPLAYMODECHANGE讯息)。应用程序软件201可以发出重新起动命令。可以使用对于ATI/AMD图形子系统用于驱动程序功能之CWDDEDI、或者使用来自其它制造商对于图形子系统用于驱动程序之相似的功能、以及禁能整合之I²C控制器、使用控制方法呼叫之禁能I²C缓冲器，所有这些于方块S906中关断显示器电源。于方块S908中可以组构开关56以选择从图形子系统40之输出，例如使用ATPX ACPI方法用于ATI/AMD图形子系统，或者使用来自其它制造商之对于图形子系统用于驱动程序之相似的功能。于方块S910中，可以逻辑方式致能新致能之图形子系统40，而使得对于操作系统之剩余的部分为可观察的。此可以使用Windows ChangeDisplaySettingEX()API呼叫完成。而且，可以藉由从显示之桌上型计算机卸下子系统而逻辑上禁能图形子系统30。此可以使用Windows ChangeDisplaySettingEX()API呼叫完成。当由操作系统询问时，可以作成另外隐私的API(避开)呼叫至驱动程序以隐藏整合的显示，由此隐藏该禁能之图形子系统。

如所提及的，于Vista下，仅仅一个图形KMD能够是主动的。欲支持通常由二个不同的装置驱动程序控制之二个图形子系统30、40，KMD代理器驱动程序组件324用作为用于二个图形子系统30、40之核心模式驱动程序。同样情况，UMD代理器驱动程序组件320、322用作为单一UMD。

当装置10转变至，或者重回至其低功率消耗模式时，执行方块S912至S918。广言之，图形子系统40被禁能和设置在其低功率消耗模式，同时致能图形子系统40。欲达成此情况，于方块S912和S914中致能图形子系统30。再者，可以藉由在方块S912逻辑致能关联于图形子系统30之显示，和于方块S914逻辑禁能有关子系统40之显示，而实施此情况。可以藉由适当的操作系统API呼叫，譬如上述之EnumDisplayDevices()和ChangeDisplaySettingEX()呼叫，或者直接与硬件通信，而实施方块S912和S914。

于方块S918中，于该显示被逻辑禁能后，可以使用API呼叫至KMD组件360、362以实际设置图形子系统40于其低功率模式。如此情况，处理器12提供适当的讯号至功率控制器60设置图形子系统40于其低功率状态。于其最简单之形式，功率控制器60断接电源至图形子系统40或图形子系统40之组件。或可取而代之，功率控制应用程序软件201可以指令功率控制器60设置图形子系统40进入低功率休眠模式，譬如由ACPI规格所定义之装置功率状态之其中之一。无论如何，于此种较低功率消耗模式，调节电压，和/或降低供电至所有的或部分的图形子系统40和/或减慢由图形子系统40使用之选择的时脉。

一旦图形子系统30、40之特定的其中一个被逻辑上和实体上致能后，UMD代理器组件320、322和KMD代理器组件324被提供为现时主动子系统之指示，以及用于图形子系统之API/DDI呼叫如适当的被路由至UMD/KMD组件340、350、360或342、352、362，对应于现时致能之图形子系统30、40，如上述说明。

欲确保适当地设定开关56，用于装置10之BIOS能够允许用户选择哪一个装置在起动时将是主动的。

有利的情况是，如所述之组构开关56和图形子系统40和图形子系统30，减少功率消耗并且引致装置10要求二个图形处理器之仅其中一个消耗功率，由此减少总能源消耗并且保护电池寿命。举例而言，可携式计算机典型由商务旅行者使用于电池操作模式(DC电源)。此种用户当旅行时之典型使用样式将包含文字处理、表示，和电子邮件应用程序软件。这些应用程序软件不需要由外部图形子系统40提供之重任务图形加速(heavy duty graphics acceleration)。从使用之第二(例如，外部)图形子系统40转变至使用之第一(例如，整合之)图形子系统30，具有较低之平均功率消耗，帮助高性能图形处理与较低功率消耗之间之平衡而没有牺牲总系统性能。

图10为本发明之另一个范例实施例，计算装置10’之部分之范例简化方块图。计算装置10’实质上相似于计算装置10。功能上相等于装置10之组件之装置10’之组件系标以“’”符号，而因此将不再作详细之说明。然而，简言之，装置10’包含二个图形子系统30’、40’。而且，图形子系统30’包含图形引擎32’、内存控制器72’、显示器接口74’、和总线接口78’。第二图形子系统40’藉由高速总线20’之方式与图形子系统30’通信。图形子系统40’包含其自己的图形引擎42’、内存控制器52’、显示器接口54’。图形子系统40’进一步与图形内存50’通信。值得注意的是，装置10’不包含用来控制哪一个图形子系统30’和图形子系统40’与显示器26’互相连接之开关。取而代之，以及将变得很清楚的，图形子系统40’被调适绘成图形横越总线20’至内存14’中。

装置10’之软件控制操作机构相似于装置10之软件控制操作机构。然而，装置10’之软件控制操作之部分当装置10’转换于高和低功率消耗状态之间时不同于装置10者。

特别地，图11描绘本发明之范例实施例之软件方块步骤S1100，该实施例可以在装置10’之系统内存内软件之控制下由处理器12’实施。再者，每次装置10’经历状态改变可以实施方块步骤S1100，对于此改变将因此配置图形子系统30和40。如所例示，于方块S1102中软件201决定是否装置10’将假定其较高功率消耗模式，或其较低功率消耗模式。

当装置10’再开始(或者转变至)其高功率消耗模式时，则执行方块S1104至S1110。于方块1104若子系统40’尚未设置于其全操作(高功率消耗)模式，则将其设置在此模式。此可以藉由提供适当的讯号透过驱动程序控制图形子系统40’至功率控制器60’而实施。其次，于方块S1106和S1108致能图形子系统40’。再者，此可以藉由于方块S1104中以逻辑方式禁能任何与图形子系统30’相关联之互连接之显示，并且于方块S808中以逻辑方式致能与图形子系统40’连接之显示而实施。可以藉由适当的操作系统API呼叫，譬如上述之EnumDisplayDevices()和ChangeDisplaySetting()呼叫，或者透过与硬件直接通信，再实施方块S1106和S1108。

值得注意的是，没有实际的显示器连接到图形子系统40’。于方块S1110，在缺乏开关56(图4之装置10)之情况下，组构图形子系统40’之驱动程序软件控制操作绘成图像于图形子系统30’之缓冲器14’中，而不在关联之内存50’内。方便地于存在高速总线20之情况(例如，具体实施为PCLe总线)，由于部分转移速度由总线致能，此种绘成可能横越总线20。

而且，进一步组构用于图形子系统30’之驱动程序以导致图形子系统30’之显示器接口74’取样于内存14’中之帧缓冲器，以便将由图形子系统40’绘成于内存14’中帧缓冲器中之图像表现于互连接显示器26’中。同时，用于图形子系统30’之驱动程序可以指导图形子系统30’之图形引擎32’保持实质地静止或闲置。此种操作模式被示意地描绘于图12A中，仅仅将图形子系统40’和图形子系统30’之主动区块用网目线作成阴影。

很显然的，于图12A之实施例中，未使用内存50’和显示器接口54’。如此情况，能够从图形子系统40’去除这些功能区块以便降低成本。当能够制造子系统40’以补偿由子系统30’所提供之功能时，制造这种图形子系统也许是很有益处的。举例而言，子系统能够设有图形引擎42’，该图形引擎42’提供3D图形或视频译码能力。图形引擎32’可以不包含这些能力。同时，由图形引擎32’提供之2D图形能力不需包含于子系统40中。消费者，仅当需要额外的功能时，能够依次加上图形子系统30’。

当装置10’欲转变至或者重回至其低功率消耗模式时，执行方块S1112至S1118。广言之，图形子系统40’被部分或完全地禁能和设置在其低功率消耗模式，并且由图形子系统30’再实施绘成。欲达成此情况，于方块S812中可以致能互连接关联于图形子系统30’之任何显示，以及于方块S1114可以逻辑上禁能与图形子系统40’实际连接之任何显示。其次，再度组构图形子系统30’之驱动程序软件控制操作以导致图形子系统30’绘成图像于内存14’中。显示器接口74’继续取样内存14’以表现图像于与端口78’相互连接之显示器26’上。而且，处理器12’首先提供适当的讯号至方块S818中之功率控制器60’，设置图形子系统40’于低功率状态。于其最简单之形式，功率控制器60’断接电源至图形子系统40’或者设置图形子系统40’成较低功率修眠模式。再者，于此较低功率修眠模式，调节电压，和/或所有的或部分的图形子系统40’被降低供电和/或减慢由图形子系统40’所使用之选择的时脉。详言之，图形子系统之图形引擎42’保持闲置或实质上闲置(例如，其可以减慢、禁能或降低供电)。此种操作模式被示意地描绘于图12B中，仅仅将图形子系统40’和图形子系统30’之主动功能区块用网目线作成阴影。非主动/闲置功能区块可以被整个禁能，或者操作于减少之电压或时脉速度。

可视需要选择使用，当图形引擎32’未使用时，可以禁能图形子系统30’之部分。此能够藉由设置图形引擎32’和其它的组件于一个或多个电压岛而促成，该电压岛可以藉由GPIO或任何时间图形子系统40’负责绘成图像之相似电路之方法而被禁能。

其它的变化亦将是明显的。举例而言，于描绘于图12A中之高功率模式中，图形子系统30’和图形子系统40’能够绘成于内存14’或内存50’中。于此种方式，二个图形子系统30’和40’可以一致操作，各绘成替代的帧于内存14’中或者绘成各帧之部分于内存14’中、。

又于其它的实施例中，额外的显示器可以连接至图形子系统30’和40’，允许共同使用多个显示器于高功率消耗模式。于此种方式，能够使用显示器接口54以驱动第二显示器。依于转变至较低功率消耗模式，能够组构装置10’以如图9B中描绘方式操作。

同样情况，装置10’(或10)能够包含多个连接至总线20’(或20)之额外的图形子系统，所有的该等图形子系统在高功率消耗模式能够是主动的，并且透过图形子系统30’之显示器接口74’绘成图形。依于转变至较低功率消耗模式，能够禁能这些图形子系统，并且绘成之图像能够留在图形子系统30’之图形引擎32’中。

又于图13中之另一个实施例中，计算装置10可底包含直接内存存取(DMA)控制器90。DMA控制器90可以将资料从内存50’转移至内存14’。于此种方式，于装置10’之较高功率修眠模式，图形子系统40’能够绘成图像至内存50’。然后这些绘成之图像能够由DMA控制器90转移至内存14’中之帧缓冲器。DMA控制器90能够形成部分之图形子系统30’或40’(例如作为图形引擎32’或42’之DMA引擎)，或者不然位在计算装置10’中。资料可以横越总线20’转移，或者不然从内存50’直接至内存14’。显示器接口74’将继续操作如上所揭示，取样于内存14’中之帧缓冲器表现绘成之图像于显示器26’上。再者，图13之装置10’之主动区块，于其高功率消耗模式于图13中以网目阴影线例示。

当然，上述之实施例仅欲作例示用而不能用作限制。实现本发明之说明之实施例可接受许多形式、部件和细部之配置、和操作次序之修饰。本发明确切地说将包括在其范围内之所有的此种修饰，如由权利要求书所界定者。