專利名稱：用于具有多重圖形子系統(tǒng)、減少的功率消耗模式的計算裝置的驅動程序架構、軟件和方法
技術領域：
本發(fā)明大體上系關于計算裝置，尤系關于具有多重圖形子系統(tǒng)、和關聯(lián)之軟件驅 動程序之裝置。于一個態(tài)樣中，本發(fā)明亦系關于用來降低此等裝置中功率消耗的方法。
背景技術：
許多電子裝置，譬如習知的計算裝置現(xiàn)在包含圖形子系統(tǒng)能夠描繪二或三維圖 形；譯碼和編碼動式視訊等等。欲提供這些特征和所希望之處理速度，現(xiàn)代的圖形子系統(tǒng) 包含持續(xù)增加數(shù)目之晶體管。毫不奇怪的，增加晶體管數(shù)量已導致由圖形子系統(tǒng)所造成之 對應較高的電力消耗。結果，最快的和最富特征的圖形子系統(tǒng)已大部分預留給能夠符合增加功率要求之 裝置。譬如膝上型、個人數(shù)字助理、視頻和音頻播放器、手機、等等之可攜式計算裝置通常已 裝備成受到功能限制，但是具有電性效率(亦即，低功率)之組件。時常這些圖形子系統(tǒng)整合于其它的計算組件中，譬如處理器互連接電路(時常稱 之為“芯片組”)。最近，有提供用于可攜式裝置之圖形特征和性能以對抗靜止式計算機之那些功能 之傾向。往往，此藉由允許附加視情況選用之外部的高功率圖形子系統(tǒng)于可攜式裝置而達 成。例如，PCI快捷(PCIe)標準考慮PCI快捷之互連接兼容圖形卡，包含圖形子系統(tǒng)，作為 至膝上型計算機裝置之外部組件。于存在之多重圖形子系統(tǒng)中，時常希望切換計算裝置之操作狀態(tài)使用一個或另一 個圖形子系統(tǒng)而不須重新起動(例如，重新開機(rebooting))計算裝置。不幸的是，一些操作系統(tǒng)之軟件架構僅僅考慮使用單一的圖形驅動程序。于是，于 存在之多重圖形子系統(tǒng)中，此單一驅動程序需要控制所有的多重子系統(tǒng)之操作。此也許是 不切實際的，尤其是如果子系統(tǒng)由不同的制造者所提供時。因此，需要可以使用多重圖形驅動程序之軟件和裝置。
發(fā)明內容
現(xiàn)今許多計算裝置可以包含二個或更多個圖形子系統(tǒng)。該多重圖形子系統(tǒng)可以具 有不同的能力，以及可以例如消耗不同數(shù)量之電力，因為一個子系統(tǒng)較其它的子系統(tǒng)消耗 更多的平均功率。較高的功率消耗圖形子系統(tǒng)可以耦接到裝置，并且此外可以用來取代，或 附加至較低的功率消耗圖形子系統(tǒng)，導致較高的性能或額外的能力，但是增加總功率消耗。 藉由從使用之較高的功率消耗圖形子系統(tǒng)轉變至較低的功率消耗圖形子系統(tǒng)，同時設置該 較高的功率消耗圖形子系統(tǒng)于較低的功率消耗模式，則減少總功率消耗。處理器執(zhí)行應用程序軟件和驅動程序軟件。驅動程序軟件包含第一和第二驅動程 序組件用來分別控制該第一和第二圖形子系統(tǒng)之操作。其它代理器驅動程序組件依于該第 一和第二圖形子系統(tǒng)之哪一個是在使用中而路由呼叫(例如，API/DDI呼叫)從該應用程 序軟件至該第一和第二驅動程序組件之其中之一。習知使用上，此代理器驅動程序組件表現(xiàn)單一接口至操作系統(tǒng)和應用程序軟 件，同時允許使用二個分離的驅動程序組件。此代理器驅動程序組件可以是窗口維斯塔 (Windows Vista)用戶模式驅動程序(user mode driver, UMD)組件和/或核心模式驅動 程序(kernel mode driver, KMD)組件。依照本發(fā)明之態(tài)樣，提供一種電子裝置。該電子裝置包括第一圖形子系統(tǒng)，用于 繪成圖形；第二圖形子系統(tǒng)，用于繪成圖形；至少一個顯示器，與該第一圖形子系統(tǒng)和該第 二圖形子系統(tǒng)之至少其中之一通信通信；處理器，執(zhí)行應用程序軟件和驅動程序軟件，該驅 動程序軟件包括第一和第二驅動程序組件用來分別控制該第一和第二圖形子系統(tǒng)之操作， 和代理器驅動程序組件用來依于該第一和第二圖形子系統(tǒng)之哪一個是在使用中而路由呼 叫從該應用程序軟件至該第一和第二驅動程序組件之其中之一。依照本發(fā)明之另一個態(tài)樣，提供一種電子裝置，包括第一圖形子系統(tǒng)，用于繪成 圖形；第二圖形子系統(tǒng)，用于繪成圖形；顯示器，與該第一圖形子系統(tǒng)和該第二圖形子系統(tǒng) 二者通信；處理器，執(zhí)行應用程序軟件和驅動程序軟件，該驅動程序軟件包括第一和第二用 戶模式驅動程序組件用于分別控制該第一和第二圖形子系統(tǒng)之操作，和用戶模式代理器驅 動程序組件用來依于該第一和第二圖形子系統(tǒng)之哪一個是在使用中而路由呼叫從該應用 程序軟件至該第一和第二用戶模式驅動程序組件之其中之一；第一和第二核心模式驅動程 序組件，用來分別控制該第一和第二圖形子系統(tǒng)之操作，以及核心模式代理器驅動程序組 件，用來依于該第一和第二圖形子系統(tǒng)之哪一個是在使用中而路由呼叫從該用戶模式驅動 程序組件其中之一至該第一和第二核心驅動程序組件之其中之一。依照本發(fā)明之又另一個態(tài)樣，提供一種操作電子裝置之方法，該電子裝置包括用 于繪成圖形的第一和第二圖形子系統(tǒng)。該方法包括下列步驟接收來自軟件應用程序之驅 動程序呼叫或執(zhí)行于該電子裝置之操作系統(tǒng)；依于該第一和第二圖形子系統(tǒng)之哪一個是在 使用中而路由來自軟件應用程序之驅動程序呼叫至用來分別控制該第一和第二圖形子系 統(tǒng)之操作之第一和第二軟件驅動程序組件之其中之一。于查閱本發(fā)明之特定實施例結合所附圖式之下列說明，本發(fā)明之其它態(tài)樣和特征 對于熟悉此項技術而言將變得很清楚。
于僅以舉例方式例示之圖形中，本發(fā)明之實施例圖1為本發(fā)明之范例實施例，計算裝置之簡化示意方塊圖；圖2為本發(fā)明之范例實施例，計算裝置之簡化示意方塊圖；圖3為習知軟件之簡化功能方塊圖；圖4為于圖2之計算裝置范例軟件之簡化功能方塊圖，包含本發(fā)明之范例實施例 之驅動程序軟件；圖5為本發(fā)明之范例實施例，于圖2之裝置由軟件所實施之詳細步驟之流程圖；圖6示意地顯示于圖4之軟件中API/DDI呼叫。圖7為本發(fā)明之范例實施例，于圖2之裝置由軟件所實施之詳細步驟之流程圖；圖8為圖2之計算裝置之進一步簡化示意方塊圖；圖9為本發(fā)明之范例實施例，于圖2之裝置由軟件所實施之詳細步驟之流程圖；圖10為本發(fā)明之另一范例實施例，計算裝置之部分之進一步部分簡化示意方塊圖；圖11為本發(fā)明之范例實施例，于圖10之裝置由軟件所實施之詳細步驟之流程圖；圖12A和12B為例示圖10之裝置之操作之簡化方塊圖；圖13為本發(fā)明之另一范例實施例，計算裝置之部分之進一步部分簡化示意方塊 圖。
具體實施例方式圖1為電子裝置10之簡化、高階層方塊圖，包含二個圖形子系統(tǒng)30和40、和顯示 器26。如將變得很清楚，各圖形子系統(tǒng)30和40包含特殊化之電子電路能夠繪制計算機圖 形，于一個或多個之2D圖、3D圖、譯碼動式視訊、等等之形式。一個圖形子系統(tǒng)40可能消耗較其它的圖形子系統(tǒng)30為高的平均功率。典型的情 況是，圖形子系統(tǒng)40消耗較高的平均功率，而具有較圖形子系統(tǒng)30為大的圖形繪制能力。 圖形子系統(tǒng)40例如也許能夠較消耗較低之平均功率之圖形子系統(tǒng)以較高之幀率(frame rate)繪制2D或3D圖形。同樣情況，圖形子系統(tǒng)30、40不需具有相同的能力。圖形子系統(tǒng) 40較圖形子系統(tǒng)30典型包含更多的功能區(qū)塊。圖形子系統(tǒng)30和40 二者可以被實體或邏輯耦接至相同的顯示器26，于此顯示器 上顯示繪制之圖形。本發(fā)明之范例實施例，裝置10可以從較高的功率消耗模式(于此模式 至顯示器26之圖形由較高功率消耗之圖形子系統(tǒng)40繪制成)切換至較低的功率消耗模式 (于此模式至顯示器26之圖形由較低功率消耗之圖形子系統(tǒng)30繪制成)，并且圖形子系統(tǒng) 40被部分、完全或實質上禁能。習用上，可以用動態(tài)方式將高功率消耗模式轉變至低功率消耗模式，而不需要裝 置10循環(huán)供電(亦即，電源切斷和重新起動)，并且可以于軟件控制下由處理器12生效。 如此情況，軟件可以包含應用程序軟件、韌體、裝置驅動程序、BIOS、等等。本發(fā)明可以形成包含二個圖形子系統(tǒng)之實際上任何電子裝置之部分。就此種情 況，裝置10能夠采取桌上型計算裝置、可攜式計算裝置(包含膝上型計算機、PDA、移動式電 話、視頻和音頻播放器、媒體中心、等等)之形式。于下文說明之范例實施例中，本發(fā)明之實施例揭示為形成移動式(膝上型)計算裝置之部分。詳言之，圖2為本發(fā)明之范例實施例，特定的移動式計算裝置10之簡化方塊圖。圖 1中顯示描繪之裝置10為根據(jù)習知的英特爾X86計算機架構之計算裝置。然而，熟悉此項 技術者將容易了解到本發(fā)明可以是具有其它架構，譬如，功率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進一步包含第一圖形子系統(tǒng)30，具體實施為整合圖形處理器 (integrated graphics processor，IGP)，適合用來產生視頻訊號顯示在顯示器26上，該顯 示器26可以是于監(jiān)視器、IXD面板、電視、等等之形式。額外的第二圖形子系統(tǒng)40形成裝置10之部分。于此范例實施例中，圖形子系統(tǒng) 40被具體實施為形成在周邊擴充卡46上之外部圖形處理器。周邊擴充卡46亦藉由于擴充 總線20上之擴充凹槽22之方式連接至接口電路16。如將變得很清楚，藉由設置第二圖形 子系統(tǒng)40，裝置10可以提供擴大的圖形能力，此能力在其它情況不表現(xiàn)于裝置10中。由第 二圖形子系統(tǒng)使用為幀緩沖器之圖形內存50可以包含在周邊擴充卡46上。同樣情況，與 圖形子系統(tǒng)40通信之功率控制器60可以視需要選擇形成于擴充卡46上，并且可以控制圖 形子系統(tǒng)40之操作。詳言之，功率控制器60可以調節(jié)由圖形子系統(tǒng)40之組件所使用之時 脈，譬如內存和像素時脈；禁能(或者斷接)圖形子系統(tǒng)40之功能區(qū)塊；降低施加到圖形子 系統(tǒng)40之部分之電壓；或者不然設置子系統(tǒng)40于其中功率消耗以已知方式減少之一個或 多個模式中。另一個視需要選用之功率控制器70可以與第一圖形子系統(tǒng)30通信，并且可以調 節(jié)由圖形子系統(tǒng)30之組件所使用之時脈，譬如內存和像素時脈；禁能(或者斷接)圖形子 系統(tǒng)30之功能區(qū)塊；降低施加到圖形子系統(tǒng)30之部分之電壓；或者不然設置子系統(tǒng)30于 其中功率消耗以已知方式減少之一個或多個模式中。雖然例示的圖形子系統(tǒng)40形成在周邊擴充卡46上，但是熟悉此項技術者將容易 了解到圖形子系統(tǒng)40僅能夠容易形成在裝置10之主機板上，或其它地方。接口電路18互連接較低速度周邊裝置和互連接，譬如光驅28、和藉由整合IDE/ SATA埠(未顯示)方式于硬盤機形式之永久儲存內存34、和列表機，以及藉由并聯(lián)或USB 埠(未顯示)方式之其它的周邊裝置。又其它的周邊裝置可以藉由較低速度擴充總線24 之方式互連接，例如遵從已知的PCI或ISA標準。譬如聲卡網絡接口(未顯示)之其它組 件可以同樣地藉由低速度擴充總線224之方式，或其它方式互連接至接口電路18。如所提示的，裝置10可以方便地形成為于膝上型或較小計算裝置形式之可攜式 計算機裝置。如此情況，單一外殼可以包含DC電源38、顯示器26、和上述主機板和組件。第二圖形子系統(tǒng)40可以附加至容裝計算裝置之剩余部分之單一外殼，或者可以形成擴展塢 之部分，該擴展塢當裝置10實體互連接至其上時僅形成裝置10之部分。裝置10可操作于至少二種功率消耗模式較高功率消耗模式和較低功率消耗模 式。于所描述之實施例中，當裝置10藉由連接到AC(主)供電之電源36供電時，裝置10 可假設在該較高功率消耗模式；當裝置10藉由使用一個或多個電池、燃料電池、等等DC電 源38供電時，可以假設在該較低功率消耗模式?；蚩蛇x擇使用，功率消耗模式可以根據(jù)例 如用戶喜好、執(zhí)行軟件應用程序之類型、電池之位準、等等，而由用互選擇、軟件控制。于所描述之實施例中，裝置10執(zhí)行儲存于系統(tǒng)內存內之軟件200，如圖4中所例 示。系統(tǒng)內存包含永久儲存內存34和主存儲器14(圖2)，并且可以進一步包含額外的隨機 存取內存、只讀存儲器和光盤儲存內存之適當?shù)慕M合，由裝置10所使用以儲存和執(zhí)行軟件 200。范例軟件200能夠例如儲存于只讀存儲器中，或者從譬如光驅28 (圖1)之外部周邊、 或者經由計算機網絡(未顯示)加載。于所例示之實施例中，軟件200系基于微軟維斯塔(Vista)平臺。然而，于本發(fā)明 之范例實施例方式之軟件操作裝置10不需要根據(jù)此平臺。取而代之，范例軟件可以結合其 它已知的計算機操作系統(tǒng)(譬如LiMDuMacOSX、或其它的操作系統(tǒng))工作。用不同的操作 系統(tǒng)，軟件架構可以與圖4中所描繪之軟件架構在材料方面不同。于窗口維斯塔操作系統(tǒng)環(huán)境中，硬件組件(譬如圖形子系統(tǒng)30、40)之低階層控制 典型由一般稱之為驅動程序之軟件組件所執(zhí)行。各硬件組件之操作由一個或多個此種組件 所控制。驅動程序架構，于窗口維斯塔操作系統(tǒng)情況被稱之為窗口裝置驅動程序模型 (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描繪根據(jù)窗口維斯塔操作系統(tǒng)之習知的軟件 200’。如所例示，軟件200’包含應用程序軟件202’、數(shù)個屬性、操作系統(tǒng)圖形組件204’、 206’、208’、210’(稱之為運作時間(rim-time)組件)；以及數(shù)個硬件特定圖形裝置驅動程 序組件220、222、和224，定義裝置驅動程序用于圖形子系統(tǒng)，像是子系統(tǒng)30和40。而且，亦 說明顯示加載器模塊218’、窗口維斯塔核心216’、和窗口圖形裝置接口(⑶I)軟件214’。如將了解到，于窗口維斯塔操作系統(tǒng)下之驅動程序軟件能夠運作于用戶模式或核 心模式其中任一情況。用戶模式驅動程序(User-mode driver, UMD)組件執(zhí)行于由處理器 12所支持之非優(yōu)先的模式，并且僅被允許限制存取于內存、緩存器、等等。于圖2中，組件 220和222為UMD組件。其它的軟件，包含應用程序軟件202’，亦執(zhí)行于此模式。UMD組件 220和222和應用程序軟件202’不能獲得直接存取至低階層系統(tǒng)資料。他們同樣不能夠存 取內存之所有的區(qū)域、所有的緩存器、等等。然而他們可以呼叫至執(zhí)行于核心模式之軟件。相比之下，核心模式驅動程序(kernel-mode driver, KMD)組件執(zhí)行于與該操作系 統(tǒng)核心相同的處理器模式，而因此一般已釋放存取至裝置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組件具有不同的結構、不同的登錄點、和不同的系統(tǒng)接口。裝置是 否需要UMD或KMD，依于裝置之類型和于操作系統(tǒng)中已經對其提供之支持而定。用于圖形 子系統(tǒng)(譬如圖形子系統(tǒng)30、40)之驅動程序典型上包含至少一個運作于核心模式之組件。 再者，于窗口維斯塔操作系統(tǒng)中，KMD組件被加載于系統(tǒng)初始化(亦即，升高供電)，而UMD 組件當需要時可經要求而加載。詳言之，于窗口維斯塔架構中，為了獲得低階層存取于由這些子系統(tǒng)所使用之資 源，用于圖形子系統(tǒng)之KMD組件與對應之KMD組件通信。典型的情況是，各KMD組件提供裝 置驅動程序接口(device driver interface，DDI)，對于對應之UMD組件為已知。DDI可以 包含功能呼叫、目標(包含方法)、輸入/輸出控制(input/output control, I0CTL)呼叫 和關聯(lián)之數(shù)據(jù)結構。如將了解的，功能呼叫透過其時常組構于此種數(shù)據(jù)結構中之功能/方 法參數(shù)接收資料。此數(shù)據(jù)結構之正確性質特定于DDI定義中。于描述之實施例中，操作系統(tǒng)圖形組件204’、206’、和208’為由操作系統(tǒng)制造商 (如此情況為微軟公司)所提供之運作時間組件；而于UMD和KMD組件形式之硬件特定圖 形裝置驅動程序組件220、222、和224可以由第三方制造商(譬如圖形子系統(tǒng)30或40之制 造商)提供。操作系統(tǒng)圖形組件包含運作時間3D圖形運作時間組件204’(直接3D運作時間)、 硬件加速圖形接口運作時間組件(DXVA) 206’、3D開放式圖形庫(Open Graphics Library, OpenGL)運作時間圖形組件208’。對應之硬件特定UMD組件220和222提供對應于直接 3D、DXVA、和開放式GL API之API硬件呼叫之硬件特定執(zhí)行。運作時間組件204，、206，、208，和UMD組件220、和222提供聯(lián)合的圖形應用程序 軟件規(guī)劃器接口(API)，由應用程序軟件202’和操作系統(tǒng)之剩余的部分使用。詳言之，API 提供功能呼叫、目標、等等，其引起于UMD組件220，和222，或于運作時間組件204’、206’、 208’中驅動程序軟件例程(例如，功能或方法)之執(zhí)行，如由微軟公司詳細說明。API呼 叫可以藉由部分之操作系統(tǒng)(例如，模塊204’、206’、208’)，或藉由其它的驅動程序由應 用程序軟件200’完成。UMD組件220和222對應于API呼叫依次執(zhí)行軟件碼(典型于功 能、或目標方法之形式)。由D3D、DXVA和開放式GL UMD組件220和222所提供之功能和 回呼詳細說明于窗口驅動程序備份工具軟件顯示裝置窗口維斯塔顯示驅動程序模型參考 (Display Devices Windows Vista Display Driver Model Reference),其可從微軟石if發(fā) 之網絡(Microsoft Developer，s Network)(網址:www. msdn. com)取得，該軟件內容由此 結合入本說明書作為參考。詳言之，于UMD組件220、222或KMD組件224由操作系統(tǒng)之加載例程加載后， 定位該驅動程序組件登錄點-著名的驅動程序登錄0 (DriverEntry())(用于核心模式 驅動程序)或者DII主要()(DIIMainO)或者否則其它方面(例如，開放式適配器0 (OpenAdapter 0))用于 UMD 組件 220、222。UMD/KMD 組件 220、222、224 包含從 OS 接收已熟 知的結構功能，該OS由在UMD/KMD組件220、222、224之登錄點之碼所填滿，指向在執(zhí)行所
9期望之性能之UMD/KMD組件220、222、224內之功能。這些名稱由DDI規(guī)格所定義，并且透 過所稱為之定義檔案來執(zhí)行。例如，KMD組件224接收驅動程序_初始化_資料(DRIVER_INITIALIZATION_DATA) 結構，該結構包含一組用于其為DDI之驅動程序執(zhí)行功能組之部分之多種操作之功能指 針。當需要時，UMD組件220、222之剩余的部分可以呼叫這些功能以起始在驅動程序中之 適當?shù)牟僮鳎擈寗映绦蛴谠S多情況(但是并非需要全部)將引致存取至硬件(通常藉由 呼叫一些其它的KMD驅動程序內部功能)。UMD組件220和222可以形成為動態(tài)鏈接庫(dynamic linked library, DLL)，并 且順應WDDM。就此種情況，各UMD組件220、222依照WDDM之IOCT提供收集之功能和目標。 概略而言，各驅動程序組件包含定義的登錄點驅動程序登錄(DriverEntry ())、定義的目標 等級、驅動程序登錄點、定義的功能和回呼叫。加載各驅動程序后，于其登錄點之軟件碼被 執(zhí)行DriverEntry ()，并且定義之驅動程序例程被暫存于預期的結構中。DIIMainO登錄點用來分配和初始UMD組件之基本數(shù)據(jù)結構，或者當卸載UMD時于 控制之機構卸除這些組件。于WDDM UMD 組件之情況，OpenAdapter ()于與 DriverEntry ()呼叫 KMD 組件相似 之方式呼叫工作。也就是說，OpenAdapterO呼叫接收具有一組UMD組件220、222填滿指 向UMD組件內適當功能之功能指針之數(shù)據(jù)結構。在UMD內名稱和支持之功能/目標和關聯(lián)之碼地址藉由此結構方式因此被返回至 操作系統(tǒng)之剩余的部分。此外，由D3D、DXVA和OpenGL UMD組件220和222支持之UMD功 能和結構被詳細說明于窗口驅動程序備份工具軟件顯示裝置窗口維斯塔顯示驅動程序模 型參考，其可以從微軟研發(fā)之網絡“ supra ”取得。于是，于加載各UMD組件220、222之結束，API功能/目標，和IOCTL對于應用程 序軟件202’和操作系統(tǒng)軟件之剩余的部分為已知。API目標可以由應用程序軟件200藉由 于相同的地址創(chuàng)造目標之例子而引證。能夠執(zhí)行功能/方法和IOCTL于他們的對應地址。操作系統(tǒng)圖形模塊進一步包含核心模式圖形核心軟件組件210’(稱之為于窗口 維斯塔操作系統(tǒng)中直接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典型于系統(tǒng)起動被加載(和初始化)。此外，KMD組件224可以包含DDI未明確已知或報告于操作系統(tǒng)之剩余的部分，但 是已知于互補的UMD組件220或222。軟件200被層化，具有較高階層層使用較低層提供某些功能。那么，應用程序軟件 202藉由制作呼叫至運作時間操作系統(tǒng)圖形組件204’、206’、208’、或UMD組件220、222、或 ⑶I 214’而典型使繪制圖形。圖形模塊204’、206’、和208’僅包含屬性、共享于所有第三方視頻驅動程序之硬件獨立碼。運作時間組件204’、206’、208’依次可以制作API/DDI呼 叫至UMD組件220和222。定義于數(shù)據(jù)結構之已知的參數(shù)例如藉由至所存在的結構之適當 的指針而被遞送至UMD組件220和222。UMD組件220、222包含硬件特定碼、和結構。然而， 如所提及，UMD組件220、222僅僅具有用戶階層存取。UMD組件220、222與KMD組件224通 信，直接使用由KMD組件224提供之已知的API/DDI，或者透過核心模式圖形核心軟件組件 210，。KMD組件224依次包含功能、目標、等等，其能夠傳遞適當?shù)牡碗A層指令至位于下 方硬件(例如，圖形子系統(tǒng)30或40)。可以進一步排列多重呼叫至KMD組件224。低階層 指令依次可以由位于下方硬件執(zhí)行。舉例而言，低階層指令可以包含可執(zhí)行指令等之圖形 處理器。不像許多其它已知之操作系統(tǒng)，窗口維斯塔僅允許加載單一顯示驅動程序KMD組 件224’。其它補助的應用程序軟件用作為顯示驅動程序加載器218’。加載器218’一般依 于起動而執(zhí)行，但是亦可以于起動后執(zhí)行。加載器218’加載第三方KMD組件(例如，組件 224’)，并且將其初始化，用來由圖形核心軟件組件210所存取。雖然可以使用加載器218 加載/卸載核心模式驅動程序組件，像是KMD組件224’，但是一個圖形KMD組件224之加 載，需要另一個驅動程序之卸載?，F(xiàn)在，于存在之二個圖形子系統(tǒng)中，像子系統(tǒng)30、40(第1圖)，UMD組件220和222 以及KMD組件224可以控制二個圖形子系統(tǒng)之操作，并且允許選擇性地切換該二個圖形子 系統(tǒng)之間之操作。至驅動程序組件220、222、和224之API呼叫可以確認多個子系統(tǒng)之哪一 個將被尋址。然而，單一 UMD/KMD提供支持多個圖形子系統(tǒng)之要求引入限制。舉例而言，對 于單一驅動程序支持很多項之不同的適配器那是不切實際的。若子系統(tǒng)由不同的制造商提 供則惡化了此問題。圖4因此顯示了本發(fā)明之范例實施例之軟件和圖形模塊。再者，范例軟件描繪于 窗口維斯塔環(huán)境之情況。如此情形，形成操作系統(tǒng)之部分之模塊和組件相同于描繪于圖3 中者，并且因此于圖4中用相同的數(shù)字(但是并沒有(’)符號)描述，而將不作進一步之詳 細之說明。然而，值得注意的是，UMD組件220和222以及KMD組件224 (圖3)已經各被代理 器驅動程序組件取代一UMD代理器組件320、322和KMD代理器組件324。如將變得很清楚， UMD代理器組件320、322和KMD代理器組件324出現(xiàn)于操作系統(tǒng)之剩余的部分，單一組之 APIs/DDI，以及表現(xiàn)為單一圖形驅動程序。如此情況，運作時間組件204、206、208、應用程序 軟件202、和操作系統(tǒng)之剩余的部分可以請求(或呼叫)圖形API功能/目標，如圖3中所
7J\ ο也對附加的功率控制應用程序軟件201的功能加以描述。可清楚了解，功率控制 應用程序軟件201可以控制圖1之圖形子系統(tǒng)30、40之全部功率消耗狀態(tài)。功率控制應用 程序軟件201可以是獨立執(zhí)行之應用程序軟件，或者可以形成全部用戶/圖形子系統(tǒng)控制 和組構應用程序軟件一譬如觸媒控制中心應用程序軟件(可以從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為對應于圖形子系統(tǒng)30和40之硬件特定UMD組件， 該圖形子系統(tǒng)30和40像UMD組件220包含功能、目標、I0CTL、等等，該等功能、目標、IOCTL 等為硬件特定一分別至圖形子系統(tǒng)30和40。KMD組件360、362同樣相似于KMD組件224， 并且包含功能、目標、I0CTL、等等，設計于核心模式與圖形子系統(tǒng)30和40互動。舉例而言，UMD組件340、350和KMD組件360可以分別提供用戶模式DirectX驅動 程序軟件、OpenGL驅動程序軟件、和核心模式驅動程序軟件組件用于第一圖形子系統(tǒng)30 ； 同時UMD組件342、352和KMD組件362可以提供用戶模式驅動程序軟件、OpenGL驅動程序 軟件、和核心模式驅動程序軟件用于第二圖形子系統(tǒng)40。習用上，組件340、350、和360 (或 者組件342、352、362)可以是習知的，于此習知的組件中他們可以由圖3中所描繪之操作系 統(tǒng)直接加載，取代圖形UMD/KMD組件220、222、和224。于此種方式，各UMD/KMD組件340、342 ；350,352 ；360、362可以實施低階層圖形功 能，并且以特定于包含之圖形硬件之方式存取圖形硬件。習用上，UMD代理器驅動程序組件320、322和KMD代理器驅動程序組件324 —方 面表現(xiàn)一致的API/DDI于操作系統(tǒng)之剩余的部分，另一方面，路由呼叫、IOCTLs、請求、存在 目標、等等(集體API/DDI呼叫)至硬件特定UMD/KMD驅動程序組件340、350、和360，或者 342、352、和 362。于操作中，UMD代理器驅動程序組件320、322和KMD代理器驅動程序組件324由 操作系統(tǒng)之剩余的部分加載。一旦加載UMD代理器驅動程序組件320、322，則執(zhí)行其登錄例程(例如， DIIMain () /OpenAdapter ())。如將變得很清楚，UMD代理器驅動程序組件320、322之登錄例 程加載UMD組件340、342之一者或二者，并且提供至維斯塔操作系統(tǒng)之剩余的部分，期望的 數(shù)據(jù)結構確認于UMD代理器驅動程序組件320、322中支持之API/DDI呼叫與UMD組件222 和224所作非常相同的方式。再者，期望之API/DDI之地址以地址之形式藉由預期之結構 之方式提供至功能、目標、IOCTLs。UMD組件340和342由UMD代理器驅動程序組件320內之軟件碼所加載，如更詳細 說明于圖5中方塊步驟S500中。詳言之，于方塊S502，加載譬如UMD組件340或342之UMD 驅動程序組件，典型作為動態(tài)鏈接庫。其次，可以藉由UMD代理器驅動程序組件320呼叫新 加載UMD組件340或342之驅動程序初始化例程DIIMain ()/OpenAdapter ()、等等。于方 塊S504中，新加載UMD組件340或342之驅動程序初始化例程返回返回支持功能、IOCTLs 等之名稱和地址(于與UMD組件220、222返回此等名稱、地址等相同的方式)至UMD代理 器組件320。其次，于方塊S508中，UMD代理器驅動程序組件320形成表示將由負載之UMD 組件340或342所支持之目標等級、功能、IOCTLs、等等之間一致性之數(shù)據(jù)結構。舉例而言，UMD代理器驅動程序組件320被設計成支持DXVA功能呼叫和目標，并 且因此形成此種已知DXVA功能呼叫和目標與在加載之UMD組件340或342內他們的登錄 點之間之一致性。于方塊S506之結論，UMD代理器驅動程序組件320可以形成于內存中結 構，該內存中設有對應于由UMD代理器驅動程序組件320所支持之各支持之DXVA功能、目標、IOCTLs等之于UMD組件340或342中之地址?？梢越逵蒛MD代理器驅動程序組件320和322或有需要時動態(tài)地加載特定的UMD 組件340或342、350或352。尤其是，若任何圖形子系統(tǒng)30和40未使用，則其對應之UMD 驅動程序組件不需被加載。對于待由UMD代理器驅動程序組件320加載之各UMD驅動程序340或342可以實 施對應于方塊步驟S500之軟件。步驟S500由用作為用于UMD組件350和352之代理器驅 動程序組件之UMD代理器驅動程序組件322以類似方式實施。而且，亦在KMD代理器驅動程序組件324之初始化后一典型為系統(tǒng)起動時，實施 方塊步驟S500。KMD代理器驅動程序組件324執(zhí)行KMD驅動程序組件360和362 (例如， OpenAdapterO)之初始化例程。一旦已藉由各UMD代理器驅動程序組件320、322和藉由用于各支持之驅動程序組 件(例如，UMD組件340、342 ；UMD組件350、352 ；和KMD組件360、362)之KMD代理器驅動 程序組件324實施方塊步驟S500 (或者他們的相等步驟)，則UMD/KMD代理器驅動程序組 件320、322和324將已經加載特定于圖形子系統(tǒng)30、40之UMD/KMD組件，并且將已確定于 加載之UMD組件340、342、350、352，和KMD組件360、362中支持之功能、IOCTLs、等等之對 應之內存地址/登錄點。為了提供系統(tǒng)支持信息至操作系統(tǒng)之剩余的部分之目的，僅僅KMD代理器驅動程 序組件324將可直接看到和可安裝于二者子系統(tǒng)30、40?？梢院喜⒂糜诙咦酉到y(tǒng)30、40 之驅動程序特定登錄項目，因此代理器驅動程序組件可以讀取和暴露該等登錄項目至UMD 組件 340、350 ； 342、352。UMD組件340、350 ；342,352亦可以返回由UMD代理器組件320、322所聚集和調整 之許多的特質，以確保返回之特質與用來與多個圖形子系統(tǒng)互動之單一驅動程序一致。這 些特質可以由UMD代理器驅動程序組件320、322傳遞至操作系統(tǒng)。舉例而言，視頻內存蓄 積(Video memory heap)、GPU引擎特質、DMM形態(tài)、等等也許需要由UMD代理器組件320、 322結合。作為另一個替代者加載UMD/KMD組件340、342 ；350,352 ；和360、362，當這些組件 被建立時，這些組件能夠以統(tǒng)計方式鏈接至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 現(xiàn)在可以依于哪一個圖形子系統(tǒng)30或40正由應用程序軟件202或操作系統(tǒng)之剩余的部分 尋址，而路由API/DDI呼叫至UMD/KMD代理器組件320、322和324至個別的UMD/KMD組件 340或342 ；350或352 ；和360或362。此以圖形方式例示于圖6中。由UMD代理器320、322和KMD代理器324所支持之API/DDI呼叫之細節(jié)可以藉由 存在具有路由例程之細節(jié)用來支持API/DDI呼叫之數(shù)據(jù)結構而暴露于剩余的應用程序和 操作系統(tǒng)，該API/DDI呼叫由UMD組件340,342 ；350,352 ；和KMD組件360,362實際實施。API/DDI呼叫可以藉由這些路由功能(或目標)而路由在UMD/KMD代理器驅動程 序組件320、322和324內。各路由例程之地址或UMD/KMD代理器驅動程序組件320、322和324之目標與待路由之特殊的API功能/呼叫/目標/I0CTL、等等相關聯(lián)而可以暴露于操 作系統(tǒng)和其它的應用程序軟件。各路由例程或目標依次路由呼叫至UMD/KMD驅動程序組件 之其中之一，對于該驅動程序組件該代理器驅動程序組件用作為代理器。于此種方式，API/ DDI呼叫至代理器驅動程序組件320、322和324可以被路由至在UMD驅動程序340、342或 350,352或KMD組件360、362中對應之驅動程序功能/呼叫/目標/I0CTL。詳言之，如圖7中所例示，各API/DDI呼叫可以根據(jù)在UMD組件中對應之功能/呼 叫/目標/IOCTL之地址而由UMD/KMD代理器驅動程序組件320、322和324僅僅被重新路 由，對于該地址對應之登錄點于方塊步驟S700中于方塊S508中已經被決定。詳言之，于方 塊S702中，依于步驟S700之執(zhí)行，UMD/KMD代理器組件320、322或KMD代理器組件324決 定哪一個UMD/KMD組件(例如，UMD組件340、342 ；350,352 ；或KMD組件360、362)將處理 該API/DDI呼叫。此情形例如可以藉由剖析該API/DDI呼叫或者關聯(lián)之資料以確認有關的 圖形子系統(tǒng)，或者僅僅藉由決定多個圖形子系統(tǒng)之哪一個現(xiàn)在正在使用而實施。如下文之 詳細說明，現(xiàn)在正在使用之圖形子系統(tǒng)30或40可以根據(jù)裝置10而取決。現(xiàn)在正在使用之 子系統(tǒng)典型繪成待顯示和由終端用戶觀看之圖形/視訊。一旦已經確認了有關的驅動程序，則UMD/KMD代理器驅動程序組件320、322或KMD 組件324決定關于形成于方塊S706中方塊508中一致結構之API/DDI呼叫之地址。一旦 已經決定了該地址，則可以作成在有關的UMD/KMD組件340或342 ；350或352 ；360或362 內之API/DDI呼叫。然后UMD/KMD組件執(zhí)行對應于該API/DDI呼叫之碼。值得注意的是，至UMD驅動程序340、342或350、352之呼叫可以制造其它的API/ DDI呼叫。這些可以導致API/DDI呼叫至KMD代理器組件324。KMD代理器組件324，像UMD 代理器組件320、322路由DDI呼叫至適當?shù)腒MD組件360、362，如圖7中詳細說明。KMD代 理器組件324可以決定KMD組件360、362之哪一個組件，核心模式API/DDI呼叫將被路由 與UMD代理器組件320、322制造評估非常相同的方式一亦即，依于呼叫之性質或者依于現(xiàn) 時主動的圖形子系統(tǒng)。對于伴隨著資料之呼叫(例如，透過創(chuàng)造之目標、或者藉由功能參數(shù)之方式)，可 以藉由UMD代理器組件320、322或KMD代理器組件324遞送指向資料之指針至決定之UMD 組件340、342、350、352或者KMD組件360、362。若資料不能被遞送為指針，則該資料傳隧至 對應之資料節(jié)構。一些API/DDI呼叫可以不被操作系統(tǒng)之剩余的部分知道，并且根據(jù)初始化(例如， 依于執(zhí)行之DllMain ()或AdapterQpen ())情況而不返回到UMD代理器驅動程序組件320、 322或KMD代理器驅動程序組件324。此情況對于譬如KMD組件360、或362之KMD組件也 許尤其顯著，該KMD組件360、362與例如由單一制造商/供貨商提供之譬如UMD組件340、 342之互補UMD組件互動。雖然可以支持DDI呼叫，但是他們不需要暴露于操作系統(tǒng)。此 種呼叫能夠典型不由KMD代理器驅動程序組件324路由，而沒有進一步之知曉。欲避免此 情況，各KMD組件360、362將報告所有支持之API/DDI，該API/DDI例如可以包含于用于操 作系統(tǒng)排程器情況切換和尋呼請求通信之一般操作系統(tǒng)中，反應于執(zhí)行驅動程序初始化例 程。在此為不可能之情況下，KMD組件360、362可以進一步包含詢問例程以返回關于將由 KMD代理器驅動程序組件324要求之API/DDI呼叫之信息。代理器驅動程序組件亦將接收來自UMD/KMD組件之呼叫，該UMD/KMD組件對API/DDI呼叫處理以確保其能夠追蹤影響圖形子系統(tǒng)30和40之任何狀態(tài)改變。圖8顯示圖2之裝置10之部分之進一步簡化方塊圖，于此圖中可以使用圖4之軟 件200 (以及尤其UMD代理器組件320、322和KMD代理器組件324)。如所例示，接口電路 16互連接中央處理器12和系統(tǒng)內存14。圖形子系統(tǒng)30 (具體實施為在接口電路16上之 圖形處理器)包含圖形引擎32、內存控制器72、顯示器接口 74、和總線接口 78。圖形引擎32為能夠繪成2D圖形或3D圖形譯碼視頻、等等之功能的區(qū)塊。如將了 解到，圖形子系統(tǒng)30可以包含多個圖形引擎。內存控制器72允許圖形子系統(tǒng)30提供存取至圖形內存和主存儲器14。于所描繪 之實施例中，由圖形子系統(tǒng)30所使用之圖形內存形成主存儲器14之部分。然而，熟悉此項 技術者將容易了解到，圖形子系統(tǒng)30可以包含或者結合其自己的局部內存?？偩€接口 78 致能子系統(tǒng)30經由總線20通信。如將了解到，顯示器接口 74可以是用來轉變顯示于由埠78互連接之顯示裝置26 上緩沖器內資料之任何適合的接口。舉例而言，顯示器接口 74可以采用隨機存取內存、數(shù) 字至模擬轉換器(RAMDAC)之形式。一個或多個視頻連接器允許圖形子系統(tǒng)30互連接至一 個或多個顯示裝置，譬如LCD面板、監(jiān)視器、電視機、等等。輸出埠78可以是在VGA埠、混合 的視頻埠、DVI埠、LVDS埠、DVO埠、SDVO埠、等等之形式。圖形子系統(tǒng)40 (例如，形成在圖2之周邊擴充卡46上)亦藉由在高速擴充總線20 上之擴充槽之方式連接至接口電路16。圖形子系統(tǒng)40包含圖形引擎42、內存控制器52、總 線接口 58、和顯示器接口 54。圖形子系統(tǒng)40包含圖形內存50，或者與圖形內存50通信。圖形引擎42，像圖形引擎32，為能夠繪成2D圖形或3D圖形譯碼視頻、等等之功能 的區(qū)塊。如將了解到，圖形子系統(tǒng)可以包含多個圖形引擎?？赡艿那闆r是，圖形引擎42可 以提供不僅由圖形引擎32所提供之功能。內存控制器52允許圖形子系統(tǒng)40存取內存50和主存儲器14?？偩€接口 58致能 圖形子系統(tǒng)40經由總線20通信。顯示器接口 54藉由內存控制器52之方式取樣于圖形內存50中之幀緩沖器，并且 表現(xiàn)圖像于視頻連接器。于此種方式，可以顯示由外部的圖形引擎42繪成于內存50中幀 緩沖器中之圖像。視頻連接器可以直接連接至外部顯示器，或者至裝置10之主機板，此處 視頻訊號可以路由至整合的顯示器，或者用來附加外部顯示器至裝置10之連接器。再者， 顯示器接口 54可以是任合適合的接口，用來轉變在緩沖器內的資料用來顯示于顯示裝置 32上，譬如RAMDAC、單端或不同的發(fā)送器、等等。如所提及的，功率控制器60系與圖形子系統(tǒng)40通信，并且使用習知的功率消耗技 術，譬如時脈和電壓調節(jié)、降低供電、或者不然禁能所有的或一些的該等組件，來控制顯示 器接口 54、內存控制器52、圖形引擎42、總線接口 58、和圖形內存50之各個或某些和其中 的一個或多個之功率消耗。功率控制器60可以藉由于總線20上的訊號或者其它的方式控 制，并且例如可以與ACPI標準兼容。圖形子系統(tǒng)30與圖形子系統(tǒng)40以非常相似的方法操作。如此情況，圖形子系統(tǒng) 30使用內存控制器72存取保持于主存儲器14或者于圖形子系統(tǒng)30之局部之內存中之幀 緩沖器。此幀緩沖器由顯示器接口 74取樣，并且圖像表示于視頻輸出連接器，該連接器能 夠直接連接至顯示器。在致力于提供價廉之整合的組件情況，圖形子系統(tǒng)30提供有限的功
15能。舉例而言，圖形子系統(tǒng)30之分辨率、內存、圖形處理器速度、3D圖形能力、等等也許相當 地受限制，并且也許較圖形子系統(tǒng)40之外部圖形處里器42操作更慢。藉由圖形子系統(tǒng)40而更有效地實施譬如三維圖形、游戲圖形、等等之計算密集圖 形。因此在裝置10內附加圖形子系統(tǒng)40之使用允許終端用戶經驗最新的圖形密集應用程 序，譬如游戲、計算機輔助設計軟件、動畫軟件、繪成軟件(rendering software)、等等。方 便來說，可以由終端用戶選擇附加上的圖形子系統(tǒng)40，并且當需要時被取代和保持現(xiàn)用。在 過去，額外的圖形計算能力僅在工作站計算裝置可取用。于移動式計算裝置上擴充槽問世 后，現(xiàn)在此種計算能力能夠于譬如膝上型計算機之可攜式計算機之擁有者所使用。當然，使 用在圖形子系統(tǒng)40上較高(或不同)性能圖形引擎42增加裝置10之全部功率消耗。此 增加之功率消耗在由電池電源供電之計算裝置上也許不足以支撐。同時，在具有圖形引擎42之額外的圖形子系統(tǒng)40存在的情況下，則圖形子系統(tǒng)30 也許是多余的。舉例而言，若多個實體顯示器未連接至裝置10，則圖形子系統(tǒng)30也許不會 發(fā)揮作用。圖形子系統(tǒng)30因此可以被禁能?；蚩扇《?，在控制圖形子系統(tǒng)30之操作 之存在之功率控制器70中，當圖形子系統(tǒng)30未使用時，其也許亦被設置在較低功率模式。 再者，功率控制器70可以禁能或斷接部分之圖形子系統(tǒng)30，或者圖形子系統(tǒng)30之時脈或電 壓調節(jié)部分。本發(fā)明之范例實施例，軟件200 (圖4)用來允許裝置10選擇性地禁能存在于子系 統(tǒng)30中之一個較高的功率圖形子系統(tǒng)40。欲達此目的，以及如圖8中所示，計算裝置10進一步包含開關56。開關56接收由 子系統(tǒng)40和子系統(tǒng)30于第一和第二輸入所產生之視頻訊號。開關56可以是任何適當?shù)?視頻開關，譬如多功器，并且用于表示在其視頻輸出連接器之在其二個訊號輸入之習知的 視頻訊號其中之一。表示之視頻訊號于開關56之輸入可以是習知的視頻訊號，譬如數(shù)字訊 號(譬如LVDS或TMDS格式等)或者模擬訊號(譬如VGA格式)。若組構開關56以接收數(shù) 字和模擬輸入訊號，或者提供視頻于任一的輸出，則開關56可以包含格式轉變器。而且，開 關56可以包含一個或多個視頻輸出，使可以連接數(shù)字和模擬顯示裝置32其中任一者或者 ■~ 者 ο開關56進一步包含控制輸入(CNTRL)。此控制輸入控制哪一個訊號輸入被提供于 開關56之視頻輸出。于所描繪之實施例中，控制輸入由處理器12反應于所要求或希望之 裝置10之功率模式中偵測或決定改變，藉由一般目的輸入輸出(general purpose input output, GPIO)接口(未顯示)之方式切換。如將變得很清楚的，若裝置10正操作于較低 功率消耗模式，則開關56組構成使得選擇由圖形子系統(tǒng)30所產生的習知的視頻訊號。反 之，若裝置10正操作于較高功率消耗模式，則選擇由較高性能外部圖形子系統(tǒng)40所產生的 視頻訊號用于顯示。同樣情況，可以減少或禁能提供至圖形子系統(tǒng)40或圖形子系統(tǒng)30之 功率。切換可以動態(tài)地實現(xiàn)，同時計算裝置10是在使用中，而不需要裝置10重新起動(亦 即，冷或熱起動)。欲完成此目的，計算裝置10亦可以包含至少一個上述之功率控制器60。于此描述 之實施例中，功率控制器60形成裝載圖形子系統(tǒng)40之周邊擴充卡46之部分。然而，功率 控制器60僅亦能夠形成計算裝置10之主機板之部分，或者作為接口 16之部分。若功率控 制器60形成擴充卡46之部分，則其可以具有較大的彈性控制子系統(tǒng)40之操作。若功率控制器60形成計算裝置10之部分，則其可以僅具有禁能供電至圖形子系統(tǒng)40之能力。為了組構和控制開關56和功率控制器60，使用在系統(tǒng)內存12內之軟件200。圖9 因此為流程圖，例示本發(fā)明之范例實施例中范例軟件方塊步驟S900用來切換裝置10于二 個有效的功率消耗模式之間?，F(xiàn)在，本發(fā)明之范例實施例，當裝置10被起始供電時，評估裝置10之功率狀態(tài)。當 需要時，功率控制應用程序軟件201組構圖形子系統(tǒng)30和40和開關56，以及如下之詳細說明?？梢越逵商幚砥?2于系統(tǒng)內存10內功率控制應用程序軟件201之控制下實施本 發(fā)明之范例實施例軟件方塊步驟S900。每次裝置10經歷狀態(tài)改變可以實施方塊步驟S900， 對于此改變將因此配置圖形子系統(tǒng)30和40。如所例示，于方塊S902中功率控制應用程序 軟件201決定是否裝置10將假定其較高功率消耗模式，或其較低功率消耗模式。應用程序軟件201 (圖4)可以維持指示圖形子系統(tǒng)30、40之哪一個系用于特定圖 形功率狀態(tài)之較佳裝置之表。各用戶功率狀態(tài)映對至圖形子系統(tǒng)30、40，并且對應用于該子 系統(tǒng)之狀態(tài)。用于個別圖形子系統(tǒng)30、40之功率狀態(tài)可以操作現(xiàn)時主動圖形子系統(tǒng)30或 40之參數(shù)，譬如時脈速度、內存速度、像素時脈速度、繪成能力、等等。于范例實施例中，當裝置10正由AC電源36操作時，可以使用較高功率消耗模式； 當裝置10由DC電源供應器38之方式操作，而當DC電源38為低、或等等時，可以使用較低 功率消耗模式。于較高功率消耗模式，圖形子系統(tǒng)40為主動的。于較低功率消耗模式，圖 形子系統(tǒng)30為主動的。若裝置10再開始(或者轉變至)其高功率消耗模式，則執(zhí)行方塊S904至S910。 于方塊S904若子系統(tǒng)40尚未設置于其全操作(高功率消耗)模式，則將其設置在此模 式。此可以藉由適當?shù)尿寗映绦蚝艚袑嵤┮?對于AMD或ATI圖形子系統(tǒng)可以使用習 知的ATPX ACPI方法，可以使用相似的方法或功能于驅動程序用于來自其它制造商之 圖形子系統(tǒng))，藉由處理器12提供適當?shù)挠嵦栔凉β士刂破?0。其次，于方塊S906致 能子系統(tǒng)40。此可以藉由使用于組構管理器(Configuration manager)中窗口 PnP呼 叫(Windows PnP call)致能子系統(tǒng)40實施。一旦子系統(tǒng)被致能，則操作系統(tǒng)可以列舉 所有的裝置以獲得新的裝置名稱。為了此目的可以使用窗口列舉顯示裝置OAPI功能 (Windows EnumDisplayDevicesOAPI function)。其后，可以使用窗口 改變顯示設定 EX () API呼叫(Windows ChangeDisplaySettingOAPI call)創(chuàng)造具有二種裝置之擴充的桌上 型計算機。應用程序軟件201現(xiàn)在可以感知適配器之數(shù)目已經改變(例如，藉由接收WM_ DISPLAYM0DECHANGE訊息)。應用程序軟件201可以發(fā)出重新起動命令?？梢允褂脤τ贏TI/ AMD圖形子系統(tǒng)用于驅動程序功能之CWDDEDI、或者使用來自其它制造商對于圖形子系統(tǒng) 用于驅動程序之相似的功能、以及禁能整合之I2C控制器、使用控制方法呼叫之禁能I2C緩 沖器，所有這些于方塊S906中關斷顯示器電源。于方塊S908中可以組構開關56以選擇從 圖形子系統(tǒng)40之輸出，例如使用ATPX ACPI方法用于ATI/AMD圖形子系統(tǒng)，或者使用來自 其它制造商之對于圖形子系統(tǒng)用于驅動程序之相似的功能。于方塊S910中，可以邏輯方式 致能新致能之圖形子系統(tǒng)40，而使得對于操作系統(tǒng)之剩余的部分為可觀察的。此可以使用 Windows ChangeDisplaySettingEXOAPI呼叫完成。而且，可以藉由從顯示之桌上型計算機 卸下子系統(tǒng)而邏輯上禁能圖形子系統(tǒng)30。此可以使用Windows ChangeDisplaySettingEXQ
17API呼叫完成。當由操作系統(tǒng)詢問時，可以作成另外隱私的API (避開)呼叫至驅動程序以 隱藏整合的顯示，由此隱藏該禁能之圖形子系統(tǒng)。如所提及的，于Vista下，僅僅一個圖形KMD能夠是主動的。欲支持通常由二個不 同的裝置驅動程序控制之二個圖形子系統(tǒng)30、40，KMD代理器驅動程序組件324用作為用于 二個圖形子系統(tǒng)30、40之核心模式驅動程序。同樣情況，UMD代理器驅動程序組件320、322 用作為單一 UMD。當裝置10轉變至，或者重回至其低功率消耗模式時，執(zhí)行方塊S912至S918。廣 言之，圖形子系統(tǒng)40被禁能和設置在其低功率消耗模式，同時致能圖形子系統(tǒng)40。欲達 成此情況，于方塊S912和S914中致能圖形子系統(tǒng)30。再者，可以藉由在方塊S912邏輯 致能關聯(lián)于圖形子系統(tǒng)30之顯示，和于方塊S914邏輯禁能有關子系統(tǒng)40之顯示，而實 施此情況?？梢越逵蛇m當?shù)牟僮飨到y(tǒng)API呼叫，譬如上述之EnumDisplayDevicesO和 ChangeDisplaySettingEXO呼叫，或者直接與硬件通信，而實施方塊S912和S914。于方塊S918中，于該顯示被邏輯禁能后，可以使用API呼叫至KMD組件360、362以 實際設置圖形子系統(tǒng)40于其低功率模式。如此情況，處理器12提供適當?shù)挠嵦栔凉β士?制器60設置圖形子系統(tǒng)40于其低功率狀態(tài)。于其最簡單之形式，功率控制器60斷接電源 至圖形子系統(tǒng)40或圖形子系統(tǒng)40之組件。或可取而代之，功率控制應用程序軟件201可 以指令功率控制器60設置圖形子系統(tǒng)40進入低功率休眠模式，譬如由ACPI規(guī)格所定義之 裝置功率狀態(tài)之其中之一。無論如何，于此種較低功率消耗模式，調節(jié)電壓，和/或降低供 電至所有的或部分的圖形子系統(tǒng)40和/或減慢由圖形子系統(tǒng)40使用之選擇的時脈。一旦圖形子系統(tǒng)30、40之特定的其中一個被邏輯上和實體上致能后，UMD代理器 組件320、322和KMD代理器組件324被提供為現(xiàn)時主動子系統(tǒng)之指示，以及用于圖形子系 統(tǒng)之API/DDI呼叫如適當?shù)谋宦酚芍罸MD/KMD組件340、350、360或342、352、362，對應于現(xiàn) 時致能之圖形子系統(tǒng)30、40，如上述說明。欲確保適當?shù)卦O定開關56，用于裝置10之BIOS能夠允許用戶選擇哪一個裝置在 起動時將是主動的。有利的情況是，如所述之組構開關56和圖形子系統(tǒng)40和圖形子系統(tǒng)30，減少功率 消耗并且引致裝置10要求二個圖形處理器之僅其中一個消耗功率，由此減少總能源消耗 并且保護電池壽命。舉例而言，可攜式計算機典型由商務旅行者使用于電池操作模式(DC 電源)。此種用戶當旅行時之典型使用樣式將包含文字處理、表示，和電子郵件應用程序軟 件。這些應用程序軟件不需要由外部圖形子系統(tǒng)40提供之重任務圖形加速(heavy duty graphics acceleration)。從使用之第二(例如，外部)圖形子系統(tǒng)40轉變至使用之第一 (例如，整合之)圖形子系統(tǒng)30，具有較低之平均功率消耗，幫助高性能圖形處理與較低功 率消耗之間之平衡而沒有犧牲總系統(tǒng)性能。圖10為本發(fā)明之另一個范例實施例，計算裝置10’之部分之范例簡化方塊圖。計 算裝置10’實質上相似于計算裝置10。功能上相等于裝置10之組件之裝置10’之組件系 標以“’”符號，而因此將不再作詳細之說明。然而，簡言之，裝置10’包含二個圖形子系統(tǒng) 30’、40’。而且，圖形子系統(tǒng)30’包含圖形引擎32’、內存控制器72’、顯示器接口 74’、和總 線接口 78’。第二圖形子系統(tǒng)40’藉由高速總線20’之方式與圖形子系統(tǒng)30’通信。圖形 子系統(tǒng)40，包含其自己的圖形引擎42，、內存控制器52，、顯示器接口 54，。圖形子系統(tǒng)40，
18進一步與圖形內存50’通信。值得注意的是，裝置10’不包含用來控制哪一個圖形子系統(tǒng) 30’和圖形子系統(tǒng)40’與顯示器26’互相連接之開關。取而代之，以及將變得很清楚的，圖 形子系統(tǒng)40’被調適繪成圖形橫越總線20’至內存14’中。裝置10’之軟件控制操作機構相似于裝置10之軟件控制操作機構。然而，裝置10’ 之軟件控制操作之部分當裝置10’轉換于高和低功率消耗狀態(tài)之間時不同于裝置10者。特別地，圖11描繪本發(fā)明之范例實施例之軟件方塊步驟S1100，該實施例可以在 裝置10’之系統(tǒng)內存內軟件之控制下由處理器12’實施。再者，每次裝置10’經歷狀態(tài)改 變可以實施方塊步驟S1100，對于此改變將因此配置圖形子系統(tǒng)30和40。如所例示，于方 塊S1102中軟件201決定是否裝置10’將假定其較高功率消耗模式，或其較低功率消耗模 式。當裝置10’再開始(或者轉變至)其高功率消耗模式時，則執(zhí)行方塊S1104至 Sllioo于方塊1104若子系統(tǒng)40’尚未設置于其全操作(高功率消耗)模式，則將其設置 在此模式。此可以藉由提供適當?shù)挠嵦柾高^驅動程序控制圖形子系統(tǒng)40’至功率控制器 60’而實施。其次，于方塊S1106和S1108致能圖形子系統(tǒng)40’。再者，此可以藉由于方塊 S1104中以邏輯方式禁能任何與圖形子系統(tǒng)30’相關聯(lián)之互連接之顯示，并且于方塊S808 中以邏輯方式致能與圖形子系統(tǒng)40’連接之顯示而實施?？梢越逵蛇m當?shù)牟僮飨到y(tǒng)API呼 叫，譬如上述之EnumDisplayDevices ()和ChangeDisplaySetting ()呼叫，或者透過與硬件 直接通信，再實施方塊S1106和S1108。值得注意的是，沒有實際的顯示器連接到圖形子系統(tǒng)40’。于方塊S1110，在缺乏 開關56(圖4之裝置10)之情況下，組構圖形子系統(tǒng)40’之驅動程序軟件控制操作繪成圖 像于圖形子系統(tǒng)30’之緩沖器14’中，而不在關聯(lián)之內存50’內。方便地于存在高速總線 20之情況(例如，具體實施為PCLe總線)，由于部分轉移速度由總線致能，此種繪成可能橫 越總線20。而且，進一步組構用于圖形子系統(tǒng)30’之驅動程序以導致圖形子系統(tǒng)30’之顯示 器接口 74’取樣于內存14’中之幀緩沖器，以便將由圖形子系統(tǒng)40’繪成于內存14’中幀 緩沖器中之圖像表現(xiàn)于互連接顯示器26’中。同時，用于圖形子系統(tǒng)30’之驅動程序可以 指導圖形子系統(tǒng)30’之圖形引擎32’保持實質地靜止或閑置。此種操作模式被示意地描繪 于圖12A中，僅僅將圖形子系統(tǒng)40’和圖形子系統(tǒng)30’之主動區(qū)塊用網目線作成陰影。很顯然的，于圖12A之實施例中，未使用內存50’和顯示器接口 54’。如此情況，能 夠從圖形子系統(tǒng)40’去除這些功能區(qū)塊以便降低成本。當能夠制造子系統(tǒng)40’以補償由子 系統(tǒng)30’所提供之功能時，制造這種圖形子系統(tǒng)也許是很有益處的。舉例而言，子系統(tǒng)能夠 設有圖形引擎42’，該圖形引擎42’提供3D圖形或視頻譯碼能力。圖形引擎32’可以不包 含這些能力。同時，由圖形引擎32’提供之2D圖形能力不需包含于子系統(tǒng)40中。消費者， 僅當需要額外的功能時，能夠依次加上圖形子系統(tǒng)30’。當裝置10’欲轉變至或者重回至其低功率消耗模式時，執(zhí)行方塊S1112至S1118。 廣言之，圖形子系統(tǒng)40’被部分或完全地禁能和設置在其低功率消耗模式，并且由圖形子系 統(tǒng)30’再實施繪成。欲達成此情況，于方塊S812中可以致能互連接關聯(lián)于圖形子系統(tǒng)30’ 之任何顯示，以及于方塊Sl 114可以邏輯上禁能與圖形子系統(tǒng)40，實際連接之任何顯示。其 次，再度組構圖形子系統(tǒng)30’之驅動程序軟件控制操作以導致圖形子系統(tǒng)30’繪成圖像于內存14’中。顯示器接口 74’繼續(xù)取樣內存14’以表現(xiàn)圖像于與端口 78’相互連接之顯示 器26，上。而且，處理器12，首先提供適當?shù)挠嵦栔练綁KS818中之功率控制器60’，設置 圖形子系統(tǒng)40’于低功率狀態(tài)。于其最簡單之形式，功率控制器60’斷接電源至圖形子系 統(tǒng)40’或者設置圖形子系統(tǒng)40’成較低功率修眠模式。再者，于此較低功率修眠模式，調節(jié) 電壓，和/或所有的或部分的圖形子系統(tǒng)40’被降低供電和/或減慢由圖形子系統(tǒng)40’所 使用之選擇的時脈。詳言之，圖形子系統(tǒng)之圖形引擎42’保持閑置或實質上閑置(例如，其 可以減慢、禁能或降低供電)。此種操作模式被示意地描繪于圖12B中，僅僅將圖形子系統(tǒng) 40’和圖形子系統(tǒng)30’之主動功能區(qū)塊用網目線作成陰影。非主動/閑置功能區(qū)塊可以被 整個禁能，或者操作于減少之電壓或時脈速度。可視需要選擇使用，當圖形引擎32’未使用時，可以禁能圖形子系統(tǒng)30’之部分。 此能夠藉由設置圖形引擎32’和其它的組件于一個或多個電壓島而促成，該電壓島可以藉 由GPIO或任何時間圖形子系統(tǒng)40’負責繪成圖像之相似電路之方法而被禁能。其它的變化亦將是明顯的。舉例而言，于描繪于圖12A中之高功率模式中，圖形子 系統(tǒng)30’和圖形子系統(tǒng)40’能夠繪成于內存14’或內存50’中。于此種方式，二個圖形子 系統(tǒng)30’和40’可以一致操作，各繪成替代的幀于內存14’中或者繪成各幀之部分于內存 14，中、。又于其它的實施例中，額外的顯示器可以連接至圖形子系統(tǒng)30’和40’，允許共同 使用多個顯示器于高功率消耗模式。于此種方式，能夠使用顯示器接口 54以驅動第二顯示 器。依于轉變至較低功率消耗模式，能夠組構裝置10’以如圖9B中描繪方式操作。同樣情況，裝置10’ (或10)能夠包含多個連接至總線20’ (或20)之額外的圖形 子系統(tǒng)，所有的該等圖形子系統(tǒng)在高功率消耗模式能夠是主動的，并且透過圖形子系統(tǒng)30’ 之顯示器接口 74’繪成圖形。依于轉變至較低功率消耗模式，能夠禁能這些圖形子系統(tǒng)，并 且繪成之圖像能夠留在圖形子系統(tǒng)30’之圖形引擎32，中。又于圖13中之另一個實施例中，計算裝置10可底包含直接內存存取(DMA)控制 器90。DMA控制器90可以將資料從內存50’轉移至內存14’。于此種方式，于裝置10’之 較高功率修眠模式，圖形子系統(tǒng)40’能夠繪成圖像至內存50’。然后這些繪成之圖像能夠由 DMA控制器90轉移至內存14’中之幀緩沖器。DMA控制器90能夠形成部分之圖形子系統(tǒng) 30’或40’(例如作為圖形引擎32’或42’之DMA引擎)，或者不然位在計算裝置10’中。 資料可以橫越總線20’轉移，或者不然從內存50’直接至內存14’。顯示器接口 74’將繼續(xù) 操作如上所揭示，取樣于內存14’中之幀緩沖器表現(xiàn)繪成之圖像于顯示器26’上。再者，圖 13之裝置10’之主動區(qū)塊，于其高功率消耗模式于圖13中以網目陰影線例示。當然，上述之實施例僅欲作例示用而不能用作限制。實現(xiàn)本發(fā)明之說明之實施例 可接受許多形式、部件和細部之配置、和操作次序之修飾。本發(fā)明確切地說將包括在其范圍 內之所有的此種修飾，如由權利要求書所界定者。
權利要求
一種電子裝置，包括第一圖形子系統(tǒng)，用于繪成圖形；第二圖形子系統(tǒng)，用于繪成圖形；至少一個顯示器，與該第一圖形子系統(tǒng)和該第二圖形子系統(tǒng)的至少其中一個通信；處理器，執(zhí)行應用程序軟件和驅動程序軟件，該驅動程序軟件包括第一和第二驅動程序組件和代理器驅動程序組件，該第一和第二驅動程序組件用來分別控制該第一和該第二圖形子系統(tǒng)的操作，而該代理器驅動程序組件用來依據(jù)該第一和第二圖形子系統(tǒng)的哪一個是在使用中而路由呼叫從該應用程序軟件至該第一和第二驅動程序組件的其中一個。
2.如權利要求1所述的電子裝置，其中，該處理器執(zhí)行指令，使得該處理器將該電子 裝置從其中該第二圖形子系統(tǒng)繪成圖形于該顯示器上的第一模式轉變至其中該第一圖形 子系統(tǒng)繪成圖形于該顯示器上的第二模式，以及該第二圖形子系統(tǒng)是處在較低功率消耗模 式。
3.如權利要求1所述的電子裝置，其中，該第一和第二驅動程序組件包括執(zhí)行于該處 理器的用戶模式的驅動程序組件。
4.如權利要求1所述的電子裝置，其中，該第一和第二驅動程序組件包括執(zhí)行于該處 理器的核心模式的驅動程序組件。
5.如權利要求1所述的電子裝置，其中，該第一和第二圖形子系統(tǒng)的哪一個是在使用 中是根據(jù)該電子裝置的功率狀態(tài)而定。
6.如權利要求1所述的電子裝置，其中，該代理器驅動程序組件路由呼叫從在該裝置 的操作系統(tǒng)至該第一和第二驅動程序組件的其中一個，是根據(jù)該第一和第二圖形子系統(tǒng)的 哪一個是在使用中而定。
7.如權利要求1所述的電子裝置，其中，該代理器驅動程序組件建立一致結構確認于 該第一和第二驅動程序組件中相等的驅動程序功能用來實施該路由。
8.一種電子裝置，包括第一圖形子系統(tǒng)，用于繪成圖形； 第二圖形子系統(tǒng)，用于繪成圖形；顯示器，與該第一圖形子系統(tǒng)和該第二圖形子系統(tǒng)二者通信； 處理器，執(zhí)行應用程序軟件和驅動程序軟件，該驅動程序軟件包括 第一和第二用戶模式驅動程序組件，用來分別控制該第一和第二圖形子系統(tǒng)的操作， 和用戶模式代理器驅動程序組件，用來根據(jù)該第一和第二圖形子系統(tǒng)的哪一個是在使用中 而路由呼叫從該應用程序軟件至該第一和第二用戶模式驅動程序組件的其中一個；第一和第二核心模式驅動程序組件，用來分別控制該第一和第二圖形子系統(tǒng)的操作， 以及核心模式代理器驅動程序組件，用來根據(jù)該第一和第二圖形子系統(tǒng)的哪一個是在使用 中而路由呼叫從該用戶模式驅動程序組件的其中一個至該第一和第二核心模式驅動程序 組件的其中一個。
9.一種用來執(zhí)行于計算機裝置上的計算機可讀取媒體存儲驅動程序軟件包括，該計算 裝置包括第一圖形子系統(tǒng)，用于繪成圖形； 第二圖形子系統(tǒng)，用于繪成圖形；顯示器，與該第一圖形子系統(tǒng)和該第二圖形子系統(tǒng)二者通信；以及處理器；該驅動程序軟件包括代理器驅動程序組件，其用來根據(jù)該第一和第二圖形子系統(tǒng)的哪 一個是在使用中而路由呼叫從該應用程序軟件至第一和第二驅動程序組件的其中一個，該 第一和第二驅動程序組件用來分別控制該第一和第二圖形子系統(tǒng)的操作。
10.如權利要求9所述的計算機可讀取媒體，其中，該代理器驅動程序組件建立一致結 構確認于該第一和第二驅動程序組件中相等的驅動程序功能用來實施該路由。
11.如權利要求10所述的計算機可讀取媒體，其中，該代理器驅動程序組件根據(jù)該第 一和第二圖形子系統(tǒng)的哪一個是在使用中而路由呼叫從在該裝置的操作系統(tǒng)至該第一和 第二驅動程序組件的其中一個。
12.如權利要求9所述的計算機可讀取媒體，其中，該第一和第二驅動程序組件包括執(zhí) 行于該處理器的用戶模式的驅動程序組件。
13.如權利要求9所述的計算機可讀取媒體，其中，該第一和第二驅動程序組件包括執(zhí) 行于該處理器的核心模式的驅動程序組件。
14.一種操作電子裝置的方法，該電子裝置包括用于繪成圖形的第一和第二圖形子系 統(tǒng)，該方法包括下列步驟接收來自軟件應用程序的驅動程序呼叫或執(zhí)行于該電子裝置的操作系統(tǒng)；根據(jù)該第一和第二圖形子系統(tǒng)的哪一個是在使用中而路由來自軟件應用程序的驅動 程序呼叫至用來分別控制該第一和第二圖形子系統(tǒng)的操作的第一和第二軟件驅動程序組 件的其中一個。
15.如權利要求14所述的方法，進一步包括建立一致結構確認于該第一和第二驅動程序組件中相等的驅動程序功能用來實施該 路由。
全文摘要
現(xiàn)今許多的計算裝置也許包含二個或更多個圖形子系統(tǒng)。多重圖形子系統(tǒng)可以具有不同的能力，并且可以例如消耗不同數(shù)量的電力，因為一個子系統(tǒng)較其它的子系統(tǒng)消耗更多的平均功率。較高的功率消耗圖形子系統(tǒng)可以耦接到裝置，并且此外可以用來取代較低的功率消耗圖形子系統(tǒng)，導致較高的性能或額外的能力，但是增加總功率消耗。藉由從使用之較高的功率消耗圖形子系統(tǒng)轉變至較低的功率消耗圖形子系統(tǒng)，同時設置該較高的功率消耗圖形子系統(tǒng)于較低的功率消耗模式，則減少總功率消耗。處理器執(zhí)行應用程序軟件和驅動程序軟件。驅動程序軟件包含第一和第二驅動程序組件用來分別控制該第一和第二圖形子系統(tǒng)之操作。其它代理器驅動程序組件根據(jù)該第一和第二圖形子系統(tǒng)之哪一個是在使用中而路由呼叫(例如，API/DDI呼叫)至該第一和第二驅動程序組件其中之一。
文檔編號G06F9/445GK101978352SQ200880126821
公開日2011年2月16日 申請日期2008年12月15日 優(yōu)先權日2007年12月13日
發(fā)明者P·布林則 申請人:先進微裝置公司