MXPA05012972A - Sistemas y metodo para virtualizar subsistemas graficos. - Google Patents

Abstract

Se proporcionan sistemas y metodos para aplicacion de maquinas virtuales a hardware de graficos. En diversas modalidades de la invencion, mientras el codigo supervisor se ejecuta en la CPU, los problemas de trabajo de graficos reales se ejecutan directamente en el hardware de graficos y el codigo supervisor se estructura como un monitor de maquina virtual de graficos. La compatibilidad de la aplicacion se retiene mediante el uso de tecnologia de monitor de maquina virtual (VMM) para ejecutar un primer sistema operativo (OS), tal como una version original de OS, de manera simultanea con un segundo OS, tal como una nueva version de OS, en maquinas virtuales separadas (VMs). La tecnologia de VMM aplicada a procesadores huesped se extiende a unidades de procesamiento de graficos (GPUs) para permitir el acceso de hardware a aceleradores de graficos, asegurando que las aplicaciones de legado operen a total desempeno. La invencion tambien proporciona metodos para hacer la experiencia del usuario cosmeticamente impecable mientras se ejecutan multiples aplicaciones en diferentes VMs. En otros aspectos de la invencion, al emplear tecnologia de VMM, la arquitectura de graficos virtualizados de la invencion se extiende para proporcionar servicios confiables y proteccion del contenido.

Description

SISTEMAS Y MÉTODOS PARA VIRTUALIZAR SUBSISTEMAS GRÁFICOS Aviso de Derechos de Autor y Permiso Una porción de la exposición de este documento de patente puede contener material que se sujeta a protección de derechos de autor. El propietario de los derechos de autor no tiene objeción a la reproducción por fax de ninguno de los documentos de patente o de la exposición de patente, según aparece en los archivos o registro de patente de la Oficina de Patentes y Marcas, pero de otro modo se reserva todos los derechos de autor. El siguiente aviso deberá aplicarse a este documento: Copyright(S) 2004, Microsoft Corp.

Campo de la Invención La presente invención se dirige a sistemas, aparatos, métodos, interfases de usuario, protocolos e interfases de programación de aplicaciones (APIs) para virtualizar subsistemas gráficos de dispositivos de cómputo. Más particularmente, la invención se dirige a arquitecturas de gráficos virtualizadas que proporcionan beneficios relacionados con compatibilidad, seguridad y administración de derechos digitales.

ANTECEDENTES A manera de antecedentes con respecto al estado de la ejecución simultánea de gráficos moderna, un subsistema de gráficos generalmente coopera con una computadora huésped para llevar a cabo ciertas labores especializadas a su favor, por ejemplo, labores que requieren, relativamente hablando, de bastante energía computacional en bruto, tal como la preparación de la salida de una aplicación para exhibición en un monitor, o impresora, u otro dispositivo. Para crear una representación gráfica de computadora 3-D, por ejemplo, los objetos por ilustrarse se representan como modelos matemáticos dentro de la computadora, los cuales son muy adecuados para el procesamiento matemáticamente intensivo por la unidad procesadora de gráficos (GPU) del subsistema de gráficos. Por ejemplo, los modelos 3-D pueden conformarse de puntos geométricos dentro de un sistema de coordenadas que consiste en un eje x, y y z, por ejemplo, correspondiente a amplitud, altura y profundidad, respectivamente. Los objetos se definen por una serie de puntos, coordenadas x, y y z (u otro sistema de coordenadas). En terminología de gráficos, un vértice es un punto, dos vértices definen una línea, o un segmento de línea, y tres vértices definen un triángulo donde los tres son "primitivos". Cuando tres o más de estos puntos se conectan se forma un polígono, siendo el triángulo el polígono más simple, el cual puede utilizarse para aproximarse a la geometría 3-D de un objeto y aplicar datos gráficos a la geometría 3-D a fin de crear una variedad de efectos artísticos y reales y transformaciones de color. La ejecución simultánea de gráficos, que utiliza sus diversas subunidades computacionales puede procesar vértices y otras corrientes de datos muy rápido y de manera eficiente para representar finalmente objetos 3-D muy complejos en un espacio de exhibición 2- D. De este modo, ciertas labores, tales como conversión y exhibición de gráficos tri-dimensionales en pantalla, típicamente involucran muchos cálculos que son muy adecuados para llevarse a cabo por un subsistema de gráficos. En un sistema de gráficos simple, tales cálculos ocurren de acuerdo con cierto nivel de procesamiento cooperativo o compartido por la unidad de procesamiento central (CPU) y la unidad procesadora de gráficos (GPU). En un escenario ejemplar, después de que se procesan las instrucciones y ocurren ciertos cálculos iniciales en la CPU, un conjunto de puntos o vértices de coordenadas que definen el objeto por convertirse se almacenan en la memoria de video para procesamiento ulterior por la GPU en la ejecución simultánea de gráficos. Si los datos son gráficos 3-D, por ejemplo, un formador de mosaicos puede fracturar los datos gráficos en simples polígonos de acuerdo con algoritmos predeterminados, diseñados para cubrir de manera eficiente la superficie del objeto que se representa - un proceso conocido como teselación. Actualmente, en la mayoría de las ejecución simultáneas de gráficos, los datos pueden operarse entonces por una o más subunidades computacionales de una GPU, tal como correctores de procedimientos, dependiendo de las instrucciones que se suministran a la GPU, la cual en cooperación con la memoria de video, es decir, el regulador de estructura, procesa los datos de acuerdo con las instrucciones de funcionamiento para los datos, y emite los datos donde se dirigen de manera adecuado, por ejemplo, hacia un dispositivo de despliegue o impresora. Como se ilustra en la Fig. 1 , con respecto a sistemas de cómputo que tienen sistemas de coprocesamiento de gráficos, los sistemas de cómputo se dividen entre la CPU huésped y el hardware de gráficos. La CPU facilita la realización de llamadas a APIs gráficos mediante aplicaciones y servicios que demandan su uso. Convencionalmente, la aplicación y circuitos excitadores se localizan en el lado de la CPU y la información proveniente de aquellas fuentes se envía como temas de trabajo a la ejecución simultánea de gráficos, tal como el despliegue de datos en un monitor. Primero, la información se envía de la CPU a la GPU, según se empaqueta por la CPU de acuerdo con APIs. Después, la información proveniente de la aplicación espera en memoria hasta que se programa y procesa por las subunidades computacionales de la GPU, tal como el(los) corrector(es) de vértice si se están procesando datos gráficos de 3-D. Después de que el(los) corrector(es) concluyen sus operaciones, la información se emite típicamente a partir del(de los) corrector(es) de vértice a través de una trayectoria de datos especial hacia el(los) corrector(es) de píxel hasta que se tiene acceso por el(los) corrector(es) de píxel para procesamiento adicional. Después de que el(los) corrector(es) de píxel han llevado a cabo sus operaciones, la información se coloca en un regulador de estructura para explorarse hacia un dispositivo de despliegue o enviarse de regreso al huésped para operación ulterior. El término "regulador de estructura" en las arquitecturas de gráficos de hoy en día generalmente se refiere a cualquier memoria (generalmente memoria de video incluida para interoperación con la GPU) utilizada en conexión con procesos de cuadriculado y/o convertidos digital a análogo (DAC). En este aspecto, aunque el término cuadriculado se utiliza algunas veces de manera más general, el procesamiento llevado a cabo en conexión con el procesamiento de pixeles o el establecimiento del procesamiento de motor en la ejecución simultánea de gráficos es generalmente . referido como cuadriculado. Por otro lado, Emisión de exploración o de DAC es el proceso de transmitir señales a un monitor o LCD en base a los contenidos del regulador de estructura. Debido a la especialización de la labor y los recursos computacionales implicados, los subsistemas gráficos de los sistemas de computadora se utilizan comúnmente para exhibir objetos gráficos en una pantalla de despliegue. El propósito de los gráficos por computadora tri-dimensionales (3-D) es generalmente crear imágenes de dos dimensiones (2-D) en una pantalla de computadora que realmente representa un objeto u objetos en tres dimensiones. En el mundo real, los objetos ocupan tres dimensiones que tienen una altura real, una amplitud real y una profundidad real. Una fotografía es un ejemplo de una representación 2-D de un espacio 3-D. Los gráficos de computadora 3-D son generalmente como una fotografía ya que representan un mundo 3-D en el espacio 2-D de una pantalla de computadora, excepto que la imagen subyacente se modela generalmente con geometría 3-D y texturas superficiales. Las imágenes creadas con gráficos de computadora 3-D se utilizan en un amplio rango de aplicaciones, desde juegos de entretenimiento en video hasta simuladores de vuelo espaciales, para pincelar en una manera realista una vista individual de una escena en un punto de tiempo dado. Los ejemplos muy conocidos de gráficos de computadora 3-D incluyen efectos especiales en películas de Hollywood tales como Terminador II, Jurassic Park, Toy Story y lo similar. Una industria que ha observado una cantidad particularmente tremenda de crecimiento en los últimos años es la industria de juegos por computadora y la generación actual de juegos por computadora aplica técnicas de gráficos 3-D en una manera siempre creciente. Al mismo tiempo, la velocidad de juego se dirige cada vez más rápido. Esta combinación ha dado origen a una genuina necesidad de conversión rápida y flexible de gráficos 3-D en sistemas relativamente económicos. Sin embargo, de acuerdo con estas líneas de tendencia a moverse rápidamente asociadas con subsistemas gráficos, la compatibilidad, seguridad y manejo de derechos se han desarrollado correspondientemente como temas. Ya que cada nueva generación de GPUs y hardware asociada reemplaza a la generación previa, además del hardware, las interfaces a la ejecución simultánea (por ejemplo, DirectX8, DirectX9, GDI , GDI+, etc.) tienen que desarrollarse y si se espera que manejen llamadas a interfaces "antiguas", entonces necesita escribirse un código separado que asegure el soporte de hardware más viejo. Después de unas cuantas generaciones más, disminuye la probabilidad de que el código de interfase de gráficos de cualquier sistema operativo en particular permanezca manejable y se incrementa la probabilidad de errores en el manejo debido a llamadas de función incompatibles ya que los efectos de la salida de elementos del código de compatibilidad se arraigan. Un problema adicional es que las "deformaciones" separadas del código de interfase de gráficos se desarrollan en virtud de la existencia de diferentes sistemas operativos, o plataformas (Macintosh, Linux, Windows, etc.), o incluso diferentes deformaciones incluidas en la misma plataforma (por ejemplo, OpenGL, GDI + , DirectX, etc.). De este modo, aún existen problemas por los cuales las diferentes versiones de sistemas operativos, interfases de gráficos y hardware asociado pueden no co-soportarse todos y estos problemas se vuelven más complicados con el tiempo. Sería deseable aliviar este problema sin tener que modificar el código núcleo proporcionado con cualquier sistema operativo en particular o conjunto de interfases. Con el mismo escenario de fondo, los problemas de seguridad y protección de contenido/manejo de derechos digitales (DR ) se vuelven más complicados de resolver en conexión con la ejecución simultánea de gráficos. Con diferentes sistemas operativos, interfaces y hardware, no existe un mecanismo común que refuerce la seguridad de los datos y refuerce la protección de contenido/condiciones de manejo de derechos digitales a través de toda la ejecución sim ultáneas conocidas. De este modo, se desea una manera o estrato común para dirigir los problemas sobre seguridad de datos y/o DRM que trabaje de manera independiente a la ejecución sim ultánea de gráficos. Por lo tanto, sería deseable virtualizar la ejecución simultánea de gráficos de un sistema de computadora para proporcionar una máq uina virtual como un estrato de interacción de entre el procesador huésped y la GPU . Sería deseable además implementar sistemas y métodos que superen las inconveniencias de presentar temas de compatibilidad, seguridad y protección de contenido/DRM q ue se encuentran cuando se utilizan diversas versiones de sistemas operativos o interfaces de diversas arquitecturas de GPU's.

BREVE DESCRIPCIÓN DE LA I NVENCIÓN En consideración a lo arriba identificado y otros inconvenientes de la materia, la presente invención proporciona sistemas y métodos para la aplicación de máquinas virtuales al espacio de hardware de gráficos. En diversas modalidades de la invención, mientras el código supervisor se ejecuta en la CPU , los temas de trabajo de gráficos reales se ejecutan directamente en el hardware de g ráficos. En una modalidad no limitante, el código supervisor se estructura como un monitor de máquina virtual de g ráficos. La compatibilidad de la aplicación se retiene mediante el uso de tecnolog ía de monitor de máquina virtual (VMM) para ejecutar un primer sistema operativo (OS) , tal como una versión original de OS, de manera simultánea con un segundo OS, tal como una nueva versión de OS , en máquinas virtuales separadas (VMs) . En una modalidad, la tecnología de VMM aplicada a procesadores huésped se extiende a unidades de procesamiento de gráficos (G PUs) para permitir el acceso de hardware a aceleradores de gráficos, aseg urando que las aplicaciones legales operen a total desempeño. La invención también proporciona métodos para hacer la experiencia del usuario cosméticamente impecable mientras se ejecutan múltiples aplicaciones en diferentes VMs. En otros aspectos de la invención, al emplear tecnolog ía de VMM, la arquitectura de gráficos virtualizados de la invención se extiende para proporcionar servicios confiables y protección de contenido. Otras ventajas y características de la invención se describen a continuación.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Los sistemas y métodos para virtualizar GPUs de acuerdo con la presente invención se describen además con relación a los dibujos acompañantes, en los cuales: La Fig ura 1 es un diagrama de bloque que ilustra una ¡mplementación de la técnica anterior de una ejecución simultánea de gráficos; La Figura 2A es un diagrama de bloque que representa la estratificación lógica del hardware y la arquitectura de software para un ambiente operativo emulado en un sistema de computadora; La Figura 2B es un diagrama de bloque que representa un sistema de cómputo virtualizado en donde la emulación se lleva a cabo por el sistema operativo huésped (ya sea directamente o a través de un hipervisor); La Figura 2C es un diagrama de bloque que representa un sistema de cómputo virtualizado alternativo en donde la emulación se lleva a cabo por un monitor de máquina virtual que se ejecuta lado a lado con un sistema operativo huésped; La Figura 3A ilustra una primer arquitectura no limitante para la aplicación de máquinas virtuales al espacio de hardware de gráficos mediante lo cual el código supervisor se ejecuta en la CPU, pero los temas de funcionamiento de gráficos se manejan directamente por el hardware de gráficos; La Figura 3B ¡lustra otro arquitectura no limitante ejemplar, proporcionada para virtualizar la ejecución simultánea de gráficos de acuerdo con la invención; La Figura 4A ilustra una modalidad para exhibir un "solo escritorio a la vez" de acuerdo con la invención; La Figura 4B ilustra una modalidad alternativa de "escritorio en una ventana", mediante lo cual todos los escritorios pueden exhibirse simultáneamente de acuerdo con la invención; La Figura 4C ilustra una arquitectura ejemplar para intermezclar datos de aplicación confiable y no confiable de acuerdo con la invención; La Figura 4D ilustra una extensión de una división confiable para incluir una vía de acceso de inter-operabilidad de medios, como un estrato separado de protección de contenido; La Figura 4E ilustra una interacción ejemplar en donde una ejecución de aplicación legal de OS Huésped en un OS huésped interactúa con un componente de servicios legales del OS Huésped para emular el comportamiento legal; La Figura 5 es un diagrama de flujo que representa una secuencia no limitante de procesamiento de datos gráficos de acuerdo con una o más modalidades de las arquitecturas de gráficos virtualizados, proporcionadas de acuerdo con la invención; La Figura 6A es un diagrama de bloque que representa un ambiente de trabajo en red ejemplar que tiene una variedad de dispositivos de cómputo en los cuales puede implementarse la presente invención; y La Figura 6B es un diagrama de bloque que representa un dispositivo de cómputo no limitante, ejemplar, en el cual puede implementarse la presente invención.

DESCRIPCIÓN DETALLADA DE LA MODALIDAD ILUSTRATIVA Panorama General Como se mencionó, la presente invención proporciona sistemas y métodos para la aplicación de máquinas virtuales al espacio de hardware de gráficos. En diversas modalidades de la invención, mientras el código supervisor, tal como un monitor de máquina virtual de gráficos, se ejecuta en la CPU, los temas de trabajo de gráficos reales se ejecutan directamente en el hardware de gráficos. En un aspecto no limitante de la invención, se proporcionan sistemas y métodos para la separación de funciones de hardware de gráficos en operaciones privilegiadas y no privilegiadas y para virtualizar de manera eficiente las operaciones privilegiadas, mientras se mantiene una experiencia de usuario impecable. En otro aspecto no limitante de la invención, se logra la virtualización eficiente de procesamiento de interrupción de hardware. En aspectos adicionales, la invención proporciona capacidades de manejo de recursos en el estrato de emulación para la asignación pre-fija de recursos, tales como memoria, ciclos de procesamiento, estado real en pantalla, etc. , a divisiones y/o para asignación dinámica de tales recursos de acuerdo con la aplicación cruzada y parámetros de plataforma cruzada/necesidades del sistema. Otro resultado benéfico de la arquitectura es que la presente invención permite una división virtual para tener acceso directo al hardware de gráficos sin requerir cambios al Sistema Operativo o aplicaciones invitados. Muchas aplicaciones también se derivan de la arquitectura básica de la invención. Por ejemplo, el código legal puede dejarse en Sistemas Operativos antiguos que utilizan una instancia del Sistema Operativo legal para la ejecución de aplicaciones dependientes del código legal. Otro ejemplo es la idea de construir servicios confiables y no confiables, lo cual a su vez puede utilizarse para soportar emisión de gráficos confiables o técnicas de protección del contenido. Otros sistemas y métodos proporcionados de acuerdo con la invención se refieren a la experiencia del usuario. Con múltiples divisiones, una experiencia de usuario proporcionada por la invención es el enfoque de "escritorio en una ventana" donde el escritorio exhibido para cada Sistema Operativo invitado se re-dirige a una ventana (o vista de escritorio alternativa) en el dispositivo de desplieg ue (o múltiples dispositivos de despliegue en el caso de monitores múltiples, algunas veces conocidos como "multimon"). En otras modalidades, la invención habilita una experiencia de usuario que permite que la ventana de diferentes Sistemas Operativos invitados se entremezclen en un solo despliegue unificado, mediante lo cual los "pixeles" asociados con cualquier ventana en particular se identifican . En una modalidad, la invención logra la identificación de pixeles y sus asociaciones de ventana mediante la adición de "prog ramas auxiliares" a los sistemas operativos invitados a fin de identificar las partes de diversas ventanas. En otras modalidades , la invención permite la interacción con el "administrador de ventanas" invitado para asegurar que la ventana no obstruida en el escritorio principal no se encuentre obstruida en el escritorio virtual de los Sistemas Operativos invitados a fin de que puedan extraerse y exhibirse en el escritorio principal . En otras modalidades, el soporte de hardware de gráficos se proporciona para ayudar parcialmente o por entero a identificar ubicaciones de memoria de pixeles provenientes de diferentes ventanas. La invención también incluye modalidades que proporcionan soporte de hardware de gráficos adicionales para ayudar a la administración de las ventanas en el escritorio virtual. Aunque un área donde los futuros Sistemas Operativos pueden agregar soporte para hacer más fácil esta tarea, la idea es permitir una estructura que identifique ventanas individuales provenientes de diferentes Sistemas Operativos invitados y hacer disponibles los datos a un servicio de presentación unificado (también algunas veces referido como un motor de composición de escritorio) que compone las fuentes múltiples. Este motor tiene acceso al estado de memoria de gráficos de múltiples invitados, mientras que los invitados normalmente no pueden ver entre sí las llamadas de función y actividades de los otros. Un enfoque que habilita los efectos de la compleja composición estratificada en la emisión de despliegue con relación al contenido de los OSs I nvitados respectivos es tener un contenido de ventana de "atracción" del motor de presentación de diferentes OSs Invitados con objeto de construir el escritorio compuesto. Un enfoque alterno es permitir que los OSs Invitados se conviertan directamente en un solo escritorio principal, es decir, se conviertan a esa memoria, pero utilicen soporte de hardware especial que limite las partes del escritorio a las cuales pueda arrastrarse los OSs Invitados. Por ejemplo, las regiones permisibles pueden controlarse mediante el uso de un mecanismo privilegiado separado, similar al mecanismo utilizado para sujeción de ventana de hardware en donde una lista de rectángulos, o un mapa de bits, define una máscara que indica cuáles pixeles pueden escribirse. Uno podría implementar que estos es una operación de "empuje" donde los OSs I nvitados se arrastran directamente hacia el escritorio y los controles del motor de presentación donde se encuentra(n) la(s) región(es) escribible(s) para cada OS I nvitado. En otras diversas modalidades, la invención proporciona sistemas y métodos para la identificación y localización de pixeles de ventanas convertidas por un primer OS y ventanas convertidas por un segundo OS y la presentación de las ventanas ya sea una a la vez o combinadas en conjunto de cierta manera para despliegue. La invención también incluye sistemas y métodos para la colocación y asignación de recursos físicos, tal como video o memoria de sistema, a un segundo OS, de tal manera que los recursos asignados son directamente accesibles y los recursos no asignados no son accesibles por el segundo OS. La invención proporciona además sistemas y métodos para interceptar y emular de manera eficiente las operaciones privilegiadas. Otros aspectos más detallados de la invención se describen abajo, pero primero, la siguiente descripción proporciona un panorama general de cierto vocabulario común para máquinas virtuales y la terminología asociada ya que los términos tienen que conocerse en conexión con los sistemas operativos y las técnicas de virtualización del procesador huésped ("CPU") . Al hacerlo, se establece un conjunto de vocabulario que un experto en la materia puede encontrar útil para la descripción que sigue del aparato, sistemas y métodos para la proporción de capacidades de emulación para el lado del subsistema de gráficos de los sistemas de cómputo de acuerdo con la invención. Panorama General de Máquinas Virtuales Las computadoras incluyen unidades centrales de procesamiento (CPUs) de propósito general o "procesadores" que se diseñan para ejecutar un conjunto específico de instrucciones del sistema. Un grupo de procesadores que tienen arquitectura o especificaciones de diseño similares pueden considerarse miembros de la misma familia de procesador. Los ejemplos de familias de procesador actuales incluyen la familia de procesador Motorota 680X0, fabricada por Internacional Business Machines (I BM) o Motorota, Inc. de Phoenix, Arizona; la familia de procesador Intel 80X86, fabricada por Intel Corporation de Sunnyvale, California; y la familia de procesador PowerPC, la cual se fabrica por Motorota, I nc y se utiliza en computadoras fabricadas por Apple Com puter, Inc. de Cupertino, California. Aunque un grupo de procesadores puede encontrarse en la misma familia debido a su arquitectura similar y consideraciones de diseño, los procesadores pueden variar ampliamente dentro de una familia de acuerdo con su velocidad de reloj y otros parámetros de desempeño. Cada familia de microprocesadores ejecuta instrucciones que son únicas para la familia del procesador. El conjunto colectivo de instrucciones que un procesador o fam ilia de procesadores puede ejecutar se conoce como el conjunto de instrucciones del procesador. Como un ejemplo, el conjunto de instrucciones utilizado por la familia de procesador I ntel 80X86 es incompatible con el conj unto de instrucciones utilizado por la familia de procesador PowerPC. El conjunto de instrucciones Intel 80X86 se basa en el formato de Computadora de Conjunto de I nstrucciones Complejas (CISC). El conjunto de instrucciones de PowerPC de Motorota se basa en el formato de Computadora de Conjunto de Instrucciones Reducido (RISC). Los procesadores CISC utilizan un gran número de instrucciones, algunas de las cuales pueden llevarse a cabo en vez de funciones complicadas, pero requieren generalmente que se ejecuten muchos ciclos de reloj . Los procesadores RISC utilizan un número menor de instrucciones disponibles para llevar a cabo un conjunto más simple de funciones que se ejecutan a mucha mayor velocidad. La unicidad de la familia del procesador entre los sistemas de com putadora también da típicamente como resultado incompatibilidad entre los otros elementos de la arquitectura de hardware de los sistemas de computadora. Un sistema de computadora fabricado con un procesador de la familia de procesadores Intel 80X86 tendrá una arquitectura de hardware que es diferente de la arquitectura de hardware de un sistema de computadora fabricado con un procesador de la familia de procesadores PowerPC. Debido a la unicidad del conjunto de instrucciones del procesador y a una arquitectura de hardware del sistema de la computadora, los programas de software de aplicación se escriben típicamente para ejecutarse en un sistema de computadora en particular que ejecuta un sistema operativo en particular. Hablando en general, los fabricantes de computadoras tratan de maximizar su compatibilidad de mercado al tener más en vez de menos aplicaciones ejecutándose en la familia de microprocesador asociadas con la línea de productos de los fabricantes de computadoras. Para expandir el número de sistemas operativos y programas de aplicación que pueden ejecutarse en un sistema de computadora, se ha desarrollado un campo de tecnología en el cual una computadora dada que tiene un tipo de CPU, llamada un huésped, incluirá un programa virtualizador que permite a la computadora huésped emular las instrucciones de un tipo no relacionado de CPU, llamada un invitado. De este modo, la computadora huésped ejecutará una aplicación que originará que una o más de las instrucciones del huésped sean llamadas a responder a una instrucción dada del invitado, y de esta manera la computadora huésped puede ejecutar tanto el software diseñado para su propia arquitectura de hardware así como también el software escrito para computadoras que tienen una arquitectura de hardware no relacionada. Como un ejemplo más específico, un sistema de computadora fabricado por Apple Computer, por ejemplo, puede ejecutar sistemas operativos y programas escritos para sistemas de computadora a base de PC. También puede ser posible utilizar prog ramas virtualizadores para ejecutar de manera concurrente en sistemas operativos incompatibles de múltiples CPU individuales. En esta última instalación, aunque cada sistema operativo es incom patible con el otro, los programas virtualizadores pueden alojar cada uno de los diversos sistemas operativos y permitir así que los sistemas operativos de otro modo incompatibles se ejecuten de manera concurrente en el mismo sistema de computadora huésped . Cuando un sistema de computadora invitado se emula en un sistema de computadora huésped, el sistema de computadora invitado se dice que es una "máquina virtual" ya que el sistema de computadora invitado solo existe en el sistema de computadora huésped como una pura representación de software de la operación de una arquitectura de hardware específica. Los términos virtualizador, em ulador, ejecutor-directo, máquina virtual y emulación del procesador se utilizan algunas veces de manera intercambiable para denotar la habilidad de imitar o emular la arquitectura de hardware de un sistema de computadora entero que utiliza uno o varios enfoques conocidos y apreciados por aquellos de experiencia en la materia. Además, todos los usos del término "emulación" en cualquier forma se intenta que abarquen este amplio significado y no se intenta distinguir entre los conceptos de ejecución de instrucción de la emulación contra la ejecución directa de las instrucciones del sistema operativo en la máquina virtual. De este modo, por ejemplo, el software de PC Virtual creado por Connectix Corporation de San Mateo, California "emula" (por emulación de la ejecución de instrucciones y/o ejecución directa) una computadora entera que incluye un procesador Pentium Intel 80X86 y diversos componentes y tarjetas del panel principal, y la operación de estos componentes se "emula" en la máquina virtual que se está ejecutando en la máquina huésped. Un programa virtualizador que se ejecuta en el software de sistema operativo y arquitectura de hardware de la computadora huésped, tal como un sistema de computadora que tiene un procesador PowerPC, imita la operación del sistema de computadora invitado por entero. El caso general de virtualización permite que una arquitectura de procesador ejecute OSs y programas para otras arquitecturas de procesador (por ejemplo, programas PowerPC Mac en Windows x86, y viceversa), pero un caso especial importante es cuando las arquitecturas de procesador subyacentes son las mismas (se ejecutan diversas versiones de Linux x86 o diferentes versiones de Windows x86 en x86). En este último caso, existe el potencial de ejecutar el OS Invitado y sus aplicaciones de manera más eficiente ya que el conjunto de instrucciones subyacentes son el mismo. En tal caso, las instrucciones del Invitado se permiten ejecutar directamente en el procesador sin perder el control o dejar que el sistema abierto ataque (es decir, el OS Invitado se encajona). Como se describe abajo en detalle, es aquí donde la separación de privilegiados contra no privilegiados y las técnicas de control de acceso a la memoria se ponen en juego. Para la virtualización donde existe una diferencia arquitectónica (PowerPC <-> x86), podrían utilizarse dos enfoques: emulación de instrucción-por-instrucción (relativamente lenta) o traducción del conjunto de instrucciones Invitadas al conjunto de instrucciones nativas (más eficiente, pero utiliza la etapa de traducción). Si se utiliza la emulación de instrucciones, entonces es relativamente fácil hacer fuerte al ambiente; sin embargo, si se utiliza traducción, entonces se regresa al caso especial donde las arquitecturas de procesador son la misma. De acuerdo con la invención, las plataformas de gráficos se virtualizan y por lo tanto un escenario ejemplar de acuerdo con la invención de aplicación a arquitecturas de gráficos sería la emulación de una tarjeta ATI que utiliza hardware Nvidia. Para el caso de virtualización de gráficos, en diversas modalidades, la invención se enfoca a la ejecución directa de órdenes a partir de la misma arquitectura de gráficos. En el contexto de gráficos, el eq uivalente de la traducción no existe realmente, o más bien la emulación y la traducción resultan ser la misma cosa. La traducción funciona en el procesador debido a que una vez que se traduce el código, el código puede ejecutare múltiples veces, amortizando así el costo de traducción. Sin embargo, debido a la manera como se estructuras las aplicaciones de gráficos, el equivalente de un programa para traducir (ignorando correctores) no necesariamente existe. En su lugar, la corriente de órdenes (lista de temas de trabajo) se regenera constantemente a fin de que no exista necesariamente ningún reuso que pueda amortizar el costo de traducción . En una modalidad más compleja, la lista de temas de trabajo podría examinarse para determinar si concuerdan en una lista pre-traducida. Como se describe en diversas modalidades a continuación , de acuerdo con diversas modalidades de la invención, la virtualización aunque ejecute directamente instrucciones del Invitado (ya sea proveniente de traducción o debido a q ue se implica la misma arquitectura de procesador) tiene un beneficio de desempeño si la seguridad del sistema puede mantenerse. En diversas modalidades, la invención describe así métodos y sistemas para controlar el acceso del I nvitado a alguno o todos los recursos físicos subyacentes (memoria, dispositivos, etc.) El programa virtualizador actúa como el intercambio entre la arquitectura de hardware de la máquina huésped y las instrucciones transmitidas por el software (por ejemplo, sistemas operativos, aplicaciones, etc.) que se ejecutan dentro del ambiente emulado. Este programa virtualizador puede ser un sistema operativo huésped (HOS) , el cual no es un sistema operativo que se ejecuta directamente en el hardware de computadora física (y el cual puede comprender un hipervisor, discutido con mayor detalle posteriormente en la presente). De manera alternativa, el ambiente emulado podría ser también un monitor de máquina virtual (VMM) que es un estrato de software que se ejecuta directamente por encima del hardware, tal vez ejecutándose lado a lado y trabajando en conjunto con el sistema operativo huésped, y el cual puede virtualizar todos los recursos de la máquina huésped (así como también ciertos recursos virtuales) al exponer interfases q ue son iguales que el hardware la VMM se está visualizando. Esta virtualización permite que el virtualizador (así como también el sistema de computadora huésped en sí) no tenga noticia de los estratos de sistema operativo que se ejecutan sobre éste. La emulación del procesador permite así que un sistema operativo invitado se ejecute en una máquina virtual creada por un virtualizador que se ejecuta en un sistema de computadora huésped que comprende tanto hardware físico como también un sistema operativo huésped. Desde una perspectiva conceptual, los sistemas de computadora generalmente comprenden uno o más estratos de software que se ejecuta en un estrato fundacional de hardware. Esta estratificación se realiza por razones de abstracción. Al definir la inferíase para un estrato dado de software, este estrato puede implementarse de manera diferente por otros estratos sobre éste. En un sistema de computadora bien diseñado, cada estrato conoce solo acerca (y solo depende de) el estrato intermedio por debajo de éste. Esto permite que un estrato o una "pila" (múltiples estratos adjuntos) se reemplacen sin impactar de manera negativa los estratos por encima de dicho estrato o pila. Por ejemplo, las aplicaciones de software (estratos superiores) típicamente dependen de niveles inferiores del sistema operativo (estratos inferiores) para escribir archivos hasta cierta forma de almacenamiento permanente, y estas aplicaciones no necesitan entender la diferencia entre datos de escritura para un disco flexible, una unidad de disco duro o un plegador de red. Si este estrato inferior se reemplaza con nuevos componentes de sistema operativo para archivos de escritura, la operación de las aplicaciones de software de estrato superior permanece sin afectar. La flexibilidad del software estratificado permite que una máquina virtual (VM) presente un estrato de hardware virtual que es, de hecho, otro estrato de software. De esta manera, una VM puede crear la ilusión para los estratos de software por encima de ésta de que los estratos de software se ejecutan en su propio sistema de computadora privado y, de este modo, las VMs pueden permitir que múltiples "sistemas invitados" se ejecuten de manera concurrente en un solo "sistema huésped". Este nivel de abstracción se representa por la ilustración de la Fig. 2A. La Fig. 2A es un diagrama que representa la estratificación lógica del hardware y arquitectura de software para un ambiente operativo emulado en un sistema de computadora. En la figura, un programa de emulación 94 se ejecuta de manera directa o indirecta en un la arquitectura de hardware física 92. El programa de emulación 94 puede ser (a) un monitor de máquina virtual que se ejecuta junto con un sistema operativo huésped, (b) un sistema operativo huésped especializado que tiene capacidades de emulación nativas o (c) un sistema operativo huésped con un componente hipervisor en donde dicho componente hipervisor lleva a cabo dicha emulación. El programa de emulación 94 emula una arquitectura de hardware invitada 96 (mostrada como líneas fraccionadas para ilustrar el hecho de que este componente es la "máquina virtual" es decir, hardware que no existe realmente sino más bien se emula por dicho programa de em ulación 94) . Un sistema operativo invitado 98 se ejecuta en dicha arquitectura de hardware invitada 96, y la aplicación de software 1 00 se ejecuta en el sistema operativo invitado 98. En el ambiente operativo emulado de la Fig. 2A - y debido a la operación del programa de emulación 94 - la aplicación de software 1 00 puede ejecutarse en el sistema de computadora 90 incluso si la aplicación de software 1 00 se encuentra diseñada para ejecutarse en un sistema operativo que es generalmente incompatible con el sistema operativo huésped y la arquitectura de hardware 92. La Fig. 2B ilustra un sistema de cómputo virtualizado que comprende un estrato de software de sistema operativo huésped 104 que se ejecuta directamente . por encima del hardware de computadora físico 1 02 donde el sistema operativo huésped (OS huésped) 104 proporciona acceso a los recursos del hardware de computadora físico 102 al exponer las interfases que son iguales al hardware del OS huésped que se está emulando (o "virtualizando") - lo cual , a su vez, permite que el OS huésped no tenga noticia de los estratos de sistema operativo que se ejecutan sobre éste. Nuevamente, para llevar acabo la emulación, el sistema operativo huésped 1 02 puede ser un sistema operativo especialmente diseñado con capacidades de em ulaciones nativas o, alternativamente, puede ser un sistema operativo estándar con un componente hipervisor incorporado para llevar a cabo la emulación (no mostrado). Refiriéndose nuevamente a la Fig. 2B, por encima del OS huésped 1 04 se encuentran dos implementaciones de máquinas virtuales (VM), VM A 108, la cual puede ser, por ejemplo, un procesador Intel 386 virtualizado, y la VM B 1 1 0, la cual puede ser, por ejemplo, una versión virtualizada de uno de los procesadores de la familia Motorota 680X0. Por encima de cada VM 108 y 1 10 se encuentran los sistemas operativos invitados (OSs invitados) A 1 12 y B 1 14, respectivamente. Ejecutándose por encima del OS A invitado 1 12 se encuentran dos aplicaciones, la aplicación A1 1 1 6 y la aplicación A2 1 18 y ejecutándose por encima del OS B invitado 1 4 se encuentra la aplicación B 1 120. Con respecto a la Fig. 2B, es importante observar que la VM A 1 08 y VM B 1 10 (las cuales se muestran en líneas fracturadas) son representaciones de hardware de computadora virtualizadas que existen solamente como construcciones de software y las cuales se hacen posibles debido a la ejecución de software(s) de emulación especializado(s) que no solo presentan VM A 108 y VM B 1 1 0 al OS I nvitado A 1 12 y OS Invitado B 1 14, respectivamente, sino que también llevan a cabo todas las etapas de software necesarias para que el OS I nvitado A 1 12 y el OS I nvitado B 1 14 ¡nteractúen de manera indirecta con el hardware de computadora físico real 102. La FIG. 2C ilustra un sistema de cómputo virtualizado, alternativo, en donde la emulación se lleva a cabo a través de un monitor de máquina virtual (VMM) 104' que se ejecuta junto con el sistema operativo huésped 104". Para ciertas modalidades, la VMM puede ser una aplicación que se ejecuta por encima del sistema operativo huésped 104y que interactúa con el hardware de computadora solo a través de dicho sistema operativo huésped 104. En otras modalidades, y como se muestra en la Fig. 2C, el VMM puede comprender en su lugar un sistema de software parcialmente independiente que en algunos niveles interactúa de manera indirecta con el hardware de computadora 102 a través del sistema operativo huésped 104, pero en otros niveles, el VMM interactúa directamente con el hardware de computadora 102 (similar a la manera como interactúa el sistema operativo huésped directamente con el hardware de computadora ). Y en todavía otras modalidades, el VMM puede comprender un sistema de software completamente independiente que interactúa en todos los niveles con el hardware de computadora 102 (similar a la manera como interactúa el sistema operativo huésped directamente con el hardware de computadora) sin utilizar el sistema operativo huésped 104 (aunque interactuando aún con dicho sistema operativo huésped 104 siempre y cuando en coordinación con el uso de dicho hardware de computadora 102 y evitando conflictos y lo similar). Todas estas variaciones de implementación de la máquina virtual se anticipan para formar modalidades alternativas de la presente invención, según se describe en la presente, y nada en la misma debe interpretarse como limitante a la invención respecto a ninguna modalidad de emulación en particular. Además, cualquier referencia a interacción entre aplicaciones 1 16, 1 18 y 1 20 a través de la VM A 1 08 y/o VM B 1 1 0 respectivamente (presumiblemente en un escenario de emulación de hardware) debe interpretarse que es, de hecho, una interacción entre las aplicaciones 1 16 , 1 18 y 1 20 y el virtualizado que ha creado la virtuaiización. De igual modo , cualquier referencia a interacción entre aplicaciones VM A 1 08 y/o VM B 1 10 con el sistema operativo huésped 1 04 y/o el hardware de computadora 102 (presumiblemente para ejecutar instrucciones de manera directa o indirecta en el hardware de computadora 102) debe interpretarse que es, de hecho, una interacción entre el virtualizador que ha creado la virtuaiización y el sistema operativo huésped 104 y/o el hardware de computadora 1 02, según sea lo adecuado.

Sistemas y Métodos para Virtualizar GPUs y la Ejecución simultánea de Gráficos Como se mencionó, la presente invención proporciona sistemas y métodos para la aplicación de máquinas virtuales al espacio de hardware de gráficos mediante lo cual el código supervisor se ejecuta en la CPU, pero los temas de trabajo de gráficos se manejan directamente por el hardware de gráficos. La Fig. 3A ilustra una primer arquitectura no limitante que ilustra algunos conceptos generales. Por ejemplo, según se ¡lustra aquí, existe un monitor de máquina virtual 304 estratificado sobre la parte superior del hardware de gráficos 302 de un dispositivo de cómputo. En una manera no limitante, esta modalidad trata el OS huésped de manera similar al OS invitado ya que recibe una máquina virtual. El OS huésped 31 0 que ejecuta App H1 y App H2 se aloja por la máquina virtual huésped 308. El OS Invitado A 330 que ejecuta App A1 se aloja por la máquina virtual A 328. El OS invitado B 340 que ejecuta App B1 se aloja por la máquina virtual B 338. En una modalidad no limitante, el código supervisor se estructura como un monitor de máquina virtual de gráficos. Un propósito de la invención es proporcionar soporte continuo para software de gráficos antiguos en Sistemas Operativos más recientes, y las diversas arquitecturas virtualizadas de la invención logran este propósito. Las soluciones que contienen la funcionalidad antigua hacia el nuevo Sistema Operativo meramente complican el nuevo Sistema Operativo, un resultado por evitarse de acuerdo con las arquitecturas de la invención. Las soluciones proporcionadas de acuerdo con la invención incluyen la ejecución de una versión virtual de un Sistema Operativo antiguo junto con el nuevo Sistema Operativo y soportando solo el software de gráficos antiguo en el caso del Sistema Operativo antiguo. Esto conlleva la noción de máquinas virtuales y monitores de máquinas virtuales, según se describe en la sección anterior, y se utiliza en productos comercialmente disponibles como PC Virtual y VMware. Sin embargo, en estas arquitecturas a base de PC, el software de gráficos en una "división" de Sistema Operativo virtual se emula con frecuencia y se lleva a cabo de manera mucho mas lenta que en la implementación no virtuallzada original. De este modo, de acuerdo con la invención, la pila de software de gráficos se permite continuar teniendo acceso al hardware de gráficos subyacentes mientras se ejecuta bajo el sistema operativo antiguo (es decir, invitado). Esto es similar a lo que se conoce como un monitor de máquina virtual de Tipo II donde un sistema operativo invitado puede ejecutarse directamente en el procesador sin costosa emulación por el monitor de máquina virtual. Se requiere soporte en el hardware de gráficos para permitir que las divisiones múltiples del Sistema Operativo se ejecuten en el hardware de gráficos sin conocimiento entre sí y sin darse cuenta de que el hardware de gráficos se ha virtualizado. De este modo, de acuerdo con modalidades de la invención, un monitor de máquina virtual de gráficos administra los recursos y controla cuál división se ejecuta en el hardware de gráficos. Mediante el uso de la invención, múltiples sistemas operativos invitados pueden ejecutarse en paralelo y cada uno tiene acceso directo a velocidad total (casi) al hardware de gráficos. Algunos invitados pueden ser Sistemas Operativos de legado que ejecutan software más antiguo, mientras que otros invitados pueden realizar otras labores específicas. La extensión de la invención conduce a modalidades que proporcionan procesamiento seguro, en donde el procesamiento seguro puede ejecutarse en cualquiera de los sistemas operativos "huésped" o "invitado". El logro de esto de acuerdo con la invención es un efecto ventajoso de la virtualización fuerte y segura del hardware de gráficos, de tal manera que los Sistemas Operativos no pueden interferir entre sí. Si los Sistemas Operativos invitados no pueden interferir entre sí, entonces la posibilidad de software de identificación que opera de manera desconocida para el usuario en un Sistema Operativo invitado diferente se elimina. El sistema trata el monitor de máquina virtual como una base confiable o "nodulo confiable". En diversas modalidades de la invención, la base confiable puede extenderse hacia otro Sistema Operativo invitado (o el huésped) para proporcionar servicios gráficos confiables adicionales (en vez de colocar todos los servicios en el monitor o nodulo de máquina virtual). Estos servicios pueden incluir el control sobre lo que es visible en el despliegue, por ejemplo, con un administrador de ventanas o motor de composición de escritorio, confiables o seguros. Esto permite que una mezcla de aplicaciones se ejecute en divisiones del sistema operativo confiables o no confiables con emisión unificada a través de un solo dispositivo de gráficos físico (o múltiples). La base segura puede extenderse además, de acuerdo con la invención, para proporcionar un sistema más fuerte para habilitar protección del contenido, por ejemplo, para dar soporte a los derechos digitales anexos a un documento, video, audio, etc. Tal sistema equilibra los servicios confiables que operan en el monitor de máquina virtual confiables y la(s) división(es) confiable(s) para reforzar los derechos digitales. Sin embargo, la interfase de usuario y otras funciones en aplicaciones de reproducción (administración de biblioteca de medios, listas de reproducción, etc.) puede separarse y ejecutarse en una división no confiable que se comunica con los servicios seguros en las divisiones confiables. A medida que los clientes se mueven a nuevos sistemas operativos y nuevas versiones de sistema operativo, la compatibilidad se ha asegurado básicamente mediante preservación diligente de interfases de software y comportamientos obsoletos, exigiendo una penalidad siempre creciente durante ciclos de desarrollo. La complejidad del diseño e implementación se incrementa y el riesgo de fracturar de manera inadvertida un comportamiento de legado persiste a través de todo el ciclo de desarrollo. De acuerdo con lo anterior, la invención propone una estrategia de desarrollo alterno en la cual el comportamiento de legado puede elegir seguramente a partir de nuevo desarrollo mientras protege aún las inversiones del cliente. La compatibilidad de aplicación se retiene mediante el uso de tecnología de monitor de máquina virtual (VMM) para ejecutar la versión de OS original de manera simultánea con el nuevo OS en máquinas virtuales separadas (VMs). La tecnología de VMM tradicional de una máquina huésped se extiende a unidades de procesamiento de gráficos (GPUs) para permitir el acceso del hardware a aceleradores de gráficos, asegurando que las aplicaciones de legado operen a total desempeño. La invención también proporciona métodos para hacer cosméticamente impecable la experiencia del usuario mientras se ejecutan múltiples aplicaciones en diferentes VMs. En otros aspectos de la invención, al emplear tecnología de VMM, la arquitectura de gráficos virtualizados de la invención se extiende para proporcionar servicios confiables y protección de contenido/administración de derechos digitales. El éxito del software a largo plazo inevitablemente conduce a interfases de software y comportamientos de legado. Los requisitos contradictorios de nueva innovación de software y la compatibilidad con lo anterior conduce a ciclos de diseño de software más complejos y que se llevan más tiempo. Los intentos por modernizar la complejidad de crecimiento al descartar bits selectos de legado utilizan más recursos para evaluar las decisiones, agregando riesgos si se toman las decisiones incorrectas, y proporciona invariablemente un alivio marginal. El resultado neto es un paso glacial de innovación y entrega en tecnologías de núcleo y focos de atención sobre innovaciones que no perturban el status quo. U n enfoque alternativo es abarcar versiones anteriores de software de sistema operativo al llevarlo al frente aunque al mismo tiempo se mantenga fuera de nuevo desarrollo. La invención utiliza así un monitor de máquina virtual para ejecutar las versiones previas de OS de manera simultánea con la última versión de OS en máquinas virtuales separadas, mientras se suministra de manera simultánea una compilación de experiencias de usuario donde, de manera impecable o casi impecable, las aplicaciones que utilizan versiones anteriores de interfases se ejecutan en los mismos am bientes para los cuales se diseñaron y se comportan de la misma manera. Antes de describir las diversas modalidades de la invención es instructivo un ejem plo. De este modo, suponga que para una segunda versión de un OS, es decir OS_B, es deseable encontrarse libre de un cierto conjunto de gráficos APls soportados en la primer versión del OS, es decir OS_A. Sin embargo, el propósito es ejecutar OS_B y OS_A de manera simultánea, es decir, las aplicaciones que utilizan interfaces de gráficos OS_A se ejecutan en la "vista" virtual OS_A mientras que las nuevas aplicaciones se ejecutan en la vista OS_B, ambas con experiencias de usuario igualmente "buenas". La definición de lo que constituye una buena experiencia de usuario es un poco nebulosa, pero ciertas reglas pueden incluir de manera varada (a) entrada de usuario (teclado, ratón, etc.) y salida de aplicación (despliegue, impresión, multimedia, etc.) impecables cuando se utiliza cualquiera de las vistas de OS, (B) poca o nula diferencia de desempeño perceptible. Una medida que puede aplicarse es que el desempeño de cualquier aplicación OS_A que se ejecuta en la vista de OS_A debe encontrarse dentro del 5% de la misma aplicación que se ejecuta en una primer versión nativa del OS sin un monitor virtual y (C) la vista virtual de OS_A debe utilizar software sin modificar que se utiliza para la primer versión del OS. Esto es deseable ya que una vez que la puerta se abre para permitir cambios a los sistemas operativos invitados, los riesgos de romper la compatibilidad re-surgen a través de la salida de elementos descrita en los antecedentes. Una manera de relajar este requisito es al permitir que se ejecuten aplicaciones auxiliares adicionales bajo el OS invitado sin modificar a fin de facilitar la operación impecable. Uno de los problemas en la proporción de mínima degradación de desempeño en la experiencia del usuario es proporcionar aceleración de hardware de los servicios de conversión de gráficos. Para un API como la interfase de dispositivo de gráficos (GDI), puede ser práctico emular la pila entera en software, pero para los APIs más recientes que dependen de la aceleración de hardware, la degradación de desempeño puede ser inaceptable. Una posibilidad es redirigir las solicitudes de procesamiento de gráficos provenientes del OS Invitado hacia el OS Huésped, por ejemplo, utilizando emulación/captura de software de las interfases de hardware de bajo nivel de un dispositivo de hardware de gráficos muy conocido. Aunque este enfoque tradicional es exitoso para dispositivos con un elevado nivel de abstracción (cantidades grandes de trabajo por solicitud) o dispositivos simples (por ejemplo, puertos seriales), no es práctico para el hardware de gráficos moderno. Las solicitudes de captura a este nivel son generalmente demasiado ineficientes (el hardware de gráficos se diseña para recibir más de 1 GB/s de datos de entrada) y el hardware de gráficos moderno es generalmente demasiado complicado para emular de manera confiable a este nivel de detalle (recuerde que un dispositivo de gráficos moderno tiene -200 millones de transistores). En un momento, este enfoque podría haber sido práctico para un dispositivo con menos de 1 0 millones de transistores y para aplicaciones menos gráficamente intensas, pero incluso bajo estas circunstancias, el grado de desempeño necesario no se suministraría. Otra opción es interceptar la corriente de protocolos gráficos a un mayor punto (independiente del dispositivo) en la corriente y redirigirlos al OS Huésped. Aunque estos elimina el problema al em ular un dispositivo complejo, pueden resultar serios problemas de desempeño si se implican corrientes de protocolo de banda amplia elevadas. Otro problema que podría resultar se refiere al escenario donde las corrientes de protocolo no son sujetas a intercepción sin cambios significativos al OS Invitado. Un enfoque podría ser reemplazar las bibliotecas de enlace dinámico del sistema (DLLs) que contienen APIs gráficos con fragmentos de protocolo por redirigirse al OS Invitado, aunque aún existen problemas significativos con este enfoque cuando los métodos de administración de estado en los APIs originales no se han diseñado con este enfoque en mente. Aunque cualquier API que fue diseñado para ejecutarse de manera remota ("remoto") igualmente tiene un comportamiento razonable que podría utilizarse para lograr esto, no todos los gráficos y medios APIs se diseñaron con esta solución en mente. Nuevamente, este enfoque requiere de la modificación (reemplazo) de componentes a nivel de sistema y, por lo tanto, introduce riesgos de compatibilidad. El enfoque de las diversas modalidades de la invención es empujar el problema hacia el hardware y continuar permitiendo que el OS Invitado tenga un acceso a hardware directo, reminiscente de técnicas VMM utilizadas para la CPU . Existen varias ventajas para esta técnica cuando se implementa de manera eficiente. Lo primero es eliminar la necesidad de hacer cambios al OS I nvitado. Lo segundo proporciona los mismo niveles de desempeño o altamente similares que si el OS Invitado se ejecutara de manera nativa en el hardware. Debe observarse también que el esquema permite que los OSs de legado soporten hardware de gráficos más reciente ya que los vendedores de hardware de gráficos continúan transportando soporte de circuito excitador para el nuevo hardware sobre OSs de legado. De este modo, las diversas arquitecturas virtualizadas de la invención, de las que se construye el hardware de gráficos pueden visualizarse, el OS Huésped y VMM se estructuran para explotar de manera eficiente el hardware y la presentación (despliegue) se virtualiza de tal manera que puede integrarse en un escritorio compuesto. La invención permite así que cada acceso de VMM a los recursos de conversión de gráficos, crea un ambiente de VMM en la GPU, para la virtualización de extremo a extremo de la ejecución simultánea. En particular, esto incluye la idea de virtualizar de manera eficiente la GPU para múltiples clientes de gráficos. En diversas modalidades, las arquitecturas de virtualización de la invención se adaptan a uno o más de los siguientes requisitos: un estado de ejecución claramente definido (contexto), soporte de conmutación de contexto de baja latencia, espacios de dirección virtual protegidos, administración de memoria por páginas a demanda, y modos de ejecución privilegiados. Estos requisitos se utilizan para proporcionar compartimiento eficiente, seguro y fuerte de los recursos de hardware de la GPU entre múltiples clientes (aplicaciones). Para simplificar la discusión de virtualización, es útil resumir el grado de soporte de virtualización que se contempla de acuerdo con la invención. La analogía más simple es debe encontrarse que casi el mismo nivel de compartimiento de GPU al que se encuentra en una CPU moderna para compartir la CPU entre múltiples clientes (aplicaciones). Esto es una consecuencia natural de la evolución de la G PU - es un recurso computacional poderoso que debe compartirse de manera eficiente entre múltiples clientes independientes. Una diferencia de la CPU es que la GPU se administra por código ejecutable que se ejecuta en la CPU en vez de en la GPU. En algunos modelos de circuito excitador, en contraste, el subsistema de gráficos de nodulo actúa como un mini-ejecutivo que proporciona servicios de programación y administración de memoria y control sobre recursos globales tales como configuración de despliegue de video, administración de potencia, etc. Este mini-ejecutivo opera de manera independiente al ejecutivo de nodulo, tomando sus propias decisiones de programación y administración de memoria con algoritmos y políticas sintonizadas a los requisitos de los clientes de la GPU . Una vez que se han cumplido los requisitos de virtualización, se vuelve posible permitir que un circuito excitador cliente tenga acceso directamente al hardware de la GPU . Las reglas son sim ilares a aquellas para la virtualización de otras funciones de nodulo, es decir, el circuito excitador alojado no debe ser capaz de detectar que se está ejecutando en un VMM y no debe ser capaz de circunvenir cualquiera de los mecanismos de protección colocados en su lugar por el VMM. Para los propósitos de esta discusión , se supone que el VMM de la GPU se incrusta en el VMM de nodulo y para todos los propósitos prácticos opera como un circuito excitador en el VMM de nodulo. El VMM de gráficos puede incluir una porción independiente de dispositivo y una porción dependiente de dispositivo (proporcionada la última por el fabricante de hardware de gráficos). La Fig. 3B ilustra otra arquitectura no limitante, ejemplar, proporcionada para virtualizar la ejecución simultánea de gráficos de acuerdo con la invención. Un monitor de máquina virtual 304 incluye un VMM de gráficos componentes que maneja la funcionalidad y manejo de gráficos de acuerdo con la invención. Cualquiera de un OS huésped con circuito excitador de gráficos huésped BGD puede interactuar con el VMM de gráficos a través de VMM 304. Ya que una de las motivaciones para utilizar un VMM es la eficiencia, tiene sentido implementar directamente un VMM de gráficos de tipo II con soporte de hardware. La proporción de un modelo de circuito excitador de despliegue avanzado (DDM) agrega soporte de hardware para acceso controlado a espacios de dirección virtual, pre-vaciado y operaciones privilegiadas. Una prueba de tornasol para el soporte eficiente de VMM ejecuta un circuito excitador de DDM avanzado existente en la parte superior del VMM de gráficos sin cambios al circuito excitador. " Esto significa que las operaciones de nodulo del subsistema de gráficos que inician la tarjeta, establecen tablas de páginas, programan controladores de despliegue, establecen la abertura de PCI, manipulan entradas interpretadas como direcciones físicas, etc. deben generar trampas hacia el VMM para la interpretación eficiente. Las interrupciones deben ser interceptables por el VMM y adelantarse al circuito excitador adecuado (Invitado). Las operaciones de frecuencia elevada no privilegiadas, tales como operaciones de conversión, deben ser ejecutables por el hardware de gráficos in intervención por el VMM. El hardware de modelo de circuito excitador avanzado soporta múltiples contextos de ejecución, cada uno con espacio de dirección virtual separado y fila de entrada (regulador anular) para la administración de reguladores DMA entrantes de corrientes de órdenes. Los recursos de memoria física locales y de sistema se representan en el espacio de dirección virtual de un contexto al inicializar las entradas de tabla de página para señalar las direcciones físicas. La terminación de las operaciones de corrientes de órdenes se señala mediante el uso de escritos de memoria (topes limitadores) e interrupciones. Un método para la administración de protección de memoria es dividir los espacios de direcciones físicas de memoria de gráficos locales y asignar una división contigua fija a cada máquina virtual (OS Invitado). La memoria fuera de la asignación no es visible a la máquina virtual. Este mecanismo podría implementarse mediante el uso de un simple nivel de indirección a través de la base y los registros límite programados por el VMM de gráficos. Esto puede requerir el control del contenido de los registros de configuración de bus de PCI, visibles al circuito excitador (léase atrapados por el VMM). En este esquema de administración de memoria, cada Invitado observa una asignación de memoria fija durante el tiempo de vida del Invitado. Esto elimina la necesidad de que el VMM atrape operaciones de tabla de página (que pueden ser frecuentes) ya que la ventana de espacio de direcciones físicas visible al hardware se controla cuidadosamente por el VMM. Esto es un primer enfoque razonable para implementar el soporte de memoria virtualizado ya que deja el VMM fuera de administración de memoria detallada mientras se proporciona de manera justificada menos utilización eficiente de los recursos de memoria. Es concebible a mayor plazo tener el VMM más involucrado en las operaciones de administración de memoria detalladas. Esta parte se vuelve más complicada ya que las operaciones utilizadas por el circuito excitador para programar las entradas de tabla de página se atrapan por el VMM. Dependiendo de los propósitos de desempeño para la paginación, el diseño de hardware puede necesitar diseñarse más cuidadosamente para mejorar la eficiencia de detectar y emular estas operaciones. Por ejemplo, puede ser benéfico diseñar la operación de representación gráfica de páginas (órdenes) a fin de que puedan especificarse múltiples representaciones como un grupo y puedan reconocerse y decodificarse fácilmente como un grupo en el VMM de gráficos. Esto reduce el número de capturas a través del VMM. También, el VMM puede utilizar servicios (confiables) en una división Invitada para soportar operaciones de paginación para almacenamiento de respaldo (otro nivel de almacenamiento de respaldo más allá de lo que ¡mplementa un circuito excitador de DDM Invitado). Aunque este esquema es más complicado, permite a cada Invitado hacer uso de todos los recursos de memoria de hardware. El enfoque descrito en conexión con estas modalidades de la invención implica el uso de tablas de página virtualizadas por software. Un enfoque alternativo a las tablas de página virtualizadas por software es agregar otro conjunto de tablas de página privilegiado, es decir, otro nivel de indirección, en el hardware de gráficos para utilizarse directamente por el VMM. Esta es una generalización de la base y limita el enfoque de registro descrito para divisiones fijas, permitiendo que el VMM controle la vista del hardware de gráficos del(de los) recurso(s) físico(s) a capacidad de granulación a nivel de página. La discusión de administración de memoria, por lo tanto, se ha enfocado al manejo de la representación de memoria de gráficos locales en contextos gráficos. Existen requisitos similares en la representación de páginas de memoria de sistema en el hardware, ya que también utilizan direcciones de memoria física. La manera en la cual el VMM de procesador maneja la memoria física se introduce en la imagen. En general, los dispositivos que utilizan direcciones físicas se administran cuidadosamente para retener el control total sobre sus representaciones. Un simple esquema de división fija propuesto para memoria de video podría extenderse para funcionar con memoria de sistema nuevamente mediante adición de controles de hardware de gráficos para limitar la ventana de memoria de sistema disponible. Sin embargo, no es aplicable si el VMM de procesador asigna memoria física no contigua cuando se atienden operaciones de asignación para Invitados . Esto significa que el esquema más complicado para administración de memoria detallada debe implementarse para recursos de memoria de sistema (esto sugiere realizar la solución de memoria de gráficos locales al mismo tiempo). Probablemente existen ciertas suposiciones elaboradas por el VMM de procesador con respecto a la adm inistración de memoria física y a interacciones potenciales con el VMM de gráficos que necesitan examinarse cuidadosamente. Para permitir que se procesen interrupciones de manera más eficiente, los tipos de interrupción podrían dividirse en aquellos que necesitan procesarse por el VMM y aq uellos que no lo necesitan. La última categoría podría incluir terminaciones de comando, etc. , y estas pueden procesarse directamente por el circuito excitador Invitado. La otra categoría principal de administración es la programación de recursos de procesamiento. El modelo de circuito excitador avanzado soporta el pre-vaciado de contextos , así el modelo de administración más simple tiene las divisiones de tiempo asignadas a VMM para divisiones, pre-vacíando el contexto de gráficos de ejecución actual de la división de ejecución actual. El modelo de circuito excitador avanzado actual utiliza una lista de ejecución doblemente regulada cuando se especifica una nueva lista de contextos por ejecutar. Existe una suposición de que no habrá más de una lista de ejecución pendiente. El modelo de programación virtualizado requerirá de ciertas modificaciones para hacerlo más fácil para el VMM a fin de cambiar divisiones en los límites de la lista de ejecución y para asegurar además que cuando se realiza una transición hacia una nueva división el estado del contexto se guarda en la división antigua y se restaura a partir de la nueva división (por ejemplo, los recursos de memoria de división adecuada se representan en los momentos correctos durante el guardado y restauración del contexto). Nuevamente, habrá suposiciones e interacciones con el programador de VMM del procesador que deben considerarse. Un esquema de programación más elaborado puede implementarse donde el VMM de gráficos es más consciente de la carga de trabajo y prioridades de diferentes contextos. Esta información puede hacerse disponible al VMM de procesador a fin de tomar decisiones de programación más inteligentes. Existen algunos temas de diseño interesantes con respecto a si el VMM de gráficos puede ejecutar un contexto a partir de la división diferente a la del VMM de procesador que se está ejecutando. Es posible y puede ser necesario perm itir cierta sobreposicion en el procesam iento durante transiciones entre divisiones para maximizar la utilización de hardware. Sin embargo, requiere de una consideración más cuidadosa acerca de la manera como se administran los recursos y se representan durante transiciones.

Con respecto a la virtualización de presentación e interacción, en una primer modalidad, una vez que se virtualiza el hardware de gráficos, entonces cada Invitado crea su propio escritorio y convierte las ventanas de las aplicaciones Invitadas a ese escritorio. Este escritorio Invitado se almacena en memoria de gráficos local y bajo un ambiente normal se explora fuera del dispositivo de despliegue (CRT o panel plano). En el ambiente virtuallzado, el contenido de los múltiples escritorios Invitados se recolectan en conjunto y se muestran en un solo despliegue. Existen varios enfoques para crear este despliegue, incluyendo la proporción de múltiples escritorios virtuales (escritorio individual a la vez), la proporción de un escritorio en su propia ventana o un solo escritorio unificado. En la primer modalidad, se selecciona un solo escritorio Invitado como el escritorio "actual" y se muestra. Mediante el uso de cierto control de Ul , el usuario puede seleccionar entre diferentes Invitados, pero solo uno se muestra a la vez. Este enfoque es el más simple ya que las imágenes de escritorio Invitado individuales pueden simplemente mostrarse. De hecho, el control de Ul determina cuál Invitado se permite establecer los registros de exploración del controlador de despliegue. La Figura 4A ilustra la modalidad que muestra un "solo escritorio a la vez". Uno puede ver que cada máquina virtual recibe su propio espacio de escritorio en memoria de gráficos locales en donde cada espacio es independiente de los otros, mediante lo cual solo el escritorio 'activo' seleccionado por el usuario se explora para despliegue. Los Invitados son así capaces de cuadricular sus respectivos temas de trabajo y dejarlos en memoria algo de tiempo y un motor de presentación es capaz de controlar cuál memoria (que contiene los bits cuadriculados) se muestra, lo cual podría implicar que se re-dimensionara el procesamiento de cuadriculado adicional o se mueva el contenido. Por definición, esta primer modalidad no permite que múltiples escritorios sean concurrentemente visibles (aunque en una configuración multimon, los diferentes controladores de despliegue podrían mostrar escritorios de diferentes Invitados en vez de todos los provenientes del mismo Invitado). Un enfoque alterno es la segunda modalidad en la cual los escritorios individuales se muestran en ventanas de contenedor separadas sobre el escritorio Huésped. Esto utiliza un servicio por ejecutarse en el Huésped que tiene acceso al contenido de cada escritorio Invitado. El servicio lleva a cabo una operación de composición para construir el escritorio Huésped mediante el uso de escritorios Invitados como entrada. Una ventana próxima se utiliza para cada escritorio Invitado, controlando el tamaño y la ubicación del escritorio. El contenido de un escritorio Invitado puede extraerse directamente del contenido de memoria de videos mediante interceptación de los cambios a los parámetros de controlador de despliegue para ese escritorio (utilizándolos para determinar la dirección de la memoria, dimensiones y otros parámetros). El escritorio Huésped compuesto se construye en casi la misma manera que el escritorio típico mediante el uso del Motor de Com posición de Escritorio (DCE) - utilizando también aceleración de gráficos de hardware. Esta segunda modalidad puede combinarse con la primera para soportar un modo con una sola vista directa de un escritorio Invitado o un modo con una vista compuesta de múltiples escritorios en ventanas separadas. La Fig . 4B ilustra una modalidad de "escritorio en una ventana" alternativo , mediante la cual todos los escritorios pueden mostrarse de manera simultánea mediante un motor de presentación que toma en cuenta la oclusión. Por ejemplo, un escritorio huésped podría ser por omisión la ventana de escritorio anterior en despliegue, y los escritorios Invitados, mostrado cada uno dentro de su propia ventana de contenedor, recibiendo una ventana separad en despliegue en la parte superior de la ventana de escritorio anterior. Esta segunda modalidad comienza a introducir algunas complicaciones con coordinación de entrada cuando la se sincroniza la posición y el tamaño de las ventanas del escritorio Invitado. A medida que las ventanas se manipulan en la ventana de contenedor Huésped para el escritorio Invitado, aquellas interacciones se capturan y envían al I nvitado para procesamiento. El Invitado, por ejemplo, su administrador de ventana, actualiza el escritorio I nvitado y las nuevas colocaciones de ventana se reflejan en el escritorio Huésped a medida q ue se reconstruye. Este tipo de coordinación de entrada ya se ha dirigido en otros productos de virtuaiización que implementan "Escritorio en una ventana" y deben no afectarse por la virtualización del hardware de gráficos. La segunda modalidad es una mejora significativa, pero aún sería deseable entremezclar las ventanas de múltiples escritorios Invitados, es decir, ocultar el hecho de que son escritorios Invitados. Este problema se suma a la localización del contenido de Ventana individual en cada escritorio Invitado, pero es más difícil que la localización del contenido de escritorio ya que la información de Ventana individual no se intercepta fácilmente a partir de la corriente de datos enviados al hardware de gráficos. Sin embargo, si la regla con respecto a la modificación del sistema operativo Invitado se viola a propósito, es posible agregar ciertos ganchos para ayudar en la identificación de pixeles (ubicaciones de memoria) para ventanas individuales. Existen un par de enfoques diferentes que pueden tomarse aquí. Un enfoque es mantener las ventanas en el escritorio Invitado inclinadas (sin sobreposición) a fin de que el contenido entero se encuentre siempre disponible en el escritorio Invitado para utilizarse por el motor de administración de ventanas Huésped/composición. Este enfoque involucra el mantenimiento de dos conjuntos separados de información de ventanas: la información virtual (en el escritorio Huésped) y la ubicación física en el escritorio I nvitado. También complica la coordinación de entrada ya que las operaciones que manipulan la ventana virtual pueden o no afectar la ventana física (por ejemplo, su la ventana virtual se obstruye puede ser benéfico reclamar el estado real en el Escritorio Invitado). Las interacciones dentro de la ventana virtual se traducen en interacciones adecuadas para la ventana física (esto podría ser tan simple como un desplazamiento de las coordenadas de entrada) . Un enfoque alterno es redirigir las ventanas de escritorio Invitado a la memoria que se administra más fácilmente. Esto es análogo a la redirección realizada para la Interfase del Dispositivo de Gráficos (GDI) cuando se mantiene un "regulador posterior" separado para cada Ventana. El contenido de estos reguladores posteriores se hace disponible al administrador de ventanas Huésped/motor de com posición. Se lleva a cabo una representación sim ilar entre coordenadas de entrada virtuales y coordenadas de entrada físicas cuando el usuario interactúa con el contenido de una ventan virtual. Con cierta previsión y planeación, es posible config urar futuros sistemas operativos para facilitar más tales intercepciones cuando estos sistemas operativos se ejecutan como I nvitados. La disposición del protector en cada escritorio Invitado (si y cuando termina de existir desde la perspectiva del usuario) , el manejo de extensión del protector, las opciones del menú de inicio, los cortos de aplicación, el panel de sujeción, etc. , surgen en una vista de escritorio unificada. Estos son problemas que pueden resolverse, pero involucran el entendimiento de más detalles acerca de las implementaciones correspondientes en cada uno de los Invitados y probablemente (estadísticamente) la extracción y surgimiento de esa información en conjunto para producir una vista unificada. Surgen cuestiones similares para soportar la capacidad de acceso unificada.

Pueden existir problemas similares en la proporción de una vista impecable de otras partes de un sistema de múltiples Invitados, por ejemplo, almacenamiento, aplicaciones instaladas, trabajo en red, etc. Una estrategia interna de exposición de los múltiples Invitados como escritorios de ventana con huellas digitales independientes permitiría enfocarse en la labor de construir una infraestructura de virtualización fuerte. En paralelo, es posible dirigir algunas de las características adicionales, tales como procesamiento confiable y protección del contenido para administración de derechos digitales. Como la base para el procesamiento seguro (confiable) de gráficos, los sistemas de gráficos visualizados, arriba descritos, se unen a otros modelos para el procesamiento seguro mediante el uso de máquinas virtuales. Las características del ambiente de gráficos visualizados fácilmente permiten que ocurra una mezcla de procesamiento confiable y no confiable en el mismo sistema, en una manera confiable a total desempeño. Tal modelo requiere que el VMM de gráficos autorice fuertemente y arranque el dispositivo de gráficos. Por supuesto, esto depende de los componentes confiables para arrancar de manera segura el VMM de gráficos. Ya que el ambiente de virtualización protege fuertemente las múltiples divisiones Invitadas y Huésped entre sí, es posible construir una división confiable que pueda realizar procesamiento de gráficos confiables. Si el administrador de ventanas y el motor de composición se ejecutan como servicios en una división confiable, entonces pueden entremezclar datos de aplicación confiables y no confiables en una manera confiable mediante el uso de los métodos de presentación previamente descritos. La Fig. 4C ilustra una arquitectura ejemplar para entremezclar datos de aplicación confiables y no confiables de acuerdo con la invención . Como se describió, de manera similar al OS H Huésped con HGD de circuito excitador de g ráficos, un OS T Confiable se proporciona como una división confiable con TGD de circuito excitador de gráficos. El OS T Confiable incluye un administrador de ventanas, o compositor de ventanas, componente que toma la entrada del código de VMM de gráficos con respecto a cualquier restricción en el almacenamiento y conversión de los datos confiables contra los datos no confiables, antes de la conversión por la ejecución simultánea de gráficos. El servicio confiable requiere de acceso a los datos de despliegue de escritorio Invitado separados, pero esta información no se interpreta como datos de control por el servicio de composición. Se utiliza como entrada de conversión, por lo que no existe riesgo de ataque del contenido de los datos compartidos. Si el hardware de gráficos se virtualiza correctamente, no existe riesgo de código en otro ataque de división. Los circuitos excitadores Invitados no pueden tomar control del hardware ni interferir con otros Invitados. El código de aplicación que se ejecuta en el interior del hardware de gráficos no puede interferir con otras aplicaciones en la misma división de Invitado, dejada sola con otras divisiones de I nvitado.

El soporte de virtualización de la invención no hace obvias las necesidades de autenticación de hardware, fuerte control sobre las emisiones de despliegue u otros requisitos para asegurar una sola división confiable que pueda suministrar de manera confiable los datos de despliegue al dispositivo de despliegue, pero permite que múltiples divisiones compartan fuertemente el hardware de gráficos con poco impacto de desempeño. Con respecto a la base para protección del contenido durante el procesamiento y despliegue de acuerdo con la invención, el refuerzo de derechos digitales para datos de video de movimiento completo se logra actualmente mediante el uso de una "Trayectoria de Video Protegida" a fin de proteger el contenido. La trayectoria de video protegida integra varios de los siguientes métodos para proporcionar transporte y procesamiento seguros de datos de video a partir de un dispositivo fuente hacia el dispositivo de despliegue: (1 ) El ambiente de nodulo se endurece para no permitir depuradores-nódulo, etc. y solo los componentes confiables se permiten operar en modo de nodulo ("anillo 0") mientras se reproduce el contenido protegido; (2) Los procesos en modo de usuario que manejan contenido protegido se endurecen de manera adicional del ataque exterior (ambiente protegido). Los datos de video colocados en (o desplegados a partir de) sistema o memoria de gráficos no pueden tener acceso desde otros procesos; (3) Los datos de video enviados sobre buses accesibles por el usuario se criptografían; (4) El circuito excitador de gráficos debe certificarse para reproducir contenido protegido y, a su vez, valida que el hardware de gráficos es una sincronización válida para contenido protegido; y (5) La protección de emisión de despliegue se soporta por el hardware de gráficos (macrovisión, CGSM-A, HDCP) y puede manipularse fuertemente por el subsistema de reproducción de medios. Los mecanismos (1 ) y (2) pueden reemplazarse con una base de cómputo de seguridad más general, de acuerdo con la invención. Esta base de cálculo de seguridad debe evitar además la circunvención a través de tecnolog ía de virtualización haciendo posible subvertir un proceso de arranque seguro. Los mecanismos (3) a (5) aún se requiere que continúen proporcionando procesamiento seguro y transporte de datos de video a medida que se m ueven de la memoria del sistema a través del hardware de gráficos y hacia el despliegue. Los métodos de virtualización de hardware de g ráficos de la invención no reemplazan ninguno de los métodos de protección de contenido relacionado con la trayectoria de gráficos específicos; en su lugar, sirven como una fundación para la construcción de servicios gráficos confiables. Estos servicios confiables pueden expandirse para incluir los componentes de procesamiento de medios protegidos (Vía de Acceso de Interoperabilidad de Medios, o Mi G para abreviar) , y ejecutarlos en división confiable "segura" en vez de una división Invitada hostil. La infraestructura de video protegida existente ya ha separado el procesamiento protegido (negociación de derechos, políticas, decodificación, descripción) del procesamiento no protegido (reproducción de aplicación GUI, etc.). Esta separación permanece intacta en el ambiente virtualizado, con los componentes protegidos ejecutándose en una división confiable (un ambiente protegido diferente [mejor]) y los componentes no protegidos permanecen en una división Invitada no confiable. La Fig. 4D ilustra la extensión de la noción de la división confiable T desarrollada en conexión con la Fig. 4C para incluir una vía de acceso de interoperabilidad de medios MIG, como un estrato separado de protección de contenido que está siendo convertido por una aplicación del reproductor de medios que se ejecuta en el OS Invitado A. De la misma manera que el producto de PC Virtual puede ejecutar un gran número de OSs, el ambiente de gráficos virtualizado de la invención es capaz de soportar los circuitos excitadores/modelos de circuito excitador para un número predefinido de sistemas operativos o versiones. El éxito de cada sistema operativo se mide por la amplitud de las aplicaciones que puede ejecutar y la eficiencia de aquellas aplicaciones. Al evitar cruelmente la urgencia de modificar los sistemas operativos Invitados, debe ser posible ejecutar cualquier aplicación bajo el sistema operativo virtualizado que se ejecuta bajo el sistema operativo que se ejecuta de manera nativa. Los lugares donde puede haber diferencias yacen en la manera como se dividen los recursos. Por ejemplo, si solo un subconjunto de los recursos (parte de la memoria de gráficos locales) se hace disponible a una división, entonces la aplicación puede no operar también. En futuros sistemas operativos, esto puede ser menos que un problema ya que la virtualización de "primer orden" - virtualización de los recursos para compartir entre las múltiples aplicaciones - se vuelve normal. La inspiración para moverse hacia hardware de gráficos completamente virtualizados es para compañías de software que se liberan de problemas de código de legado mientras proporcionan aún una trayectoria práctica para la compatibilidad continua de la aplicación. Como un efecto secundario, la invención también proporciona un excelente ambiente para procesamiento de gráficos confiable y protección de contenido. Esta segunda medida de éxito significa que las aplicaciones que se mueven al frente deben detener el uso de código de legado y moverse hacia delante también. Para bases de código de grandes aplicaciones, esto puede ser excesivamente difícil. Por ejemplo, puede no ser posible dejar software de GDI detrás como código de legado si, por ejemplo, una base de código de aplicación de legado que se desarrolla con versiones OS, tal como código de base de Microsoft Office, es inextricablemente dependiente de esto. En tales casos, tal vez podrían existir modelos híbridos que pueden explorarse. Por ejemplo, los sistemas operativos Invitados pueden observarse como proveedores de servicios generales. Nuevamente mediante el uso de GDI como un ejemplo, un sistema operativo de legado podría considerarse para proporcionar un servicio de conversión a GDI . La aplicación utiliza un mecanismo similar a remoto que utiliza el servicio. El propósito en tal caso no es necesariamente ejecutar la aplicación sin ningún cambio de código, sino más bien hacer un mínimo de cambios que permitirían que la aplicación continúe utilizando el código GDI de legado como un servicio de división transversal mientras adquiere tiempo para la transición completa al API . La Fig. 4E ilustra interacción ejemplar en donde una aplicación de legado de OS A Invitado que se ejecuta en el OS H huésped interactúa con un componente de servicios de legado de OS A Invitado para, no obstante, emular el comportamiento de legado desde la perspectiva del OS H huésped. La Fig. 5 ilustra una secuencia ejemplar en donde una aplicación que se ejecuta en un OS Invitado, de acuerdo con cualquiera de las arquitecturas virtualizadas mostrada o descrita en la presente, emite una orden que implica recursos de subsistema de gráficos. En 500, una aplicación que se ejecuta en un OS Invitado emite un problema de trabajo de gráficos (por ejemplo, arrastra círculos azules sobre la pantalla en la coordenada "x, y"). En 510, el OS Invitado maneja la solicitud, enviándola a la fila de trabajo de gráficos y programador asociado. En 520, cuando el problema de trabajo de gráficos se encuentra listo (programado), un señalador hacia los datos del problema de trabajo de gráficos se pasa al hardware mediante los circuitos excitadores de gráficos. En 530, si el problema de trabajo de gráficos es una operación privilegiada, entonces el VMM de gráficos recibe y maneja la solicitud de trabajo en base a políticas (OS Invitado contra OS Huésped, política de memoria, tipo de orden, etc.)- Si el problema de trabajo de gráficos no es privilegiado, entonces en su lugar, en 540, el hardware de gráficos procede a manejar directamente la solicitud. La invención virtualiza así el hardware del procesador hacia el acelerador de gráficos con el intento de proporcionar los beneficios de conversión de alto desempeño a múltiples sistemas operativos Invitados que se ejecutan en un ambiente virtualizado. Tal ambiente puede utilizarse para resolver de manera eficiente varios problemas: (A) eliminar el código de legado en el desarrollo del nuevo sistema operativo mientras se mantiene la compatibilidad de la aplicación ai ejecutar la aplicación de legado en el sistema operativo de legado en un ambiente de máquina virtual; (B) proporcionar mezcla segura de infraestructura de procesamiento confiable y no confiable en el mismo ambiente virtualizado; y (C) nivelar el ambiente confiable para proporcionar protección de contenido para la administración de derechos digitales.

Ambientes Distribuidos e Interconectadas Ejemplares Un experto en la materia puede apreciar que la invención puede implementarse en relación con cualquier computadora u otro dispositivo servidor o cliente, el cual puede desplegar como parte de una red de computadora, o en un ambiente de computación distribuido. En este aspecto, la presente invención pertenece a cualquier sistema de computadora o ambiente que tiene cualquier número de memoria o unidades de almacenamiento, y cualquier número de aplicaciones y procesos que ocurren a través de cualquier número de unidades de almacenamiento o volúmenes, los cuales pueden utilizarse en relación con virtualizar la ejecución simultánea de gráficos de acuerdo con la presente invención. La presente invención puede aplicar a un ambiente con computadoras de servidor y computadoras de cliente desplegadas en un ambiente de red o ambiente de computación distribuido, teniendo almacenamiento local o remoto. La presente invención también puede aplicarse a los dispositivos de computación autónomos, que tienen funcionalidad de lenguaje de programación, capacidades de ejecución e interpretación para generar, recibir y transmitir información en relación con los servicios locales o remotos. En un ambiente de juegos, una ejecución simultánea de gráficos es particularmente relevante para aquellos dispositivos de computación que operan en una red o ambiente de computación distribuida, y de esta manera la virtualización de la ejecución simultánea de gráficos de acuerdo con la presente invención puede aplicarse con mayor eficacia en aquellos ambientes. Los dispositivos de computación distribuida proporcionan parte de los servicios y recursos de computadora por intercambio entre sistemas y dispositivos de computadora. Estos recursos y servicios incluyen el intercambio de información, memoria de pequeña capacidad con acceso rápido y almacenamiento en disco para archivos. La computación distribuida tiene ventaja de conectividad de red , permitiendo a los clientes apalancar su energ ía colectiva para beneficiar la empresa completa. En este aspecto, una variedad de dispositivos puede tener aplicaciones , objetos o recursos que pueden implicar los procesos de gráficos de la invención. La Fig. 6A proporciona un diagrama esquemático de un ambiente de computación distribuida o interconectada ejemplar. El ambiente de computación distribuida comprende objetos de computación 10a, 10b, etc. y dispositivos u objetos de computación 610a, 61 0b, 61 0c, etc. Estos objetos pueden comprender programas, métodos, almacenamiento de datos, lógica programable, etc. Los objetos pueden comprender partes de los mismos o diferentes dispositivos tales como PDAs, dispositivos de audio/video, reproductores MP3 , computadoras personales, etc. Cada objeto puede comunicarse con otro objeto a manera de la red de comunicaciones 14. Esta red puede por sí misma comprender otros objetos de computación y dispositivos de computación que proporcionan servicios al sistema de la Fig. 6A, y pueden representar por sí mismo las múltiples redes interconectadas. De acuerdo con un aspecto de la invención, cada objeto 1 0a, 1 0b, etc. , o 61 0a, 61 0b, 61 0c, etc. puede contener una aplicación que podría hacer uso de un API , u otro objeto, software, firmware y/o hardware, para solicitar el uso de los procesos de virtualización de gráficos de la invención. También, puede apreciarse que un objeto, tal como 61 0c, puede presentarse en otro dispositivo de computadora 10a, 10b, etc. o 610a, 610b, etc. De esta manera, a pesar de que el ambiente físico representado puede mostrar los dispositivos conectados como computadoras, tal ilustración es meramente ejemplar y el ambiente físico puede representarse o describirse alternativamente comprendiendo varios dispositivos digitales tales como PDAs, televisiones, reproductores MP3, etc. , objetos de software tales como interfases, objetos COM y lo similar. Existen una variedad de sistemas, componentes, y configuraciones de red que soportan los ambientes de computación distribuida. Por ejemplo, los sistemas de computación pueden conectarse juntos mediante sistemas cableados o inalámbricos, por redes locales o redes ampliamente distribuidas. Actualmente, varias de las redes se acoplan a la Internet, la cual proporciona una infraestructura para computación ampliamente distribuida y comprende varias redes diferentes. Varias de las infraestructuras pueden utilizarse para comunicaciones ejemplares hechas incidentes para los procesos de virtualización de hardware de gráficos de la presente invención. En ambientes de red locales, existen al menos cuatro medios de transporte de red disparados que pueden cada uno soportar un protocolo único, tal como un conducto de Energía, datos (tanto inalámbricos como cableados), voz (por ejemplo, teléfono), y medios de entretenimiento. La mayoría de los dispositivos de control locales tales como interruptores de luz y electrodomésticos pueden utilizar conductos de energía para conectividad. Los Servicios de Datos pueden entrar al hogar como banda ancha (por ejemplo, ya sea DSL o Cable moderno) y son accesibles dentro del hogar utilizando ya sea conectividad inalámbrica (por ejemplo, Homero o 802.1 1 B) o cableada (por ejemplo, PNA Hogar, Cat 5. , Eternet, aún conducto d energía). El tráfico de voz puede entrar al hogar ya sea como cableado (por ejemplo, Cat 3) o inalámbrico (por ejemplo, teléfonos celulares) y puede distribuirse dentro del hogar utilizando el alambrado Cat 3. Los medios de entretenimiento, u otros datos gráficos, pueden ingresar al hogar ya sea a través de satélite o cable y se distribuye típicamente en el hogar utilizando el cable coaxial. IEEE 1394 y DVl también son interconexiones digitales para grupos de dispositivos de medios. Todos estos ambientes de red y otros que pueden emerger como estándares de protocolo pueden interconectarse para formar una red, tal como intranet, que puede conectarse al mundo externo por vía de Internet. En breve, una variedad de fuentes disparadas existen para el almacenamiento y transmisión de datos, y por consecuencia, moviéndose hacia delante, los dispositivos de computación requerirán maneras para compartir datos, tales como datos accesados o utilizados incidentes para objetos de programa, los cuales hacen uso de los servicios de gráficos visualizados de acuerdo con la presente invención. El Internet comúnmente se refiere a la colección de redes y accesos que utilizan el juego TCP/IP de protocolos, que se conocen bien en la materia de red de computadora. TCP/IP es un acrónimo para " Protocolo de Control de Transmisión/Protocolo de I nternet". El Internet puede describirse como un sistema de redes de computadora remotas geográficamente distribuidas interconectadas por computadoras que ejecutan protocolos de red que permite a los usuarios interactuar y compartir información sobre la (s) red (es). Debido a que tal parte de información de alto esparcimiento, las redes remostas tales como la I nternet hasta ahora de esta manera generalmente se han incluido en un sistema abierto para el cual los promotores pueden diseñar aplicaciones de software para realizar servicios u operaciones especializadas , esencialmente sin restricción . De esta manera, la infraestructura de red permite un huésped de topologías de red tales como cliente/servidor, par a par, o arquitecturas híbridas. El "cliente" es un miembro de una clase o grupo que utiliza los servicios de otra clase o grupo al cual no se relaciona. De esta manera , en la computación, un cliente es un proceso, es decir, rigurosamente un grupo de instrucciones o tareas, que solicita un servicio proporcionado por otro programa. El proceso del cliente utiliza el servicio solicitado sin tener que "conocer" cualquiera de los detalles de trabajo acerca del otro programa o el servicio por sí mismo. En una arquitectura de cliente/servidor, particularmente un sistema interconectado, un cliente es usualmente una computadora que tiene acceso a los recursos de red compartida proporcionados por otra computadora, por ejemplo, un servidor. En el ejemplo de la Fig . 6A, las computadoras 61 0a, 610b, etc. , pueden considerarse como clientes y computadoras 10a, 1 0b, etc. pueden considerarse como el servidor en donde el servidor 10a, 10b, etc. mantiene la información que se duplica así en las computadoras de cliente 610a, 610b, etc., a pesar de que cualquier computadora puede considerarse un cliente, un servidor, o ambos, dependiendo de las circunstancias. Cualquiera de estos dispositivos de computación pueden ser datos de procesamiento o servicios de petición o pruebas que pueden implicar una implementación de las arquitecturas de gráficos visualizados de la invención. Un servidor es típicamente un sistema de computadora remota accesible sobre una red local o remota, tal como el Internet. El proceso del cliente puede ser activo en un primer sistema de computadora, y el proceso del servidor puede ser activo en un segundo sistema de computadora, comunicándose con otro sobre un medio de comunicaciones, proporcionando de esta manera funcionalidad distribuida y permitiendo a los múltiples clientes tener ventaja de las capacidades crecientes de información del servidor. Cualquiera de los objetos de software utilizados en cuanto a hacer uso de la (s) arquitectura (s) virtualizada (s) de la invención puede distribuirse a través de múltiples objetos o dispositivos de computación. El (los) cliente (s) y el (los) servidor (es) se comunican con otro que utiliza la funcionalidad proporcionada por la (s) capa (s) de protocolo. Por ejemplo, Protocolo de Transferencia de Hipertexto (HTTP) es un protocolo común que se utiliza junto con la Red Mundial (WWW) o "La Red". Típicamente, una dirección de red de computadora tal como una dirección de Protocolo de Internet (IP) u otra referencia tal como un Localizador de Recursos Universal (URL) puede utilizarse para identificar las computadoras del cliente o servidor entre sí. La dirección de red puede referirse a una dirección URL. La comunicación puede proporcionarse sobre un medio de comunicaciones, por ejemplo, el (los) cliente (s) y el (los) servidor (es) puede (n) acoplarse entre sí por medio de conexión (es) TCP/IP para la comunicación de alta capacidad. De esta manera, la Fig. 6A ilustra un ambiente distribuido o interconectado ejemplar, con un servidor en comunicación con las computadoras del cliente por medio de una red/bus, en la cual puede emplearse la presente invención. A mayor detalle, un número de servidores 10a, 10b, etc. se interconectan por medio de una red/bus de comunicaciones 14, que puede ser una LAN, WAN, intranet, el Internet, etc. , con un número de dispositivos de computación remota o de cliente 610a, 610b, 610c, 610d, 610e, etc. , tal como una computadora portátil, computadora móvil, cliente delgado, electrodoméstico interconectado, u otro dispositivo, tal como una VCR, TV, horno, luz, calentador y lo similar de acuerdo con la presente invención. De esta manera se contempla que la presente invención puede aplicar para cualquier dispositivo de computación en relación con el cual es deseable implementar las interfaces de gráficos invitadas y sistemas operativos de acuerdo con la invención. En un ambiente de red en el cual la red/bus de comunicaciones 14 es el Internet, por ejemplo, los servidores 10a, 10b, etc. puede ser servidores Red con los cuales los clientes 610a, 610b, 610c, 610d, 610e, etc. se comunican por medio de cualquier número de protocolos conocidos tales como HTTP. Los servidores 10a, 10b, etc. también pueden servir como clientes 610a, 610b, 610c, 610d, 610e, etc., como pueden ser características de un ambiente de computación distribuida. Las comunicaciones pueden ser cableadas o inalámbricas, en donde sea adecuado. Los dispositivos del cliente 610a, 610b, 610c, 610d, 610e, etc. , puede o no pueden comunicarse por medio de red/bus de comunicaciones 14, y pueden tener comunicaciones independientes asociadas con las mismas. Por ejemplo, en el caso de una TV o VCR, puede o no puede existir un aspecto interconectado al control del mismo. Cada computadora de cliente 610a, 610b, 610c, 610d, 610e, etc. , y la computadora del servidor 10a, 10b etc. puede equiparse con varios objetos o módulos de programa de aplicación 635 y con conexiones o acceso a varios tipos de objetos o elementos de almacenamiento, a través de los cuales los archivos o las corrientes de datos pueden almacenarse o a los cuales pueden descargarse, transmitirse o migrarse la (s) parte (s) de archivos o corrientes de datos. Cualquiera de una o más de las computadoras 10a, 10b, 610a, 610b, etc. pueden ser responsables del mantenimiento y actualización de una base de datos 20 u otro elemento de almacenamiento, tal como una base de datos o memoria 20 para almacenar los datos procesados de acuerdo a la invención. De esta manera, la presente invención puede utilizarse en un ambiente de red de computadora que tiene computadoras del cliente 610a , 610b, etc. que pueden tener acceso e ¡nteractuar con una red/bus de com putadora 14 y computadoras del servidor 1 0a, 1 0b, etc. que pueden ¡nteractuar con las computadoras de cliente 61 0a, 610b, etc. y otros dispositivos similares , y bases de datos 20.

Dispositivo de Computación Ejemplar La Fig. 6B y la sig uiente discusión se pretende que proporcionan una breve descripción general de un ambiente de computación adecuado en relación con el cual puede implementarse la invención. Deberá entenderse, sin embargo, que los dispositivos de computación móviles, portátiles y otros de todos los tipos se contemplan para utilizarse en relación con la presente invención, es decir, en cualquier parte en donde toda una GPU existe en un ambiente de computación. Mientras que una computadora de propósito general se describe abajo, esto es un ejemplo, y la presente invención puede implementarse con un cliente delgado que tiene interacción e interoperabilidad de red/bus. De esta manera, la presente invención puede implementarse en un ambiente de servicios presentados interconectados en los cuales se implican muy pocos recursos o de cliente mínimos, por ejemplo, un ambiente interconectado en el cual el dispositivo de cliente sirve meramente como una interfase a la red/bus, tal como un objeto colocado en un aparato doméstico. En esencia, en cualquier lugar donde los datos puedan almacenarse o del cual puedan extraerse los datos o transmitirse a otra computadora es un ambiente deseable, o adecuado, para la operación de las técnicas de virtualización de gráficos de acuerdo con la invención . A pesar de que no se requiere, la invención puede implementarse en total o en parte por medio de un sistema operativo, para utilizarse por un promotor de servicios para un dispositivo u objeto, y/o incluirse dentro del software de aplicación que opera en conexión con el (los) conducto (s) de gráficos virtualizados de la invención . El software puede describirse en el contexto general de instrucciones ejecutables por computadora, tales como módulos de programa, que se ejecutan por una o más computadoras, tales como estaciones de trabajo del cliente, servidores u otros dispositivos. Generalmente, los módulos de programa incluyen rutinas, programas, objetos, componente, estructuras de datos y lo similar que realizan pruebas particulares o tipos de datos de resumen particular. Típicamente, la funcionalidad de los módulos de programa puede combinarse o distribuirse según se desee en varias modalidades. Además, aquellas expertos en la materia apreciarán que la invención puede practicarse con otros protocolos y configuraciones del sistema de com putadora. Otros sistemas de computación bien conocidos, am bientes , y/o configuraciones que pueden ser adecuados para utilizarse con la invención incluyen, pero no se limitan a, computadoras personales (PCs) , máquinas de contador automático, computadoras de servidor, dispositivos portátiles o móviles, sistemas multiprocesadores, sistemas basados en microprocesador, electrónicos de consum idor programables, PCs de red , electrodomésticos, luces, elementos de control ambientales, minicomputadoras, maxicomputadoras y lo similar. La invención también puede practicarse en ambientes de computación distribuida en donde las pruebas se realizan por dispositivos de procesamiento remoto que se unen a través de una red/bus de comunicaciones u otro medio de transmisión de datos. En un ambiente de computación distribuida, los módulos de programa pueden ubicarse tanto en medios de almacenamiento de computadora remota y local incluyendo dispositivos de almacenamiento de memoria, y los nodos de cliente a su vez pueden comportarse como nodos de servidor. La Fig. 6B de esta manera ilustra un ejemplo de un ambiente de sistema de computadora adecuado 600 en el cual puede implementarse la invención , a pesar de que según queda claro anteriormente, el ambiente de sistema de computación 600 únicamente es un ejemplo de un ambiente de computación adecuado y no se pretende que sugiera ninguna limitación en cuanto al alcance de uso o funcionalidad de la invención. Nada del ambiente de computación 600 deberá interpretarse como que tiene alguna dependencia o requisito en relación a cualquiera de uno o combinación de componentes ilustrados en el ambiente de operación ejemplar 600. Con referencia a la Fig . 6B, un sistema ejemplar para implementar la invención incluye un dispositivo de computadora de propósito general en la forma de una computadora 61 0. Los componentes de la computadora 61 0 pueden incluir, pero no se limitan a, una unidad de procesamiento 620, una memoria de sistema 630, y un bus de sistema 621 que acopla varios componentes de sistema incluyendo la memoria de sistema a la unidad de procesamiento 620. El bus de sistema 621 puede ser de cualquiera de varios tipos de estructuras de bus incluyendo un bus de memoria o controlador de memoria, un bus periférico, y un bus local utilizando cualquiera de una variedad de arquitecturas de bus. A manera de ejemplo, y no limitación, tales arquitecturas incluyen bus de Arquitectura Estándar de Industria (ISA), bus de Arquitectura de Micro Canal (MCA), bus de ISA Mejorada (EISA), bus local de Asociación de Estándares Electrónicos de Video (VESA), bus de Interconexión de Componente Periférico (PCI) (también conocido como bus Mezanine), y PCI Express (PCIe). La computadora 610 típicamente incluye una variedad de medios leíbles por computadora. Los medios leíbles por computadora puede ser cualquiera de los medios disponibles que pueden tener acceso por computadora 610 e incluye medios tanto volátiles como no volátiles, medios removibles y no removibles. A manera de ejemplo, y no limitación, los medios leíbles por computadora pueden comprender medios de almacenamiento de computadora y medios de comunicación. El medio de almacenamiento de computadora incluye tanto medio volátil y no volátil, removible y no removible implementado en cualquier método o tecnología para almacenamiento de información tal como las instrucciones leíbles por computadora, estructuras de datos, módulos de programa u otros datos. El medio de almacenamiento de computadora incluye, pero no se limita a, RAM, ROM, EEPROM, memoria flash u otra tecnología de memoria, CDROM, discos versátiles digitales (DVD) u otro almacenamiento de disco óptico, casetes magnéticos, cinta magnética, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnéticos, o cualquier otro medio que pueda utilizarse para almacenar la información deseada y que pueda tener acceso por computadora 610. El medio de comunicación típicamente incorpora instrucciones leíbles por computadora, estructuras de datos, módulos de programa u otros datos en una señal de datos modulados tales como una onda vehículo u otro mecanismo de transporte e incluye cualquier medio de suministro de información. El término "señal de datos modulado" significa una señal que tiene una o más de sus características establecidas o cambiadas en una manera tal a fin de codificar la información en la señal. A manera de ejemplo, y no limitación, el medio de comunicación incluye medio cableado tal como una red cableado o conexión cableada directa, y medio inalámbrico tal como acústico, RF, infrarrojo y otro medio inalámbrico. Las combinaciones de cualquiera de los anteriores deberán también incluirse dentro del alcance de los medios leíbles por computadora. La memoria de sistema 630 incluye medios de almacenamiento de computadora en la forma de memoria volátil y/o no volátil tal como memoria de lectura única (ROM) 631 y una memoria de acceso al azar (RAM) 632. Un sistema básico de entrada/salida 633 (BIOS), conteniendo las rutinas básicas que ayudan a transferir la información entre los elementos dentro de la computadora 610, tal como durante la instalación, se almacena típicamente en ROM 631 . RAM 632 típicamente contiene módulos de programa y/o datos que son inmediatamente accesibles para y/o actualmente operarse por la unidad de procesamiento 620. A manera de ejemplo, y no limitación, Fig . 6B ilustra el sistema operativo 634, los programas de aplicación 635, otros módulos de programa 636, y datos de programa 637. La computadora 61 0 también puede incluir otros medios de almacenamiento de computadora volátil/no volátil, removible/no removible. A manera de ejemplo solamente, la Fig. 6B ilustra una unidad de transmisión de disco duro 641 que lee o escribe a un medio magnético no removible, no volátil, una unidad de transmisión de disco magnético 651 que se lee de o escribe para un disco magnético no volátil , removible 652, y una unidad de transmisión de disco óptico 655 que se lee de o escribe hacia un disco óptico no volátil, removible 656, tal como un CD-ROM u otro medio óptico. Otros medios de almacenamiento de computadora volátil/no volátil, removible/no removible que puede utilizarse en el ambiente de operación ejemplar incluyen , pero no se limitan a, casetes de cinta magnética, tarjetas de memoria flash, discos versátiles digitales, cinta de video digital, RAM de estado sólido, ROM de estado sólido y lo similar. La unidad de transmisión de disco duro 641 típicamente se conecta al bus de sistema 621 a través de una ¡nterfase de memoria no removible tal como una interfase 640, y unidad de transmisión de disco magnético 651 y unidad de transmisión de disco óptico 655 se conectan típicamente al bus de sistema 621 por una interfase de memoria removióle, tal como una interfase 650. Las unidades de transmisión y sus medios de almacenamiento de computadora asociados anteriormente discutidos e ilustrados en la Fig . 6B proporcionan almacenam iento de instrucciones leíbles por computadora, estructuras de datos, módulos de programa y otros datos para la computadora 610. En la Fig. 6B, por ejemplo, la unidad de transmisión de disco duro 641 se ilustra como sistema operativo de almacenamiento 644, programas de aplicación 645, otro módulos de programa 646 y datos de programa 647. Nótese que los componentes pueden ser ya sea los mismos o diferentes del sistema operativo 634, los programas de aplicación 635, otros módulos de programa 636 y los datos de programa 637. El sistema operativo 644, los programas de aplicación 645, otros módulos de programa 646 y los datos de programa 647 se dan diferentes números aquí para ilustrar que, en lo mínimo, son copias diferentes. Un usuario puede ingresar comandos e información en la computadora 61 0 a través de los dispositivos de entrada tal como un teclado 662 y dispositivo de señalización 661 , comúnmente referido como un ratón, almohadilla al taco o bola de seguimiento. Otros dispositivos de entrada (no mostrados) pueden incluir un micrófono, dispositivo manual conectado a una terminal, almohadilla de juego, disco satelital , explorador, o lo similar. Estos y otros dispositivos de entrada frecuentemente se conectan a la unidad de procesamiento 620 a través de una interfase de entrada de usuario 660 q ue se acopla al bus de sistema 621 , pero puede conectarse por otras estructuras de bus y estructura, tal como un puerto paralelo, puerto de juego o bus serial universal (USB) . Estos son los tipos de estructuras que se virtualizan por las arquitecturas de la invención. Una interfase de gráficos 682, tal como una de las interfases implementadas por el Northbridge, también puede conectarse al bus de sistema 621 . Northbridge es un conjunto de microcircuitos que se comuniza con la CPU , o unidad de procesamiento huésped 620, y asume la responsabilidad de comunicaciones tales como PCI, PCIe y comunicaciones de puerto de gráficos aceleradas (AGP) . La invención contempla tanto las implementaciones de gráficos I ntegrados (dentro del Northbridge) y discretos (fuera del Northbridge) . Uno o más unidades procesadoras de gráficos (GPUs) 684 pueden comunicarse con la interfase de gráficos 682. En este aspecto, GPUs 684 generalmente incluyen el almacenamiento de memoria de un microcircuito, tal como almacenamiento registrado y GPUs 684 se comunican con una memoria de video 686. Sin embargo, GPUs 684, son de un ejemplo de co-procesador y de esta m anera una variedad de dispositivos co-procesadores puede incluirse en la computadora 61 0, y puede incluir una variedad de sombreadores de procedimiento, tal como sombreadores de vértice y píxeles. Un monitor 691 u otro tipo de dispositivo de visualización también se conecta al bus de sistema 626 por medio de una interfase, tal como una interfase de video 690, la cual puede a su vez comunicarse con la memoria de video 686. Además del monitor 691 , las computadoras también pueden incluir otros dispositivos de entrada periféricos tales como parlantes 697 e impresora 696, los cuales pueden conectarse a través de una interfase periférica de salida 695. La computadora 610 puede operar en un ambiente distribuido o interconectado utilizando conexiones lógicas hacia una o más computadoras remotas, tales como una computadora remota 680. La computadora remota 680 puede ser una computadora personal, un servidor, un guiador, una PC de red , un dispositivo par u otro nodo de red común, y típicamente incluye varios o todos los elementos anteriormente descritos en relación a la computadora 61 0, a pesar de que solamente un dispositivo de almacenamiento de memoria 681 se ha ilustrado en la Fig. 6B. Las conexiones lógicas representadas en la Fig. 6B incluyen una red de área local (LAN) 671 y una red de área amplia (WAN 673) , sino también incluyen otras redes/buses. Tales ambientes de red son de lugar común en hogares, oficinas, redes de computadora a nivel empresarial, intranets, e Internet. Cuando se utiliza en un ambiente de red LAN , la computadora 610 se conecta al LAN 671 a través de una interfase o adaptador de red 670. Cuando se utiliza en un ambiente de red WAN, la computadora 61 0 típicamente incluye un módem 672 u otro medio para establecer las comunicaciones sobre el WAN 673, tal como el I nternet. El módem 672, el cual puede ser interno o externo, puede conectarse al bus de sistema 621 por medio de la interfase de entrada de usuario 660, u otro mecanismo adecuado. En un ambiente de red, los módulos de programa representados en relación a la computadora 610, o partes de la misma, pueden almacenarse en el dispositivo de almacenamiento de memoria remota. A manera de ejemplo, y no de limitación , la Fig . 6B ilustra los programas de aplicación remota 685 como residentes en el dispositivo de memoria 681 . Se apreciará que las conexiones de red mostradas son ejemplares y otros medios para establecer un enlace de comunicaciones entre las computadoras, pueden utilizarse. Existen múltiples vías para implementar la presente invención, por ejemplo, un API adecuado, equipo de herramienta, código de unidad de transmisión , sistema operativo, control, objeto de software descargable o autónomo, etc. , el cual permite que las aplicaciones y servicios utilicen la (s) arquitectura (s) virtualizada (s) , sistemas y métodos de la invención. La invención contempla el uso de la invención desde el punto de vista de un API (u otro objeto de software), así como también de un objeto hardware o software que recibe cualquiera de las técnicas anteriormente mencionadas de acuerdo con la invención. De esta manera, varias implementaciones de la invención descritas en la presente pueden tener aspectos que se encuentran completamente en hardware, parcialmente en hardware y parcialmente en software, así como tam bién en software. Según se menciona anteriormente, mientras que las modalidades ejemplares de la presente invención se han descrito en relación con diversos dispositivos de computación y arquitecturas de red, los conceptos subyacentes pueden aplicarse cualquier dispositivo o sistema de computación en el cual es deseable emplear una GPU . Por ejemplo, el (los) diverso (s) algoritmo (s) e implementaciones de hardware de la invención pueden aplicarse al sistema operativo de un dispositivo de computadora, proporcionado como un objeto separado en el dispositivo, como parte de otro objeto , como un control reutilizable, como un objeto descargable de un servidor, como un "hombre medio" entre un dispositivo u objeto y la red , como un objeto distribuido, como hardware, en memoria, una combinación de cualquiera de los precedentes, etc. Un experto en la materia apreciará que existen numerosas vías para proporcionar el código de objeto y nomenclatura que logra la misma, similar o equivalente funcionalidad lograda por las diversas modalidades de la invención. Según se menciona, las diversas técnicas descritas en la presente pueden implementarse en relación con el hardware o software o, en donde sea adecuado, con una combinación de ambos. De esta manera, los métodos y aparatos de la presente invención, o ciertos aspecto o partes de la misma, pueden tomar la forma de código de programa (es decir, instrucciones) incorporadas en medios tangibles, tal como discos flexibles, CD-ROMs, unidades de transmisión duras, o cualquier otro medio de almacenamiento leíble por máquina, en donde, cuando el código de programa se carga en y se ejecuta por una máquina, tal como una computadora, la máquina llega a ser un aparato para practicar la invención. En el caso de ejecución de código de programa en computadoras programables, el dispositivo de computación generalmente incluye un procesador, un m edio de almacenamiento leíble por el procesador (incluyendo elementos de almacenamiento y/o memoria volátil y no volátil) , al menos un dispositivo de entrada, y al menos un dispositivo de salida. Uno o más programas que pueden implementar o utilizar las técnicas de virtualización GPU de la presente invención , por ejemplo, a través del uso de una API de procesamiento de datos, controles reutilizables, o lo similar, se implementan preferentemente en un lenguaje de programación orientado por objeto o de procedimiento de alto nivel para comunicarse con un sistema de com putadora. Sin embargo, el (los) programa (s) puede (n) implementarse en lenguaje de máquina o instalación, si se desea. En cualq uier caso, el lenguaje puede ser un lenguaje interpretado o complicado, y com binarse con im plementaciones de hardware. Los métodos y el aparato de la presente invención tam bién pueden practicarse por medio de las com unicaciones incorporadas en la forma de código de programa que se transmite sobre algún medio de transmisión, en donde, cuando el código de programa se recibe y se carga en y se ejecuta por una máquina, tal como un EPROM, un grupo de entrada, un dispositivo lógico programable (PLD), una computadora de cliente, etc. , la máquina llega a ser un aparato para practicar la invención. Cuando se implementa sobre un procesador de propósito general , el código de programa se combina con el procesador para proporcionar un aparato utilizar la presente invención en el contexto de una ejecución simultánea de gráficos, la invención no se limita, pero a su vez puede implementarse para virtualizar una segunda unidad de procesamiento especializada cooperando con un procesador principal por otras razones así también. Además, la invención contemple el escenario en donde los múltiples casos de la misma versión o liberación de una OS son operativos en máquinas virtuales separadas de acuerdo a la invención. Puede apreciarse que la virtualización de la invención es independiente de las operaciones para las cuales se utiliza la GPU. También se pretende que la invención aplique a todas las arquitecturas de GPU, incluyendo pero no limitándose a implementaciones de GPU múltiples, así como también modalidades multi-GPU que proporcionan la ilusión de una interfase de GPU única. Todavía además, la presente invención puede implementarse en o a través de una pluralidad de dispositivos o microcircuitos de procesamiento, y el almacenamiento puede efectuarse de igual forma a través de una pluralidad de dispositivos. Por lo tanto, la presente invención no deberá limitarse a cualquier modalidad única, sino a su vez deberá interpretarse en el ancho y alcance de acuerdo con las reivindicaciones anexas. único que opera para provocar la funcionalidad de la presente invención. Adicionalmente, cualquiera de las técnicas de almacenamiento utilizadas en relación con la presente invención pueden ser invariablemente una combinación de hardware y software. Mientras que la presente invención se ha descrito en relación con las modalidades preferidas de las diversas figuras, se entenderá que otras modalidades similares pueden utilizarse o pueden hacerse modificaciones y adicionales a la modalidad descrita para realizar la misma función de la presente invención sin desviarse de la misma. Por ejemplo, mientras que los ambientes de red ejemplares de la invención se describen en el contexto de un ambiente ¡nterconectado, tal como un ambiente interconectado par a par, un experto en la materia reconocerá que la presente invención no se limita a la misma, y que los métodos, según se describe en la presente solicitud puede aplicar a cualquier ambiente o dispositivo de computación, tal como una consola de juego, computadora móvil, computadora portátil, etc. , sea inalámbrica o cableada, y pueden aplicarse a cualquier número de tales dispositivos de computación conectados por medio de una red de comunicaciones, e interactuando a través de la red. Además, deberá enfatizarse que una variedad de plataformas de computadora, incluyendo los sistemas operativos del dispositivo portátil y otros sistemas operativos específicos de aplicación, se contemplan, especialmente a medida que el número de dispositivos interconectados inalámbricos continúa proliferando. Mientras que las modalidades ejemplares se refieren a

Claims (10)

1. REIVINDICACIONES 1 . Un método para procesar datos gráficos en un sistema de cómputo que tiene un primer sistema operativo alojado en una primer máquina virtual y un segundo sistema operativo alojado en una segunda máquina virtual, caracterizado porque comprende: recibir uno o más temas de trabajo por llevarse a cabo mediante una unidad de procesamiento de gráficos (GPU) de un subsistema de gráficos del sistema de cóm puto en donde el uno o más temas de trabajo se originan por dicha primer máquina virtual o dicha segunda máquina virtual; y procesar el uno o más temas de trabajo con la GPU sin consideración de si el uno o más temas de trabajo se basan en una inferíase a partir de dicho primer sistema operativo o en base a una inferíase de dicho segundo sistema operativo.
2. 2. Un método según la reivindicación 1 , caracterizado porque incluye además: procesar dicho uno o más temas de trabajo por un componente de monitor de máquina virtual de gráficos de un componente de monitor de máquina virtual que habilita dichas máquinas virtuales, primera y segunda.
3. 3. Un método según la reivindicación 2, caracterizado porque dicho procesamiento incluye: asignar al menos un recurso físico que incluye al menos uno de memoria de sistema o memoria de video para dicho uno o más temas de trabajo.
4. 4. Un método según la reivindicación 3, caracterizado porque dicha asignación del al menos un recurso físico incl uye la asignación separada de al menos un espacio de memoria en video o espacio de memoria en sistema para temas de trabajo originados por aplicaciones separadas que se ejecutan ya sea en dicha primer m áquina virtual o dicha segunda máquina virtual.
5. 5. Un método según la reivindicación 2, caracterizado porque dicho procesamiento incluye determinar si el uno o más temas de trabajo son privilegiados o no privilegiados, y aplicar diferentes conjuntos de reglas para el procesamiento de temas de trabajo privilegiados contra no privilegiados.
6. 6. Un método según la reivindicación 1 , caracterizado porq ue incluye además: componer el despliegue de la emisión del uno o más temas de trabajo a partir de una base de código confiable, creada por un componente monitor de máquina virtual que habilita a dichas máquinas virtuales, primera y segunda.
7. 7. Un método según la reivindicación 1 , caracterizado porque incluye además: procesar la emisión de una aplicación no confiable que se ejecuta en la primer máquina, incluyendo la utilización de al menos un servicio confiable que se ejecuta en la segunda máquina para proteger dicha emisión.
8. 8. Una interfase de programación de aplicaciones , caracterizada porque comprende instrucciones ejecutables por computadora para llevar a cabo comunicaciones de acuerdo con el método según la reivindicación 1 .
9. 9. Una unidad procesadora de gráficos, caracterizada porque comprende componentes funcionales adaptados para llevar a cabo el método según la reivindicación 1.
10. 10. Un dispositivo de cómputo caracterizado porque comprende medios para llevar a cabo el método según la reivindicación 1 . 1 1. Un método para procesar datos gráficos en un sistema de cómputo que tiene una primer versión de un sistema operativo alojado en una primer máquina virtual por un componente monitor de máquina virtual y una segunda versión del sistema operativo alojado en una segunda máquina virtual por el componente monitor de máquina virtual, caracterizado porque comprende: recibir uno o más temas de trabajo provenientes de la primer máquina virtual o la segunda máquina virtual para llevarse a cabo por una unidad de procesamiento de gráficos (GPU) de un subsistema de gráficos del sistema de cómputo, en donde al menos uno de los temas de trabajo incluye una orden privilegiada; descubrir la orden privilegiada por el componente monitor de máquina virtual; y emular la orden privilegiada de al menos uno de los temas de trabajo en base a por lo menos una política predefinida. 12. Un método según la reivindicación 1 1 , caracterizado porque incluye además comunicarse con un componente monitor de máquina virtual de gráficos del componente monitor de la máquina virtual, en donde el componente monitor de la máquina virtual de gráficos maneja temas de trabajo con órdenes privilegiadas de la GPU a favor de ambas dicha primer máquina virtual y dicha segunda máquina virtual. 1 3. Una interfase de programación de aplicación caracterizada porque comprende instrucciones ejecutables por computadora para llevar a cabo comunicaciones de acuerdo con el método según la reivindicación 1 1 . 14. Una unidad procesadora de gráficos caracterizada porque comprende componentes funcionales adaptados para llevar acabo el método según la reivindicación 1. 15. Un dispositivo de cómputo caracterizado porque comprende medios para llevar a cabo el método según la reivindicación 1 1 . 16. Un dispositivo de cómputo caracterizado porque comprende: una primer aplicación y una segunda aplicación que se ejecuta en una o más máquinas virtuales del dispositivo de cómputo; un componente de monitor de máquina virtual que, a menos que se autorice, no permite que las llamadas de interfase de gráficos provenientes de la primer aplicación interactúen con cualquier recurso físico que no se autorice para la primer aplicación. 17. Un dispositivo de cómputo según la reivindicación 16, caracterizado porque el componente monitor de máquina virtual no permite que las llamadas de interfase de gráficos provenientes de la primer aplicación cambien o lean la memoria del sistema o la memoria local asociada con la segunda aplicación. 1 8. Un dispositivo de cómputo según la reivindicación 16, caracterizado porque dicho componente monitor de máquina virtual incluye una base de código confiable para presentar ventanas de despliegue en base a emisiones de la primer aplicación de la segunda aplicación, respectivamente. 19. Un dispositivo de cómputo según la reivindicación 18, caracterizado porque dicha primer aplicación se ejecuta en una primer plataforma de sistema operativo que tiene un primer escritorio asociado con la misma y dicha segunda aplicación se ejecuta en una segunda plataforma de sistema operativo que tiene un segundo escritorio asociado con la misma, y dicha presentación por la base de código confiable incluye la presentación de dicho primer escritorio en una primer ventana en despliegue y dicho segundo escritorio en una segunda ventana en despliegue. 20. Un dispositivo de cómputo según la reivindicación 18, caracterizado porque dicha primer aplicación se ejecuta en una primer plataforma de sistema operativo que tiene un primer escritorio asociado con la misma y dicha segunda aplicación se ejecuta en una segunda plataforma de sistema operativo que tiene un primer escritorio asociado con la misma, y dicha presentación por la base de código confiable incluye la presentación ya sea de dicho primer escritorio o de dicho segundo escritorio en despliegue.