-
HINTERGRUND DER ERFINDUNG
-
Datenverarbeitungssysteme haben signifikante Beiträge zu dem Fortschritt der modernen Gesellschaft geleistet und werden in einer Anzahl von Applikationen bzw. Anwendungen verwendet, um vorteilhafte Ergebnisse zu erreichen. Zahlreiche Vorrichtungen, wie zum Beispiel Desktop-Personal-Computer (PCs), Laptop-PCs, Tablet-PCs, Netbooks, Smartphones, Server und ähnliches, haben eine erhöhte Produktivität und reduzierte Kosten bei der Kommunikation und Analyse von Daten, einen erhöhten Konsum von elektronischen Inhalten (engl. „electronic content”) und ähnliches auf den meisten Bereichen von Unterhaltung, Ausbildung, Wirtschaft und Wissenschaft ermöglicht bzw. vereinfacht. Entwicklungsaspekte von Datenverarbeitungssystemen enthalten Client-Server-Datenverarbeitungsplattformen, Virtuelle-Maschine-Datenverarbeitungsplattformen und Cloud-Datenverarbeitungsplattformen sowie Grafikverarbeitung auf allen diesen Plattformen.
-
Für grafikintensive Anwendungen, wie zum Beispiel online Computerspiele, führt das Windows-Operativsystem jede Instanz der Anwendung in Vollbildmodus aus. Der Vollbildmodus ist ein exklusiver Modus (engl. „exclusive mode”), so dass eine andere Instanz der Anwendung, die ausgeführt wird, Displayframes nicht ausgeben kann, da die erste Instanz im Vollbildmodus ausgeführt wird. Selbst auf einem Server mit mehreren Grafikverarbeitungseinheiten können mehrere Instanzen einer Anwendung folglich nicht gleichzeitig ausgeführt werden, da die erste Anwendung im Vollbildmodus ausgeführt werden wird. Selbst bei Implementierungen mit virtuellen Maschinen wird die erste Anwendung, die auf einem Gastoperativsystem ausgeführt wird, in ähnlicher Weise im Vollbildmodus ausgeführt werden und andere Anwendungen, die auf anderen Gastvorrichtungen ausgeführt werden, daran hindern, Displayframes auszugeben. Mit der Verbreitung (engl. „proliferation”) von Multiprozessor- und/oder Multikern- und/oder GPU-Servervorrichtungen wäre es aber vorteilhaft, in der Lage zu sein, mehrere grafikintensive Anwendungen oder Instanzen der gleichen Anwendung ausführen zu können. Es besteht folglich einen kontinuierlichen Bedarf an verbesserten Grafikverarbeitungstechniken auf Client-Server-Datenverarbeitungsplattformen, Virtuelle-Maschine-Datenverarbeitungsplattformen und Cloud-Datenverarbeitungsplattformen.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Die vorliegende Technologie mag am besten verstanden werden durch Bezugnahme auf die nachfolgende Beschreibung und die begleitenden Zeichnungen, die zur Darstellung von Ausführungsformen der vorliegenden Technologie, die auf serverbasierte Grafikverarbeitungstechniken gerichtet ist, verwendet werden.
-
In einer Ausführungsform enthält ein serverbasiertes Grafikverarbeitungsverfahren ein Erhalten, bei einer gegebenen Instanz einer Laufzeit-Programmierschnittstelle (engl. „runtime application programming interface”), einer Mehrzahl von Grafikbefehlen. Die Mehrzahl von Grafikbefehlen von der gegebenen Instanz der Laufzeit-Programmierschnittstelle wird durch eine gegebene Instanz einer Gast-Zwischenschicht (engl. „guest shim layer”) hindurch an eine gegebene Instanz einer Gast-Displayvorrichtungsschnittstelle (engl. „guest display device interface”) weitergeleitet. Die gegebene Instanz der Gast-Displayvorrichtungsschnittstelle ruft auf zurück in (engl. „calls back into”) die gegebene Instanz der Gast-Zwischenschicht hinein mit einem Funktionsaufruf als Reaktion auf (engl. „in response to”) die Mehrzahl von Grafikbefehlen. Die gegebene Instanz der Laufzeit-Programmierschnittstelle, die gegebene Instanz der Gast-Zwischenschicht und die gegebene Instanz der Gast-Displayvorrichtungsschnittstelle werden unter der Kontrolle einer gegebenen Instanz eines Gastoperativsystems ausgeführt. Der Funktionsaufruf wird von der gegebenen Instanz der Gast-Zwischenschicht durch einen Kommunikationskanal eines Host-Gast-Kommunikationsmanagers (engl. „host guest communication manager”) hindurch an eine Host-Displayvorrichtungsschnittstelle gesendet. Ein Renderingkontext für jeden erhaltenen Funktionsaufruf wird von der Host-Displayvorrichtungsschnittstelle bestimmend bzw. bestimmt. Die Host-Displayvorrichtungsschnittstelle sendet jeden Funktionsaufruf eines gegebenen Renderingkontexts an eine gegebene Instanz der Thunk-Schicht (engl. „thunk layer”). Der Host-Gast-Kommunikationsmanager, die Host-Displayvorrichtungsschnittstelle und die gegebene Instanz der Thunk-Schicht werden unter der Kontrolle eines Hostoperativsystems ausgeführt.
-
Das Verfahren enthält auch ein Erhalten einer anderen Mehrzahl von Grafikbefehlen bei einer anderen Instanz der Laufzeit-Programmierschnittstelle. Die andere Mehrzahl von Grafikbefehlen von der anderen Instanz der Laufzeit-Programmierschnittstelle wird durch eine andere Instanz der Gast-Zwischenschicht hindurch an eine andere Instanz der Gast-Displayvorrichtungsschnittstelle weitergeleitet. Die andere Instanz der Gast-Displayvorrichtungsschnittstelle ruft zurück in die andere Instanz der Gast-Zwischenschicht hinein mit einem anderen Funktionsaufruf als Reaktion auf die andere Mehrzahl von Grafikbefehlen. Die andere Instanz der Laufzeit-Programmierschnittstelle, die andere Instanz der Gast-Zwischenschicht und die andere Instanz der Gast-Displayvorrichtungsschnittstelle werden unter der Kontrolle einer anderen Instanz eines Gastoperativsystems ausgeführt. Der andere Funktionsaufruf von der anderen Instanz der Gast-Zwischenschicht wird durch einen anderen Kommunikationskanal des Host-Gast-Kommunikationsmanagers hindurch an die Host-Displayvorrichtungsschnittstelle gesendet. Jeder andere Funktionsaufruf eines anderen Renderingkontexts wird von der Host-Displayvorrichtungsschnittstelle an eine andere Instanz der Thunk-Schicht gesendet. Die andere Instanz der Thunk-Schicht wird unter der Kontrolle des Hostoperativsystems ausgeführt.
-
In einer anderen Ausführungsform enthält eine serverbasierte Grafikverarbeitungstechnik ein Laden einer gegebenen Instanz einer Gast-Zwischenschicht als Reaktion darauf, dass eine gegebene Instanz einer Laufzeit-Programmierschnittstelle einen ersten Grafikbefehl von einer gegebenen Anwendung erhält. Eine gegebene Instanz einer Gast-Displayvorrichtungsschnittstelle, die zurück in die gegebene Instanz der Gast-Zwischenschicht hinein aufruft, wird als Reaktion darauf geladen, dass die gegebene Instanz der Gast-Zwischenschicht geladen wird. Die Gast-Zwischenschicht, die Gast-Displayvorrichtungsschnittstelle und die Laufzeit-Programmierschnittstelle werden unter der Kontrolle von einem Virtuelle-Maschine-Gastoperativsystem ausgeführt. Die gegebene Instanz der Zwischenschicht fordert einen Kommunikationskanal zwischen der gegebenen Instanz der Zwischenschicht und einer Host-Displayvorrichtungsschnittstelle von einem Host-Gast-Kommunikationsmanager als Reaktion auf das Laden der gegebenen Instanz der Gast-Zwischenschicht an. Der Host-Gast-Kommunikationsmanager lädt die Host-Displayvorrichtungsschnittstelle und erzeugt einen Kommunikationskanal zwischen der gegebenen Instanz der Zwischenschicht und der Host-Displayvorrichtungsschnittstelle als Reaktion auf die Anforderung für den Kommunikationskanal. Die Host-Displayvorrichtungsschnittstelle lädt eine gegebene Instanz einer Thunk-Schicht als Reaktion auf dem Laden der Host-Displayvorrichtungsschnittstelle. Der Host-Gast-Kommunikationsmanager, die Host-Displayvorrichtungsschnittstelle und die Thunk-Schicht werden unter der Kontrolle eines Virtuelle-Maschine-Manager-Hostoperativsystems (engl. „virtual machine manager host operating system”) ausgeführt. Die Host-Displayvorrichtungsschnittstelle erzeugt auch einen gegebenen Renderingkontext zwischen der gegebenen Instanz der Gast-Zwischenschicht und der gegebenen Instanz der Thunk-Schicht, die an eine gegebene Grafikverarbeitungseinheit kommunikativ gekoppelt ist, als Reaktion auf das Laden der Host-Displayvorrichtungsschnittstelle.
-
Dann werden die Grafikbefehle von der gegebenen Instanz der Laufzeit-Programmierschnittstelle durch die gegebene Instanz der Gast-Zwischenschicht an die gegebene Instanz der Host-Displayvorrichtungsschnittstelle weitergeleitet. Die gegebene Instanz der Host-Displayvorrichtungsschnittstelle ruft auf zurück in die gegebene Instanz der Gast-Zwischenschicht hinein mit einem oder mehreren Funktionsaufrufen basierend auf einem Satz von den Grafikbefehlen. Der eine Funktionsaufruf oder die mehreren Funktionsaufrufe wird bzw. werden von der gegebenen Instanz der Gast-Zwischenschicht durch den Kommunikationskanal hindurch an die Host-Displayvorrichtungsschnittstelle gesendet. Ein gegebener Renderingkontext wird für jeden Funktionsaufruf bestimmt, der von der Host-Displayvorrichtungsschnittstelle erhalten wird. Jeder Funktionsaufruf des gegebenen Renderingkontexts wird von der Host-Displayvorrichtungsschnittstelle an die gegebene Instanz der Thunk-Schicht gesendet.
-
In noch einer anderen Ausführungsform enthält eine serverbasierte Grafikverarbeitungstechnik ein Injizieren (engl. „injecting”) einer Anwendungsinitialisierungsroutine (engl. „application initialization routine”), wenn eine Anwendung in einem gegebenen Virtuelle-Maschine-Gast zu laufen beginnt, wobei die Anwendungsinitialisierungsroutine einen Einsprungpunkt (engl. „entry point”) enthält, der einen Suchpfad (engl. „search path”) für eine gegebene Instanz der Displayvorrichtungsschnittstelle in einen Suchpfad einer gegebenen Instanz einer Gast-Zwischenschicht ändert. Die Gast-Zwischenschicht, an dem geänderten Suchpfad, wird zum Laufen in dem gegebenen Virtuelle-Maschine-Gast geladen. Eine Gast-Displayvorrichtungsschnittstelle, die zurück in die Gast-Zwischenschicht hinein aufruft, wird als Reaktion auf das Laden der Gast-Zwischenschicht zur Ausführung in dem gegebenen Virtuelle-Maschine-Gast geladen. Ein Kommunikationskanal zwischen der Gast-Zwischenschicht und einer Host-Displayvorrichtungsschnittstelle wird als Reaktion auf das Laden der Gast-Zwischenschicht von einem Host-Gast-Kommunikationsmanager angefordert, der in einem Virtuelle-Maschine-Management-Host (engl. „virtual machine management host”) läuft. Die Host-Displayvorrichtungsschnittstelle, die in dem Virtuelle-Maschine-Management-Host ausgeführt werden soll, wird geladen und ein Kommunikationskanal zwischen der Zwischenschicht und der Host-Displayvorrichtungsschnittstelle wird erzeugt als Reaktion auf die Anforderung für den Kommunikationskanal. Eine gegebene Instanz einer Thunk-Schicht wir zur Ausführung in dem Virtuelle-Maschine-Management-Host geladen, wobei die gegebene Instanz der Thunk-Schicht an eine gegebene Grafikverarbeitungseinheit kommunikativ gekoppelt ist, als Reaktion auf das Laden der Host-Displayvorrichtungsschnittstelle. Ein gegebener Renderingkontext wird auch zwischen der gegebenen Instanz der Virtuelle-Maschine-Gast und der gegebenen Instanz der Thunk-Schicht erzeugt als Reaktion auf dem Laden der Host-Displayvorrichtungsschnittstelle.
-
Diese Zusammenfassung ist bereitgestellt, um eine Auswahl an Konzepte in einer simplifizierten Form darzustellen, die unten in der detaillierten Beschreibung weiter beschrieben werden. Diese Zusammenfassung ist nicht zur Identifikation von entscheidenden oder essentiellen Merkmale des beanspruchten Gegenstands beabsichtigt, noch ist sie zur Verwendung zur Begrenzung des Umfangs des beanspruchten Gegenstands beabsichtigt.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Ausführungsformen der vorliegenden Technologie werden beispielhaft und nicht begrenzend dargestellt in den Figuren der begleitenden Zeichnungen, in denen gleiche Bezugszeichen auf ähnliche Elemente verweisen und in denen:
-
1 ein Blockdiagramm einer Darstellung auf Hardwareebene von einem Client-Server- oder Cloud-Datenverarbeitungsplattform zeigt, gemäß einer Ausführungsform der vorliegenden Technologie.
-
2 ein Blockdiagramm einer Virtuelle-Maschine-Darstellung von dem Client-Server- oder Cloud-Datenverarbeitungsplattform zeigt, gemäß einer Ausführungsform der vorliegenden Technologie.
-
3 ein Blockdiagramm einer Virtuelle-Maschine-Darstellung auf der Renderingfunktionsebene von dem Client-Server- oder Cloud-Datenverarbeitungsplattform zeigt, gemäß einer Ausführungsform der vorliegenden Technologie.
-
Die 4A–4E ein Flussdiagramm von einem auf Client-Server- oder Cloud-Datenverarbeitung basierenden Grafikverarbeitungsverfahren zeigen, gemäß einer Ausführungsform der vorliegenden Technologie.
-
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
-
Bezug wird jetzt detailliert auf die Ausführungsbeispiele der vorliegenden Technologie genommen, von denen Beispiele in den begleitenden Zeichnungen dargestellt sind. Während die vorliegende Technologie im Zusammenhang mit diesen Ausführungsformen beschrieben wird, wird es verstanden werden, dass diese nicht bezwecken, die Erfindung zu diesen Ausführungsformen zu begrenzen. Die Erfindung ist im Gegenteil dafür gedacht, Alternative, Modifikationen und Äquivalente abzudecken, die in dem Umfang der Erfindung, wie dieser von den angehängten Ansprüchen definiert wird, mit enthalten sein mögen. In der folgenden detaillierten Beschreibung der vorliegenden Technologie werden viele spezifische Details dargelegt, um ein vollständiges Verständnis der vorliegenden Technologie bereitzustellen. Es wird aber verstanden werden, dass die vorliegende Technologie ohne diese spezifischen Details praktiziert werden mag. In anderen Fällen sind wohlbekannte Verfahren, Vorgänge und Schaltkreise nicht in Detail beschrieben worden, um Aspekte der vorliegenden Technologie nicht in unnötiger Weise zu verschleiern.
-
Einige der folgenden Ausführungsformen der vorliegende Technologie werden in Form von Routinen, Modulen, logischen Blöcken und anderen symbolischen Darstellungen von Operationen auf Daten innerhalb einer oder mehrerer elektronischen Vorrichtungen präsentiert. Die Beschreibungen und Darstellungen sind die Mittel, die von Fachleuten verwendet werden, um die Substanz deren Arbeit an andere Fachleute so effizient wie möglich zu vermitteln. Eine Routine, ein Modul, ein logischer Block und/oder ähnliches ist, hierin und generell, dazu konzipiert, eine selbständige Sequenz von Prozessen oder Instruktionen zu sein, die zu einem gewünschten Ergebnis führen. Die Prozesse sind die, die physikalische Manipulationen von physikalischen Größen aufweisen. Normalerweise, aber nicht notwendigerweise, nehmen diese physikalischen Manipulationen die Form von elektrischen oder magnetischen Signalen an, die in einer elektronischen Vorrichtung gespeichert, übertragen, verglichen und in anderer Weise manipuliert werden können. Der Einfachheit halber und mit Bezug auf den verbreiteten Gebrauch werden diese Signale als Daten, Bits, Werte, Elemente, Symbole, Zeichen, Terme, Zahle, Strings und/oder ähnliches bezeichnet mit Bezug auf Ausführungsformen der vorliegenden Technologie.
-
Es sollte aber berücksichtigt werden, dass alle diese Begriffe als bezugnehmend auf physikalische Manipulationen und Größen interpretiert werden sollen, und dass sie lediglich zweckmäßige Bezeichnungen sind, und dass sie im Hinblick auf Begriffe, die in der Technik gewöhnlich benutzt werden, interpretiert werden sollen. Falls nicht explizit anders angeführt ist und wie es aus der nachfolgenden Diskussion hervorgeht, wird es verstanden, dass durch Diskussionen der vorliegenden Technologie, Diskussionen, die Begriffe wie „Empfangen” und/oder ähnliches verwenden, sich auf Handlungen und Prozesse einer elektronischen Vorrichtung beziehen, wie zum Beispiel eine elektronische Datenverarbeitungsvorrichtung, die Daten manipuliert und transformiert. Die Daten werden als physikalische (zum Beispiel elektronische) Größen innerhalb der Logikschaltkreise, Register, Speicher und/oder ähnliches von der elektronischen Vorrichtung dargestellt, und werden in andere Daten transformiert, die in ähnlicher Weise als physikalische Größen innerhalb der elektronischen Vorrichtung dargestellt werden.
-
In dieser Anmeldung ist es beabsichtigt, dass die Verwendung der Disjunktiven die Konjunktive enthält. Es ist nicht beabsichtigt, dass die Verwendung definiter oder indefiniter Artikel eine Kardinalität kennzeichnet. Insbesondere wird es beabsichtigt, dass ein Bezug auf „das” Objekt oder auf „ein” Objekt auch ein Objekt aus einer möglichen Mehrzahl solcher Objekte bezeichnet. Es soll auch verstanden werden, dass die hierin benutzte Phraseologie und Terminologie dem Zweck der Beschreibung dient und nicht als begrenzend angesehen werden soll.
-
Bezugnehmend auf die 1 wird eine Darstellung auf Hardwareebene von einer Client-Server- oder Cloud-Datenverarbeitungsplattform gezeigt, gemäß einer Ausführungsform der vorliegenden Technologie. Der Client-Server- oder Cloud-Datenverarbeitungsplattform 100 weist eine Mehrzahl von Benutzervorrichtungen 105–115 auf, die durch ein oder mehrere Netzwerke 120 an eine oder mehrere Servervorrichtungen 125 kommunikativ gekoppelt sind. In der Cloud-Datenverarbeitungsplattform werden Hardwareressourcen, Software und Information für Benutzervorrichtungen als einen Utility über ein Netzwerk bereitgestellt. Die Cloud-Datenverarbeitungsplattform liefert folglich Datenverarbeitung als einen Service eher als ein Produkt. Benutzervorrichtungen greifen auf cloudbasierte Ressourcen zu durch einen Webbrowser oder eine leichtgewichtige (engl. „light weight”) Desktop- oder Mobil-Anwendung. Die Cloud-Datenverarbeitungsplattform ermöglicht Vorrichtungs- und Standortsunabhängigkeit, Virtualisierung, Mandantenfähigkeit (engl. „multi-tenancy”), Zuverlässigkeit, Performance, Sicherheit, Wartung, Infrastrukturkonvergenz, gemeinsame bzw. geteilte (engl. „shared”) Services und/oder ähnliches, um Bedürfnisse zu bedienen, die fluktuierend, unvorhersehbar und/oder ähnliches sein mögen.
-
Jeder Server 125 mag eine oder mehrere Verarbeitungseinheiten 130–140, einen oder mehr von einer Datenverarbeitungsvorrichtung lesbaren Datenträger (zum Beispiel Speicher) 145, eine oder mehrere Netzwerkschnittstellen 150 und/oder ähnliches aufweisen, die durch einen oder mehreren Kommunikationslinks 155 zusammengekoppelt sind. In einer Ausführungsform weist der Server eine zentrale Verarbeitungseinheit (CPU) 130, nicht flüchtigen Speicher, wie zum Beispiel einen ausschließlich lesbaren Speicher (ROM), ein magnetisches Festplattenlaufwerk, ein optisches Plattenlaufwerk und/oder ähnliches, flüchtigen Speicher, wie zum Beispiel einen frei adressierbaren Speicher, eine oder mehrere Netzwerkschnittstellenkarten zum kommunikativen Koppeln des Servers 125 an ein oder mehrere Netzwerke 120, und eine Mehrzahl von Grafikverarbeitungseinheiten 135–140 auf.
-
Anwendungen, die auf der Servervorrichtung 125 laufen bzw. ausgeführt werden (engl. „running”), mögen Displayframes rendern, die auf einem Display bzw. einer Anzeigevorrichtung der Benutzervorrichtung 105 ausgegeben werden sollen. Die Displayframedaten werden auf dem Server 125 encodiert, um sie zu komprimieren, und querdurch ein oder mehrere Netzwerke 120 an die Benutzervorrichtung 105 gesendet. Die Benutzervorrichtung 105 decodiert die Displayframedaten und gibt sie auf dem Display aus, das an die Benutzervorrichtung 105 angeschlossen ist. In einer Implementierung mag die Anwendung eine grafikintensive Anwendung sein, wie zum Beispiel ein Mehrspieler-Computerspiel oder ähnliches.
-
Jetzt bezugnehmend auf die 2 wird eine Virtuelle-Maschine-Darstellung von der Client-Server- oder Cloud-Datenverarbeitungsplattform gezeigt. Der eine oder mehreren Prozessoren des Servers 125, die von einer Datenverarbeitungsvorrichtung ausführbare Instruktionen ausführen, implementieren ein Hostoperativsystem 210, eine Virtuelle-Maschine-Management-(VMM)-Hostanwendung 220 und eine Mehrzahl von Virtuelle-Maschine-(VM)-Gastoperativsysteme 230–250. In einer Implementierung mag das Hostoperativsystem 210 ein Windows 7 Operativsystem von Microsoft aus Redmond, Washington, USA sein. Die VMM-Hostanwendung 220 wird als eine Anwendung des Hostoperativsystems 210 ausgeführt. In einer Implementierung mag die Virtuelle-Maschine-Management-Hostanwendung 220 VirtualBox von Oracle aus Redwood Shores, Kalifornien, USA sein. Eine Mehrzahl von VM-Gastoperativsystemen 230–250 laufen in der virtuellen Maschine, die von der VMM-Hostanwendung 220 implementiert ist. In einer Implementierung mag jedes VM-Gastoperativsystem 220–250 eine Instanz des Windows 7 Operativsystems sein. Jede von einer oder mehreren Benutzervorrichtungen 105–115 mag als ein Gast kommunikativ an den Server 125 durch eine entsprechende Instanz des VM-Gastoperativsystems 220–250 koppeln.
-
Jetzt bezugnehmend auf die 2 wird eine Virtuelle-Maschine-Darstellung von der Client-Server- oder Cloud-Datenverarbeitungsplattform auf der Renderingfunktionsebene gezeigt, gemäß einer Ausführungsform der vorliegenden Technologie. Die Servervorrichtung weist Anwendungen, Treiber, Utilities und ähnliches für jeden einer Mehrzahl von Gästen, die unter der Kontrolle von einem jeweiligen Virtueller-Gast-Operativsystem 240 ausgeführt wird. Die Servervorrichtung weist auch eine Virtuelle-Maschine-Monitor-Hostanwendung und Treiber, Utilities und ähnliches für jeden von einem oder mehreren Hosts auf, ausführend unter der Kontrolle von einem (VMM-)Hostoperativsystem 210. In einer Implementierung steuert das VM-Gast-OS 240 die Ausführung einer Benutzeranwendung 205, eines Anwendungsinitialisierungsutility 310, einer Laufzeit-Anwendungsprogrammierschnittstelle (API) 315, einer Gast-Zwischenschicht 320 und einer Gast-Vorrichtungstreiberschnittstelle (DDI) 325. Das VMM-Host-OS 210 steuert die Ausführung eines Host-Gast-Kommunikationsmanagers (HGCM) 330, einer Host-DDI 335, einer Thunk-Schicht 340, eines OS-Kernel-Modus-Treibers (engl. „OS kernel mode driver”) 345, eines vorrichtungsspezifischen Kernel-Modus-Treibers 350.
-
Für jeden Renderingkontext mag der Gast, in einer Implementierung, eine Instanz der Benutzeranwendung 205, des Anwendungsinitialisierungsutility 310, der Laufzeit-Anwendungsprogrammierschnittstelle 315, der Gast-Zwischenschicht 320, der Gast-DDI 325, der Thunk-Schicht 340, des OS-Kernel-Modus-Treibers 345, des vorrichtungsspezifischen Kernel-Modus-Treibers 350 und der gegebenen GPU 355 aufweisen. Der HGCM 330 und die Host-DDI 335 werden von einer Mehrzahl von Gästen geteilt bzw. gemeinsam genutzt. Obwohl 3 einen einzigen Gast darstellt, wird es verstanden, dass eine Mehrzahl von Gästen typisch auf einer Servervorrichtung implementiert wird.
-
Wenn eine Anwendung 305 auf dem VM-Gast-OS 240 zum Laufen beginnt, wird die Anwendungsinitialisierungsroutine 310 injiziert (engl. „injected”). In einer Implementierung ist die Anwendungsinitialisierungsroutine 310 eine kurze Dynamisch-Gelinkte-Bibliothek (zum Beispiel appin.dll). Die Anwendungsinitialisierungsroutine 310, die in die Anwendung 305 injiziert wird, enthält einige Einsprungpunkte (engl. „entry points”), wobei einer von denen einen Aufruf (engl. „call”) (zum Beispiel set_dll_searchpath()) enthält, um den Suchpfaden für die Displayvorrichtungsschnittstelle zu ändern. Während der Initialisierung wird der Suchpfaden für die Displayvorrichtungsschnittstelle (zum Beispiel c:\windows\system32\...\umd.dll) in den Suchpfad der Gast-Zwischenschicht (zum Beispiel c:\...\vmm\...\umd.dll) 320 geändert. Folglich wird die Laufzeit-API 315 nach der DDI in einem anderen Pfad suchen, was dazu führen wird, dass die Laufzeit-API 315 die Gast-Zwischenschicht 320 lädt. In einer Implementierung ist die Gast-Zwischenschicht 320 eine unabhängige Bibliothek. Die Gast-Zwischenschicht-Bibliothek 320 hat die gleichen Einsprungpunkte wie eine konventionelle Displayvorrichtungsschnittstelle (DDI).
-
Während der Initialisierung lädt die Gast-Zwischenschicht 320 die Gast-DDI 325. In einer Implementierung mag die Gast-DDI 325 eine Benutzer-Modus-Treiber-Dynamische-Gelinkte-Bibliothek (nvd3dUMD.dll) sein. Die Laufzeit-API 315 leitet einen oder mehrere Zeiger an die Gast-Zwischenschicht 320 weiter, wenn sie in den zutreffenden Einsprungpunkt (zum Beispiel OpenAdapter()) in der Gast-Zwischenschicht 320 hinein aufruft. Die Zeiger, die an die Gast-Zwischenschicht 320 weitergeleitet werden, sind Zurückaufrufe (engl. „call backs”) in die Laufzeit-API 315 hinein. Die Gast-Zwischenschicht 320 speichert die von der Laufzeit-API 315 erhaltenen Zeiger. Die Gast-Zwischenschicht 320 lädt und initialisiert die Gast-DDI 325 durch Weiterleiten von Zeigern, die Zurückaufrufe in lokale Funktionen der Gast-Zwischenschicht 320 hinein sind. Die Gast-DDI 325 retourniert auch Zeiger auf eine oder mehrere Datenstrukturen an die Gast-Zwischenschicht 320. Die von der Gast-DDI 325 an die Gast-Zwischenschicht 320 retournierten Zeiger mögen Zeiger auf einen oder mehrere Befehlspuffer aufweisen. Die von der Gast-DDI 325 retournierten Datenstrukturzeiger werden von der Gast-Zwischenschicht 320 gespeichert. Die Gast-DDI 325 kann folglich initialisieren, ohne mit der Laufzeit-API 315 zurückzusprechen (engl. „talking back”).
-
Während der Initialisierung fordert jede Gast-Zwischenschicht 320 auch einen Kommunikationskanal (zum Beispiel Pipe, Socket) von dem HGCM 330 an. Wenn ein Kommunikationskanal etabliert ist, wird ein Mapping erzeugt, um einen Renderingkontext eines gegebenen Gasts mit einer gegebenen GPU-Hardware des Hosts zu assoziieren. In einer Implementierung retourniert der HGCM einen Token-Identifikator (ID) an die Gast-Zwischenschicht 320, der das Renderingkontext-Mapping identifiziert. Die Gast-Zwischenschicht 320 fordert auch an, dass der HGCM 330 die Host-DDI 335 lädt. Die Gast-Zwischenschicht 320 fordert ferner eine Kopie der binären Datei der Thunk-Schicht 340, des OS-Kernel-Modus-Treibers 345 und/oder des anwendungsspezifischen Benutzer-Modus-Treibers 350 an. Als Reaktion ruft der HGCM 330 die Binärdatei der Thunk-Schicht 340, des OS-Kernel-Modus-Treibers 345 und/oder des anwendungsspezifischen Benutzer-Modus-Treibers 350 ab und retourniert sie über den Kommunikationskanal an die Gast-Zwischenschicht 320. Die Gast-Zwischenschicht 320 speichert die Binärdatei der Thunk-Schicht 340, des OS-Kernel-Modus-Treibers 345 und/oder des anwendungsspezifischen Benutzer-Modus-Treibers 350 (im Folgenden als die Gast-Stack-Binärdatei bezeichnet) in dem Speicher (zum Beispiel virtueller Disk) zum Verwenden beim Bestimmen des Formats von geeigneten Datenstrukturen, so dass die Befehle, die von der Gast-Zwischenschicht 320 gesendet werden, zu dem Format passt, das in dem Host-Stack verwendet wird. Die Datenstrukturdetails, auf welche es in der Host-Stack-Binärdatei Bezug genommen wird, mögen die bestimmten verwendeten Puffer, deren Speicherstellen und ähnliches enthalten. Die Host-DDI 335, die Thunk-Schicht 340, der OS-Kernel-Modus-Treiber 345 und/oder der vorrichtungsspezifische Kernel-Modus-Treiber 350 erzeugen auch eine Speicherallokation zum Speichern der Datenstrukturen, die zum Weiterleiten von Renderingbefehlen durch den Stack von der Gastanwendung zu dem vorrichtungsspezifischen Kernel-Modus-Treiber hinunter verwendet werden.
-
Danach, während Rendering, sendet die Anwendung 305 verschiedene Befehl an die Laufzeit-API 315. Die Befehle mögen solche Sachen enthalten wie ein Dreieck zu zeichnen, eine Farbe zu ändern, eine Textur zu setzen und/oder ähnliches. In einer Implementierung mögen die Befehle von der Anwendung 305 DirectX-Befehle sein. Die Laufzeit-API 315 mag die Befehle validieren, bevor sie mit den Befehlen in die Gast-Zwischenschicht 320 hinein aufruft. Die Laufzeit-API 315 mag im Wesentlichen in Übereinstimmung mit einer konventionellen Laufzeit-API von Microsoft Corporation (zum Beispiel d3d9.dll) operieren. Die Gast-Zwischenschicht 320 ruft wiederum mit den Befehlen in die Gast-DDI 325 hinein. Die Gast-DDI 325 transformiert die Befehlsfunktionen in Bytecode-Aufrufe in Befehlspuffern, die gemäß der Kopie der gespeicherten Kopie der Host-Stack-Binärdatei allokiert wurden. Wenn die Befehlspuffer gesetzt worden sind, werden ein oder mehrere Funktionsaufrufe, die Zeiger auf die Befehlspuffer enthalten, von der Gast-DDI 325 an die Gast-Zwischenschicht 320 mittels Rückaufrufe, die in der Initialisierungsphase spezifiziert worden sind, weitergeleitet. Die Funktionsaufrufe, die Zeiger auf die Befehlspuffer enthalten, werden von der Gast-Zwischenschicht 320 durch den HGCM 330 an die Host-DDI 335 weitergeleitet. Die Remote-Prozedur-Aufrufe werden durch eine Pipe zwischen dem Gast und dem Host geroutet, die eingerichtet wurde, als der HGCM initialisiert wurde. In einer Implementierung leitet die Gast-Zwischenschicht 320 einen Token-ID, der mit dem Renderingkontext assoziiert ist, an die Host-DDI 335 zusammen mit den Aufrufen von der Gast-DDI 325 weiter.
-
Die Host-DDI 335 bestimmt einen Renderingkontext für den Funktionsaufruf, den sie von der Gast-Zwischenschicht 320 erhalten hat. In einer Implementierung verwendet die Host-DDI 335 den Token-ID als einen Handle für eine Datenstruktur, die den Renderingkontext für den entsprechenden Gast definiert. Die Host-DDI 335 leitet wiederum die Funktionsaufrufe durch die Thunk-Schicht 340 an den Operativsystem-Kernel-Modus-Treiber 345 weiter. Als Reaktion scheduliert (engl. „schedules”) der Operativsystem-Kernel-Modus-Treiber 345 die Befehlspuffer an den Funktionszeigern, die mit den Funktionsaufrufen mit dem vorrichtungsspezifischen Kernel-Modus-Treiber 350 enthalten waren, zur Ausführung der Funktionsaufrufe bei einer gegebenen GPU 355. Der vorrichtungsspezifische Kernel-Modus-Treiber 355 setzt das Befehlsregister der GPU 355 zum Ausführen des Grafikbefehls und steuert die von der GPU 355 durchgeführte Ausführung davon. In einer Implementierung mag die Thunk-Schicht 340 im Wesentlichen gleich einer Thunk-Schicht von Microsoft Corporation (zum Beispiel GDI32.dll) operieren. Der OS-Kernel-Modus-Treiber 345 mag im Wesentlichen gleich einem konventionellen OS-Kernel-Modus-Treiber von Microsoft Corporation (zum Beispiel dxgkrnl.sys) operieren. In einer Implementierung mag der vorrichtungsspezifische Kernel-Modus-Treiber im Wesentlichen gleich einem konventionellen vorrichtungsspezifischen Kernel-Modus-Treiber von Nvidia Corporation aus Santa Clara, Kalifornien (zum Beispiel kmd.sys) operieren.
-
Für einen displaybezogenen Funktionsaufruf (zum Beispiel Present()) routet die Host-DDI 335 die gerenderten Framedaten an einen Encoder, assoziierte API und Treiber 360 (im Folgenden einfach als der Encoder bezeichnet), wenn die gerenderten Framedaten an die Host-DDI 335 retourniert werden. Die gerenderten Framedaten werden von der Host-DDI 335 an den Encoder 360 statt zurück zu der Gast-Zwischenschicht, Gast-DDI-Laufzeit-API und Anwendung umgeroutet bzw. umgeleitet (engl. „rerouted”). Der Encoder 360 encodiert die gerenderten Framedaten, um die Daten zu komprimieren. Die komprimierten Daten werden dann von dem Encoder 360 an eine Netzwerkschnittstelle, assoziierte API und Treiber 365 (im Folgenden einfach als die Netzwerkschnittstelle bezeichnet) zum Senden an die adäquaten Benutzervorrichtungen 105–115 gesendet. In einer Implementierung mag der Encoder 360 ein konventioneller Encoder sein, wie zum Beispiel ein H.264-Encoder.
-
An den Ebenen der Thunk-Schicht 340, des OS-Kenrmodustreibers 345 und des vorrichtungsspezifischen Kernel-Modus-Treibers 350 sind die Funktionsaufrufe lediglich Renderingtasks und ein Vollbildmodus macht keinen Sinn. Die Host-DDI 335 kann das Ziel von mehreren Sitzungen des Host-Gast-Kommunikationsmanagers sein, was bedeutet, dass mehrere Gast-VM zu den gleichen Komponenten im Host sprechen können. In der Art und Weise, wie die Komponenten im Host scheduliert werden, müssen sie nicht in Vollbild übergehen. Die Anwendung 305, die in dem VM-Gast-OS 240 läuft, läuft aber Vollbild, zeigt aber nichts auf einem Bildschirm. Das VM-Gast-OS 240 muss tatsächlich nicht die gerenderten Bilddaten von dem VMM-Host-OS 210 zurückerhalten.
-
Jetzt bezugnehmend auf die 4A–4E wird ein auf Client-Server- oder Cloud-Datenverarbeitung basierten Grafikverarbeitungsverfahren gezeigt, gemäß einer Ausführungsform der vorliegenden Technologie. Das Verfahren mag als ein oder mehrere Sätze von Instruktionen (zum Beispiel Computerprogrammen, Utilities, Treibern, Routinen) implementiert werden, die von Datenverarbeitungsvorrichtungen ausführbar sind, die in einem oder mehreren von Datenverarbeitungsvorrichtungen lesbaren Datenträger (zum Beispiel Computerspeicher) gespeichert sind und die von einer oder mehreren Verarbeitungseinheiten (zum Beispiel CPUs, GPUs) ausgeführt werden.
-
Das Verfahren beginnt bei 402 damit, dass Grafikbefehle von einer Anwendung, die unter der Kontrolle eines Virtuelle-Maschine-(VM)-Gastoperativsystems (OS) läuft, bei einer Laufzeit-Programmierschnittstelle (API) erhalten werden. Bei 404 wird eine Gast-Zwischenschicht als Reaktion darauf geladen, dass die Laufzeit-API einen ersten Grafikbefehl erhält. Bei 406 fordert die Gast-Zwischenschicht einen Kommunikationskanal (zum Beispiel Pipe, Socket) zu einer Host-Displayvorrichtungsschnittstelle (DDI) von einem Host-Gast-Kommunikationsmanager auf, wenn die Gast-Zwischenschicht geladen ist. Der HGCM wird unter der Kontrolle des Virtuelle-Maschine-Management-(VMM)-Host-OS geladen. Bei 408 lädt der HGCM die Host-DDI, falls diese nicht schon geladen wurde, und erzeugt einen Kommunikationskanal (zum Beispiel Pipe, Socket) zwischen der Gast-Zwischenschicht und der Host-DDI als Reaktion auf die Anforderung von der Gast-Zwischenschicht. Bei 410 assoziiert der HGCM einen Renderingkontext (zum Beispiel Adapter) zwischen der gegebenen Instanz der Gast-Zwischenschicht und einer Thunk-Schicht. Bei 412 wird die Thunk-Schicht für den assoziierten Renderingkontext geladen. Bei 414 werden ein oder mehrere Puffer von der Thunk-Schicht allokiert, wenn die Thunk-Schicht geladen ist. Bei 416 wird ein OS-Kernel-Modus-Treiber geladen, wenn die Thunk-Schicht geladen wurde. Bei 418 wird ein vorrichtungsspezifischer Kernel-Modus-Treiber für eine gegebene Grafikverarbeitungseinheit (GPU) geladen, wenn der OS-Kernel-Modus-Treiber geladen ist.
-
Bei 422 fordert die Gast-Zwischenschicht eine Kopie der Binärdatei der Thunk-Schicht, des OS-Kernel-Modus-Treibers und/oder des vorrichtungsspezifischen Kernel-Modus-Treibers (hierin nachfolgend Host-Stack bezeichnet) von der Host-DDI durch den HGCM an. Bei 422 retourniert die Host-DDI die Kopie der Host-Stack-Binärdatei an die Gast-Zwischenschicht durch den HGCM. Bei 424 parst die Gast-Zwischenschicht die Host-Stack-Binärdatei, um Zeiger auf einen oder mehrere Befehlspuffer zu bestimmen, die von der Thunk-Schicht allokiert wurden.
-
In einer Implementierung enthält VirtualBox eine Softwareentwicklungskit (engl. „software development kit”) (SDK), die einen HGCM bereitstellt. Der HGCM sorgt für eine Registrierung davon, dass die Host-DDI von der Zwischenschicht innerhalb des Gasts aufrufbar ist. Konventionell hat VirtualBox auch ihre eigenen Grafiktreiber (zum Beispiel Benutzer-Modus und Kernel-Modus) für softwarebasiertes Rendering auf der zentralen Verarbeitungseinheit. Softwarebasiertes Rendering auf der zentralen Verarbeitungseinheit stellt aber wesentlich niedrigere Renderingperformance im Vergleich zu Hardwarebasiertem Rendering auf einer Grafikverarbeitungseinheit bereit. Folglich verwendet Ausführungsformen der vorliegenden Technologie der HGCM von VirtualBox aber nicht die Grafiktreiber von VirtualBox.
-
Bei 426 lädt die Gast-Zwischenschicht einen Gast-Displayvorrichtungsschnittstelle-(DDI)-Benutzer-Modus-Treiber, wenn die Gast-Zwischenschicht geladen ist, und parst die Zeigern auf den einen oder die mehreren Befehlspuffer zu der Gast-DDI. Bei 428 retourniert die Gast-DDI Zurückrufe auf Renderingfunktionen mit Zeigern auf entsprechende Datenstrukturen an die Gast-Zwischenschicht, wenn die Gast-DDI geladen ist. Die Prozesse von 402–428 werden für jede Anwendung wiederholt, die unter der Kontrolle einer Instanz eines Virtuelle-Maschine-Gast-OS läuft.
-
Bei 430 ruft die Laufzeit-API die Gast-Zwischenschicht mit den erhaltenen Grafikbefehlen auf. Bei 432 ruft die Gast-Zwischenschicht die Gast-DDI mit den erhaltenen Grafikbefehlen auf. Bei 434 verarbeitet die Gast-DDI die erhaltenen Grafikbefehle, was ein Auffüllen (engl. „filling”) von einem oder mehreren Befehlspuffern mit Argumenten aus den erhaltenen Befehlen beinhaltet. Bei 436 ruft die Gast-DDI zurück zu der Gast-Zwischenschicht mit einem zweckmäßigen (engl. „appropriate”) Funktionsaufruf, nachdem die Gast-DDI einen Satz von einem oder mehreren entsprechenden Renderingbefehlen verarbeitet hat. Die Funktionsaufrufe mögen Renderingfunktionen, Darstellungsfunktionen (engl. „present functions”) und/oder ähnliches sein. Wenn die Funktion eine Renderingfunktion ist, enthält der Aufruf Zeiger auf einen oder mehrere Befehlspuffer. Bei 438 sendet die Gast-Zwischenschicht die Funktionsaufrufe mit einem Token-ID (zum Beispiel einem Handle) von der Gast-DDI durch den von dem HGCM bereitgestellten Kommunikationskanal an die Host-DDI. Die Prozesse von 430–438 werden für jede Anwendung durchgeführt, die unter der Kontrolle von einer unterschiedlichen Instanz eines Virtuelle-Maschine-Gast-OS läuft.
-
In einer Implementierung mag die Laufzeit-API etwa 100–300 Grafikbefehle für jeden gerenderten Frame erhalten. Die Gast-DDI ruft mit etwa 2–6 Funktionsaufrufen für jeden gerenderten Frame zurück. Die Parameter der Grafikbefehle werden von der Gast-DDI direkt in Befehlspuffer in dem VMM-Host-OS-Speicherraum hinein geladen, auf den der OS-Kernel-Modus-Treiber und/oder der vorrichtungsspezifischen Kernel-Modus-Treiber direkt zugreifen kann bzw. können, ohne zusätzliche Speicherzugriffe. Folglich ist der Kommunikationskanal zwischen der Zwischenschicht und der Host-DDI auf 2–6 Funktionsaufrufe statt 100–300 Grafikbefehle begrenzt.
-
Bei 440 bestimmt die Host-DDI einen Renderingkontext, der mit dem Token-ID assoziiert ist, für jeden Funktionsaufruf, der von einer Gast-Zwischenschicht-Instanz erhalten wird. Bei 442 sendet die Host-DDI jeden Funktionsaufruf eines gegebenen Renderingkontexts an die entsprechende Instanz der Thunk-Schicht. Bei 444 sendet die gegebene Thunk-Schicht den Funktionsaufruf an den OS-Kernel-Modus-Treiber. Bei 446 sendet der OS-Kernel-Modus-Treiber den Funktionsaufruf an den vorrichtungsspezifischen Kernel-Modus-Treiber. Bei 448 scheduliert der OS-Kernel-Modus-Treiber den Funktionsaufruf durch Setzen eines Befehlsregisters der GPU zum Ausführen des Funktionsaufrufs. Die Prozesse von 440–448 werden von den entsprechenden Instanzen der Thunk-Schicht, des OS-Kernel-Modus-Treibers und des vorrichtungsspezifischen Kernel-Modus-Treibers für die assoziierten Renderingkontexte durchgeführt.
-
Bei 450 gibt die GPU gerenderte Framedaten an den vorrichtungsspezifischen Kernel-Modus-Treiber aus, wenn der Funktionsaufruf eine Darstellungsfunktion ist. Bei 452 retourniert der vorrichtungsspezifische Kernel-Modus-Treiber die gerenderten Framedaten an die Host-DDI durch den OS-Kernel-Modus-Treiber und die Thunk-Schicht. Bei 454 leitet die Host-DDI die gerenderten Framedaten an einen Encoder zum Encodieren weiter, um die gerenderten Framedaten zu komprimieren. Bei 456 leitet der Encoder die encodierten komprimierten Framedaten an eine Netzwerkschnittstelle weiter zum Senden an eine Benutzervorrichtung.
-
Ausführungsformen der vorliegenden Technologie ermöglichen vorteilhafterweise, dass mehrere Grafikanwendungen gleichzeitig auf einer Server-Datenverarbeitungsvorrichtung mit mehreren Grafikverarbeitungseinheiten laufen. Ausführungsformen ermöglichen vorteilhafterweise eine erhöhte Dichte (engl. „density”) auf Grafikverarbeitungseinheit-Client-Server-Plattformen und Cloud-Datenverarbeitungsplattformen. Die Host-zu-Gast-Kommunikation ist relativ niedrig und schnell gemäß Ausführungsformen der vorliegenden Technologie, was gut für die Performance ist. In einer Implementierung mögen Aufrufe von dem Gast-OS an das Host-OS innerhalb einer Umlaufzeit (engl. „roundtrip”) von etwa 0,3 ms oder weniger stattfinden. Die physikalischen bzw. körperlichen Gast-Adressen können die physikalischen bzw. körperlichen Adressen der auf dem Basis-OS laufenden GPU überlappen, so dass es keine Duplikation gibt, was auch gut für die Performance ist. Die Anwendungen gemäß Ausführungsformen der vorliegenden Technologie sehen genuine Operativsystemdateien (engl. „genuine operating system files”), die für Antibetrugstechniken (engl. „anti-cheat techniques”) und Digitales-Rechtemanagement-Techniken (engl. „digital rights management techniques”) robust sind. Die Anwendungen haben den Eindruck, dass sie Vollbild laufen, was auch gut für die Performance ist. Die Benutzer-Modus-Treiber laufen in der Virtuelle-Maschine, die gedeckelt (engl. „capped”), aufgesteckt (engl. „pinned”), gedrosselt (engl. „throttled”) und/oder ähnliches zu Kernen, Threads und/oder ähnliches werden kann. Encodieren kann sich von dem Renderziel im Host ernähren (engl. „feed off the render target”), was auch gut für die Performance ist. Der Virtuelle-Maschine-Treiber kann eine FB-Größe von 1/n berichten bzw. aufweisen (engl. „report”), wobei n die Anzahl der virtuellen Maschinen ist. Das Rendering kann auf jeglicher GPU ausgeführt werden, einschließlich kopfloser Tesla (engl. „headless Tesla”), wenn diese als eine kopflose DX-Rendering-Vorrichtung angeschlossen ist.
-
Die vorhergehenden Beschreibungen spezifischer Ausführungsformen der vorliegenden Technologie wurden zwecks Illustration und Beschreibung dargestellt. Sie sind nicht als vollständig oder als die Erfindung an die genauen beschriebenen Formen begrenzend anzusehen, und viele Modifikationen und Variationen sind möglich angesichts der obigen Lehre. Die Ausführungsformen wurden ausgesucht und beschrieben, um die Prinzipien der vorliegenden Technologie und deren praktischen Anwendung bestmöglich zu beschreiben, um es damit andere Fachleute zu ermöglichen, die vorliegende Technologie und verschiedene Ausführungsformen mit verschiedenen Modifikationen, die für die beabsichtigte Verwendung geeignet sind, am besten zu verwenden. Es wird beabsichtigt, dass der Umfang der Erfindung von den hierzu angehängten Ansprüchen und deren Äquivalenten definiert wird.
