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

专利名称：用于具有多重图形子系统、减少的功率消耗模式的计算装置的驱动程序架构、软件和方法
技术领域：
本发明大体上系关于计算装置，尤系关于具有多重图形子系统、和关联之软件驱 动程序之装置。于一个态样中，本发明亦系关于用来降低此等装置中功率消耗的方法。
背景技术：
许多电子装置，譬如习知的计算装置现在包含图形子系统能够描绘二或三维图 形；译码和编码动式视讯等等。欲提供这些特征和所希望之处理速度，现代的图形子系统 包含持续增加数目之晶体管。毫不奇怪的，增加晶体管数量已导致由图形子系统所造成之 对应较高的电力消耗。结果，最快的和最富特征的图形子系统已大部分预留给能够符合增加功率要求之 装置。譬如膝上型、个人数字助理、视频和音频播放器、手机、等等之可携式计算装置通常已 装备成受到功能限制，但是具有电性效率(亦即，低功率)之组件。时常这些图形子系统整合于其它的计算组件中，譬如处理器互连接电路(时常称 之为“芯片组”)。最近，有提供用于可携式装置之图形特征和性能以对抗静止式计算机之那些功能 之倾向。往往，此藉由允许附加视情况选用之外部的高功率图形子系统于可携式装置而达 成。例如，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可以是于监视器、IXD面板、电视、等等之形式。额外的第二图形子系统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不需要根据此平台。取而代之，范例软件可以结合其 它已知的计算机操作系统(譬如LiMDuMacOSX、或其它的操作系统)工作。用不同的操作 系统，软件架构可以与图4中所描绘之软件架构在材料方面不同。于窗口维斯塔操作系统环境中，硬件组件(譬如图形子系统30、40)之低阶层控制 典型由一般称之为驱动程序之软件组件所执行。各硬件组件之操作由一个或多个此种组件 所控制。驱动程序架构，于窗口维斯塔操作系统情况被称之为窗口装置驱动程序模型 (Windows Device Driver Model，WDDM)，并且更详细说明于微软窗口驱动程序备份工具 软件应用程序接口(Microsoft Windows Driver Kit API)。详细说明可以于下列网址获 得:http://www.microsoft. com/whdc/devtools/WDK/AboutffDK. mspx 禾口 http://msdn2. microsoft, com/en-us/1 ibrary/aa480220. aspx，该说明之内容由此加入作为参考。在解说图4中所例示之软件200之操作之前，适合先说明习知的窗口维斯塔 (Windows Vista)架构。欲达此目的，图3描绘根据窗口维斯塔操作系统之习知的软件 200’。如所例示，软件200’包含应用程序软件202’、数个属性、操作系统图形组件204’、 206’、208’、210’(称之为运作时间(rim-time)组件)；以及数个硬件特定图形装置驱动程 序组件220、222、和224，定义装置驱动程序用于图形子系统，像是子系统30和40。而且，亦 说明显示加载器模块218’、窗口维斯塔核心216’、和窗口图形装置接口(⑶I)软件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组
8件。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/1 ibrary/aa4490246. aspx。UMD组件和KMD组件具有不同的结构、不同的登录点、和不同的系统接口。装置是 否需要UMD或KMD，依于装置之类型和于操作系统中已经对其提供之支持而定。用于图形 子系统(譬如图形子系统30、40)之驱动程序典型上包含至少一个运作于核心模式之组件。 再者，于窗口维斯塔操作系统中，KMD组件被加载于系统初始化(亦即，升高供电)，而UMD 组件当需要时可经要求而加载。详言之，于窗口维斯塔架构中，为了获得低阶层存取于由这些子系统所使用之资 源，用于图形子系统之KMD组件与对应之KMD组件通信。典型的情况是，各KMD组件提供装 置驱动程序接口(device driver interface，DDI)，对于对应之UMD组件为已知。DDI可以 包含功能呼叫、目标(包含方法)、输入/输出控制(input/output control, I0CTL)呼叫 和关联之数据结构。如将了解的，功能呼叫透过其时常组构于此种数据结构中之功能/方 法参数接收资料。此数据结构之正确性质特定于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),其可从微软石if发 之网络(Microsoft Developer，s Network)(网址:www. msdn. com)取得，该软件内容由此 结合入本说明书作为参考。详言之，于UMD组件220、222或KMD组件224由操作系统之加载例程加载后， 定位该驱动程序组件登录点-著名的驱动程序登录0 (DriverEntry())(用于核心模式 驱动程序)或者DII主要()(DIIMainO)或者否则其它方面(例如，开放式适配器0 (OpenAdapter 0))用于 UMD 组件 220、222。UMD/KMD 组件 220、222、224 包含从 OS 接收已熟 知的结构功能，该OS由在UMD/KMD组件220、222、224之登录点之码所填满，指向在执行所
9期望之性能之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 ()，并且定义之驱动程序例程被暂存于预期的结构中。DIIMainO登录点用来分配和初始UMD组件之基本数据结构，或者当卸载UMD时于 控制之机构卸除这些组件。于WDDM UMD 组件之情况，OpenAdapter ()于与 DriverEntry ()呼叫 KMD 组件相似 之方式呼叫工作。也就是说，OpenAdapterO呼叫接收具有一组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包含初始例程、驱动程序登录0，该驱动程序 登录0典型藉由名称和内存地址返回目标等级、功能和结构之识别符，提供所需的DDI用 于KMD组件224。如所提及的，KMD组件224典型于系统起动被加载(和初始化)。此外，KMD组件224可以包含DDI未明确已知或报告于操作系统之剩余的部分，但 是已知于互补的UMD组件220或222。软件200被层化，具有较高阶层层使用较低层提供某些功能。那么，应用程序软件 202藉由制作呼叫至运作时间操作系统图形组件204’、206’、208’、或UMD组件220、222、或 ⑶I 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中所
7J\ ο也对附加的功率控制应用程序软件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包含功能、目标、I0CTL、等等，该等功能、目标、IOCTL 等为硬件特定一分别至图形子系统30和40。KMD组件360、362同样相似于KMD组件224， 并且包含功能、目标、I0CTL、等等，设计于核心模式与图形子系统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 (例如， OpenAdapterO)之初始化例程。一旦已藉由各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功能/呼叫/目标/I0CTL、等等相关联而可以暴露于操 作系统和其它的应用程序软件。各路由例程或目标依次路由呼叫至UMD/KMD驱动程序组件 之其中之一，对于该驱动程序组件该代理器驱动程序组件用作为代理器。于此种方式，API/ DDI呼叫至代理器驱动程序组件320、322和324可以被路由至在UMD驱动程序340、342或 350,352或KMD组件360、362中对应之驱动程序功能/呼叫/目标/I0CTL。详言之，如图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提供有限的功
15能。举例而言，图形子系统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实施。一旦子系统被致能，则操作系统可以列举 所有的装置以获得新的装置名称。为了此目的可以使用窗口列举显示装置OAPI功能 (Windows EnumDisplayDevicesOAPI function)。其后，可以使用窗口 改变显示设定 EX () API呼叫(Windows ChangeDisplaySettingOAPI call)创造具有二种装置之扩充的桌上 型计算机。应用程序软件201现在可以感知适配器之数目已经改变(例如，藉由接收WM_ DISPLAYM0DECHANGE讯息)。应用程序软件201可以发出重新起动命令。可以使用对于ATI/ AMD图形子系统用于驱动程序功能之CWDDEDI、或者使用来自其它制造商对于图形子系统 用于驱动程序之相似的功能、以及禁能整合之I2C控制器、使用控制方法呼叫之禁能I2C缓 冲器，所有这些于方块S906中关断显示器电源。于方块S908中可以组构开关56以选择从 图形子系统40之输出，例如使用ATPX ACPI方法用于ATI/AMD图形子系统，或者使用来自 其它制造商之对于图形子系统用于驱动程序之相似的功能。于方块S910中，可以逻辑方式 致能新致能之图形子系统40，而使得对于操作系统之剩余的部分为可观察的。此可以使用 Windows ChangeDisplaySettingEXOAPI呼叫完成。而且，可以藉由从显示之桌上型计算机 卸下子系统而逻辑上禁能图形子系统30。此可以使用Windows ChangeDisplaySettingEXQ
17API呼叫完成。当由操作系统询问时，可以作成另外隐私的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呼叫，譬如上述之EnumDisplayDevicesO和 ChangeDisplaySettingEXO呼叫，或者直接与硬件通信，而实施方块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，
18进一步与图形内存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至 Sllioo于方块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’ 之任何显示，以及于方块Sl 114可以逻辑上禁能与图形子系统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中以网目阴影线例示。当然，上述之实施例仅欲作例示用而不能用作限制。实现本发明之说明之实施例 可接受许多形式、部件和细部之配置、和操作次序之修饰。本发明确切地说将包括在其范围 内之所有的此种修饰，如由权利要求书所界定者。
权利要求
一种电子装置，包括第一图形子系统，用于绘成图形；第二图形子系统，用于绘成图形；至少一个显示器，与该第一图形子系统和该第二图形子系统的至少其中一个通信；处理器，执行应用程序软件和驱动程序软件，该驱动程序软件包括第一和第二驱动程序组件和代理器驱动程序组件，该第一和第二驱动程序组件用来分别控制该第一和该第二图形子系统的操作，而该代理器驱动程序组件用来依据该第一和第二图形子系统的哪一个是在使用中而路由呼叫从该应用程序软件至该第一和第二驱动程序组件的其中一个。
2.如权利要求1所述的电子装置，其中，该处理器执行指令，使得该处理器将该电子 装置从其中该第二图形子系统绘成图形于该显示器上的第一模式转变至其中该第一图形 子系统绘成图形于该显示器上的第二模式，以及该第二图形子系统是处在较低功率消耗模 式。
3.如权利要求1所述的电子装置，其中，该第一和第二驱动程序组件包括执行于该处 理器的用户模式的驱动程序组件。
4.如权利要求1所述的电子装置，其中，该第一和第二驱动程序组件包括执行于该处 理器的核心模式的驱动程序组件。
5.如权利要求1所述的电子装置，其中，该第一和第二图形子系统的哪一个是在使用 中是根据该电子装置的功率状态而定。
6.如权利要求1所述的电子装置，其中，该代理器驱动程序组件路由呼叫从在该装置 的操作系统至该第一和第二驱动程序组件的其中一个，是根据该第一和第二图形子系统的 哪一个是在使用中而定。
7.如权利要求1所述的电子装置，其中，该代理器驱动程序组件建立一致结构确认于 该第一和第二驱动程序组件中相等的驱动程序功能用来实施该路由。
8.一种电子装置，包括第一图形子系统，用于绘成图形； 第二图形子系统，用于绘成图形；显示器，与该第一图形子系统和该第二图形子系统二者通信； 处理器，执行应用程序软件和驱动程序软件，该驱动程序软件包括 第一和第二用户模式驱动程序组件，用来分别控制该第一和第二图形子系统的操作， 和用户模式代理器驱动程序组件，用来根据该第一和第二图形子系统的哪一个是在使用中 而路由呼叫从该应用程序软件至该第一和第二用户模式驱动程序组件的其中一个；第一和第二核心模式驱动程序组件，用来分别控制该第一和第二图形子系统的操作， 以及核心模式代理器驱动程序组件，用来根据该第一和第二图形子系统的哪一个是在使用 中而路由呼叫从该用户模式驱动程序组件的其中一个至该第一和第二核心模式驱动程序 组件的其中一个。
9.一种用来执行于计算机装置上的计算机可读取媒体存储驱动程序软件包括，该计算 装置包括第一图形子系统，用于绘成图形； 第二图形子系统，用于绘成图形；显示器，与该第一图形子系统和该第二图形子系统二者通信；以及处理器；该驱动程序软件包括代理器驱动程序组件，其用来根据该第一和第二图形子系统的哪 一个是在使用中而路由呼叫从该应用程序软件至第一和第二驱动程序组件的其中一个，该 第一和第二驱动程序组件用来分别控制该第一和第二图形子系统的操作。
10.如权利要求9所述的计算机可读取媒体，其中，该代理器驱动程序组件建立一致结 构确认于该第一和第二驱动程序组件中相等的驱动程序功能用来实施该路由。
11.如权利要求10所述的计算机可读取媒体，其中，该代理器驱动程序组件根据该第 一和第二图形子系统的哪一个是在使用中而路由呼叫从在该装置的操作系统至该第一和 第二驱动程序组件的其中一个。
12.如权利要求9所述的计算机可读取媒体，其中，该第一和第二驱动程序组件包括执 行于该处理器的用户模式的驱动程序组件。
13.如权利要求9所述的计算机可读取媒体，其中，该第一和第二驱动程序组件包括执 行于该处理器的核心模式的驱动程序组件。
14.一种操作电子装置的方法，该电子装置包括用于绘成图形的第一和第二图形子系 统，该方法包括下列步骤接收来自软件应用程序的驱动程序呼叫或执行于该电子装置的操作系统；根据该第一和第二图形子系统的哪一个是在使用中而路由来自软件应用程序的驱动 程序呼叫至用来分别控制该第一和第二图形子系统的操作的第一和第二软件驱动程序组 件的其中一个。
15.如权利要求14所述的方法，进一步包括建立一致结构确认于该第一和第二驱动程序组件中相等的驱动程序功能用来实施该 路由。
全文摘要
现今许多的计算装置也许包含二个或更多个图形子系统。多重图形子系统可以具有不同的能力，并且可以例如消耗不同数量的电力，因为一个子系统较其它的子系统消耗更多的平均功率。较高的功率消耗图形子系统可以耦接到装置，并且此外可以用来取代较低的功率消耗图形子系统，导致较高的性能或额外的能力，但是增加总功率消耗。藉由从使用之较高的功率消耗图形子系统转变至较低的功率消耗图形子系统，同时设置该较高的功率消耗图形子系统于较低的功率消耗模式，则减少总功率消耗。处理器执行应用程序软件和驱动程序软件。驱动程序软件包含第一和第二驱动程序组件用来分别控制该第一和第二图形子系统之操作。其它代理器驱动程序组件根据该第一和第二图形子系统之哪一个是在使用中而路由呼叫(例如，API/DDI呼叫)至该第一和第二驱动程序组件其中之一。
文档编号G06F9/445GK101978352SQ200880126821
公开日2011年2月16日 申请日期2008年12月15日 优先权日2007年12月13日
发明者P·布林则 申请人:先进微装置公司