DE102011016051A1

DE102011016051A1 - Techniken zum Verwalten von Energieverwendung

Info

Publication number: DE102011016051A1
Application number: DE102011016051A
Authority: DE
Inventors: Rajesh Poornachandran; Michael D. Rosenzweig
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2010-04-08
Filing date: 2011-04-04
Publication date: 2011-10-13
Also published as: US20110249022A1; GB201105959D0; GB2479633B; CN102213996B; GB2479633A; CN102213996A; RU2011113545A; TWI544322B; TW201211754A; RU2481615C2

Abstract

Techniken werden beschrieben, die verwendet werden können, um Zeichnungsanfragen von Anwendungen zu verwalten, basierend teilweise darauf, ob die Zeichnungsanfragen angezeigt werden können, und teilweise auf den Energieverbrauchszuständen von Hardware in dem System. Wenn die Zeichnungsanfrage nicht angezeigt werden kann, dann kann eine Anzahl an Antworten stattfinden. Beispielsweise anstatt Bereitstellen der Zeichnungsanfrage an Hardware stellt der Treiber einen Null Pixel Bereich an die Hardware bereit. In einigen Fällen sichert der Treiber die Zustandsänderungen, die resultiert wären, wenn die Zeichnungsanfrage ausgeführt worden wäre, und die Zeichnungsanfrage wird in einen Puffer gerendert, anstatt dass die Hardware eingeschaltet wird. Andere Beispiele sind hierin beschrieben.

Description

Technisches Gebiet
Der hierin offenbarte Gegenstand bezieht sich im Allgemeinen auf das Einsparen von Energieverbrauch, wenn Grafiken zur Anzeige angefragt werden.
Stand der Technik
In Smartphones und mobilen EDV-Geräte findet Power-Management statt, wenn es für eine spezifizierte Zeitspanne keine Benutzeraktivität gibt, oder wenn es einen anderen externen Faktor gibt, der das Gerät dahingehend anfragt, in einen Niedrigenergiezustand einzutreten. Techniken zum Power-Management überwachen die Geräteverwendung, und versuchen, die Plattform-Subsysteme für die unterstützten Anwendungsfälle in angemessene Niedrigenergiezustände zu versetzen. Um aggressiv Energie einzusparen, schaltet ein Grafiktreiber (oder der Displaytreiber) das Display ab, basierend auf Benutzeraktivität, egal ob die Grafik- und Videohardwareakzeleratorengines in Verwendung sind. Außerdem sind sich Vordergrund- und Hintergrundanwendungen, die in der Plattform laufen, nicht immer über Power-Management vor Ort bewusst, und können fortfahren, Zugriff auf Video- und Grafikakzeleratoren anzufragen. Anwendungen können sich der Tatsache hinsichtlich Niedrigenergiezuständen von Hardware unbewusst sein, da entweder das Betriebssystem (operating system, OS) oder Grafiksystem die Leistungsfähigkeit nicht aufweisen, Anwendungen über Niedrigenergiezustandsübergänge zu benachrichtigen, Anwendungen nicht an Benachrichtigungen interessiert sind und sie sich nicht bei dem Plattform-Power-Manager/Betriebssystem anmelden, oder die Anwendung die Power-Management-Benachrichtigungen ignoriert. Trotz der Tatsache, dass das Display ausgeschaltet wird, können Anwendungen Verwendung von Grafik- und Videoakzeleratoren anfragen, was Grafik- und Videoakzeleratoren anschaltet, und in unnötigem Energieverbrauch resultiert, da angefragte Ausgabe (Bilder und Video) nicht für den Endbenutzer sichtbar sind, und deshalb in verschwendeter Arbeit resultieren.
Kurze Beschreibung der Zeichnungen
Erfindungsgemäße Ausführungsformen werden exemplarisch und in keiner Weise einschränkend in den Zeichnungen veranschaulicht, bei denen gleiche Bezugsnummern zum Verweis auf ähnliche Elemente verwendet werden.
1 zeigt eine Systemarchitektur gemäß verschiedener Ausführungsformen.
2 zeigt eine Interaktion zwischen einem Grafiktreiber, Anwendung, und Power-Manager.
3 stellt einen Prozess dar, in dem ein Treiber die Zielregion veranlasst, Null Pixel groß zu sein, wenn eine Zeichnungsanfrage nicht angezeigt wird.
4 stellt einen Prozess dar, in dem der Grafiktreiber bestimmt, ob die Anwendung, die Zeichnung anfrägt, ebenfalls auf vormals gerenderten Inhalt angewiesen ist.
5 stellt einen beispielhaften Prozess dar, der verwendet werden kann, um zwischen Anwendungen, die Grafikhardware verwenden, und denjenigen, die keine Grafikhardware verwenden, zu unterscheiden, und um Einschalten von Hardware und Anweisungen an Hardware angemessen zu handhaben.
6 stellt ein System dar, in dem ein Power-Manager (power manager, PM) und Anwendungen in Kommunikationen involviert sind, die Herunterfahrzustände von Hardware in der Plattform betreffen.
7 stellt ein System gemäß einer Ausführungsform dar.
Ausführliche Beschreibung
Verweise in dieser Beschreibung auf „eine Ausführungsform” bedeuten, dass ein bestimmtes Merkmal, eine Struktur oder Charakteristikum, das in Verbindung mit der Ausführungsform beschrieben wird, zumindest in einer Ausführungsform der vorliegenden Erfindung enthalten ist. Somit beziehen sich die Verwendungen des Ausdrucks „bei einer Ausführungsform” an verschiedenen Stellen in dieser Beschreibung nicht notwendigerweise immer auf die gleiche Ausführungsform. Darüber hinaus können die bestimmten Merkmale, Strukturen oder Charakteristika in einer oder mehr Ausführungsformen kombiniert werden.
Bei verschiedenen Ausführungsformen verwaltet ein Grafiktreiber oder andere Logik Anfragen von einer Anwendung, um das Hochfahren von Grafikakzelerationshardware zu verringern, wenn ein Display ausgeschaltet wird, oder das Display konfiguriert wird, sodass es keinen Inhalt auf einem Bildschirm anzeigt, wobei die Anwendung Inhalt anfrägt, der zur Anzeige angefragt wird. Der Treiber hält die Zustandsänderungen der Anwendung fest, ruft aber die Grafik- oder Videohardwareengines nicht dahingehend auf, das Ziel zu rendern. Stattdessen werden die Grafik- oder Videohardwareengines aufgerufen, Null Pixel auszugeben.
Bei verschiedenen Ausführungsformen fährt der Treiber Hardware nicht hoch oder schaltet diese nicht ein, um den Zeichenaufruf zu verarbeiten, und die Hardware rendert den Zeichenaufruf nicht. Der Treiber aktualisiert Zustandsänderungen auf eine Art und Weise, wie angefragt von der Anwendung, in den Datenstrukturen des Treibers. Wenn das System hochfährt, benachrichtigt ein Power-Manager (power manager, PM) den Grafikfenstermanager dahingehend, dass er seine Client-Fenster auffrischen soll, und der korrekte Zustand wird erneut gespeichert, basierend auf den Zuständen, gespeichert von dem Treiber. In einigen Fällen benachrichtigt der Power-Manger den Fenstermanager während Systemwiederaufnahme, um alle Fenster der Anwendung aufzufrischen, sodass sie in dem erwarteten Zustand befindlich sind. Sobald das Subsystem aufwacht, benachrichtigt PM alle Anwendungen dahingehend, das aufgewachte Subsystem aufzufrischen, sodass Treiber anschließend nicht dem Zustand von Subsystemen nachgehen muss.
Bei verschiedenen Ausführungsformen, wenn die Anwendung auf vormals gerenderte Zeichnungen zugreift, die aus vormaligen Zeichenaufrufen resultieren, frägt der Treiber das Speichern von zumindest einem Frame an, der vormals zum Rendern angefragt worden ist. Die Anwendung rendert nicht-anzeigbaren Inhalt in einen Puffer, sodass Hardware später ausgeschaltet verbleiben kann (oder in einem Niedrigenergiezustand), und der gepufferte Inhalt in den Puffer der Anwendung übertragen wird. Außerdem hält der Treiber die Zustandsänderungen der Anwendung fest, falls Hardware, die verwendet werden soll, ausgeschaltet (oder in einem Niedrigenergiezustand) verbleiben kann.
Bei verschiedenen Ausführungsformen unterscheidet der Treiber zwischen Anwendungen, deren Anfragen ohne das Einschalten von Hardware ausgeführt werden können, und denjenigen, deren Anfragen unter Verwendung von Akzelerationshardware ausgeführt werden. Bei Anfragen, die ohne Verwendung von Akzelerationshardware ausgeführt werden können, geht der Grafiktreiber Zustandsänderungen nach, veranlasst die Akzelerationshardware jedoch dahingehend nicht, dass sie eingeschaltet werden muss. Die Zentraleinheit (central processing unit, CPU) kann anstatt der Akzeleration für das Rendern von Bildern niedriger Komplexität verwendet werden. In einigen Fällen hängt die Verwendung der Akzelerationshardware oder der CPU von den Eigenschaften des Systems sowie der zu rendernden Arbeitslast ab. In einigen Fällen weisen 3D-Frames sehr kleine Delta in ihren Arbeitslasten zwischen Frames auf. Basierend auf dieser Annahme ist ein Ansatz, die Menge der „nächsten” Arbeitslast basierend auf einer vorherigen Arbeitslast zu schätzen. Das Verwenden der Hardwareengine kann stattfinden, wenn die erwartete Arbeitslast ausreichend groß ist.
Bei verschiedenen Ausführungsformen ermöglicht das System Zwei-Wege-Kommunikation zwischen dem Power-Manager und Anwendungen. Anwendungen fragen an, dass der Power-Manager die Anwendungen benachrichtigt, wenn ein Akzelerationshardwareelement heruntergefahren wird (oder in einem Niedrigenergiezustand ist). Der Power-Manager unterweist die Anwendungen, keine Befehle zum Zeichnen von Bildern an das heruntergefahrene Subsystem oder Grafikakzelerationshardware zu übertragen. Anwendungen benachrichtigen den Power-Manager ebenfalls über die Inaktivität der Anwendung, sodass der Power-Manager die Plattform in einen Niedrigenergiezustand überführen kann, sogar bevor ein Benutzerinaktivitätszeitgeber das Herunterfahren von Akzelerationshardware veranlasst. Dies kann wesentliche Energieeinsparungen verursachen.
In einigen Fällen, wenn ein Bildschirmschoner auf dem Display betrieben wird, werden Hardwareakzeleratoren heruntergefahren. In einigen Fällen kann jedoch ein 3D-Bildschirmschoner beispielsweise weniger Energie verbrauchen, wenn er unter Verwendung von Hardwareakzeleratoren gerendert wird, anstatt unter Verwendung von Software, die von einer CPU ausgeführt wird.
Dementsprechend, wenn ein 3D-Bildschirmschoner verwendet wird, werden Hardwareakzeleratoren verwendet.
1 zeigt eine Systemarchitektur gemäß verschiedener Ausführungsformen. Anwendungen 102 sind Software, die Grafikzeichnungsanfragen nach 2-D-, 3-D-Bildern und Video bereitstellen. Anwendungen 102 können sich der Tatsache unbewusst sein, dass das Display heruntergefahren ist, oder dass ein Bild, das zur Anzeige angefragt ist, nicht angezeigt wird. Anwendungen 102 können sich ebenfalls der Tatsache unbewusst sein, dass die Hardware in dem System heruntergefahren wurde oder in Niedrigenergiezuständen ist.
Grafik-(graphics, GFX)-Laufzeitblock 104 empfängt Befehle höheren Levels, und übersetzt diese Befehle in Befehle niedrigeren Levels für GFX-Treiber 106. GFX-Laufzeitblock 104 stellt APIs bereit, die Anwendungen zum Zeichnen verwenden. GFX-Laufzeitblock 104 verringert die Portierungsbemühung, die für eine Anwendung benötigt wird, um über mehrere OS zu laufen. Grafiklaufzeitblock 104 kann mit Windows, Linux und anderen Betriebssystemen betrieben werden. Beispielsweise kann Grafiklaufzeitblock 104 als eine DirectX- oder OpenGL-kompatible Logik implementiert werden.
GFX-Treiberblock 106 ist eine Softwareschicht, die eine Schnittstelle zwischen Anwendungen 102, Grafiklaufzeit 104, Power-Manager 108 und Hardware-(hardware, HW)-Akzelerationsgeräten ist. Anwendungen stellen Grafikoperationsanfragen an GFX-Treiberblock 106 bereit. In einigen Fällen wissen Anwendungen nicht, dass Hardware ausgeschaltet ist, oder wissen, dass angefragte Zeichnungen nicht sichtbar sein werden, wenn sie z. B. von einem anderen Objekt verdeckt werden, oder wenn ein Bildschirmschoner betrieben wird. GFX-Treiberblock 106 steuert das Rendern von Bildern und Video sowie Hardware, die die Anzeige von Bildern und Video antreibt. GFX-Treiberblock 106 übersetzt die Laufzeitanfragen der Anwendung in Hardwarebefehle. In einigen Fällen schaltet GFX-Treiberblock 106 die Hardware ein, um die Anfrage auszuführen. In einigen Fällen interagiert GFX-Treiberblock 106 mit PM 108, um die Plattformhardware in Niedrigenergiezustand anzutreiben. Das Folgende stellt z. B. beispielhafte Energieverwendungszustände bereit:
Gerätespezifische Niedrigenergiezustände für jegliche GFX-HW oder Video-HW oder Display-HW:

D1:

Subsystem vollständig AUSGESCHALTET.

D0:

Subsystem in vollständig betriebsfähigem Modus (AN)

D0il:

Subsystem AN mit Taktschaltung

D0i3:

Subsystem AN mit Energieschaltung

Systemlevelschlafzustände (Sx oder S0ix) und beinhaltend alle Plattform-Subsysteme:

S0:

Plattform ist AN, und alle Subsysteme sind in voll leistungsfähigem Zustand.

S0i1:

Aktives Standby/AOAC-(Always-ON-Always-Connected)-Standby; verwendet während kurzer Leerlaufzeiträumen (Benutzer verwendet das Gerät interaktiv).

S0i2:

Aktives Standby; verwendet während erweiterter Leerlaufzeiträumen (Benutzer verwendet das Gerät passiv).

S0i3:

Schlafzustand; Benutzer verwendet das Gerät nicht.

S3:

Stromsparzustand.

S4:

Ruhezustand.

S5:

Vollständig AUSGESCHALTET.

Power-Manager-(power manager, PM)-Block 108 verwaltet Hardwareenergieverbrauch in der Plattform. Wenn beispielsweise eine Zeitspanne abläuft, in der das Display nicht verwendet wird, oder wenn es keine Benutzerinteraktion gibt, fährt PM-Block 108 eine oder mehr von Display-Hardware 110, Videohardware 112, und Grafik-(graphics, GFX)-Hardware 114 herunter. Außerdem kann PM-Block 108 das Display herunterfahren, oder Anzeige eines Bildschirmschoners anfragen. Das Herunterfahren kann das Verringern von Energieverbrauch der Hardware gemäß der Dx-, D0x-, Sx- oder SiOx-Zustände umfassen, die vorstehend beschrieben wurden.
Video-HW-Block 112 kann Videocodierungs- und Videodecodierungshardwareengines gemäß anwendbarer Videokomprimierungs- und -dekomprimierungsstandards beinhalten.
Beispielsweise kann Video-HW-Block 112 Komprimierung und Dekomprimierung gemäß jeglichem MPEG-2-, MPEG-4-, H.263-, H.264-, und dem aufkommenden H.265-Standard bereitstellen. GFX-HW-Block 114 kann 2D- oder 3D-Grafikakzeleratorhardware sein. Beispielsweise kann GFX-HW-Block 114 2D- oder 3D-Grafikakzeleratorhardware für DirectX- oder OpenGL-Grafikpipelines sein. Display-Hardware-(hardware, HW)-Block 110 empfängt Inhalt, der von Video-HW-Block 112 oder GFX-HW-Block 114 generiert wird, und formatiert den Inhalt zur Anzeige auf einem Panel. Jeder der Blöcke 110–114 ist in der Lage, in heruntergefahrene oder verringerte Energiemodi einzutreten.
2 zeigt eine Interaktion zwischen einem GFX-Treiber, Anwendung, und PM. Nachdem ausreichende Benutzerinaktivitat erkannt wurde, versetzt PM eine oder mehr von Display-, Video- und GFX-Hardware in Niedrigenergiezustände, indem er Stromsparanfragen ausgibt. PM gibt eine Stromsparanfrage an GFX-Treiber aus, um Strom für jede Insel zu verringern, die nicht verwendet wird. Ein Niedrigenergiezustand kann jeder von Dx-, D0x-, Sx- und SiOx-Zuständen sein, die vorstehend beschrieben wurden. Beispielsweise kann erkannte Benutzerinaktivität keine Benutzerinteraktion mit einem System für eine Zeitspanne beinhalten, wie z. B. dem Sensorbildschirm, der Tastatur, Maus, oder Scroll-Gerät des Systems.
GFX-Treiber antwortet auf die Stromsparanfrage indem er bestimmt, ob unbenutzte GFX-, Video- oder Display-Hardware ausgeschaltet wird. GFX-Treiber gibt einen BUSY-Indikator an den PM für das spezifische Hardware-Gerät (d. h. „Insel”) zurück, für das ein Stromsparen angefragt worden ist, wobei das Hardware-Gerät allerdings in Verwendung war. Wenn der PM einen BUSY-Indikator empfängt, versucht der PM erneut, Strom an das spezifische Hardware-Gerät zu einem späteren Zeitpunkt zu sparen. Wenn das spezifische Hardware-Gerät nicht in Verwendung ist, wenn eine Stromsparanfrage empfangen wird, fährt der PM die Insel zu einem Niedrigenergieverbrauchszustand herunter. In einigen Fällen fährt zumindest der GFX-Treiber die Display-Insel herunter, sogar wenn andere HW-Akzeleratoren beschäftigt sind, um Energieverbrauch zu verringern.
In diesem Beispiel wissen die Anwendungen nichts über den Plattformzustand, und generieren Befehle für die GFX-/Videohardware, sogar wenn die Möglichkeit besteht, dass das Display abgeschaltet ist, oder die Anfrage ein nicht-anzeigbares Bild rendert. In Antwort auf den Empfang einer Grafik-Hardware-Aktivitätsanfrage von einer Anwendung generieren Grafiklaufzeit und der Grafiktreiber Befehle für die Hardware. Der PM hat Strom jedoch an zumindest ein Hardware-Gerät in der Plattform verringert. Anwendungen interagieren mit der GFX-Laufzeit und dem GFX-Treiber, um die Befehle an die Plattform zu generieren. Bei den derzeitigen Implementierungen schaltet der GFX-Treiber die GFX-/Videohardware ein, um diese Befehle zu verarbeiten, was in unnötigem Energieverbrauch resultiert, wenn der Inhalt nicht-anzeigbar ist.
3 stellt einen Prozess dar, in dem ein Treiber die Zielregion veranlasst, Null Pixel groß zu sein, wenn eine Zeichnungsanfrage nicht angezeigt wird. Bei 302 fragt eine Anwendung das Zeichnen von Pixeln auf einem Display an. Ein Zeichenaufruf könnte DrawRectangle, DrawWindow, etc. sein. Grafiklaufzeit könnte den Zeichenaufruf in Dreiecke mit angemessenen Eckpunkten übersetzen. Bei 304 generiert Grafiklaufzeit Befehle für Hardware, um die Anfrage von der Anwendung auszuführen. Bei 306 bestimmt Grafiktreiber, ob die angefragte Zeichnung nicht-anzeigbar ist. Das Display kann beispielsweise in Niedrigenergiemodus sein oder die Zeichnung kann von einem Bildschirmschoner oder anderem Bild oder Video verdeckt sein. Das Display kann von einem Power-Manager oder anderer Logik abgeschaltet worden sein. Die Zeichnungsanfrage kann nicht-anzeigbar sein, wenn sie von einem anderen Bild vollständig verdeckt ist. Wenn die angefragte Zeichnung nicht-anzeigbar ist, dann bestimmt bei Block 308 der GFX-Treiber, ob die Hardware, die die angefragte Zeichnung rendern soll, ausgeschaltet oder in Niedrigenergiemodus ist.
Wenn die Hardware ausgeschaltet oder in einem Niedrigenergiemodus ist, dann wird die Hardware eingeschaltet (Block 310), wobei allerdings das Renderziel von der Hardware auf Null Pixel eingestellt wird (Block 312), sodass keine Pixel von der Hardware an die Display-Hardware ausgegeben werden (Block 314). Das Einschalten der Hardware, obwohl das Bild nicht-anzeigbar ist, hilft dabei, das aktuelle Bild und die Zustandsinformationen beizubehalten und aktuell zu halten, wenn das Display wieder angeschaltet wird. Dies kann Energieverbrauch von der Insel einsparen, da die Insel nicht viel Arbeit ausführt, obwohl die Insel eingeschaltet ist. In einigen Fällen kann Null Pixel Renderziel von Software ausgegeben werden, die von einer Zentraleinheit ausgeführt wird, um das ordentliche Zustandsmanagement des Grafik-Subsystems für die Client-Anwendung aufrechtzuerhalten.
Bei einigen Ausführungsformen beinhaltet eine Videohardwareengine sowohl Videocodierungs- als auch -decodierungshardwareblöcke. Bei einigen Ausführungsformen können die Videocodierungs- und -decodierungshardwareblöcke leistungsverwaltet werden. In einigen Fällen kann ein Null Pixel Ziel als eine Eingabe in einen hochgefahrenen Videocodierungshardwareblock oder -decodierungshardwareblock bereitgestellt werden. In einigen Fällen verwenden Videocodierer und -decodierer den vorherigen Frame als eine Referenz, um den nächsten Frame zu codieren oder zu decodieren. Dementsprechend kann das Null Pixel Ziel nicht anwendbar oder leistungseffizient für Videocodierungs- oder -decodierungsoperation sein, da es den Inhalt des vorherigen Frames verwenden kann. Daher können keine Null Pixel an Videocodierungs- oder -decodierungsblock bereitgestellt werden, wenn es irgendwelche sichtbaren Artefakte verursacht.
Bei einigen Ausführungsformen kann anstatt eines Null Pixel Renderziels ein Viertel oder ein Sechzehntel der spezifizierten Auflösung gerendert werden, um die Arbeitslast des Renderns dramatisch zu verringern. Die Auflösung kann von anderen Brüchen in anderen Mengen, wie z. B. ein Halb, verringert werden.
Wenn die Zeichnung anzeigbar ist oder wenn die angefragte Hardware eingeschaltet wird, werden die Befehle der Hardware vorgelegt (Block 314).
In einigen Fällen kann ein Benutzer GFX-Treibereinstellungen für eine bestimmte Anwendung aufheben. Bei einigen Anwendungen wird der Prozess von 3 nicht angewendet, und stattdessen wird der Prozess von 2 verwendet.
Einige Anwendungen können es nicht tolerieren, dass Null Pixel gerendert werden, wie in dem Prozess von 3. Beispielsweise lesen einige Anwendungen gerenderten Inhalt zurück, und führen Aktionen aus, indem sie den vormals gerenderten Inhalt verwenden, egal ob der zu rendernde Inhalt von der gleichen Anwendung oder einer anderen Anwendung angefragt wurde. Beispielsweise generieren einige Anwendungen Inhalt, basierend auf vormals gerendertem Inhalt. 4 stellt einen Prozess dar, der eine Variation des Prozesses von 3 ist. In dem Prozess von 4 bestimmt bei Block 402 der Grafiktreiber, ob die Anwendung, die die Zeichnung anfrägt, ebenfalls auf vormals gerenderten Inhalt angewiesen ist. Allgemeiner ausgedrückt, wird bestimmt, ob die Anwendung vormals gerenderten Inhalt liest. Vormals gerenderter Inhalt kann Off-Screen-Inhalt oder Inhalt, der nicht-anzeigbar war, weil er von einem anderen angezeigten Inhalt verdeckt worden war, beinhalten. Beispielsweise identifiziert ein Prozessidentifikator einer Anwendung eine Anwendung, die vormals gerenderten Inhalt liest. Wenn beispielsweise diese Anwendung Funktion glReadPixels verwendet, dann versucht die Anwendung, vormals gerenderten Inhalt zu lesen. in einigen Fällen prüft der Treiber, ob die Anwendung oder der Pixel-Shader auf den gerenderten Inhalt in einem vorherigen Frame zugegriffen hat, um zu bestimmen, ob die Anwendung auf vormals gerenderten Inhalt zu greift.
Wenn die Anwendung vormals gerenderten Inhalt liest, dann ermöglicht der GFX-Treiber in Block 404 das Stattfinden der Zustandsänderungen in den Datenstrukturen des GFX-Treibers, die von der Anwendung angefragt wurden. Beispielsweise können Zustandsänderungen das Erleuchten eines Frames, Erleuchten einer Textur, nächster Befehl oder nächste Ausführung für Hardware, und andere Zustände beinhalten. Außerdem erlaubt in Block 406 es der GFX-Treiber der Anwendung, Off-Screen-Inhalt in einen Puffer zu rendern. Beispielsweise können 0-N-Frames gepuffert werden, wobei N eine Ganzzahl ≥ 1 ist. Eine Anwendung kann vormals gerenderten Inhalt aus dem Puffer zurücklesen.
In einigen Fällen kann softwareimplementierte Grafikverarbeitung stattfinden, um nicht-anzeigbaren Inhalt in einen Puffer zu rendern, und die Hardware wird nicht eingeschaltet. In einigen Fällen wird Hardware eingeschaltet, wenn Grafikverarbeitung stattfinden soll, und die verarbeiteten Items werden in dem Puffer gespeichert. Die eingeschaltete Hardware wird ausgeschaltet (oder tritt in Niedrigenergiemodus ein), nachdem die gerenderte Zeichnung in dem Puffer gespeichert worden ist (Block 408). Zum Ausgleich würde softwareimplementierte Grafikverarbeitung die CPU anstelle eines Grafikprozessors (graphics processing unit, GPU) verwenden, und kann in höherem Energieverbrauch resultieren, als das Einschalten von GPU-Hardware.
Anschließend kann die Anwendung auf das vormals gerenderte Bild zugreifen, indem sie eine Kopieroperation von dem Puffer in einen Speicherpuffer verwendet, der von der Anwendung verwendet wird, ohne die Grafikhardware einzuschalten.
Wenn die Anwendung keinen vormals gerenderten Inhalt liest, ermöglicht der GFX-Treiber es der Hardware in Block 410 eingeschaltet zu werden (oder vollständig hochgefahren zu werden). Wenn die Zeichnungsanfrage anzeigbar ist, ermöglicht der GFX-Treiber es der Hardware, die angefragten Aktionen auszuführen. Wenn die Zeichnungsanfrage nicht-anzeigbar ist, gibt GFX-Treiber ein Null Pixel Ziel an die eingeschaltete Hardware aus, wie in dem Prozess von 3. In einigen Fällen, obwohl nicht dargestellt, wenn die Zeichnungsanfrage nicht-anzeigbar ist, gibt GFX-Treiber ein zu renderndes Null Pixel Ziel aus, indem er eine CPU verwendet, ohne die Hardware einzuschalten.
In einigen Fällen kann ein Benutzer GFX-Treibereinstellungen für eine bestimmte Anwendung aufheben. Bei einigen Anwendungen wird der Prozess von 4 nicht angewendet, und stattdessen wird der Prozess von 2 verwendet.
5 stellt einen beispielhaften Prozess dar, der verwendet werden kann, um zwischen Anwendungen, die Grafikhardware verwenden, und denjenigen, die keine Grafikhardware verwenden, zu unterscheiden, und um Einschalten von Hardware und Anweisungen an Hardware angemessen zu handhaben.
Wenn eine angefragte Zeichnung nicht-anzeigbar ist (Block 306), und wenn die Hardware, die die angefragte Zeichnung verarbeiten soll, ausgeschaltet ist (Block 502), dann wird bestimmt, ob die Anfrage gehandhabt werden kann, während die Hardware ausgeschaltet oder in einem Niedrigenergiemodus befindlich ist (Block 504). Ein Niedrigenergiemodus kann jeder von Dx-, D0x-, Sx- und SiOx-Zuständen sein, die vorstehend beschrieben wurden. Beispielsweise kann die Hardware für eine einfache Kopieroperation oder Grafikverarbeitung, ausgeführt von Software, ausgeschaltet oder in einem Niedrigenergiemodus verbleiben. In anderen Fällen kann Hardware jedoch eingeschaltet werden. Um beispielsweise die Zeichnungsanfrage auszuführen, kann es effizienter sein, von dem Standpunkt des Energieverbrauchs, die Hardware hochzufahren. in einigen Fällen kann die Zeichnungsanfrage Hardware verwenden, sodass die Hardware hochgefahren wird.
Wenn die Anfrage gehandhabt werden kann, ohne Hardware einzuschalten (Block 504), dann werden die Zustandsinformationen des GFX-Treibers aktualisiert, zu demjenigen, was stattfinden würde, wenn die Zeichnungsanfrage ausgeführt geworden wäre, aber ohne die Hardware einzuschalten (Block 506).
Wenn die angefragte Hardware bereits eingeschaltet wurde (Block 502), oder die Anfrage nicht gehandhabt werden kann, ohne die Hardware hochzufahren (Block 504), dann wird das Renderziel auf Null mal Null (0×0) Pixel eingestellt (Blöcke 508 und 510). In einigen Fällen kann Null Pixel Renderziel von Software ausgegeben werden, die von einer GPU ausgeführt wird, ohne die Hardware einzuschalten.
Wenn die Zeichnung anzeigbar ist, wird der Befehl der Hardware zum Rendern vorgelegt (Block 510).
In einigen Fällen kann ein Benutzer GFX-Treibereinstellungen für eine bestimmte Anwendung aufheben. Bei einigen Anwendungen wird der Prozess von 5 nicht angewendet, und stattdessen wird der Prozess von 2 verwendet.
6 stellt ein System dar, in dem ein Power-Manager (power manager, PM) und Anwendungen in Kommunikationen involviert sind, die Herunterfahrzustände von Hardware in der Plattform betreffen. PM gibt Benachrichtigungen über Plattformleistungsänderungen an interessierte leistungsbewusste Anwendungen für deren Zusammenarbeit an Anwendungen aus. Wenn Anwendungen die Benachrichtigung von PM über Leistungsänderung der Plattform empfangen, können Anwendungen zusammenarbeiten, indem sie ihre Zeichnungsoperationen stoppen. Leistungsbewusste Anwendungen benachrichtigen den PM über ihre Inaktivität, sodass der PM entscheiden kann, welche Hardware heruntergefahren wird. Von den Benachrichtigungen, die von den Anwendungen empfangen wurden, kann PM den HW-Akzelerator zuordnen, der von der Anwendung verwendet wird (z. B. GFX oder Video), und verringert dementsprechend Leistung der HW, wenn keine andere Anwendung/Entität die HW verwendet.
PM frägt verringerte Leistung eines Hardwareakzelerators an, indem er mit dem GFX-Treiber interagiert. In Antwort auf die Inaktivitätsbenachrichtigungen der Anwendung kann PM Hardwareakzeleratoren in das Energiesparen überführen, sogar bevor Benutzterinaktivität erkannt wird. Leistungsbewusste Grafiklaufzeit arbeitet mit PM zusammen, und verringert Hardwareanfragen an Treiber. GFX-Laufzeit kann all die Anwendungsanfragen abbrechen. In einigen Fällen lehnt GFX-Laufzeit Anwendungsanfragen ab, indem sie antwortet, dass eine Plattform nicht zum Verarbeiten der Anfragen bereit ist. Die GFX-Laufzeit kann die Anwendung informieren, dass sie keine weiteren Befehle generiert, die an Hardwareakzeleratoren gerichtet sind. Während eines Hochfahrens kann PM den Fenstermanager anfragen, eine Auffrischung auszuführen, sodass Anwendungen sich hinsichtlich der erwarteten Zustände auffrischen können.
7 stellt ein System gemäß einer Ausführungsform dar. System 700 kann Host-System 702 und Display 722 beinhalten. Computersystem 700 kann in einem Handheld-PC, Mobiltelefon, einer Set-Top-Box oder jedem EDV-Gerät implementiert sein. Host-System 702 kann Chipsatz 705, Prozessor 710, Host-Speicher 712, Speicher 714, Grafik-Subsystem 715 und Funkgerät 720 beinhalten. Chipsatz 705 kann Interkommunikation zwischen Prozessor 710, Host-Speicher 712, Speicher 714, Grafik-Subsystem 715 und Funkgerät 720 bereitstellen. Beispielsweise kann Chipsatz 705 einen Speicheradapter (nicht dargestellt) beinhalten, der in der Lage ist, Interkommunikation mit Speicher 714 bereitzustellen. Beispielsweise kann der Speicheradapter in der Lage sein, mit Speicher 714 gemäß irgendeinem der folgenden Protokolle zu kommunizieren: Small Computer Systems Interface (SCSI), Fibre Channel (FC) und/oder Serial Advanced Technology Attachment (S-ATA).
Bei verschiedenen Ausführungsformen kann Prozessor 710 Energieverbrauch von Komponenten in Grafik-Subsystem gemäß hierin beschriebener Techniken regulieren.
Prozessor 710 kann als CISC-(Complex Instruction Set Computer)- oder RISC-(Reduced Instruction Set Computer)-Prozessor, Mehrkernprozessor oder jeder andere Mikroprozessor oder Zentraleinheit implementiert sein.
Host-Speicher 712 kann als ein flüchtiges Speichergerät implementiert sein, u. a. ein Direktzugriffsspeicher (Random Access Memory, RAM), dynamischer Direktzugriffsspeicher (Dynamic Random Access Memory, DRAM) oder statischer RAM (Static RAM, SRAM). Speicher 714 kann als ein Permanentspeichergerät implementiert sein, u. a. ein magnetisches Diskettenlaufwerk, optisches Diskettenlaufwerk, Bandlaufwerk, ein internes Speichergerät, ein angeschlossenes Speichergerät, Flash-Memory, batteriegepufferter SDRAM (synchroner DRAM, synchronous DRAM) und/oder ein Speichergerät, auf das über ein Netzwerk zugegriffen werden kann.
Grafik-Subsystem 715 kann Verarbeiten von Bildern, wie z. B. Standbildern oder Videos, zur Anzeige ausführen. Eine analoge oder digitale Schnittstelle kann verwendet werden, um Grafik-Subsystem 715 und Display 722 kommunikativ zu koppeln. Beispielsweise kann die Schnittstelle irgendeine einer High-Definition Multimediaschnittstelle, ein DisplayPort, eine drahtlose HDMI und/oder drahtlose HD konforme Techniken sein. Grafik-Subsystem 715 kann in Prozessor 710 oder Chipsatz 705 integriert sein. Grafik-Subsystem 715 kann eine eigenständige Karte sein, die kommunikativ mit Chipsatz 705 gekoppelt ist.
Funkgerät 720 kann ein oder mehr Funkgeräte beinhalten, die in der Lage sind, Signale gemäß anwendbarer Drahtlosstandards zu übertragen und zu empfangen, u. a. irgendeine Version von IEEE 802.11 und IEEE 802.16.
Obwohl nicht dargestellt, kann System 700 Zugriff auf Eingabegeräte beinhalten, wie z. B. ein Sensorbildschirm, Maus und Kamera.
Die hierin beschriebenen Grafik- und/oder Videoverarbeitungs-Techniken können in verschiedenen Hardware-Architekturen implementiert werden. Beispielsweise kann Grafk- und/oder Videofunktionalität innerhalb eines Chipsatzes integriert sein. Alternativ kann ein separater Grafik- und/oder Videoprozessor verwendet werden. Als noch eine weitere Ausführungsform können die Grafik- und/oder Videofunktionen durch einen Universalprozessor, einschließlich ein Mehrkernprozessor, implementiert werden. Bei einer weiteren Ausführungsform können die Funktionen in einem Unterhaltungselektronikgerät implementiert sein.
Ausführungsformen der vorliegenden Erfindung können als irgendeine Form oder eine Kombination der Folgenden implementiert sein: ein oder mehr Mikrochips oder integrierte Schaltungen, die mittels eines Motherboards verbunden sind, fest verdrahtete Logik, von einem Speichergerät gespeicherte und von einem Mikroprozessor ausgeführte Software, Firmware, ein anwendungsspezifischer integrierter Schaltkreis (application specific integrated circuit, ASIC) und/oder ein Field Programmable Gate Array (FPGA). Der Begriff „Logik” kann beispielsweise Software oder Hardware und/oder Kombinationen von Software und Hardware beinhalten.
Ausführungsformen der vorliegenden Erfindung können beispielsweise als ein Computerprogramm-Produkt bereitgestellt sein, das ein oder mehr maschinenlesbare Medien mit darauf gespeicherten maschinenausführbaren Befehlen beinhalten kann, die, wenn sie von einer oder mehr Maschinen, wie z. B. einem Computer, einem Netzwerk von Computern oder anderen elektronischen Geräten ausgeführt werden, dazu führen können, dass die eine oder die mehreren Maschinen Operationen in Übereinstimmung mit Ausführungsformen der vorliegenden Erfindung ausführen. Ein maschinenlesbares Medium kann beinhalten, ist aber nicht beschränkt auf, Disketten, optische Disks, CD-ROMs (Compact Disc-Read Only Memories), magnetooptische Disks, ROMs (Read Only Memories), RAMs (Random Access Memories), EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetische oder optische Karten, Flash-Memory oder andere Art von Medien/maschinenlesbares Medium, das zum Speichern maschinenausführbarer Befehle geeignet ist.
Die Zeichnungen und die vorstehende Beschreibung gaben Beispiele der vorliegenden Erfindung. Obwohl sie als eine Anzahl ganz verschiedener funktionaler Objekte dargestellt sind, ist es für Fachleute selbstverständlich, dass ein oder mehr solcher Elemente sehr wohl zu einzelnen funktionalen Elementen kombiniert werden können. Alternativ können bestimmte Elemente in mehrere funktionale Elemente geteilt werden. Elemente aus einer Ausführungsform können einer weiteren Ausführungsform hinzugefügt werden. Beispielsweise können hierin beschriebene Reihenfolgen von Prozessen verändert werden und sind nicht auf die hierin beschriebene Art und Weise beschränkt. Außerdem müssen die Handlungen eines jeden Ablaufdiagramms weder in der gezeigten Reihenfolge implementiert sein, noch müssen alle Vorgänge unbedingt ausgeführt werden. Ebenfalls können diejenigen Vorgänge, die nicht von anderen Vorgängen abhängen, parallel mit den anderen Vorgängen ausgeführt werden. Der Umfang der vorliegenden Erfindung ist jedoch keineswegs durch diese spezifischen Beispiele beschränkt. Zahlreiche Variationen, entweder ausdrücklich in der Beschreibung gegeben oder nicht, wie z. B. Unterschiede in Struktur, Abmessung und Verwendung von Material, sind möglich. Der erfindungsgemäße Umfang ist zumindest so breit, wie von den folgenden Ansprüchen gegeben.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

IEEE 802.11 [0053]
IEEE 802.16 [0053]

Claims

Computerimplementiertes Verfahren, umfassend: Empfangen einer Zeichnungsanfrage; Bestimmen, ob die Zeichnungsanfrage keine anzeigbare Zeichnungsanfrage beinhaltet; Selektives Modifizieren der Zeichnungsanfrage in Antwort auf eine Bestimmung, dass die Zeichnungsanfrage keine anzeigbare Zeichnungsanfrage beinhaltet; und Ausgeben der Zeichnungsanfrage.
Verfahren nach Anspruch 1, wobei das selektive Modifizieren der Zeichnungsanfrage das selektive Verringern einer Anzahl an Pixeln der Zeichnungsanfrage umfasst.
Verfahren nach Anspruch 2, wobei das selektive Verringern einer Anzahl an Pixeln der Zeichnungsanfrage das Einstellen von Pixel-Dimensionen auf Null mal Null umfasst, und weiter das Anfragen eines Einschaltens von Zeichnungsakzelerationshardware in Antwort auf die Anfrage umfasst.
Verfahren nach Anspruch 2, wobei das selektive Verringern einer Anzahl an Pixeln der Zeichnungsanfrage das Einstellen von Pixel-Dimensionen auf einen Bruchteil von Dimensionen der Pixel der Zeichnungsanfrage umfasst, wobei der Bruchteil weniger als Eins ist.
Verfahren nach Anspruch 1, wobei das selektive Modifizieren der Zeichnungsanfrage umfasst: Bestimmen, ob ein Ausgeber der Zeichnungsanfrage vormals gerenderte Grafiken liest; Bestimmen eines Zustand, der aus dem Ausführen der Zeichnungsanfrage resultiert; und in Antwort auf eine Bestimmung, dass der Ausgeber vormals gerenderte Grafiken liest, Speichern des bestimmten Zustands ohne Ausführen der Zeichnungsanfrage, und Speichern einer gerenderten Zeichnungsanfrage in einen Puffer.
Verfahren nach Anspruch 1, weiter umfassend: in Antwort auf die Zeichnungsanfrage, die eine anzeigbare Zeichnungsanfrage beinhaltet, das Anfragen, dass Zeichnungsakzelerationshardware eingeschaltet wird, und das Vorlegen des Befehls an die Hardware, wobei die Hardware entweder Display-, Video- oder Grafikhardware umfasst.
Verfahren nach Anspruch 1, weiter umfassend: Bestimmen, ob die Zeichnungsanfrage ausgeführt werden kann, wobei die Akzelerationshardware, verbunden mit der Zeichnungsanfrage, in Niedrigenergiemodus verbleibt und in Antwort auf eine Bestimmung, dass die Zeichnungsanfrage ausgeführt werden kann, wobei die Akzeferationshardware, verbunden mit der Zeichnungsanfrage, in Niedrigenergiemodus verbleibt, Speichern des bestimmten Zustands ohne Ausführen der Zeichnungsanfrage.
Verfahren nach Anspruch 7, weiter umfassend: in Antwort auf eine Bestimmung, dass die Zeichnungsanfrage nicht ausgeführt werden kann mit Hardware, verbunden mit der Zeichnungsanfrage, die in Niedrigenergiemodus verbleibt, das Anfragen, dass die verbundene Hardware eingeschaltet wird, und das Vorlegen der Zeichnungsanfrage an die hochgefahrene Hardware.
Verfahren nach Anspruch 1, weiter umfassend: Verwenden einer Anwendung, ausgeführt von einer Zentraleinheit, um Rendern von Zeichnungen niedriger Komplexität der Zeichnungsanfrage auszuführen, unabhängig vom Hochfahren von Grafik- oder Videohardware.
Vorrichtung, umfassend: einen Grafiktreiber zum: Bestimmen, ob eine empfangene Zeichnungsanfrage keine anzeigbare Zeichnungsanfrage beinhaltet und Selektiven Modifizieren der Zeichnungsanfrage in Antwort auf eine Bestimmung, dass die Zeichnungsanfrage keine anzeigbare Zeichnungsanfrage beinhaltet, und einen Power-Manager (power manager, PM), um selektiv anzufragen, eine Zeichnungsakzelerationshardware einzuschalten, in Antwort auf eine Zeichnungsanfrage, und um selektiv Energieverbrauch von Akzelerationshardware in Antwort auf Leerlauf von zumindest einer Anwendung für einen Grenzwert einer Zeitspanne zu verringern.
Vorrichtung nach Anspruch 10, wobei der PM entscheiden soll, welche Hardware angefragt werden soll, in einen Niedrigenergiemodus einzutreten, basierend auf einer Anzeige von Inaktivität der Anwendung, der PM zumindest eine Anwendung über Niedrigenergiezustand von Hardware benachrichtigen soll, und die zumindest eine Anwendung Zeichnungsanfragen an die Hardware in Niedrigenergiezuständen in Antwort darauf, dass die Zeichnungsanfrage nicht-anzeigbar ist, verringern soll.
Vorrichtung nach Anspruch 10, weiter umfassend einen Fenstermanager, wobei der PM den Fenstermanager benachrichtigen soll, den letzten Frame während Systemwiederaufnahme aufzufrischen.
Vorrichtung nach Anspruch 10, wobei: der Grafiktreiber den PM über Hardware-Inaktivität benachrichtigen soll und der Grafiktreiber Verwendung einer Zentraleinheit anfragen soll, um in der Zeichnungsanfrage Verarbeiten von Grafiken niedriger Komplexität auszuführen.
Vorrichtung nach Anspruch 10, wobei: der Grafiktreiber den PM über Hardware-Inaktivität benachrichtigen soll, und der PM inaktive Hardware in Niedrigenergiezustände überführen soll.
Vorrichtung nach Anspruch 10, wobei: zum selektiven Modifizieren der Zeichnungsanfrage der Grafiktreiber Pixel-Dimensionen auf einen Bruchteil von Dimensionen der Pixel der Zeichnungsanfrage einstellen soll, wobei der Bruchteil weniger als Eins ist.
Vorrichtung nach Anspruch 10, wobei der Grafiktreiber: Bestimmen soll, ob ein Ausgeber der Zeichnungsanfrage vormals gerenderte Grafiken liest; einen Zustand bestimmen soll, der aus dem Ausführen der Zeichnungsanfrage resultiert; und in Antwort auf eine Bestimmung, dass der Ausgeber vormals gerenderte Grafiken liest, der Grafiktreiber den bestimmten Zustand speichern soll, ohne Ausführen der Zeichnungsanfrage, und eine gerenderte Zeichnungsanfrage in einen Puffer speichern soll.
Vorrichtung nach Anspruch 10, wobei der Grafiktreiber: Verwendung einer Anwendung anfragen soll, ausgeführt von einer Zentraleinheit, um Rendern von Zeichnungen niedriger Komplexität der Zeichnungsanfrage auszuführen, unabhängig vom Hochfahren von Grafik- oder Videohardware.
System, umfassend: eine drahtlose Schnittstelle; ein Display-Gerät; und ein Computersystem, das kommunikativ mit dem Display-Gerät gekoppelt ist, wobei das Computersystem konfiguriert ist, um: eine Zeichnungsanfrage zu empfangen; zu bestimmen, ob die Zeichnungsanfrage keine anzeigbare Zeichnungsanfrage beinhaltet; und selektiv die Zeichnungsanfrage in Antwort auf eine Bestimmung, dass die Zeichnungsanfrage keine anzeigbare Zeichnungsanfrage beinhaltet, zu modifizieren.
System nach Anspruch 18, wobei zum selektiven Verringern einer Anzahl an Pixeln der Zeichnungsanfrage das Computersystem Pixel-Dimensionen auf einen Bruchteil von Dimensionen der Pixel der Zeichnungsanfrage einstellen soll, wobei der Bruchteil weniger als Eins ist.
System nach Anspruch 18, wobei zum selektiven Modifizieren der Zeichnungsanfrage, das Computersystem: Bestimmen soll, ob ein Ausgeber der Zeichnungsanfrage vormals gerenderte Grafiken liest; einen Zustand bestimmen soll, der aus dem Ausführen der Zeichnungsanfrage resultiert; und in Antwort auf eine Bestimmung, dass der Ausgeber vormals gerenderte Grafiken liest, den bestimmten Zustand ohne Ausführen der Zeichnungsanfrage speichern soll, und eine gerenderte Zeichnungsanfrage in einen Puffer speichern soll.
System nach Anspruch 18, wobei das Computersystem ebenfalls konfiguriert ist, um: zu bestimmen, ob die Zeichnungsanfrage ausgeführt werden kann, wobei die Hardware in Niedrigenergiemodus ist und in Antwort auf eine Bestimmung, dass die Zeichnungsanfrage ausgeführt werden kann mit Hardware, verbunden mit der Zeichnungsanfrage, die in Niedrigenergiemodus verbleibt, den bestimmten Zustand, ohne dass die Zeichnungsanfrage ausgeführt wird, zu sichern.
System nach Anspruch 18, wobei das Computersystem ebenfalls konfiguriert ist, um: Verwendung einer Anwendung anzufragen, ausgeführt von einer Zentraleinheit, um Rendern von Zeichnungen niedriger Komplexität der Zeichnungsanfrage auszuführen, unabhängig vom Hochfahren von Grafik- oder Videohardware.