KR101565562B1 - 다수의 그래픽 서브시스템 및 감소된 전력 소비 모드들을 구비한 연산 장치를 위한 드라이버 아키텍쳐, 소프트웨어 및 방법 - Google Patents

다수의 그래픽 서브시스템 및 감소된 전력 소비 모드들을 구비한 연산 장치를 위한 드라이버 아키텍쳐, 소프트웨어 및 방법 Download PDF

Info

Publication number
KR101565562B1
KR101565562B1 KR1020107015543A KR20107015543A KR101565562B1 KR 101565562 B1 KR101565562 B1 KR 101565562B1 KR 1020107015543 A KR1020107015543 A KR 1020107015543A KR 20107015543 A KR20107015543 A KR 20107015543A KR 101565562 B1 KR101565562 B1 KR 101565562B1
Authority
KR
South Korea
Prior art keywords
graphics
driver
components
software
subsystem
Prior art date
Application number
KR1020107015543A
Other languages
English (en)
Other versions
KR20100110824A (ko
Inventor
폴 블린저
Original Assignee
어드밴스드 마이크로 디바이시즈, 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 어드밴스드 마이크로 디바이시즈, 인코포레이티드 filed Critical 어드밴스드 마이크로 디바이시즈, 인코포레이티드
Publication of KR20100110824A publication Critical patent/KR20100110824A/ko
Application granted granted Critical
Publication of KR101565562B1 publication Critical patent/KR101565562B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/325—Power saving in peripheral device
    • G06F1/3265—Power saving in display device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/3293—Power saving characterised by the action undertaken by switching to a less power-consuming processor, e.g. sub-CPU
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/36—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators characterised by the display of a graphic pattern, e.g. using an all-points-addressable [APA] memory
    • G09G5/363—Graphics controllers
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2330/00—Aspects of power supply; Aspects of display protection and defect management
    • G09G2330/02—Details of power systems and of start or stop of display operation
    • G09G2330/021—Power management, e.g. power saving
    • G09G2330/022—Power management, e.g. power saving in absence of operation, e.g. no data being entered during a predetermined time
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2340/00—Aspects of display data processing
    • G09G2340/04—Changes in size, position or resolution of an image
    • G09G2340/0407—Resolution change, inclusive of the use of different resolutions for different screen areas
    • G09G2340/0435—Change or adaptation of the frame rate of the video stream
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2360/00—Aspects of the architecture of display systems
    • G09G2360/06—Use of more than one graphics processor to process data before displaying to one or more screens
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2370/00—Aspects of data communication
    • G09G2370/04—Exchange of auxiliary data, i.e. other than image data, between monitor and graphics controller
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/12—Synchronisation between the display unit and other units, e.g. other display units, video-disc players
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

많은 연산 장치는 2개 이상의 그래픽 서브시스템을 포함할 수 있다. 다수의 그래픽 서브시스템들은 서로 다른 기능을 가질 수 있으며, 그리고 예를 들어 상이한 전력량을 소비할 수 있는데, 어느 하나의 서브시스템이 다른 것들에 비하여 더 많은 평균 전력을 소비한다. 저전력을 소비하는 그래픽 서브시스템을 대신하여 또는 그에 부가하여, 고전력을 소비하는 그래픽 서브시스템이 연산 장치에 결합되어 사용됨으로써, 더 높은 성능 또는 부가적인 기능들을 얻을 수 있지만, 전체적인 전력 소비가 증가하게 된다. 고전력을 소비하는 그래픽 서브시스템을 저전력 소비 모드에 두면서, 고전력을 소비하는 그래픽 서브시스템의 사용으로부터 저전력을 소비하는 그래픽 서브시스템으로 전환함으로써, 전체적인 전력 소비가 감소된다. 프로세서는 애플리케이션 소프트웨어 및 드라이버 소프트웨어를 실행한다. 드라이버 소프트웨어는 제1, 2 그래픽 서브시스템의 동작을 각각 제어하기 위한 제1, 2 드라이버 컴포넌트를 포함한다. 추가적인 프록시 드라이버 컴포넌트는, 제1, 2 그래픽 서브시스템 중에서 어느 것이 사용 중인지에 따라, 호출들(예를 들어, API/DDI 호출들)을 제1, 2 드라이버 컴포넌트 중 하나로 라우팅한다.

Description

다수의 그래픽 서브시스템 및 감소된 전력 소비 모드들을 구비한 연산 장치를 위한 드라이버 아키텍쳐, 소프트웨어 및 방법{DRIVER ARCHITECTURE FOR COMPUTING DEVICE HAVING MULTIPLE GRAPHICS SUBSYSTEMS, REDUCED POWER CONSUMPTION MODES, SOFTWARE AND METHODS}
관련 출원들에 대한 상호 참조
본 출원은, 그 명칭이 "다수의 그래픽 서브시스템 및 감소된 전력 소비 모드를 구비한 연산 장치를 위한 드라이버 아키텍쳐, 소프트웨어 및 방법"이며 2007년 12월 13일 발명자들 필 뭄마흐(Phil Mummah) 및 폴 블린저(Paul Blinzer)에 의해 출원된 미국 가 출원 제61/013,527호에 대한 우선권을 주장하는 바, 이는 본 양수인에 의해 소유되며 그 전체 내용은 본원의 참조로서 통합된다. 본 출원은 또한 2006년 5월 30일 출원된 미국 특허 출원 제11/421,005호 및 2007년 5월 30일 출원된 미국 특허 출원 제11/755,625호와 관련되며, 이들 역시 본원의 참조로서 통합된다.
본 발명은 일반적으로 컴퓨팅 장치에 관한 것으로서, 특히 다수의 그래픽 서브시스템을 구비한 장치들 및 연관된 소프트웨어 드라이버들에 관한 것이다. 또한, 일 양상에 있어서, 본 발명은 이러한 장치들에서의 전력 소비를 낮추는 방법들에 관한 것이다.
종래의 연산 장치(computing device)들과 같은 많은 전자 장치들은 2차원 및 3차원 그래픽의 렌더링, 동영상의 디코딩 및 인코딩 등이 가능한 그래픽 서브시스템을 포함한다. 이러한 기능들 및 원하는 처리 속도를 제공하기 위해, 최근의 그래픽 서브시스템들이 포함하는 트랜지스터의 수는 계속하여 증가하고 있다. 당연하게도, 트랜지스터의 개수의 증가로 인해, 그래픽 서브시스템들에 의한 전력 소비 역시 그에 대응하게 증가하게 되었다.
결과적으로, 증가된 전력 요구를 만족시킬 수 있는 장치들에 대해서는 대부분 가장 빠르고 가장 다양한 기능을 제공하는 그래픽 서브시스템들이 이용되고 있다. 랩탑, PDA, 비디오 및 오디오 재생기, 휴대전화 등과 같은 휴대형 연산 장치들은 종종 기능적으로는 제한되지만, 전기적으로는 효율적(즉, 저전력)인 컴포넌트들을 탑재해 왔다.
대체로 이러한 그래픽 서브시스템들은, 프로세서 상호 연결 회로들(processor interconnect circuits)(보통 "칩셋(chipset)"이라 부름)과 같은 다른 연산 컴포넌트들 내에 통합된다.
최근, 고정형 컴퓨터의 그래픽 기능들 및 성능에 필적하는 그래픽 기능 및 성능을 휴대용 장치들에 제공하고자 하는 경향이 있다. 종종, 이는 휴대용 장치들에 대해 선택적(optional)인 외장형의 고전력 그래픽 서브시스템을 부가할 수 있도록 함으로써 이루어진다. 예를 들어, PCI 익스프레스(PCI Express; 이하 PCIe라 함) 표준은, 그래픽 서브시스템을 포함하는 PCI 익스프레스에 따른 그래픽 카드들을 랩탑 연산 장치들에 외장형 컴포넌트들로서 서로 결합시키는 것을 고려하고 있다.
다수의 그래픽 서브시스템들이 존재하는 경우에는 종종, 상기 연산 장치를 재시작(예를 들어, 리부팅)하지 않으면서 하나 또는 나머지의 그래픽 서브시스템을 사용할 수 있도록 상기 연산 장치의 동작 상태를 스위칭해야 하는 요구사항이 존재한다.
유감스럽게도, 일부 운영 체제들의 소프트웨어 아키텍쳐(software architecture)는 단일의 그래픽 드라이버의 사용 만을 고려한다. 이에 따라, 다수의 그래픽 서브시스템이 존재하는 경우, 이러한 단일 드라이버가 다수의 서브시스템들 전부의 동작을 제어할 필요가 있다. 이는 비현실적이며, 상기 서브시스템들이 서로 다른 제조자들에 의해 제공되는 경우에 특히 그러하다.
따라서, 다수의 그래픽 드라이버들의 사용을 허용하는 소프트웨어 및 장치들이 필요하다.
많은 연산 장치는 2개 이상의 그래픽 서브시스템을 포함할 수 있다. 다수의 그래픽 서브시스템들은 서로 다른 기능을 가질 수 있으며, 그리고 예를 들어 상이한 전력량을 소비할 수 있는데, 어느 하나의 서브시스템이 다른 것들에 비하여 더 많은 평균 전력을 소비한다. 저전력을 소비하는 그래픽 서브시스템을 대신하여 또는 그에 부가하여, 고전력을 소비하는 그래픽 서브시스템이 연산 장치에 결합되어 사용됨으로써, 더 높은 성능 또는 부가적인 기능들을 얻을 수 있지만, 전체적인 전력 소비가 증가하게 된다. 고전력을 소비하는 그래픽 서브시스템을 저전력 소비 모드에 두면서, 고전력을 소비하는 그래픽 서브시스템의 사용으로부터 저전력을 소비하는 그래픽 서브시스템으로 전환함으로써, 전체적인 전력 소비가 감소된다.
프로세서는 애플리케이션 소프트웨어 및 드라이버 소프트웨어를 실행한다. 상기 드라이버 소프트웨어는 제1 및 제2 그래픽 서브시스템들의 동작을 각각 제어하기 위한 제1 및 제2 드라이버 컴포넌트를 포함한다. 추가적인 프록시 드라이버 컴포넌트(proxy driver component)는, 상기 제1 및 제2 그래픽 시스템 중에서 어느 것이 사용 중인지에 따라, 상기 애플리케이션 소프트웨어로부터의 호출들(예를 들어, API/DDI 호출들)을 상기 제1 드라이버 컴포넌트 및 상기 제2 드라이버 컴포넌트 중 하나로 라우팅(routing)시킨다.
편리하게는, 이러한 프록시 드라이버 컴포넌트는 두 개의 분리된 드라이버 컴포넌트들을 이용할 수 있게 하면서, 운영 체제 및 애플리케이션들에 대한 단일 인터페이스를 제공한다. 상기 프록시 드라이버 컴포넌트는 윈도즈 비스타 사용자 모드 드라이버(user mode driver; 이하 UMD라 칭함) 컴포넌트 및/또는 커널 모드 드라이버(kernel mode driver; 이하 KMD라 칭함) 컴포넌트일 수 있다.
본 발명의 일 양상에 따르면, 전자 장치가 제공된다. 이 전자 장치는 그래픽을 렌더링하도록 동작가능한 제1 그래픽 서브시스템; 그래픽을 렌더링하도록 동작가능한 제2 그래픽 서브시스템; 상기 제1 그래픽 서브시스템 및 상기 제2 그래픽 서브시스템 중 적어도 하나와 통신하는 적어도 하나의 디스플레이; 및 애플리케이션 소프트웨어 및 드라이버 소프트웨어를 실행하는 프로세서를 포함하며, 여기서 상기 드라이버 소프트웨어는 상기 제1 및 제2 그래픽 서브시스템의 동작을 각각 제어하기 위한 제1 드라이버 컴포넌트, 제2 드라이버 컴포넌트, 및 상기 제1 및 제2 그래픽 시스템 중 어느 것이 사용 중인지에 따라, 애플리케이션으로부터의 호출들을 상기 제1 및 상기 제2 드라이버 컴포넌트들 중 하나로 라우팅시키는 프록시 드라이버 컴포넌트를 포함한다.
본 발명의 다른 양상에 따르면, 전자 장치가 제공된다. 이 전자 장치는 그래픽을 렌더링하도록 동작가능한 제1 그래픽 서브시스템; 그래픽을 렌더링하도록 동작가능한 제2 그래픽 서브시스템; 상기 제1 그래픽 서브시스템 및 상기 제2 그래픽 서브시스템 모두와 통신하는 디스플레이; 및 애플리케이션 소프트웨어 및 드라이버 소프트웨어를 실행하는 프로세서를 포함하며, 여기서 상기 드라이버 소프트웨어는, 상기 제1 및 제2 그래픽 서브시스템의 동작을 각각 제어하기 위한 제1 및 제 2 사용자 모드 드라이버 컴포넌트; 상기 제1 및 제2 그래픽 시스템 중 어느 것이 사용중인지에 따라, 상기 애플리케이션으로부터의 호출들을 상기 제1 및 제2 사용자 모드 드라이버 컴포넌트들 중 하나로 라우팅시키는 사용자 모드 프록시 드라이버 컴포넌트; 상기 제1 및 제2 그래픽 서브시스템의 동작을 각각 제어하기 위한 제1 및 제2 커널 모드 드라이버 컴포넌트; 및 상기 제1 및 제2 그래픽 시스템 중 어느 것이 사용중인지에 따라, 사용자 모드 드라이버 컴포넌트들 중 하나로부터의 호출들을 상기 제1 및 제2 커널 모드 드라이버 컴포넌트들 중 하나로 라우팅시키는 커널 모드 프록시 드라이버 컴포넌트를 포함한다.
본 발명의 또 다른 양상에 따르면, 그래픽을 렌더링하도록 동작가능한 제1 및 제2 그래픽 서브시스템을 포함하는 전자 장치의 동작 방법이 제공된다. 이 방법은, 상기 전자 장치에서 실행하는 소프트웨어 애플리케이션 또는 운영 체제로부터 드라이버 호출들을 수신하는 단계; 및 상기 제1 및 제2 그래픽 서브시스템 중 어느 것이 사용중인지에 따라, 소프트웨어 애플리케이션으로부터의 상기 드라이버 호출들을 상기 제1 및 제2 그래픽 서브시스템들의 동작을 각각 제어하기 위한 제1 및 제2 소프트웨어 드라이버 컴포넌트들중 하나로 라우팅하는 단계를 포함한다.
본 발명의 다른 양상들 및 특징들은 첨부도면과 함께 본 발명의 구체적인 실시예들에 대한 하기의 설명을 살펴봄으로써 당업자에게 명백해질 것이다.
도면은 본 발명의 실시예들을 단지 예로서만 설명한다.
도 1은 본 발명의 실시예의 예시인 연산 장치의 간략화된 도식적인 블록도이다.
도 2는 본 발명의 실시예의 예시인 연산 장치의 간략화된 도식적인 블록도이다.
도 3은 종래의 소프트웨어의 간략화된 기능적 블록도이다.
도 4는 도 2의 상기 연산 장치에서 예시적인 소프트웨어의 간략화된 기능적 블록도이며, 본 발명의 실시예들의 예시적인 드라이버 소프트웨어를 포함한다.
도 5는 본 발명의 실시예들의 예시적인 도 2의 장치에서 소프트웨어에 의해 수행되는 절차들을 상술한 흐름도이다.
도 6은 도 4의 소프트웨어 내의 API/DDI 호출(call)을 도식적으로 설명한다.
도 7은 본 발명의 실시예들의 예시적인 도 2의 장치에서 소프트웨어에 의해 수행되는 절차들을 상술하는 흐름도이다.
도 8은 도 2의 상기 연산 장치의 보다 간략화된 도식적인 블록도이다.
도 9는 본 발명의 실시예들의 예시적인 도 2의 장치에서 소프트웨어에 의해 수행되는 절차들을 상술하는 흐름도이다.
도 10은 본 발명의 추가적인 실시예의 예시적인 연산 장치의 부분들에 대한 보다 부분적으로 간략화된 도식적인 블록도이다.
도 11은 본 발명의 실시예들의 예시적인 도 10의 장치에서 소프트웨어에 의해 수행되는 절차들을 상술하는 흐름도이다.
도 12A 및 도 12B는 도 10의 장치의 동작을 도시하는 간략화된 도식적인 블록도들이다.
도 13은 본 발명의 추가적인 실시예의 예시적인 연산 장치의 부분들에 대한 보다 부분적으로 간략화된 도식적인 블록도이다.
도 1은 두 개의 그래픽 서브시스템(30 및 40)과 디스플레이(26)를 포함하는 전자 장치(10)의 간략화된 상위 수준(high level)의 블록도이다. 명백해지는 바와 같이, 각각의 그래픽 서브시스템(30, 40)은 하나 이상의 2차원 그래픽, 3차원 그래픽, 디코딩된 동영상 등의 형태로 된 컴퓨터 그래픽을 렌더링할 수 있도록 특화된 전자 회로를 포함하고 있다.
하나의 그래픽 서브시스템(40)은 다른 그래픽 서브시스템(30)보다 더 높은 평균 전력을 소비할 수 있다. 통상적으로, 그래픽 서브시스템(40)은 그래픽 서브시스템(30) 보다 더 높은 평균 전력을 소비함으로써 더 그래픽 렌더링 성능을 갖는다. 그래픽 서브시스템(40)은, 예를 들어 더 낮은 평균 전력을 소비하는 그래픽 서브시스템보다 더 높은 프레임 레이트(frame rate)로 2차원 또는 3차원 그래픽을 렌더링할 수 있다. 마찬가지로, 그래픽 서브시스템들(30, 40)이 동일한 성능을 가질 필요는 없다. 그래픽 서브시스템(40)은 통상적으로 그래픽 서브시스템(30) 보다 더 많은 기능 블록(functional block)들을 포함한다.
두 개의 그래픽 서브시스템들(30 및 40) 모두는 렌더링된 그래픽이 표시되는 동일한 디스플레이(26)에 물리적으로 또는 논리적으로 결합될 수 있다. 본 발명의 예시적인 실시예들로서, 장치(10)는, 디스플레이(26)에 대한 그래픽이 고전력 소비 그래픽 서브시스템(40)에 의해 렌더링되는 고전력 소비 모드(higher power consumption mode)로부터, 디스플레이(26)에 대한 그래픽이 저전력 소비 그래픽 서브시스템(30)에 의해 렌더링되며, 그래픽 서브시스템(40)은 부분적으로, 완전하게 또는 실질적으로 디스에이블(disable)되는 저전력 모드(lower power mode)로 스위치(switch)할 수 있다.
편리하게는, 고전력 모드로부터 저전력 모드로의 전환은 장치(10)에 대하여 전력 사이클(즉, 전원 종료와 재시작)을 요구하지 않으면서 동적으로 수행되며, 소프트웨어의 제어하에서 프로세서(12)에 의해 이루어질 수 있다. 이러한 환경에서, 소프트웨어는 애플리케이션 소프트웨어, 펌웨어(firmware), 장치 드라이버, BIOS 등을 포함할 수 있다.
본 발명은 두 개의 그래픽 서브시스템을 포함하는 실질적으로 모든 전자 장치의 일부를 형성할 수 있다. 그러한 것으로서, 장치(10)는 탁상용 연산 장치, 휴대용 연산 장치(랩탑 컴퓨터, PDA, 이동전화기, 비디오 또는 오디오 플레이어, 미디어 센터(media center) 등을 포함함)의 형태를 가질 수 있다.
후술되는 예시적인 실시예에서, 본 발명의 실시예는 이동식 (랩탑) 연산 장치의 일부를 형성하는 것으로 개시되어 있다.
구체적으로, 도 2는 본 발명의 예시적인 실시예인 특정의 이동식 연산 장치(10)의 간략화된 블록도이다. 도 1에 나타난 장치(10)는 종래의 인텔 x86 컴퓨터 아키텍쳐를 기반으로 하는 연산 장치이다. 그러나, 당업자라면 본 발명이, 이를 테면 PowerPC 아키텍쳐, AMD x86 또는 기타 알려진 아키텍쳐들과 같은 다른 아키텍쳐들을 포함하는 연산 장치들에서 구현될 수 있다는 점을 쉽게 이해할 것이다.
도시된 바와 같이, 예시적인 장치(10)는 중앙처리장치(CPU)로서 형성된 프로세서(12), 호스트 메모리(14) 및 주변 장치들을 포함하고, 이들은 모두 통합 인터페이스 회로들(16 및 18)(노스 브릿지(north bridge)(16) 및 사우스 브릿지(south bridge)(18)라고도 칭함)을 통해 상호 연결된다. 이들 모두는 마더보드 상에 형성될 수 있다.
인터페이스 회로(16)는 고속 인터페이스이고, CPU(12), 메모리(14) 및 주변 장치들을 고속 확장 버스(20) 방식에 의해 상호 연결한다. 인터페이스 회로(16)는 또한 저속 인터페이스 회로(18)에 CPU(12)를 상호 연결한다. 하나 이상의 주변 장치 확장 슬롯(peripheral expansion slot)(22)들이 고속 확장 버스(20) 방식에 의해 인터페이스 회로(16)에 상호 연결될 수 있다. 예시적인 고속 확장 버스(20)는 초당 기가바이트 범위의 대역폭을 갖는 PCI 익스프레스(PCIe) 버스이고, 이 대역폭에서 데이터 전송 읽기와 쓰기를 가능하게 한다.
인터페이스 회로(16)는 제1 그래픽 서브시스템(30)을 추가적으로 포함하는데, 이는 모니터, LCD 패널, TV 등의 형태를 가질 수 있는 디스플레이(26) 상에 디스플레이용 비디오 신호를 생성하기에 적합한 통합 그래픽 프로세서(integrated graphics processor; IGP)로서 구현된다.
부가적인 제2 그래픽 서브시스템(40)은 장치(10)의 일부를 형성한다. 예시된 실시예에서, 그래픽 서브시스템(40)은 주변 장치 확장 카드(46) 상에 형성되는 외장형 그래픽 프로세서로서 구현된다. 주변 장치 확장 카드(46)도 확장 버스(20) 상의 확장 슬롯(22) 방식에 의해 인터페이스 회로(16)에 역시 연결된다. 명백해지는 바와 같이, 제2 그래픽 서브시스템(40)을 제공함으로써, 장치(10)는 확장된 그래픽 성능을 제공할 수 있는데, 이는 그렇지 않으면 장치(10)에 존재하지 않았을 것이다. 제2 그래픽 서브시스템이 프레임 버퍼로 사용하기 위한 그래픽 메모리(50)는 주변 장치 확장 카드(46) 상에 포함될 수 있다. 마찬가지로, 그래픽 서브시스템(40)과 통신하는 전력 제어기(60)는 확장 카드(46) 상에 선택적으로 형성될 수 있으며, 그래픽 서브시스템(40)의 동작을 제어할 수 있다. 구체적으로, 전력 제어기(60)는 그래픽 서브시스템(40)의 컴포넌트들에 의해 사용되는 클록들, 이를 테면 메모리 및 픽셀(pixel) 클록과 같은 클록들을 조절(throttle)하거나, 그래픽 서브시스템(40)의 기능 블록들을 디스에이블(또는 분리)하거나, 그래픽 서브시스템(40)의 부분들에 인가되는 전압을 낮추거나, 그렇지 않으면 알려진 방법에 의해 서브시스템(40)을 전력 소비가 감소되는 하나 이상의 모드들로 둘 수 있다.
다른 선택적인 전력 제어기(70)는 제1 그래픽 서브시스템(30)과 통신할 수 있으며, 그래픽 서브시스템(30)의 컴포넌트들에 의해 사용되는 클록들, 이를 테면 메모리 및 픽셀 클록과 같은 클록들을 조절(throttle)하거나, 그래픽 서브시스템(30)의 기능 블록들을 디스에이블(또는 분리)하거나, 그래픽 서브시스템(30)의 부분들에 인가되는 전압을 낮추거나, 그렇지 않으면 알려진 방식들에 따라 서브시스템(30)을 전력 소비가 감소되는 하나 이상의 모드들로 둘 수 있다.
비록 예시된 그래픽 서브시스템(40)이 주변 장치 확장 카드(46) 상에 형성되어 있기는 하지만, 당업자라면 그래픽 서브시스템(40)은 장치(10)의 마더보드 상에 또는 다른 곳에 쉽게 형성될 수 있다는 것을 쉽게 이해할 것이다.
인터페이스 회로(18)는 저속 주변 장치들을 상호 연결하며, 그리고 통합된 IDE/SATA 포트(미도시) 방식으로, 이를 테면 광학 디스크 드라이브(28) 등과 하드 드라이브의 형태의 영구 저장 메모리(34)를 상호 연결하고, 병렬 또는 USB 포트(미도시) 방식으로 프린터 및 다른 주변 장치들을 상호 연결한다. 또 다른 주변 장치들은, 예를 들어 알려진 PCI 또는 ISA 표준들을 따르는 저속 확장 버스(24) 방식에 의해 상호 연결될 수 있다. 저속 확장 버스(24) 방식이나 또는 다른 방식으로, 이를 테면 사운드 카드들 및 네트워크 인터페이스들(미도시)과 같은 다른 컴포넌트들이 인터페이스 회로(18)에 마찬가지로 상호 연결될 수 있다.
언급된 바와 같이, 장치(10)는 랩탑 또는 소형 연산 장치의 형태의 휴대용 연산 장치로서 간편하게 형성될 수 있다. 그러한 것으로서, 단일의 하우징(housing)이 DC 전력원(38), 디스플레이(26) 및 전술한 마더보드와 컴포넌트들을 포함할 수 있다. 상기 제2 그래픽 서브시스템(40)은 상기 연산 장치의 나머지를 수용하는 단일 하우징에 부가되거나, 또는 장치(10)가 물리적으로 상호 연결될 때 단지 그 장치(10)의 일부를 형성하는 도킹 스테이션(docking station)의 일부를 형성할 수 있다.
장치(10)는 적어도 두 개의 전력 소비 모드들, 즉 고전력 소비 모드와 저전력 소비 모드에서 동작할 수 있다. 상기 도시된 실시예들에서, 장치(10)가 AC(메인) 공급원에 연결된 전원(36)에 의해 전력 공급을 받을 때에는, 고전력 모드인 것으로 추정할 수 있으며, 그리고 장치(10)가 하나 이상의 배터리, 연료 전지 등을 이용하여 DC 전력원(38)에 의해 전력 공급을 받을 때에는, 저전력 소비 모드인 것으로 추정할 수 있다. 대안적으로, 전력 소비 모드들은, 예를 들어 사용자의 선호도, 실행되는 소프트웨어 애플리케이션들의 종류, 배터리 레벨 등에 기초하여, 사용자에 의해 선택되고, 소프트웨어로 제어될 수 있다.
상기 도시된 실시예에서, 장치(10)는 도 4에 도시된 바와 같이 시스템 메모리 내에 저장된 소프트웨어(200)를 실행한다. 시스템 메모리는 영구 저장 메모리(34) 및 호스트 메모리(14)(도 2)를 포함하며, 그리고 소프트웨어(200)를 저장하고 실행하기 위해 장치(10)가 사용하는 랜덤 액세스 메모리, 판독 전용 메모리 및 디스크 저장 메모리의 적합한 조합을 더 포함할 수 있다. 예시적인 소프트웨어(200)는, 예를 들어 판독 전용 메모리에 저장되거나, 또는 이를 테면 디스크 드라이브(28)(도 1)와 같은 외장형 주변 장치로부터 또는 컴퓨터 네트워크(미도시) 상으로 로딩될 수 있다.
도시된 실시예에서, 소프트웨어(200)는 마이크로소프트 비스타(Microsoft Vista) 플랫폼을 기반으로 하고 있다. 그러나, 본 발명의 예시적인 실시예들에서, 장치(10)를 동작시키는 소프트웨어는 이러한 플랫폼에 기초할 필요는 없다. 대신에, 예시적인 소프트웨어는, 이를 테면 리눅스(Linux), 맥운영 체제X(MacOSX) 또는 다른 운영 체제들과 같은 다른 알려진 컴퓨터 운영 체제와 결합하여 동작할 수 있다. 다른 운영 체제들에서 동작하기 위해서는, 상기 소프트웨어 아키텍쳐가 도 4에서 도시된 것과 현저하게 달라질 수 있다.
윈도즈 비스타(Windows Vista) 운영 체제 환경에서는, 이를 테면 그래픽 서브시스템(30, 40)과 같은 하드웨어 컴포넌트들에 대한 하위 수준의 제어는 통상적으로 드라이버라고 일반적으로 호칭되는 소프트웨어 컴포넌트들에 의해 수행된다. 각 하드웨어 컴포넌트의 동작은 하나 이상의 이러한 컴포넌트들에 의해 제어된다.
윈도즈 비스타(Windows Vista) 운영 체제의 관점에서, 드라이버 아키텍쳐는 윈도즈 디바이스 드라이버 모델(Windows Device Driver Model; WDDM)이라 불리며, 마이크로소프트 윈도즈 드라이버 킷 API (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)의 동작을 설명하기 전에 종래의 윈도즈 비스타 아키텍쳐에 대해 설명하는 것이 바람직하다. 이를 위하여, 도 3은 윈도즈 비스타 운영 체제를 기반으로 하는 종래의 소프트웨어 (200')를 도시한다. 도시된 바와 같이, 소프트웨어(200')는 애플리케이션 소프트웨어(202'), 운영 체제의 몇 개의 일반적인 그래픽 컴포넌트들(204', 206', 208' 및 210')(런타임 컴포넌트들이라고 불림)과 몇 개의 하드웨어 특정의 그래픽 디바이스 드라이버 컴포넌트들(220, 222, 및 224)을 포함함으로써, 서브시스템(30 또는 40)과 같은 그래픽 서브시스템을 위한 디바이스 드라이버를 규정한다. 또한, 디스플레이 로더 모듈(display loader module)(218'), 윈도즈 비스타 커널(Windows Vista kernel)(216') 및 상기 윈도즈 그래픽 디바이스 인터페이스(GDI) 소프트웨어(214')가 역시 도시된다.
이해되는 바와 같이, 상기 윈도즈 비스타 운영 체제하의 드라이버 소프트웨어는 사용자 모드 또는 커널 모드에서 실행될 수 있다. 사용자 모드 드라이버(UMD) 컴포넌트들은 프로세서(12)에 의해 지원되는 비특권 모드(non-privileged mode)에서 실행되고, 메모리 및 레지스터(reigister)들 등에 대한 접근은 제한된 것으로만 허용된다. 도 2에서, 컴포넌트들(220 및 222)은 UMD 컴포넌트들이다. 애플리케이션 소프트웨어(202')를 포함한 다른 소프트웨어 역시 이러한 모드에서 실행된다. UMD 컴포넌트들(220 및 222)과 애플리케이션 소프트웨어(202')는 하위 수준 시스템 데이터에 직접적인 접근 권한을 얻을 수 없다. 이들은 마찬가지로 모든 메모리 영역 및 모든 레지스터들에 접근할 수 없다. 하지만, 이들은 커널 모드에서 실행되는 소프트웨어에 대하여 호출(call)들을 생성할 수 있다.
대조적으로, 커널 모드 드라이버(KMD) 컴포넌트들은 상기 운영 체제 커널과 동일한 프로세서 모드에서 실행되며, 이에 따라 상기 메모리, 레지스터들 및 장치(10)의 다른 자원들에 대하여 일반적으로 자유로운 접근 권한을 갖는다. UMD 컴포넌트들은 연산 장치(10)의 자원들에 대한 하위 수준의 접근 권한을 획득하기 위하여 KMD 컴포넌트들을 호출할 수 있다. 컴포넌트(224)는 KMD 컴포넌트이다. KMD 드라이버 아키텍쳐는 2006년 5월 10일자 http://www.microsoft.com/whdc/driver/wdf/KMDF-samp.mspx의 커널 모드 드라이버 프레임워크를 위한 표본 드라이버들(Sample Drivers for the Kernel Mode Driver Framework) 및 http://msdn2.microsoft.com/en-us/library/aa490246.aspx의 WDM 소개에서 추가적으로 상술된다.
UMD 컴포넌트들 및 KMD 컴포넌트들은 다른 구조들, 다른 엔트리 포인트(entry point)들 및 다른 시스템 인터페이스들을 갖는다. 장치가 UMD 또는 KMD 중 어느 것을 요구하는 지는, 장치의 형태 및 운영 체제에서 이를 위해 이미 제공된 지원에 따라 결정된다. 그래픽 서브시스템(30 및 40)과 같은 그래픽 서브시스템을 위한 드라이버들은 통상적으로 적어도 하나의 커널 모드에서 실행되는 컴포넌트를 포함한다. 또한, 상기 윈도즈 비스타 운영 체제에서, 필요에 따라, UMD 컴포넌트들이 요청즉시(on demand) 로딩되는 동안, KMD 컴포넌트들은 시스템 초기화 시에(즉, 전원 공급시에) 로딩된다.
보다 구체적으로, 상기 윈도즈 비스타 아키텍쳐에서는, 그래픽 서브시스템들을 위한 UMD 컴포넌트들이 상기 서브시스템들에 의해 사용되는 자원들에 대한 하위 수준의 접근권한을 획득하기 위하여 대응되는 KMD 컴포넌트들과 통신한다. 통상적으로, 각각의 KMD 컴포넌트는 디바이스 드라이버 인터페이스(device driver interface; 이하 DDI라 칭함)를 제공하고, 이는 대응되는 UMD 컴포넌트에게 알려져 있다. DDI는 함수 호출(function call)들, (메쏘드들을 포함하는) 객체들, 입출력 제어(input/output control; 이하 IOCTL이라 칭함) 호출들 및 연관된 데이터 구조들을 포함할 수 있다. 이해되는 바와 같이, 함수 호출들은 함수/메쏘드 파라미터들을 통하여 이러한 데이터 구조들 내에 보통 구성되는 데이터를 수신한다. 상기 데이터 구조의 정확한 특성은 상기 DDI 정의에 상술되어 있다.
상기 도시된 실시예에서, 운영 체제 그래픽 컴포넌트들(204', 206' 및 208')은 상기 운영 체제의 제조자(상기의 경우는 마이크로소프트사)가 제공하는 런타임 컴포넌트들이고, 반면에 UMD 및 KMD 컴포넌트들의 형태를 가진 하드웨어 특정의 드라이버 컴포넌트들(220, 222 및 224)은 (이를 테면 그래픽 서브시스템 (30 또는 40)의 제조자들과 같은) 제3자 제조자들이 제공한다.
운영 체제 그래픽 컴포넌트들은 런타임 3차원 그래픽 런타임 컴포넌트 (204')(run time 3D graphics run-time component)(다이렉트 3D 런타임)(Direct 3D Run time), 하드웨어 가속 그래픽 인터페이스 런타임 컴포넌트 (DXVA)(206') 및 3차원 오픈 그래픽 라이브러리(OpenGL) 런타임 그래픽 컴포넌트 (208')을 포함한다. 대응되는 하드웨어 특정의 UMD 컴포넌트들(220 및 222)은 다이렉트 3D, DXVA 및 OpenGL API들에 대응되는 API 하드웨어 호출들의 하드웨어 특정의 구현을 제공한다.
런타임 컴포넌트들(204', 206' 및 208')과 UMD 컴포넌트들(220 및 222)은 애플리케이션 소프트웨어 (202') 및 상기 운영 체제의 나머지 부분이 사용할 수 있도록 통일화된 그래픽 API를 제공한다. 구체적으로, 상기 API들은 마이크로소프트에 의해 상술되는 바와 같이 UMD 컴포넌트들(220' 및 222') 내 또는 런타임 컴포넌트들(204', 206' 및 208') 내의 드라이버 소프트웨어 루틴들(예를 들어, 함수들 또는 메쏘드들)이 실행되도록 하는 함수 호출(function call)들 및 객체들 등을 제공한다. API 호출들은 애플리케이션 소프트웨어(200')에 의해서, 상기 운영 체제의 부분들(예를 들어, 모듈들 204', 206' 및 208')에 의해서 또는 다른 드라이버들에 의해서 생성될 수 있다. UMD 컴포넌트들(220 및 222)은 상기 API 호출들에 대응되는 (통상적으로 함수들 또는 객체의 메쏘드들의 형태인) 소프트웨어 코드를 차례로 실행한다. D3D, DXVA 및 OpenGL UMD 컴포넌트들(220 및 222)에 의해 제공되는 함수들 및 콜백(call-back)들은 마이크로소프트 개발자 네트워크(Microsoft Developer's Network)(www.msdn.com)에서 찾아볼 수 있는 윈도즈 드라이버 키트: 디스플레이 디바이스 윈도즈 비스타 디스플레이 드라이버 모델 레퍼런스(Windows Driver Kit: Display Devices Windows Vista Display Driver Model Reference)에서 상술되고, 그 내용은 여기에 참고로 편입된다.
보다 구체적으로, UMD 컴포넌트(220 및 222) 또는 KMD 컴포넌트(224)가 운영 체제의 로딩 루틴에 의해 로딩된 후, (커널 모드 드라이버들을 위한) DriverEntry(), DllMain() 또는 상기 UMD 컴포넌트들(220 및 222)을 위한 그외의 다른 이름(예를 들어, OpenAdapter())을 갖는 드라이버 컴포넌트 엔트리 포인트의 위치가 정해진다. 상기 UMD/KMD 컴포넌트들(220, 222 및 224)은 예상 동작을 구현한 상기 UMD/KMD 컴포넌트들(220, 222 및 224) 내부의 함수들을 지시하기 위하여 상기 UMD/KMD 컴포넌트(220, 222 및 224)의 상기 엔트리 포인트에서의 코드로 채워진 잘 알려진 구조를 상기 OS로부터 수신하는 함수들을 포함한다. 상기 이름들은 상기 DDI 명세에 의해 정의되고 소위 정의 파일을 통하여 구현된다.
예를 들어, KMD 컴포넌트(224)는 DDI의 드라이버 구현 함수 집합의 일부인 다양한 동작들을 위한 함수 포인터들을 포함하는 DRIVER_INITIALIZATION_DATA 구조를 수신한다. 요구될 때에, UMD 컴포넌트들(220 및 222)의 나머지 부분들은 반드시 전부는 아니지만 많은 경우에 있어서 (보통 일련의 추가적인 KMD 드라이버 내부 함수들을 호출하는 방식에 의해) 하드웨어에 대한 접근 권한을 발생시키는 상기 드라이버 내에서의 바람직한 동작을 시작시키기 위한 함수들을 호출할 수 있다.
UMD 컴포넌트들(220 및 222)는 동적 연결 라이브러리(dynamic linked library; DLL)들의 형태로 형성될 수 있고, 상기 WDDM을 따른다. 그러한 것으로서, 각각의 UMD 컴포넌트(220 및 222)는 상기 WDDM에 따라 함수들 및 객체들의 집합과 IOCTL들을 제공한다. 대체적으로, 각 드라이버 컴포넌트는 정의된 엔트리 포인트 DriverEntry() 및 정의된 객체 클래스들, 드라이버 엔트리 포인트들 및 정의된 함수들과 콜백들을 포함한다. 각각의 드라이버가 로딩된 후, 그 엔트리 포인트 DriverEntry()에서의 소프트웨어 코드가 실행되고 정의된 루틴들은 예상 구조 내에 등록된다.
상기 DllMain() 엔트리 포인트는 상기 UMD 컴포넌트의 기본적인 데이터 구조들을 할당하고 초기화하기 위해 사용되거나, 상기 UMD가 로딩되지 않을 때 이들을 제어된 기법으로 구분하기 위해서 사용된다.
상기 WDDM UMD 컴포넌트의 경우, 상기 OpenAdapter() 호출은 상기 KMD 컴포넌트의 상기 DriverEntry() 호출과 비슷한 방법으로 동작한다. 즉, 상기 OpenAdapter() 호출은 함수 포인터들의 집합과 함께 데이터 구조를 수신하고, 상기 함수 포인터들의 집합은 상기 UMD 컴포넌트 내부의 적절한 함수들을 지시하기 위하여 상기 UMD 컴포넌트(220 및 222)가 채우는 것이다.
상기 이름들 및 지원되는 함수들/객체 및 상기 UMD 내부에서의 관련 코드 주소들은 이러한 구조 방식에 의해 상기 운영 체제의 나머지 부분들에게 결과적으로 반환된다. 여기에서 또한, D3D, DXVA 및 OpenGL UMD 함수들(220 및 222)에 의해 지원되는 UMD 함수들 및 구조들은 상기에서 언급했던 마이크로소프트 개발자 네트워크(Microsoft Developer's Network)에서 찾아볼 수 있는 윈도즈 드라이버 키트: 표시장치 윈도즈 비스타 디스플레이 드라이버 모델 레퍼런스(Windows Driver Kit: Display Devices Windows Vista Display Driver Model Reference)에서 상술된다.
따라서, 각각의 UMD 컴포넌트(220 및 222)를 로딩한 결과, API 함수들/객체들 및 IOCTL들은 애플리케이션들(202') 및 상기 운영 체제 소프트웨어의 나머지 부분에게 알려진다. API 객체들은 식별된 주소에서 객체들의 인스턴스(instance)들을 생성함으로써 애플리케이션 소프트웨어(200)에 의해 인스턴스화 될 수 있다. 함수들/메쏘드들 및 IOCTL들은 그들과 대응되는 주소들에서 실행될 수 있다.
운영 체제 그래픽 모듈들은 커널 모드 그래픽 코어 소프트웨어 컴포넌트(210')(이후 윈도즈 비스타 운영 체제 내의 DirectX라 칭함) 및 KMD 컴포넌트(224)를 추가적으로 포함한다. 그래픽 코어 소프트웨어 컴포넌트(210')은 UMD 컴포넌트들(220 및 222)이 장치(10)의 자원에 대한 커널 모드 접근 권한을 획득할 수 있게 허용함으로써 UMD 컴포넌트들(220 및 222)을 위해 API를 제공한다. 그래픽 코어 소프트웨어 컴포넌트(210')은 비디오 메모리 관리자, 스케쥴러, 및 호환성을 위해 특정 API/DDI 호출들을 번역(또는 썽크(thunk))하는 루틴들을 추가적으로 포함할 수 있다. KMD 컴포넌트(224)는 전술된 바와 같이 상기 윈도즈 드라이버 모델(Windows Driver Model) 또는 상기 윈도즈 드라이버 프레임워크(Windwos Driver Framework)를 따를 수 있다. 그러한 것으로서, KMD 컴포넌트(224)는 DDI를 제공하는, 정의된 객체 클래스들, 함수들 및 구조들을 포함한다.
UMD 컴포넌트들(220 및 222)과 마찬가지로, KMD 컴포넌트(224)는, KMD 컴포넌트(224)를 위해 상기 필요한 DDI를 제공하면서, 통상적으로 이름 또는 메모리 주소에 의한 식별자로서 객체 클래스들, 함수들 및 구조들의 식별자들을 반환하는 초기화 루틴, DriverEntry()를 포함한다. 주목한 바와 같이, KMD 컴포넌트(224)는 시스템 시작시에 통상적으로 로딩(및 초기화)된다.
추가적으로는, KMD 컴포넌트(224)는 상기 운영 체제의 나머지 부분에 특별히 알려지거나 보고되지 않았으나 상보적인 UMD 드라이버(220 또는 222)에게는 알려진 DDI를 포함할 수 있다.
소프트웨어(200)는 특정한 기능성을 제공하기 위해 하위 계층(layer)들을 이용한 상위 수준의 계층들로 계층화된다. 따라서, 애플리케이션 소프트웨어(202)는 통상적으로 런타임 운영 체제 그래픽 모듈들(204', 206' 및 208'), 또는 UMD 컴포넌트들(220 및 222) 또는 GDI(214')에 대한 호출을 생성함으로써 그래픽을 렌더링한다. 그래픽 모듈들(204', 206' 및 208')은 모든 제3자(third party) 비디오 드라이버들에게 공통적인 일반적인 하드웨어 독립적 코드 만을 포함한다. 런타임 컴포넌트들(204', 206' 및 208')은 순서대로 UMD 컴포넌트들(220 및 222)에 대한 API/DDI 호출을 생성할 수 있다. 데이터 구조들에 정의된 알려진 파라미터들은 예를 들어 파퓰레이트된(populated) 구조들에 대한 적절한 포인터들에 의해 UMD 컴포넌트들(220 및 222)에 전달될 수 있다. UMD 컴포넌트들(220 및 222)는 하드웨어 특정의 코드 및 구조를 포함한다. 그러나, 언급된 바와 같이, UMD 컴포넌트들(220 및 222)은 오직 사용자 수준의 접근 권한을 가지고 있다. UMD 컴포넌트들(220 및 222)은 KMD 컴포넌트(224)에 의해 제공되는 알려진 API/DDI를 직접적으로 이용하여 또는 커널 모드 그래픽 코어 소프트웨어 컴포넌트(210')을 통해 KMD 컴포넌트(224)와 통신한다.
KMD 컴포넌트(224)는 또한 적절한 하위 수준 명령들을 그 기초가 되는 하드웨어(예를 들어, 그래픽 서브시스템(30 또는 40))에게 전달할 수 있는 함수들 및 객체들 등을 포함한다. 상기 KMD 컴포넌트(224)에 대한 다수의 호출들이 또한 큐잉(queuing)될 수 있다. 상기 하위 수준 명령들은 또한 상기 기초가 되는 하드웨어에 의해 실행될 수 있다. 예를 들어, 상기 하위 수준 명령들은 그래픽 프로세서가 수행가능한 명령들 등을 포함할 수 있다.
다른 알려진 운영 체제와 달리, 윈도즈 비스타는 오직 하나의 디스플레이 드라이버 KMD 컴포넌트(224')의 로딩 만을 허용한다. 추가적인 부속 애플리케이션은 디스플레이 드라이버 로더(display driver loader)(218')로서 동작한다. 이러한 로더(218')는 통상적으로 시작 당시에 실행되지만, 시작 후에 실행될 수도 있다. 로더(218')는 그래픽 코어 소프트웨어 컴포넌트(210)에 의한 접근을 위하여 제3자 KMD 컴포넌트들(예를 들어, KMD 컴포넌트(224'))을 로딩하고 초기화한다. 비록 로더(218)가 KMD 컴포넌트(224')와 같은 커널 모드 드라이버 컴포넌트들을 로딩/언로딩하기 위하여 사용될지라도, 상기 하나의 그래픽 KMD 컴포넌트의 로딩은 다른 드라이버의 언로딩을 필요로 한다.
이제, 서브시스템(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)는 API들/DDI의 단일 집합을 운영 체제의 나머지 부분에게 제시하고, 단일 그래픽 드라이버처럼 보이게 된다. 그러한 것으로서, 런타임 컴포넌트들(204, 206 및 208), 애플리케이션 소프트웨어(202) 및 상기 운영 체제의 나머지 부분은 도 3에서와 같이 그래픽 API 함수들/객체들을 불러올 수(또는 호출할 수) 있다.
또한, 추가적인 전력 제어 애플리케이션(201)이 기능적으로 도시된다. 명백해지는 바와 같이, 전력 제어 애플리케이션은 그래픽 서브시스템(30 및 40)(도 1)의 전체적 전력 소비 상태를 제어할 수 있다. 전력 제어 애플리케이션(201)은 독립형(stand-alone) 애플리케이션이거나, 또는 이를 테면 ATI/AMD 사로부터 입수할 수 있는 카탈리스트 제어 센터(Catalyst Control Center) 애플리케이션과 같은 전체적인 사용자/그래픽 서브시스템 제어 및 설정 애플리케이션의 일부를 형성할 수도 있다.
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 컴포넌트들이고, UMD 컴포넌트(220)과 같이 각각 그래픽 서브시스템(30 및 40)에 대하여 하드웨어 특정의 함수들, 객체들 및 IOCTL들 등을 포함한다. 마찬가지로, KMD 컴포넌트들(360 및 362)은 KMD 컴포넌트(224)와 유사하고, 커널 모드에서 그래픽 서브시스템들(30 및 40)과 상호 동작하도록 설계된 함수들, 객체들 및 IOCTL들 등을 포함한다.
예를 들어, UMD 컴포넌트들(340 및 350)과 KMD 컴포넌트(360)은 제1 그래픽 서브시스템(30)을 위해 각각 사용자 모드 DirectX 드라이버 소프트웨어, OpenGL 드라이버 소프트웨어 및 커널 모드 드라이버 소프트웨어 컴포넌트들을 제공할 수 있고, 반면에 UMD 컴포넌트들(342 및 352)과 KMD 컴포넌트(362)는 제2 그래픽 서브시스템(40)을 위해 사용자 모드 드라이버 소프트웨어, OpenGL 드라이버 소프트웨어 및 커널 모드 드라이버 소프트웨어를 제공할 수 있다. 편리하게는, 컴포넌트들(340, 350 및 360)(또는 컴포넌트들(342, 352 및 362))은, 그래픽 UMD/KMD 컴포넌트들(220, 222 및 224)의 자리에 도 3에 도시된 바와 같이 상기 운영 체제에 의해 직접 로딩될 수 있다는 점에서 통상적일 수 있다.
이러한 방식으로, 각각의 그래픽 UMD/KMD 컴포넌트들(340 및 342, 350 및 352, 360 및 362)은 하위 수준의 그래픽 함수를 실행할 수 있으며, 포함된 그래픽 하드웨어 특정되는 방식으로 그래픽 하드웨어를 액세스할 수 있다.
편리하게는, UMD 프록시 드라이버 컴포넌트들(320 및 322)과 KMD 프록시 드라이버 컴포넌트(324)는, 한편으로는 상기 운영 체제의 나머지 부분과 다른 애플리케이션들에게 하나의 통일된 API/DDI를 제공하고, 다른 한편으로는 호출들, IOCTL들, 요청들 및 현 객체들 등(집합적으로 API/DDI 호출들)을 하드웨어 특정의 UMD/KMD 드라이버 컴포넌트들(340, 350 및 360, 또는 342, 352 및 362)로 라우팅시킨다.
동작시, UMD 프록시 드라이버 컴포넌트들(320 및 322)과 KMD 프록시 드라이버 컴포넌트(324)는 상기 운영 체제의 나머지 부분들에 의해 로딩된다.
일단 UMD 프록시 드라이버 컴포넌트(320 또는 322)가 로딩되면, 그 엔트리 루틴(예를 들어, DllMain()/OpenAdapter())이 실행된다. 명백해지는 바와 같이, UMD 프록시 드라이버 컴포넌트들(320 및 322)의 엔트리 루틴은 UMD 컴포넌트들(340 및 342) 중 하나 또는 모두를 로딩하고, 상기 비스타 운영 체제의 나머지 부분에게 UMD 프록시 드라이버 컴포넌트(320 및 322) 내에서 지원되는 API/DDI 호출들을 식별하기 위한 예상 데이터 구조를 제공하는 바, 이는 UMD 컴포넌트들(224 및 224)이 수행하는 방식과 많은 부분에서 동일한 방식으로 이루어진다. 마찬가지로, 기다리고 있는 API/DDI들의 주소들은 예상 구조 방식에 의해 함수들의 주소, 객체들, IOCTL들의 형태로 제공된다.
UMD 컴포넌트들(340 및 342)은, 도 5의 블록(S500)에서 보다 특별하게 도시하는 바와 같이, UMD 프록시 드라이버 컴포넌트(320) 내부의 소프트웨어 코드에 의해 로딩된다. 구체적으로, 블록(S502) 내에서 UMD 컴포넌트(340 또는 342)와 같은 UMD 드라이버 컴포넌트가 통상적으로 동적 연결 라이브러리(dynamically linked library)로서 로딩된다. 다음으로, 상기 새롭게 로딩된 UMD 컴포넌트(340 또는 342)의 상기 드라이버 초기화 루틴 DllMain()/OpenAdapter() 등은 UMD 프록시 드라이버 컴포넌트(320)에 의해 호출될 수 있다. 상기 새롭게 로딩된 UMD 컴포넌트(340 또는 342)의 상기 드라이버 초기화 루틴은 지원되는 함수들 및 IOCTL들 등의 이름들 및 주소들을 (UMD 컴포넌트(220 및 222)가 그러한 이름들, 주소들 등을 반환하는 것과 동일한 방식으로) 블록(S504) 내의 UMD 프록시 컴포넌트(320)에게 반환한다. 다음으로, UMD 프록시 드라이버 컴포넌트(320)는 블록(S508) 내의 상기 로딩된 UMD 컴포넌트(340 또는 342)에 의해 지원되도록 하기 위하여 객체 클래스들, 함수들 및 IOCTL들 등 사이의 일치(concordance)를 나타내는 데이터 구조를 형성한다.
예를 들어, UMD 프록시 드라이버 컴포넌트(320)는 DXVA 함수 호출들 및 객체들을 지원하도록 설계되며, 이에 따라 알려진 DXVA 함수 호출들, 그러한 객체들 및 상기 로딩된 UMD 컴포넌트(340 또는 342) 내의 이들의 엔트리 포인트들 사이의 일치(concordance)를 형성한다. 블록(S506) 수행 결과, UMD 프록시 드라이버 컴포넌트(320)는 메모리 내에 구조를 형성할 수 있고, 상기 구조는 UMD 프록시 드라이버 컴포넌트(320)에 의해 지원되는 DXVA 함수, 객체, IOCTL 등에 각각 대응되는, UMD 컴포넌트(340 또는 342) 내의 주소들을 제공한다.
특정의 UMD 컴포넌트들(340 또는 342, 350 또는 352)은 프록시 드라이버 컴포넌트들(320 및 322)에 의해 또는 동적으로 필요에 따라 로딩될 수 있다. 특히, 그래픽 서브시스템(30 또는 40) 중 임의의 것이 사용되지 않는다면, 그에 대응하는 UMD 드라이버 컴포넌트들은 로딩될 필요가 없다.
블록들(S500)에 대응하는 소프트웨어는 각 UMD 드라이버(340 및 342)가 UMD 프록시 드라이버 컴포넌트(320)에 의해 로딩되도록 수행될 수 있다. 유사하게, 단계들(S500)은 UMD 컴포넌트들(350 및 352)을 위한 프록시 드라이버 컴포넌트로서 동작하는 UMD 프록시 드라이버 컴포넌트(322)에 의해 수행될 수 있다.
마찬가지로, 블록들(S500)은 통상적으로 시스템 시작시에 KMD 프록시 드라이버 컴포넌트(324)의 초기화시에 수행된다. KMD 프록시 드라이버 컴포넌트(324)는 KMD 드라이버들(360 및 362)(예를 들어, OpenAdapter())의 초기화 루틴들을 실행한다.
블록들(S500)(또는 그들에 상당하는 것들)이 각각의 UMD 프록시 드라이버 컴포넌트(320 및 322)에 의해 그리고 각각 지원되는 드라이버 컴포넌트(예를 들어, UMD 컴포넌트들(340 및 342), UMD 컴포넌트들(350 및 352) 및 KMD 컴포넌트들(360 및 362))을 위한 KMD 프록시 드라이버 컴포넌트(324)에 의해 일단 실행되면, UMD/KMD 프록시 드라이버 컴포넌트들(320, 322 및 324)은 그래픽 서브시스템들(30 및 40) 특정의 UMK/KMD 컴포넌트들을 로딩하게 되고, 로딩된 UMD 컴포넌트들(340 및 342, 350 및 352)과 KMD 컴포넌트(360 및 362) 내의 지원되는 함수들, IOCTL들 등의 대응하는 메모리 주소/엔트리 포인트들을 확인하게 된다.
상기 운영 체제의 나머지 부분들에 시스템 자원 정보를 제공하기 위하여, 오직 KMD 프록시 컴포넌트(324)만 그래픽 서브시스템들(30 및 40) 모두를 위하여 직접적으로 보이고 설치가능하게 된다. 그래픽 서브시스템(30 및 40) 모두를 위한 드라이버 특정의 등록 엔트리들은 상기 프록시 드라이버 컴포넌트가 판독할 수 있고 그들을 UMD 컴포넌트들(340 및 350, 342 및 352)에게 드러나도록 하기 위하여 병합될 수 있다.
UMD 컴포넌트들(340 및 342, 350 및 352)은 또한, UMD 프록시 컴포넌트들(320 및 322)에 의해 수집되고 조정될 필요가 있는 다수의 속성들을 반환할 수 있으며, 이는 상기 반환된 속성들이 다수의 그래픽 서브시스템들과 상호 동작하기 위해 사용되는 단일의 드라이버와 모순이 없는지 확인하기 위함이다. 이러한 속성들은 UMD 프록시 컴포넌트들(320 및 322)에 의해 상기 운영 체제에 전달될 수 있다. 예를 들어, 비디오 메모리 힙들(heaps), GPU 엔진 속성들, DMM 토폴로지 등이 UMD 프록시 컴포넌트들(320 및 322)에 의해 결합될 필요가 있을 수 있다.
UMD/KMD 컴포넌트들(340 및 342, 350 및 352, 360 및 362)을 로딩하는 것에 대한 추가적 대안으로서, 이들이 생성(build)될 때 UMD 프록시 드라이버 컴포넌트들(320 및 322)과 KMD 프록시 컴포넌트(324)에 정적(static)으로 링크(link)될 수도 있다. 물론 이것은 UMD/KMD 컴포넌트들(340 및 342, 350 및 352, 360 및 362)의 소스 코드(source code) 또는 링크가능한 객체 모듈들에 대한 접근을 필요로 할 것이다.
결과적으로, UMD 프록시 컴포넌트들(320 및 322), 드라이버 UMD 컴포넌트들(340 및 342, 350 및 352, 360 및 362), UMD 프록시 컴포넌트(320 및 322), KMD 프록시(324)를 로딩/링크하는 KMD 프록시 컴포넌트(324)는, 애플리케이션 소프트웨어(202) 또는 상기 운영 체제의 나머지 부분에 의해 어느 그래픽 서브시스템(30 또는 40)이 어드레싱되는 지에 따라, 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 호출들로서 UMD 컴포넌트들(340 및 342, 350 및 352)과 KMD 컴포넌트들(360 및 362)에 의해 실질적으로 수행되는 호출들에 대한 라우팅 루틴들의 상기 구체적 항목들로 데이터 구조를 채움으로써 이루어진다.
API/DDI 호출들은 UMD/KMD 프록시 드라이버 컴포넌트(320, 322 및 324) 내부에서 상기 라우팅 함수들(또는 객체들)에 의해 라우팅될 수 있다. 상기 UMD/KMD 프록시 드라이버 컴포넌트들(320, 322 및 324)의 각 라우팅 루틴 또는 객체의 주소는, 라우팅될 상기 특정 함수/호출/객체/IOCTL 등에 따라, 상기 운영 체제 및 다른 애플리케이션들에게 드러날 수 있다. 각각의 라우팅 루틴 또는 객체는 UMD/KMD 드라이버 컴포넌트들 중 하나로 호출들을 라우팅하며, 이 경우 상기 프록시 드라이버 컴포넌트는 UMD/KMD 드라이버 컴포넌트들 중 하나를 위한 프록시 역할을 수행한다. 이러한 방식으로, 프록시 드라이버 컴포넌트들(320, 322 및 324)에 대한 API/DDI 호출은 UMD 드라이버(340 및 342, 또는 350 및 352) 또는 KMD 컴포넌트(360 및 362) 내에서 상기 대응되는 드라이버 함수/호출/객체/IOCTL로 라우팅될 수 있다.
구체적으로, 도 7에서 도시된 바와 같이 각각의 API/DDI 호출은 UMD/KMD 프록시 드라이버 컴포넌트(320, 322 또는 324)에 의해 간단히 재라우팅될 수 있으며, 이는 UMD 컴포넌트들 내의 대응되는 함수/호출/객체/IOCTL의 주소에 기초하여 이루어지는 것으로, 이 경우 블록(S700) 내의 블록(S508)에서 대응되는 엔트리 포인트는 그에 따라 결정된다. 구체적으로, 단계들(S700)의 실행시, UMD/KMD 프록시 컴포넌트(320 및 322) 또는 KMD 프록시 컴포넌트(324)는 어느 UMD/KMD 컴포넌트(예를 들어, UMD 컴포넌트(340 및 342, 350 및 352) 또는 KMD 컴포넌트(360 및 362))가 블록(S702) 내의 API/DDI 호출을 다루어야 하는 지를 결정한다. 이는, 예를 들어, 상기 API/DDI 호출 또는 상기 연관된 그래픽 서브시스템을 식별하기 위해 연관된 데이터를 분석(parsing)함으로써, 또는 간단히 다수의 그래픽 서브시스템들 중 어느 것이 현재 사용 중인지를 결정함으로써 수행될 수 있다. 하기에서 상술되는 바와 같이, 현재 사용 중인 그래픽 서브시스템(30 또는 40)은 장치(10)의 전력 소비 모드에 의존적일 수 있다. 상기 현재 사용 중인 그래픽 서브시스템은 통상적으로 그래픽/비디오가 디스플레이되도록 렌더링하고, 최종 사용자가 볼 수 있게 한다.
일단 상기 연관된 드라이버가 식별되면, UMD/KMD 프록시 컴포넌트(320 및 322) 또는 KMD 컴포넌트(324)는 블록(S706) 내의 블록(S508)에서 형성되는 일치(concordance) 구조를 참조하여 상기 API/DDI 호출들의 주소를 결정한다. 일단 상기 주소가 결정되면, 상기 연관된 UMD/KMD 컴포넌트(340 또는 342, 350 또는 352, 360 또는 362) 내부의 상기 API/DDI 호출이 생성될 수 있다. 이후, UMD/KMD 컴포넌트는 API/DDI 호출에 대응되는 코드를 실행한다.
특히, UMD 컴포넌트들(340 및 342 또는 350 및 352)에 대한 호출들은 추가의 커널 모드 API/DDI 호출들을 생성할 수 있다. 이는 KMD 프록시 컴포넌트(324)에 대한 API/DDI 호출들로 귀결될 수 있다. KMD 프록시 컴포넌트(324)는, UMD 프록시 컴포넌트들(320 및 322)과 마찬가지로, 도 7에 상술된 바와 같이 DDI 호출을 적절한 KMD 컴포넌트(360 및 362)로 라우팅시킨다. KMD 프록시 컴포넌트(324)는 어느 KMD 컴포넌트(360 및 362)에게로 커널 모드 API/DDI 호출이 라우팅되어야 하는 지를 결정할 수 있는데, 이는 UMD 프록시 컴포넌트들(320 및 322)이 평가(assessment)를 수행하는 방식, 즉 호출의 특성에 의존하여 또는 현재 동작중인 그래픽 서브시스템에 의존하는 것과 매우 동일한 방식으로 이루어진다.
(예를 들어, 객체들의 생성을 통해 또는 함수 파라미터들에 의해) 데이터를 수반하는 호출들에 있어서, UMD 프록시 컴포넌트들(320 및 322) 또는 KMD 프록시 컴포넌트(324)에 의해, 상기 데이터에 대한 포인터들이 상기 결정된 UMD 컴포넌트(340, 342, 350 및 352) 또는 KMD 컴포넌트(360 및 362)에게 전달될 수 있다. 만일 상기 데이터가 포인터로서 전달되지 못한다면, 그 데이터는 대응되는 데이터 구조에 터널링(tunnelling)될 수 있다.
어떤 API/DDI 호출들은 운영 체제의 나머지 부분들에게 알려지지 않을 수 있고, 초기화시(예를 들어, DllMain() 또는 AdapterOpen()의 실행시)에 UMD 프록시 드라이버 컴포넌트(320 및 322) 또는 KMD 프록시 드라이버 컴포넌트(324)에게 반환되지 않을 수 있다. 이는 단일의 제조자/공급자에 의해 제공되는 UMD 컴포넌트(340 및 342)와 같은 상보적인 UMD 컴포넌트와 상호 동작하는 KMD 컴포넌트들(360 또는 362)과 같은 KMD 컴포넌트들에 대해 특히 그러할 수 있다. 비록 DDI 호출들이 지원될 수 있다고 할지라도, 이들은 운영 체제에게 노출될 필요가 없다. 통상적으로, 이러한 호출들은 추가적인 지식(knowledge)없이 KMD 프록시 드라이버 컴포넌트(324)에 의해 라우팅될 수 없다. 이를 회피하기 위해, 각각의 KMD 컴포넌트(360 및 362)는, 예를 들어 드라이버 초기화 루틴의 실행에 응답하여, 운영 체제 스케줄러의 컨텍스트 스위치 및 페이지 요청들을 위한 일반적인 운영 체제 통신에 관련될 수 있는 지원되는 모든 API/DDI들을 보고해야 한다. 이러한 것이 가능하지 않는한, KMD 컴포넌트(360 및 362)는 KMD 프록시 드라이버 컴포넌트(324)에 의해 요구되는 API/DDI들 호출들에 대한 정보를 반환하는 질문 루틴(query routine)을 더 포함할 수 있다.
프록시 드라이버 컴포넌트는, 그래픽 서브시스템들(30 및 40)에게 영향을 줄 수 있는 어떠한 상태 변화들을 확실하게 추적하기 위해, API/DDI 호출들에 대해 행해진 UMD/KMD 컴포넌트들로부터의 호출들을 또한 수신해야 한다.
도 8은 도 2의 장치(10)의 일부분에 대한 추가적인 간략화된 블록도를 나타내는 바, 여기에서는 도 4의 소프트웨어(200)(및 특히 UMD 프록시 컴포넌트들(320 및 322)과 KMD 프록시 컴퍼넌트(324))가 사용될 수 있다. 도시된 바와 같이, 인터페이스 회로(16)는 중앙처리장치(12) 및 시스템 메모리(14)를 상호 연결한다. (인터페이스 회로(16) 상의 그래픽 프로세서로서 구현되는) 그래픽 서브시스템(30)은 그래픽 엔진(32), 메모리 제어기(72), 디스플레이 인터페이스(74) 및 버스 인터페이스(78)를 포함한다.
그래픽 엔진(32)은 2차원 그래픽 또는 3차원 그래픽을 렌더링하고, 비디오를 디코딩하는 등을 할 수 있는 기능 블록이다. 이해되는 바와 같이, 그래픽 서브시스템(30)은 다수의 그래픽 엔진들을 포함할 수 있다.
메모리 제어기(72)는 그래픽 서브시스템(30)이 그래픽 메모리 및 호스트 메모리(14)에 대한 접근 권한을 제공할 수 있도록 한다. 도시된 실시예에서, 그래픽 서브시스템(30)에 의해 사용되는 그래픽 메모리는 호스트 메모리(14)의 일부를 형성한다. 그러나, 당업자라면 그래픽 서브시스템(30)이 그 자신의 로컬 메모리를 포함하거나 그것과 통신할 수 있음을 쉽게 이해할 것이다. 버스 인터페이스(78)는 서브시스템(30)이 버스(20)를 통해 통신할 수 있게 한다.
이해되는 바와 같이, 디스플레이 인터페이스(74)는 포트(78)에 의해 상호 연결된 디스플레이 장치(26) 상에 디스플레이하기 위해 버퍼 내의 데이터를 변환하는 데에 적절한 임의의 인터페이스가 될 수 있다. 예를 들어, 디스플레이 인터페이스(74)는 랜덤 액세스 메모리, 디지털-아날로그 컨버터("RAMDAC")의 형태를 취할 수 있다. 하나 이상의 비디오 커넥터들은 그래픽 서브시스템(30)이 LCD 패널, 모니터, TV 등과 같은 하나 이상의 디스플레이 장치와 상호 연결될 수 있게 한다. 출력 포트(78)는 VGA 포트들, 복합(composite) 비디오 포트들, DVI 포트들, LVDS 포트들, DVO 포트들, SDVO 포트들 등의 형태를 가질 수 있다.
(예를 들어, 도 2의 주변 장치 확장 카드(46) 상에 형성되는) 그래픽 서브시스템(40)은 또한 고속 확장 버스(20)를 통해 확장 슬롯 방식에 의해 인터페이스 회로(16)에 연결된다. 그래픽 서브시스템(40)은 그래픽 엔진(42), 메모리 제어기(52), 버스 인터페이스(58) 및 디스플레이 인터페이스(54)를 포함한다. 그래픽 서브시스템(40)은 그래픽 메모리(50)를 포함하거나, 또는 이와 통신한다.
그래픽 엔진(42)은, 그래픽 엔진(32)과 마찬가지로, 2차원 그래픽 또는 3차원 그래픽을 렌더링하거나, 비디오를 디코딩하는 등을 할 수 있는 기능 블록이다. 이해되는 바와 같이, 그래픽 서브시스템은 다수의 그래픽 엔진을 포함할 수 있다. 아마도, 그래픽 엔진(42)은 그래픽 엔진(32)에 의해 제공되지 않는 기능들을 간단하게 제공할 수도 있을 것이다.
메모리 제어기(52)는 그래픽 서브시스템(40)이 메모리(50)와 호스트 메모리(14)에 대한 접근 권한을 가질 수 있게 한다. 버스 인터페이스(58)는 그래픽 서브시스템(40)이 버스(20) 상으로 통신할 수 있게 한다.
디스플레이 인터페이스(54)는, 메모리 제어기(52)에 의해, 그래픽 메모리(50)에서 프레임 버퍼를 샘플링하고 비디오 커넥터에 이미지를 제공한다. 이러한 방식으로, 메모리(50)의 프레임 버퍼에서 외부 그래픽 엔진(42)에 의해 렌더링되는 이미지가 디스플레이될 수 있게 된다. 비디오 커넥터는 외부 디스플레이에 직접적으로 연결되거나, 또는 장치(10)의 마더보드에 연결될 수 있고, 여기서 비디오 신호는 통합된 디스플레이 또는 외부 디스플레이를 장치(10)에 부착하기 위한 커넥터에 라우팅될 수 있다. 또한, 디스플레이 인터페이스(54)는 RAMDAC, 싱글-엔드형(single-ended), 또는 차동 트랜스미터(differential transmitter) 등과 같은 디스플레이 장치(32) 상에 디스플레이하기 위해 버퍼 내의 데이터를 변환하는 데에 적절한 어떠한 인터페이스라도 될 수 있다.
설명한 바와 같이, 전력 제어기(60)는 그래픽 서브시스템(40)과 통신하며, 그리고 하나 이상의 디스플레이 인터페이스(54), 메모리 제어기(52), 그래픽 엔진(42), 버스 인터페이스(58) 및 그래픽 메모리(50) 중 각각 또는 일부의 전력 소비를, 클록 및 전압 조절(throttle), 전원 차단, 또는 그렇지 않으면 이들 컴포넌트들의 전부나 일부를 디스에이블시키는 것과 같은 종래의 전력 소비 기술을 이용하여 제어한다. 전력 제어기(60)는 버스(20) 상의 신호들에 의해 또는 다른 방법으로 제어될 수 있으며, 예를 들어 ACPI 표준을 따를 수 있다.
그래픽 서브시스템(30)은 그래픽 서브시스템(40)과 상당히 동일한 방식으로 동작한다. 그러한 것으로서, 그래픽 서브시스템(30)은 호스트 메모리(14) 내 또는 서브시스템(30)에 국한된 메모리 내에 탑재된 프레임 버퍼에 접근하기 위해 메모리 제어기(72)를 사용한다. 이러한 프레임 버퍼는 디스플레이 인터페이스(74)에 의해 샘플링되고, 이미지는 디스플레이에 직접 연결될 수 있는 비디오 출력 커넥터에 제공된다. 경제적인 통합 컴포넌트들을 제공하고자 하는 노력으로, 그래픽 서브시스템(30)은 제한된 기능을 제공한다. 예를 들어, 그래픽 서브시스템(30)의 해상도, 메모리, 그래픽 프로세서 속도, 3차원 그래픽 기능 등은 상대적으로 제한되고, 그래픽 서브시스템(40)의 외장형 그래픽 프로세서(42) 보다 더 느리게 동작할 수 있다.
3차원 그래픽, 게임 그래픽 등과 같은 연산 집중적인 그래픽은 그래픽 서브시스템(40)에 의해 더욱 효과적으로 실행된다. 따라서, 애드온 그래픽 서브시스템(add-on graphics subsystem)(40)을 장치(10) 내에서 사용함으로써, 최종 사용자들은 게임, 컴퓨터 지원 디자인 소프트웨어, 애니메이션 소프트웨어, 렌더링 소프트웨어 등과 같은 그래픽 집중적인 애플리케이션들의 최신의 것들을 체험할 수 있다. 편리하게는, 애드온 그래픽 서브시스템(40)은 최종 사용자에 의해 선택될 수 있고, 필요에 따라 교체되고 현재 상태로 유지될 수 있다. 과거에, 부가적인 그래픽 연산 성능은 워크스테이션 연산 장치 상에서만 이용 가능했다. 이동식 연산 장치 상에서의 확장 슬롯들이 출현하여, 이제 그러한 연산 성능은 랩탑과 같은 휴대용 컴퓨터 소유자들도 이용가능하게 되었다. 물론, 그래픽 서브시스템(40) 상에서 더 높은(또는 다른) 성능의 그래픽 엔진(42)을 사용하게 되면, 장치(10)의 전체적인 전력 소비가 증가하게 된다. 이렇게 증가된 전력 소비는 배터리 전원에 의해 전력 공급을 받는 연산 장치 상에서는 지속가능하지 않을 수 있다.
동시에, 그래픽 엔진(42)을 장착한 애드온 그래픽 서브시스템(40)이 존재하는 경우, 그래픽 서브시스템(30)은 여분의(redundant) 것이 될 수 있다. 예를 들어, 장치(10)에 다수의 물리적인 디스플레이들이 연결되어 있지 않다면, 그래픽 서브시스템(30)은 할 수 있는 역할이 없을 수 있다. 이에 따라, 그래픽 서브시스템(30)은 디스에이블 될 수 있다. 대안적으로, 그래픽 서브시스템(30)의 동작을 제어하는 전력 제어기(70)가 존재하는 경우, 그래픽 서브시스템(30)은 사용되지 않을 때에 저전력 모드에 놓일 수 있다. 또한, 전력 제어기(70)는 그래픽 서브시스템(30)의 부분들을 디스에이블시키거나 연결을 끊거나, 또는 그래픽 서브시스템(30)의 부분들을 클록 또는 전압 조절(throttle) 할 수 있다.
본 발명의 예시적인 실시예들에서, 소프트웨어(200)(도 4)는, 서브시스템(30)이 존재하는 경우, 장치(10)가 하나의 더 높은 전력의 그래픽 서브시스템(40)을 선택적으로 디스에이블시킬 수 있게 한다.
이를 위해, 그리고 도 8에 나타낸 바와 같이, 연산 장치(10)는 스위치(56)를 더 포함한다. 스위치(56)는 제1 및 제2 입력에서 서브시스템(40) 및 서브시스템(30)에 의해 생성된 비디오 신호를 수신한다. 스위치(56)는 멀티플렉서와 같은 어떠한 적절한 비디오 스위치일 수도 있으며, 종래의 비디오 신호 중 하나를 그 비디오 출력 커넥터에서의 두 개의 신호 입력에 제공하도록 동작 가능할 수 있다. 스위치(56)의 입력에서 제공된 비디오 신호는 디지털 신호(이를 테면, LVDS 또는 TMDS 포맷 등)나 아날로그 신호(이를 테면, VGA 포맷)와 같은 종래의 비디오 신호일 수 있다. 스위치(56)가 디지털 및 아날로그 입력 신호 모두를 수신하거나 어느 하나의 출력에 비디오를 제공하도록 설정된다면, 그 스위치(56)는 포맷 변환기를 포함할 수 있다. 또한, 스위치(56)는 디지털 또는 아날로그 디스플레이 장치(32) 중 하나 또는 양자의 연결을 허용하기 위하여 하나 이상의 비디오 출력을 포함할 수 있다.
스위치(56)는 제어 입력(CNTRL)을 더 포함한다. 이 제어 입력은 어느 신호 입력이 스위치(56)의 비디오 출력에 제공되는지를 제어한다. 도시된 실시예에서, 상기 제어 입력은, 장치(10)의 전력 모드의 변경이 요구되는지 또는 바람직한지를 검출 또는 결정하는 것에 응답하여, 범용 입출력(GPIO) 인터페이스(미도시)에 의하여 프로세서(12)에 의해 토글(toggle)된다. 명백해지는 바와 같이, 스위치(56)는, 장치(10)가 저전력 소비 모드에서 동작하는 경우, 그래픽 서브시스템(30)에 의해 생성된 종래의 비디오 신호가 선택되도록 구성된다. 반대로, 장치(10)가 고전력 소비 모드에서 동작하는 경우에는, 고성능의 외부 그래픽 서브시스템(40)에 의해 생성되는 비디오 신호가 디스플레이를 위해 선택된다. 유사하게, 그래픽 서브시스템(40) 또는 그래픽 서브시스템(30)에 제공되는 전력은 감소되거나 또는 디스에이블될 수 있다. 장치(10)가 사용 중인 동안, 이 장치(10)를 재시작할 필요없이(즉, 콜드(Cold)나 웜(Warm) 스타트없이), 스위칭이 동적으로 수행될 수 있다.
이를 달성하기 위해, 연산 장치(10)는 상술한 전력 제어기(60)를 적어도 하나 포함할 수 있다. 도시된 실시예에서, 전력 제어기(60)는 그래픽 서브시스템(40)을 갖는 주변 장치 확장 카드(46)의 일부를 형성한다. 그러나, 전력 제어기(60)는 단지 연산 장치(10)의 마더보드의 일부를 형성하거나, 또는 인터페이스(16)의 일부를 형성할 수 있다. 전력 제어기(60)가 확장 카드(46)의 일부를 형성한다면, 서브시스템(40)의 동작을 제어하기 위한 보다 큰 유연성(flexibility)을 가질 수 있다. 만약 전력 제어기(60)가 연산 장치(10)의 일부를 형성한다면, 그래픽 서브시스템(40)에 대한 전력을 디스에이블하는 기능 만을 가질 수 있다.
시스템 메모리(12) 내의 소프트웨어(200)는 스위치(56)와 전력 제어기(60)를 설정하고 제어하는 데에 이용된다. 이에 따라, 도 9는 본 발명의 예시적인 실시예에서 2개의 전력 소비 모드들 간에서 장치(10)를 스위칭하기 위한 예시적인 소프트웨어 블록(S500)을 도시하는 흐름도이다.
이제, 본 발명의 예시적인 실시예들에서, 장치(10)에 처음 전원이 공급될 때에, 이 장치(10)의 전력 상태가 평가된다. 하기 설명되는 바와 같이, 전력 제어 애플리케이션(201)은 필요에 따라 그래픽 서브시스템(30 및 40) 및 스위치(56)를 설정한다.
본 발명의 예시적인 실시예들에서, 소프트웨어 블록들(S900)은 시스템 메모리(10) 내의 전력 제어 애플리케이션(201)의 제어하에서 프로세서(12)에 의해 수행될 수 있다. 블록들(S900)은 장치(10)가 상태 변경을 거칠 때 마다 수행될 수 있으며, 그래픽 서브시스템들(30 및 40)은 그에 따라 구성되어야 한다. 도시된 바와 같이, 블록(S902)에서, 전력 제어 애플리케이션(201)은 장치(10)가 고전력 소비 모드를 갖는지 아니면 저전력 소비 모드를 갖는 지를 결정한다.
애플리케이션(201)은 어느 그래픽 서브시스템(30 및 40)이 특정 그래픽 전력 상태에 대해 선호되는 장치인지 나타내는 테이블을 유지할 수 있다. 각 사용자 전력 상태는 그래픽 서브시스템(30 및 40)과 그 서브시스템에 대한 대응 상태에 매핑(mapping)된다. 개별적인 그래픽 서브시스템들(30 및 40)에 대한 전력 상태들은 클럭 속도, 메모리 속도, 픽셀 클럭 속도, 렌더링 성능 등과 같은 현재 동작중인 그래픽 서브시스템(30 또는 40)의 동작 파라미터들일 수 있다.
본 예시적인 실시예에서, 고전력 소비 모드는 장치(10)가 AC 전력원(36)으로부터 동작하는 중에 사용될 수 있고, 저전력 소비 모드는 장치(10)가 DC 공급기(38) 방식으로 동작될 때, 상기 DC 전원(38)이 낮을 때 등에 사용될 수 있다. 고전력 소비 모드에서는, 그래픽 서브시스템(40)이 동작중이다. 저전력 소비 모드에서는, 그래픽 서브시스템(30)이 동작중이다.
장치(10)가 고전력 소비 모드를 재시작(또는 고전력 소비 모드로 전환)하려고 하면, 블록들(S904 내지 S910)이 실행된다. 블록(S504)에서, 서브시스템(40)은 이미 완전 동작 모드(full operational mode)가 아니라면, 완전 동작(고전력 소비) 모드에 놓이게 된다. 이는 프로세서(12)에 의해 적절한 신호를 전력 제어기(60)에 제공하는 적합한 드라이버 호출(AMD 또는 ATI 그래픽 서브시스템들에 있어서는 종래의 ATPX ACPI 메쏘드가 사용될 수도 있고, 다른 제조자들의 그래픽 서브시스템들에 있어서는 비슷한 메쏘드들 또는 함수들이 드라이버들을 위하여 사용될 수 있음)에 의해 수행될 수 있다. 다음으로, 블록들(S906)에서 서브시스템(40)이 인에이블된다. 이는 설정 관리자(configuration manager)의 윈도즈 PnP 호출들을 사용하여 서브시스템(40)을 인에이블시킴으로써 수행될 수 있다. 일단 상기 서브시스템이 인에이블되면, 상기 운영 체제는 새로운 장치 이름들을 획득하기 위하여 모든 장치들을 열거할 수 있다. Windows EnumDisplayDevices() 함수는 이러한 목적으로 이용될 수 있다. 이후, 두 장치들 모두를 갖는 확장된 데스크탑이 Windows ChangeDisplaySettingsEX() API 호출을 이용하여 생성될 수 있다. 이제, 애플리케이션(201)은 (예를 들어, WM_DISPLAYMODECHANGE 메시지를 수신함으로써) 다수의 어댑터들이 변경되었음을 알 수 있다. 애플리케이션(201)은 재시작 명령을 발행할 수 있다. 디스플레이들은, ATI/AMD 그래픽 서브시스템들을 위한 드라이버들의 함수인 CWDDEDI를 이용하거나, 다른 제조자들의 그래픽 서브시스템들을 위한 드라이버들의 유사한 함수들을 이용하여 전원이 차단될 수도 있고, 통합 I2C 제어기를 디스에이블시킬 수 있고, 제어 메쏘드 호출을 이용하여 I2C 버퍼를 디스에이블시킬 수 있는데, 이 모든 것은 블록(S906)에서 이루어진다. 블록(S908)에서, 스위치(56)는 그래픽 서브시스템(40)으로부터의 출력을 선택하도록 구성될 수 있는데, 이는 예를 들어 ATI/AMD 그래픽 서브시스템들에 대해서는 ATPX ACPI 메쏘드를 사용하거나, 또는 다른 제조자들의 그래픽 서브시스템들에 대해서는 유사한 함수들을 이용하여 이루어진다. 블록(S910)에서, 새롭게 인에이블된 그래픽 서브시스템(40)은 논리적으로 인에이블되어, 상기 운영 체제의 나머지 부분에 가시적이 된다. 이는 윈도즈 ChangeDisplaySettingsEX() API 호출을 이용하여 이루어질 수 있다. 마찬가지로, 그래픽 서브시스템(30)은 디스플레이된 데스크탑으로부터 상기 서브시스템을 분리함으로써 논리적으로 디스에이블될 수 있다. 이는 윈도즈 ChangeDisplaySettingsEX() API 호출을 이용하여 이루어질 수 있다. 운영 체제의 요청을 받았을 때 통합 디스플레이들을 감추기 위한 추가적인 사설 API (이스케이프) 호출이 드라이버에게 생성될 수 있으며, 이에 의해 상기 디스에이블된 그래픽 서브시스템이 감추어진다.
주목한 바와 같이, 비스타에서는 단지 하나의 그래픽 KMD 만이 동작중일 수 있다. 보통은 두 개의 다른 장치 드라이버들에 의해 제어되는 두 개의 그래픽 서브시스템들(30 및 40)을 지원하기 위해, KMD 프록시 컴포넌트(324)는 두 개의 그래픽 서브시스템들(30 및 40)을 위한 커널 모드 드라이버로서 역할을 수행한다. 마찬가지로, UMD 프록시 컴포넌트들(320 및 322)도 단일 UMD와 같은 역할을 수행한다.
장치(10)가 저전력 소비 모드로 전환하거나 또는 저전력 소비 모드를 재시작하려 할 때, 블록들(S912 내지 S918)이 실행된다. 대체적으로, 그래픽 서브시스템(40)은 그래픽 서브시스템(30)이 인에이블되는 동안 디스에이블되고 저전력 소비 모드에 놓이게 된다. 이를 행하기 위해, 블록들(S912 및 S914)에서 그래픽 서브시스템(30)이 인에이블된다. 여기에서 또한, 이는 블록(S912)에서 그래픽 서브시스템(30)과 연관된 디스플레이를 논리적으로 인에이블시키고, 블록(S914)에서 서브시스템(40)과 연결된 디스플레이들을 논리적으로 디스에이블시킴으로써 수행될 수 있다. 블록들(S912 및 S914)은 전술된 EnumDisplayDevices() 및 ChangeDisplaySettingsEX() 호출들과 같은 적절한 운영 체제 API 호출들에 의해, 또는 하드웨어와의 직접 통신에 의해 수행될 수 있다.
디스플레이가 논리적으로 디스에이블된 후, KMD 컴포넌트들(360 및 362)에 대한 API 호출들은 블록(S918)에서 물리적으로 그래픽 서브시스템(40)을 저전력 모드로 두기 위해 사용될 수 있다. 그러한 것으로서, 프로세서(12)는 적합한 신호를 전력 제어기(60)에 제공하여 그래픽 서브시스템(40)을 저전력 상태에 둔다. 가장 간단한 형태로, 전력 제어기(60)는 그래픽 서브시스템(40) 또는 그래픽 서브시스템(40)의 컴포넌트들에 대한 전력을 차단한다. 대안적으로, 그래픽 서브시스템(40)이 ACPI 명세서에서 규정한 장치 전력 상태들 중 하나와 같은 저전력 수면 모드로 진입하도록, 전력 제어 애플리케이션(201)이 전력 제어기(60)에게 지시할 수 있다. 어떠한 경우이든, 이러한 저전력 소비 모드에서는 전압이 조절되며, 그리고/또는 그래픽 서브시스템(40)의 전부 또는 일부가 전력 차단되며, 그리고/또는 그래픽 서브시스템(40)에 의해 사용되는 선택된 클록들이 늦춰진다.
일단 그래픽 서브시스템(30 및 40) 중 특정한 하나가 논리적으로 그리고 물리적으로 인에이블되면, UMD 프록시 컴포넌트들(320 및 322)과 KMD 프록시 컴포넌트(324)는 현재 동작중인 서브시스템에 대한 표시를 제공받고, 그래픽 서브시스템을 위한 API/DDI 호출들은 전술된 바와 같이 현재 인에이블된 그래픽 서브시스템(30 및 40)에 적절하게 대응되는 상기 UMD/KMD 컴포넌트들(340, 350 및 360 또는 342, 352 및 362)로 라우팅된다.
스위치(56)가 적절하게 설정될 수 있도록 하기 위해, 장치(10)에 대한 BIOS는 사용자로 하여금 어느 장치가 시작시에 동작중이어야 하는지를 선택하게 할 수 있다.
유익하게는, 상기 설명한 바와 같이 스위치(56), 그래픽 서브시스템(40) 및 그래픽 서브시스템(30)을 설정하게 되면, 전력 소비를 줄이며, 장치(10)가 두 개의 그래픽 프로세서들 중 단지 하나에 대해 요구되는 전력을 소비하게 함으로써, 전체적인 에너지 소비를 줄이고 배터리 수명을 보존한다. 예를 들어, 휴대용 컴퓨터들은 통상적으로 배터리로 동작하는 모드(DC 전력)에서 업무상의 여행자들에 의해 사용된다. 이러한 사용자들의 통상적인 사용 형태는 문서 처리, 프레젠테이션 및 이메일 애플리케이션들을 포함할 것이다. 이들 애플리케이션들은 외장형 그래픽 서브시스템(40)에 의해 제공되는 과중한 임무용 그래픽 가속이 필요하지 않다. 제 2(예를 들어, 외장형) 그래픽 서브시스템(40)의 사용에서 낮은 평균 전력을 소비하는 제 1(예를 들어, 통합된) 그래픽 서브시스템(30)의 사용으로 전환하는 것은 전반적인 시스템 성능을 희생하지 않으면서 고성능 그래픽 프로세스와 저전력 소비 간의 균형을 맞추는데 도움을 준다.
도 10은 본 발명의 다른 예시적인 실시예의 연산 장치(10') 일부분에 대한 예시적인 간략화된 블록도들이다. 연산 장치(10')는 연산 장치(10)와 본질적으로 유사하다. 장치(10)의 컴포넌트들에 기능적으로 등가인 장치(10')의 컴포넌트들은 프라임(') 기호로 라벨을 붙였으므로, 상세히 설명되지 않을 것이다. 그러나, 간략히 말하면, 장치(10')는 두 개의 그래픽 서브시스템(30' 및 40')을 포함한다. 또한, 그래픽 서브시스템(30')은 그래픽 엔진(32'), 메모리 제어기(72'), 디스플레이 인터페이스(74') 및 버스 인터페이스(78')를 포함한다. 제2 그래픽 서브시스템(40')은 고속 버스(20')에 의해 그래픽 서브시스템(30')과 통신한다. 그래픽 서브시스템(40')은 자신의 그래픽 엔진(42'), 메모리 제어기(52') 및 디스플레이 인터페이스(54')를 포함한다. 그래픽 서브시스템(40')은 또한 그래픽 메모리(50')와 통신한다. 특히, 장치(10')는 그래픽 서브시스템(30')과 그래픽 서브시스템(40') 중 어느 것이 디스플레이(26')와 상호 연결되는 지를 제어하는 데에 이용되는 스위치를 포함하지 않는다. 대신에, 명백해지는 바와 같이, 서브시스템(40')은 버스(20')를 통해 메모리(14')에 그래픽을 렌더링하도록 되어 있다.
장치(10')의 동작을 제어하는 소프트웨어의 구조는 장치(10)의 경우와 유사하다. 그러나, 장치(10')가 고전력 및 저전력 소비 상태들 사이를 전환할 때에 이 장치(10')의 동작을 제어하는 소프트웨어 부분들은 장치(10)의 것들과 다르다.
구체적으로, 도 11은 장치(10')의 시스템 메모리 내의 소프트웨어의 제어하에서 프로세서(12')에 의해 수행될 수 있는 본 발명의 예시적인 실시예들에 따른 소프트웨어 블록들(S1100)을 도시한다. 여기에서 또한, 블록들(S1100)은 장치(10')가 상태 변경을 거칠 때 마다 수행될 수 있으며, 서브시스템들(30' 및 40')은 그에 따라 구성되어야 한다. 도시된 바와 같이, 블록(S1102)에서, 상기 소프트웨어는 장치(10')가 고전력 소비 모드에 있는지, 아니면 저전력 소비 모드에 있는 지를 결정한다.
장치(10')가 고전력 소비 모드를 재시작(또는 고전력 소비 모드로 전환)하려고 하면, 블록들(S1104 내지 S1110)이 실행된다. 블록(S1104)에서, 그래픽 서브시스템(40')은 이미 완전 동작 모드가 아니라면, 완전 동작(고전력 소비) 모드에 놓이게 된다. 이는 그래픽 서브시스템(40')을 제어하는 드라이버를 통해, 전력 제어기(60')에 적당한 신호를 제공함으로써 수행될 수 있다. 다음으로, 그래픽 서브시스템(40')이 블록들(S1106 및 S1108)에서 인에이블된다. 여기에서 또한, 이는 블록(S1104)에서 그래픽 서브시스템(30')과 연관된 어떠한 상호 연결된 디스플레이를 논리적으로 디스에이블시키고, 블록(S808)에서 그래픽 서브시스템(40')과 연결된 디스플레이를 논리적으로 인에이블시킴으로써 수행될 수 있다. 블록들(S1106 및 S1108)은 전술된 EnumDisplayDevices() 및 ChangeDisplaySettingsEX() 호출들과 같은 적절한 운영 체제 API 호출들에 의해 또는 하드웨어와의 직접 통신에 의해 다시 수행될 수 있다.
특히, 그래픽 서브시스템(40')에는 어떠한 물리적 디스플레이도 연결되지 않는다. (도 4의 장치(10)의) 스위치(56)가 부재하는 경우, 그래픽 서브시스템(40')의 동작을 제어하는 드라이버 소프트웨어는 블록(S1110)에서 연관된 메모리(50') 내부 대신에, 그래픽 서브시스템(30')의 버퍼(14')에서 이미지들을 렌더링하도록 구성된다. 편리하게는, 고속 버스(20)(예를 들어, PCIe 버스로서 구현됨)가 존재하는 경우, 상기 버스에 의해 인에이블되는 전송 속도에 일부 기인하여, 이러한 렌더링은 버스(20)를 통해 가능하다.
물론, 그래픽 서브시스템(30')에 대한 드라이버는 또한, 메모리(14')의 프레임 버퍼에서 그래픽 서브시스템(40')에 의해 렌더링되는 이미지를 상호 연결된 디스플레이(26')에 제공하기 위해, 그래픽 서브시스템(30')의 디스플레이 인터페이스(74')가 메모리(14')의 프레임 버퍼를 샘플링하도록 구성된다. 동시에, 그래픽 서브시스템(30')에 대한 드라이버는 그래픽 서브시스템(30')의 그래픽 엔진(32')이 실질적으로 휴지(dormant) 또는 아이들(idle) 상태로 남아있도록 지시할 수 있다. 이러한 동작 모드는 그래픽 서브시스템(40') 및 그래픽 서브시스템(30')의 동작 중에 있는 블록들에만 음영이 표시되는 상태로, 도 12a에 개략적으로 도시된다.
명백해지는 바와 같이, 도 12a의 실시예에서, 메모리(50') 및 디스플레이 인터페이스(54')는 사용되지 않는다. 그러한 것으로서, 이들 기능 블록들은 비용 절감을 위하여 서브시스템(40')으로부터 제거될 수 있다. 서브시스템(40')이 서브시스템(30')에 의해 제공된 기능을 보충하도록 제조될 수 있으므로, 이러한 그래픽 서브시스템을 제조하는 것은 이익이 될 수 있다. 예를 들어, 서브시스템은 3차원 그래픽 또는 비디오 디코딩 기능들을 제공하는 그래픽 엔진(42')을 제공할 수 있다. 그래픽 엔진(32')은 이러한 기능들을 포함하지 않을 수 있다. 동시에, 그래픽 엔진(32')에 의해 제공되는 2차원 그래픽 기능이 서브시스템(40')에 포함될 필요가 없다. 소비자들은 추가적 기능이 필요한 때에만 그래픽 서브시스템(30')을 순서대로 부가할 수 있을 것이다.
장치(10')가 저전력 소비 모드로 전환하거나 또는 저전력 소비 모드를 재시작하려 할 때, 블록들(S1112 내지 S1118)이 실행된다. 대체적으로, 그래픽 서브시스템(40')은 부분적으로 또는 완전히 디스에이블되고 저전력 소비 모드에 놓이게 되고, 렌더링이 그래픽 서브시스템(30')에 의해 다시 한번 수행된다. 이를 행하기 위해, 블록(S812)에서 그래픽 서브시스템(30')과 연관된 어떠한 상호 연결된 디스플레이라도 인에이블시킬 수 있으며, 블록(S1114)에서 그래픽 서브시스템(40')과 물리적으로 연결된 어떠한 디스플레이라도 논리적으로 디스에이블시킬 수 있다. 다음으로, 그래픽 서브시스템(30')의 동작을 제어하는 드라이버 소프트웨어는 그래픽 서브시스템(30')이 메모리(14')의 이미지를 렌더링하도록 다시 한번 구성된다. 디스플레이 인터페이스(74')는 포트(78')에 상호 연결된 디스플레이(26') 상에 이미지를 제공하도록 메모리(14')를 계속해서 샘플링한다. 물론, 프로세서(12')는 먼저 블록(S818)에서 전력 제어기(60')에 적합한 신호를 제공하여 그래픽 서브시스템(40')을 저전력 상태로 둔다. 가장 간단한 형태로, 전력 제어기(60')는 그래픽 서브시스템(40')에 대하여 전력을 차단하거나 그래픽 서브시스템(40')을 저전력 수면 모드로 만든다. 여기에서 또한, 이러한 저전력 소비 모드에서는, 전압이 조절되며, 그리고/또는 그래픽 서브시스템(40')의 전부 또는 일부가 전력 차단되며, 그리고/또는 그래픽 서브시스템(40')에 의해 사용되는 선택된 클록들이 늦춰진다. 구체적으로, 그래픽 서브시스템의 그래픽 엔진(42')은 아이들 상태 또는 실질적으로 아이들 상태(예를 들어, 느려지거나 디스에이블되거나 전력 차단됨)로 남게 된다. 이러한 동작 모드는 그래픽 서브시스템(40') 및 그래픽 서브시스템(30')의 오직 동작중인 블록들에만 음영이 표시되는 상태로, 도 12b에 개략적으로 도시된다. 비동작중이거나/아이들한 기능 블록들은 전체적으로 디스에이블되거나, 감소된 전압 또는 클록 속도에서 동작될 수 있다.
선택적으로, 그래픽 서브시스템(30')의 부분들은 그래픽 엔진(32')이 사용중이 아닐 때 디스에이블 될 수 있다. 이는 그래픽 서브시스템(40')이 책임하에 이미지를 렌더링을 해야하는 어느 경우라도 GPIO 또는 유사한 회로 방식에 의해 디스에이블되는 하나 이상의 볼티지 아일랜드(voltage island)들에 그래픽 엔진(32') 및 다른 컴포넌트들을 배치함으로써 촉진될 수 있다.
다른 변형들도 또한 명백할 것이다. 예를 들어, 도 12a에 도시된 고전력 모드에 있어서 그래픽 서브시스템(30') 및 그래픽 서브시스템(40') 모두는 메모리(14') 또는 메모리(50')에 렌더링할 수 있다. 이러한 방식으로, 두 개의 그래픽 서브시스템들(30' 및 40')은 각각 메모리(14') 내의 교대적인 프레임을 렌더링하거나 또는 메모리(14') 내의 각각의 프레임의 일부분을 렌더링하면서 동시에 동작할 수 있다.
또 다른 실시예들에서, 추가적인 디스플레이들이 그래픽 서브시스템들(30' 및 40')에 연결됨으로써, 고전력 소비 모드에서 다수의 디스플레이들의 동시적인 사용을 가능하게 한다. 이러한 방식으로, 디스플레이 인터페이스(54)는 제2 디스플레이를 구동하는 데에 이용될 수 있다. 저전력 소비 모드로의 전환 시에, 장치(10')는 도 9b에 도시된 바와 같이 동작하도록 구성될 수 있다.
마찬가지로, 장치(10')(또는 장치(10))는 버스(20')(또는 버스(20))에 연결된 다수의 추가적인 그래픽 서브시스템들을 포함할 수 있으며, 이러한 그래픽 서브시스템들 모두는 고전력 소비 모드에서 동작중일 수 있고, 그래픽 서브시스템(30')의 디스플레이 인터페이스(74')를 통해 그래픽을 렌더링할 수 있다. 저전력 소비 모드로의 전환시, 이들은 디스에이블될 수 있고, 렌더링은 그래픽 서브시스템(30')의 그래픽 엔진(32')에게 남겨질 수 있다.
도 13에 도시된 또 다른 실시예의 경우, 연산 장치(10)는 직접 메모리 접근(direct memory access; 이하 DMA라 칭함) 제어기(90)를 포함할 수 있다. DMA 제어기(90)는 데이터를 메모리(50')에서 메모리(14')로 전송할 수 있다. 이러한 방식으로, 장치(10')의 고전력 소비 모드에서, 그래픽 서브시스템(40')은 메모리(50')에 이미지들을 렌더링할 수 있다. 이러한 렌더링된 이미지들은 이후 DMA 제어기(90)에 의해 메모리(14') 내의 프레임 버퍼로 전송될 수 있다. DMA 제어기(90')는 그래픽 서브시스템(30' 또는 40')의 일부(예를 들어, 그래픽 엔진들(32' 또는 42')의 DMA 엔진들로서)를 형성할 수 있고, 그렇지 않으면 연산 장치(10') 내에 배치될 수 있다. 데이터는 버스(20')를 통해, 또는 그렇지 않으면 직접 메모리(50')에서 메모리(14')로 전송될 수 있다. 디스플레이 인터페이스(74')는 전술된 바와 같이, 디스플레이(26') 상으로 렌더링된 이미지를 제공하기 위해 메모리(14')의 프레임 버퍼를 샘플링하도록 동작을 계속할 것이다. 또한, 고전력 소비 모드인 도 13의 장치(10')의 동작중인 블록들은 도 13에서 음영이 표시되어 도시된다.
물론, 전술된 실시예들은 단지 도시적인 것으로서 제한하는 방식으로 의도된 것이 아니다. 본 발명을 실시하는 상술된 실시예들은 형태, 부분들의 배열, 세부사항들 및 동작 순서에 대하여 다양한 변형의 여지가 있다. 본 발명은 청구범위에 의해 정의되는 범위 내에서 이러한 모든 변경을 포괄하도록 의도된다.
10: 전자 장치
12: 프로세서
14, 50: 메모리
16: 고속 인터페이스
18: 저속 인터페이스
30, 40: 그래픽 서브시스템
60, 70: 전력 제어기

Claims (15)

  1. 그래픽(graphics)을 렌더링(rendering)하도록 동작가능한 제1 그래픽 서브시스템(graphics subsystem)과;
    그래픽을 렌더링하도록 동작가능한 제2 그래픽 서브시스템과;
    상기 제1 그래픽 서브시스템 및 상기 제2 그래픽 서브시스템 중 적어도 하나와 통신하는 적어도 하나의 디스플레이와;
    운영 체제 소프트웨어, 애플리케이션 소프트웨어(application software) 및 드라이버 소프트웨어(driver software)를 실행하는 프로세서를 포함하며,
    상기 드라이버 소프트웨어는, 상기 제1, 2 그래픽 서브시스템의 동작을 각각 제어하기 위한 제1, 2 드라이버 컴포넌트(driver component)와, 프록시 드라이버 컴포넌트(proxy driver component)를 포함하며,
    상기 프록시 드라이버 컴포넌트는 지원되는 드라이버 호출들(driver calls)과 상기 제1 및 제2 드라이버 컴포넌트들의 함수들(functions)과의 사이의 일치(concordance)를 나타내는 데이터 구조를 형성하고, 상기 프록시 드라이버 컴포넌트는 상기 제1 그래픽 서브 시스템과 상기 제2 서브 시스템 중 활성 그래픽 서브 시스템 시스템과 상기 운영 체제 소프트웨어 및 상기 애플리케이션 소프트웨어와 인터페이스 하기 위해 상기 운영 체제 소프트웨어에 단일 드라이버로서 보이며, 상기 프록시 드라이버 컴포넌트는 상기 애플리케이션으로부터 드라이버 호출들을 수신하고, 상기 제1 그래픽 시스템과 상기 제2 그래픽 시스템 중 어느 것이 사용중인지에 따라 상기 수신된 드라이버 호출들을 상기 애플리케이션으로 상기 제1 드라이버 컴포넌트와 상기 제2 드라이버 컴포넌트 중 하나로 라우팅하는 것을 특징으로 하는 전자 장치.
  2. 제 1 항에 있어서,
    상기 프로세서는 상기 프로세서로 하여금 상기 제2 그래픽 서브시스템이 상기 디스플레이 상에 그래픽을 렌더링하는 제1 모드로부터, 상기 제1 그래픽 서브시스템이 상기 디스플레이 상에 그래픽을 렌더링하는 제2 모드로 상기 전자 장치를 전환시키도록 하는 명령어들을 실행시키며, 그리고
    상기 제2 그래픽 서브시스템은 저전력 소비 모드(lower power consumption mode)에 놓이는 것을 특징으로 하는 전자 장치.
  3. 제 1 항에 있어서,
    상기 제1, 2 드라이버 컴포넌트는 상기 프로세서의 사용자 모드(user mode)에서 실행하는 드라이버 컴포넌트들을 포함하는 것을 특징으로 하는 전자 장치.
  4. 제 1 항에 있어서,
    상기 제1, 2 드라이버 컴포넌트는 상기 프로세서의 커널 모드(kernel mode)에서 실행하는 드라이버 컴포넌트들을 포함하는 것을 특징으로 하는 전자 장치.
  5. 제 1 항에 있어서,
    상기 제1, 2 그래픽 서브 시스템 중 어느 것이 사용중인지는 상기 전자 장치의 전력 상태에 따르는 것을 특징으로 하는 전자 장치.
  6. 제 1 항에 있어서,
    상기 프록시 드라이버 컴포넌트는, 상기 제1 및 제2 그래픽 서브 시스템 중에서 어느 것이 사용중인지에 따라, 상기 장치의 운영 체제로부터의 호출들을 상기 제1, 2 드라이버 컴포넌트 중 하나로 라우팅하는 것을 특징으로 하는 전자 장치.
  7. 삭제
  8. 그래픽을 렌더링하도록 동작가능한 제1 그래픽 서브시스템과;
    그래픽을 렌더링하도록 동작가능한 제2 그래픽 서브시스템과;
    상기 제1 그래픽 서브시스템 및 상기 제2 그래픽 서브시스템 모두와 통신하는 디스플레이와; 그리고
    애플리케이션 소프트웨어 및 드라이버 소프트웨어를 실행하는 프로세서를 포함하며,
    여기서, 상기 드라이버 소프트웨어는,
    상기 제1, 2 그래픽 서브시스템의 동작을 각각 제어하기 위한 제1, 2 사용자 모드 드라이버 컴포넌트, 및 상기 제1, 2 그래픽 서브 시스템 중 어느 것이 사용중인지에 따라, 상기 애플리케이션으로부터의 호출들을 상기 제1, 2 사용자 모드 드라이버 컴포넌트들 중 하나로 라우팅시키기 위한 사용자 모드 프록시 드라이버 컴포넌트와; 그리고
    상기 제1, 2 그래픽 서브시스템의 동작을 각각 제어하기 위한 제1, 2 커널 모드 드라이버 컴포넌트, 및 상기 제1, 2 그래픽 서브 시스템 중 어느 것이 사용중인지에 따라, 상기 사용자 모드 드라이버 컴포넌트들 중 하나로부터의 호출들을 상기 제1, 2 커널 모드 드라이버 컴포넌트들 중 하나로 라우팅시키기 위한 커널 모드 프록시 드라이버 컴포넌트를 포함하는 것을 특징으로 하는 전자 장치.
  9. 연산 장치(computing device) 상에서 운영 체제 소프트웨어 및 애플리케이션 소프트웨어(application software)와 관련하여 실행을 위한 드라이버 소프트웨어(driver software)가 저장된 컴퓨터 판독가능한 매체로서,
    상기 연산 장치는 그래픽을 렌더링하도록 동작가능한 제1 그래픽 서브시스템; 그래픽을 렌더링하도록 동작가능한 제2 그래픽 서브시스템; 상기 제1, 2 그래픽 서브시스템 모두와 통신하는 디스플레이; 및 프로세서를 포함하며,
    여기서, 상기 드라이버 소프트웨어는 상기 제1, 2 그래픽 서브시스템의 동작을 각각 제어하는 제 1, 2 드라이버 컴포넌트와, 프록시 드라이버 컴포넌트를 포함하며,
    상기 프록시 드라이버 컴포넌트는 지원되는 드라이버 호출들(driver calls)과 상기 제1, 2 드라이버 컴포넌트들의 함수들(functions)과의 사이의 일치(concordance)를 나타내는 데이터 구조를 형성하고, 상기 프록시 드라이버 컴포넌트는 상기 제1 그래픽 서브 시스템과 상기 제2 서브 시스템 중 활성 그래픽 서브 시스템 시스템과 상기 운영 체제 소프트웨어 및 상기 애플리케이션 소프트웨어와 인터페이스 하기 위해 상기 운영 체제 소프트웨어에 단일 드라이버로서 보이며, 상기 프록시 드라이버 컴포넌트는 상기 애플리케이션으로부터 드라이버 호출들을 수신하고, 상기 제1 그래픽 시스템과 상기 제2 그래픽 시스템 중 어느 것이 사용중인지에 따라 상기 수신된 드라이버 호출들을 상기 애플리케이션으로 상기 제1 드라이버 컴포넌트와 상기 제2 드라이버 컴포넌트 중 하나로 라우팅하는 것을 특징으로 하는 컴퓨터 판독가능한 매체.
  10. 삭제
  11. 제 9 항에 있어서,
    상기 프록시 드라이버 컴포넌트는, 상기 제1, 2 그래픽 서브시스템 중에서 어느 것이 사용중인지에 따라, 상기 연산 장치 상의 운영 체제로부터의 호출들을 상기 제1, 2 드라이버 컴포넌트 중 하나로 라우팅하는 것을 특징으로 하는 컴퓨터 판독가능한 매체.
  12. 제 9 항에 있어서,
    상기 제1, 2 드라이버 컴포넌트는 상기 프로세서의 사용자 모드에서 실행하는 드라이버 컴포넌트를 포함하는 것을 특징으로 하는 컴퓨터 판독가능한 매체.
  13. 제 9 항에 있어서,
    상기 제1, 2 드라이버 컴포넌트는 상기 프로세서의 커널 모드에서 실행하는 드라이버 컴포넌트를 포함하는 것을 특징으로 하는 컴퓨터 판독가능한 매체.
  14. 그래픽을 렌더링하도록 동작가능한 제1, 2 그래픽 서브시스템을 포함하는 전자 장치의 동작 방법으로서,
    지원되는 드라이버 호출들(driver calls)과 상기 제1 및 제2 드라이버 컴포넌트들의 함수들(functions)과의 사이의 일치(concordance)를 나타내는 데이터 구조를 형성하는 단계와;
    프록시 드라이버에서, 상기 전자 장치에서 실행하는 운영 체제 또는 소프트웨어 애플리케이션으로부터 상기 드라이버 호출들을 수신하는 단계와; 그리고
    상기 제1, 2 그래픽 서브시스템 중 어느 것이 사용중인지에 따라, 상기 소프트웨어 애플리케이션으로부터의 상기 드라이버 호출들을, 상기 제1, 2 그래픽 서브시스템의 동작을 각각 제어하기 위한 제1, 2 소프트웨어 드라이버 컴포넌트들중 하나로 라우팅시키는 단계를 포함하는 것을 특징으로 하는 전자 장치의 동작 방법.
  15. 삭제
KR1020107015543A 2007-12-13 2008-12-15 다수의 그래픽 서브시스템 및 감소된 전력 소비 모드들을 구비한 연산 장치를 위한 드라이버 아키텍쳐, 소프트웨어 및 방법 KR101565562B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US1352707P 2007-12-13 2007-12-13
US61/013,527 2007-12-13

Publications (2)

Publication Number Publication Date
KR20100110824A KR20100110824A (ko) 2010-10-13
KR101565562B1 true KR101565562B1 (ko) 2015-11-03

Family

ID=40637775

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020107015543A KR101565562B1 (ko) 2007-12-13 2008-12-15 다수의 그래픽 서브시스템 및 감소된 전력 소비 모드들을 구비한 연산 장치를 위한 드라이버 아키텍쳐, 소프트웨어 및 방법

Country Status (6)

Country Link
US (1) US8487943B2 (ko)
EP (1) EP2243080B1 (ko)
JP (1) JP5427187B2 (ko)
KR (1) KR101565562B1 (ko)
CN (1) CN101978352B (ko)
WO (1) WO2009076671A2 (ko)

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8427496B1 (en) 2005-05-13 2013-04-23 Nvidia Corporation Method and system for implementing compression across a graphics bus interconnect
CN101464785B (zh) * 2007-12-17 2010-12-08 联想(北京)有限公司 基于wddm的屏幕获取方法及带多显示器的计算机系统
US8300056B2 (en) 2008-10-13 2012-10-30 Apple Inc. Seamless display migration
TWI397819B (zh) * 2008-12-31 2013-06-01 Asustek Comp Inc 一種驅動硬體裝置及處理資料之系統及其方法
US9075559B2 (en) 2009-02-27 2015-07-07 Nvidia Corporation Multiple graphics processing unit system and method
US8610731B2 (en) * 2009-04-30 2013-12-17 Microsoft Corporation Dynamic graphics pipeline and in-place rasterization
US9135675B2 (en) 2009-06-15 2015-09-15 Nvidia Corporation Multiple graphics processing unit display synchronization system and method
US8484616B1 (en) * 2009-06-23 2013-07-09 Emc Corporation Universal module model
US9336028B2 (en) * 2009-06-25 2016-05-10 Apple Inc. Virtual graphics device driver
US8838797B2 (en) * 2009-07-10 2014-09-16 Empire Technology Development Llc Dynamic computation allocation
US8558839B1 (en) * 2009-07-24 2013-10-15 Nvidia Corporation Displaying critical system screens in a multiple graphics adapter environment
US8305380B2 (en) * 2009-09-09 2012-11-06 Advanced Micro Devices, Inc. Managing resources to facilitate altering the number of active processors
US8780122B2 (en) * 2009-09-16 2014-07-15 Nvidia Corporation Techniques for transferring graphics data from system memory to a discrete GPU
US20110169844A1 (en) * 2009-09-16 2011-07-14 Nvidia Corporation Content Protection Techniques on Heterogeneous Graphics Processing Units
US20110063309A1 (en) * 2009-09-16 2011-03-17 Nvidia Corporation User interface for co-processing techniques on heterogeneous graphics processing units
US9524138B2 (en) 2009-12-29 2016-12-20 Nvidia Corporation Load balancing in a system with multi-graphics processors and multi-display systems
US9830889B2 (en) 2009-12-31 2017-11-28 Nvidia Corporation Methods and system for artifically and dynamically limiting the display resolution of an application
US8797334B2 (en) 2010-01-06 2014-08-05 Apple Inc. Facilitating efficient switching between graphics-processing units
US8368702B2 (en) 2010-01-06 2013-02-05 Apple Inc. Policy-based switching between graphics-processing units
US8648868B2 (en) 2010-01-06 2014-02-11 Apple Inc. Color correction to facilitate switching between graphics-processing units
JP2011141707A (ja) 2010-01-07 2011-07-21 Sony Corp 情報処理装置、情報処理方法及びプログラム
US20110216078A1 (en) * 2010-03-04 2011-09-08 Paul Blinzer Method, System, and Apparatus for Processing Video and/or Graphics Data Using Multiple Processors Without Losing State Information
US8484495B2 (en) * 2010-03-25 2013-07-09 International Business Machines Corporation Power management in a multi-processor computer system
US20120092351A1 (en) * 2010-10-19 2012-04-19 Apple Inc. Facilitating atomic switching of graphics-processing units
US8806511B2 (en) 2010-11-18 2014-08-12 International Business Machines Corporation Executing a kernel device driver as a user space process
US8924752B1 (en) 2011-04-20 2014-12-30 Apple Inc. Power management for a graphics processing unit or other circuit
US10817043B2 (en) * 2011-07-26 2020-10-27 Nvidia Corporation System and method for entering and exiting sleep mode in a graphics subsystem
US8692833B2 (en) 2011-08-09 2014-04-08 Apple Inc. Low-power GPU states for reducing power consumption
US9047835B2 (en) * 2011-08-17 2015-06-02 Broadcom Corporation Thermal and power aware graphics processing
CN103988190A (zh) * 2011-12-16 2014-08-13 英特尔公司 用于通过外部显示-数据i/o端口来扩展图形处理的方法、设备及系统
US8941671B2 (en) * 2012-01-13 2015-01-27 Microsoft Corporation Para-virtualized domain, hull, and geometry shaders
US8692832B2 (en) * 2012-01-23 2014-04-08 Microsoft Corporation Para-virtualized asymmetric GPU processors
KR101920239B1 (ko) * 2012-03-06 2018-11-20 삼성전자주식회사 파일 시스템 기능을 제공하는 단말기의 장치 및 방법
US9390461B1 (en) * 2012-05-08 2016-07-12 Apple Inc. Graphics hardware mode controls
KR20140013652A (ko) * 2012-07-26 2014-02-05 삼성전자주식회사 시스템 온 칩 및 이를 포함하는 전자 기기
US9591309B2 (en) 2012-12-31 2017-03-07 Nvidia Corporation Progressive lossy memory compression
US9607407B2 (en) 2012-12-31 2017-03-28 Nvidia Corporation Variable-width differential memory compression
US9818379B2 (en) 2013-08-08 2017-11-14 Nvidia Corporation Pixel data transmission over multiple pixel interfaces
US10496152B2 (en) * 2013-09-27 2019-12-03 Intel Corporation Power control techniques for integrated PCIe controllers
US9989980B1 (en) * 2015-08-17 2018-06-05 Amazon Technologies, Inc. System level thermal management
US9967577B2 (en) * 2015-08-31 2018-05-08 Microsoft Technology Licensing, Llc Acceleration interface for video decoding
KR102365678B1 (ko) * 2017-03-29 2022-02-21 삼성전자주식회사 외부 장치를 이용한 화면 출력 방법 및 이를 지원하는 전자 장치
CN108549477B (zh) * 2018-03-28 2020-12-18 联想(北京)有限公司 一种功率调整方法及电子设备
US11726324B2 (en) * 2018-08-31 2023-08-15 Apple Inc. Display system
CN110152291A (zh) * 2018-12-13 2019-08-23 腾讯科技（深圳）有限公司 游戏画面的渲染方法、装置、终端及存储介质
CN110377352B (zh) * 2019-05-20 2022-06-14 中国人民解放军军事科学院战争研究院 基于移动设备云系统的任务处理方法和装置
US11218374B2 (en) * 2019-07-30 2022-01-04 Microsoft Technology Licensing, Llc Discovery and resolution of network connected devices
CN112860428A (zh) * 2019-11-28 2021-05-28 华为技术有限公司 一种高能效的显示处理方法及设备
CN113050998B (zh) * 2021-03-30 2022-08-19 联想(北京)有限公司 电子设备及控制方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003044025A (ja) 2001-07-31 2003-02-14 Toshiba Corp 表示機構
JP2007272267A (ja) 2006-03-30 2007-10-18 Namco Bandai Games Inc 画像生成システム、プログラム及び情報記憶媒体
WO2007140404A2 (en) * 2006-05-30 2007-12-06 Ati Technologies Ulc Device having multiple graphics subsystems and reduced power consumption mode, software and methods

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0588846A (ja) * 1991-09-30 1993-04-09 Toshiba Corp フラツトパネル表示制御システム
JPH1165719A (ja) 1997-08-21 1999-03-09 Toshiba Corp コンピュータおよび画像表示方法
JPH11242604A (ja) * 1997-09-22 1999-09-07 Hitachi Ltd 代理サーバおよび代理サーバプログラムが記録された記録媒体
AU2570399A (en) * 1998-01-30 1999-08-16 3Com Corporation Software architecture for providing low level hardware device drivers from the user mode under multi-tasking operating systems
US6624816B1 (en) 1999-09-10 2003-09-23 Intel Corporation Method and apparatus for scalable image processing
US6760031B1 (en) 1999-12-31 2004-07-06 Intel Corporation Upgrading an integrated graphics subsystem
US7079149B2 (en) 2001-10-09 2006-07-18 Texas Instruments Incorporated System, method, and device for accelerated graphics port linking
US7600222B2 (en) 2002-01-04 2009-10-06 Microsoft Corporation Systems and methods for managing drivers in a computing system
US6864891B2 (en) 2002-01-31 2005-03-08 Hewlett-Packard Development Company L.P. Switching between internal and external display adapters in a portable computer system
US7102645B2 (en) 2003-12-15 2006-09-05 Seiko Epson Corporation Graphics display controller providing enhanced read/write efficiency for interfacing with a RAM-integrated graphics display device
US8176503B2 (en) 2004-01-27 2012-05-08 Hewlett-Packard Development Company, L.P. Device driver selection
US6985152B2 (en) 2004-04-23 2006-01-10 Nvidia Corporation Point-to-point bus bridging without a bridge controller
JP2005316176A (ja) 2004-04-28 2005-11-10 Toshiba Corp 電子機器及び表示制御方法
US7669050B2 (en) * 2004-06-24 2010-02-23 International Business Machines Corporation Method to enable user mode process to operate in a privileged execution mode
US8446417B2 (en) 2004-06-25 2013-05-21 Nvidia Corporation Discrete graphics system unit for housing a GPU
TWM261751U (en) 2004-07-09 2005-04-11 Uniwill Comp Corp Switching display processing architecture for information device
CN100351788C (zh) * 2005-05-18 2007-11-28 大唐移动通信设备有限公司 嵌入式设备的驱动方法
TWI366151B (en) * 2005-10-14 2012-06-11 Via Tech Inc Multiple graphics processor system and methods
US7698597B2 (en) 2006-02-28 2010-04-13 International Business Machines Corporation Method of isolating erroneous software program components
US8555099B2 (en) 2006-05-30 2013-10-08 Ati Technologies Ulc Device having multiple graphics subsystems and reduced power consumption mode, software and methods
US7698579B2 (en) * 2006-08-03 2010-04-13 Apple Inc. Multiplexed graphics architecture for graphics power management

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003044025A (ja) 2001-07-31 2003-02-14 Toshiba Corp 表示機構
JP2007272267A (ja) 2006-03-30 2007-10-18 Namco Bandai Games Inc 画像生成システム、プログラム及び情報記憶媒体
WO2007140404A2 (en) * 2006-05-30 2007-12-06 Ati Technologies Ulc Device having multiple graphics subsystems and reduced power consumption mode, software and methods

Also Published As

Publication number Publication date
JP5427187B2 (ja) 2014-02-26
EP2243080B1 (en) 2016-09-21
KR20100110824A (ko) 2010-10-13
US20090153540A1 (en) 2009-06-18
JP2011509446A (ja) 2011-03-24
WO2009076671A2 (en) 2009-06-18
EP2243080A2 (en) 2010-10-27
CN101978352A (zh) 2011-02-16
CN101978352B (zh) 2017-11-03
WO2009076671A3 (en) 2009-07-30
US8487943B2 (en) 2013-07-16

Similar Documents

Publication Publication Date Title
KR101565562B1 (ko) 다수의 그래픽 서브시스템 및 감소된 전력 소비 모드들을 구비한 연산 장치를 위한 드라이버 아키텍쳐, 소프트웨어 및 방법
US8868945B2 (en) Device having multiple graphics subsystems and reduced power consumption mode, software and methods
KR101545682B1 (ko) 고속의 주변 상호연결 버스를 통한 비디오 렌더링
US20080204460A1 (en) Device having multiple graphics subsystems and reduced power consumption mode, software and methods
US7698579B2 (en) Multiplexed graphics architecture for graphics power management
US8773443B2 (en) Compression for co-processing techniques on heterogeneous graphics processing units
US8199155B2 (en) System, method, and computer program product for saving power in a multi-graphics processor environment
EP2476037B1 (en) Managing resources to facilitate altering the number of active processors
US20090177864A1 (en) Multiprocessor computing systems with heterogeneous processors
KR20080078008A (ko) 디스플레이 제어기의 저 전력소비 프로세서로의 통합
US20160292812A1 (en) Hybrid 2d/3d graphics rendering
US9064322B1 (en) Method and system for steering access to display configuration information in a multi-GPU system
CN117078499B (zh) 双显卡渲染处理方法、装置、计算设备及可读存储介质

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant