BRPI0505081B1 - Systems and methods for virtualization of graphic subsystems - Google Patents

Description

"SISTEMAS Ξ MÉTODOS PARA VIRTUALIZAÇÃO DE SUBSISTEMAS GRÁFICOS" NOTIFICAÇÃO E PERMISSÃO DE DIREITOS AUTORAIS Uma porção da revelação deste documento de patente pode conter material que está sujeito à proteção de direitos autorais. O proprietário dos direitos autorais não tem objeção à reprodução em fac-símile por qualquer um do documento de patente ou da revelação de patente, como ele aparece nos arquivos ou registros de patentes da Repartição de Patentes e Marca de Indústria e de Comércio, mas de outra forma se reserva todos os direitos dos direitos autorais. A seguinte notificação se aplicará a esse documento: Copyright© 2004, Microsoft Corp.

CAMPO DA INVENÇÃO A presente invenção é direcionada a sistemas, aparelhos, métodos, interfaces do usuário, protocolos e interfaces de programação de aplicação (APIs) para virtualização de subsistemas gráficos de dispositivos de computação. Mais particularmente, a invenção é direcionada a arquiteturas gráficas virtualizadas que provêem benefícios relacionados com compatibilidade, segurança e controle dos direitos digitais.

ANTECEDENTES

Por meio dos antecedentes com relação ao estado da canalização gráfica moderna, um subsistema gráfico geralmente coopera com um computador hospedeiro para executar certas tarefas especializadas no seu nome, por exemplo, tarefas que exigem, falando de forma relativa, muita da energia computa- cíonal pura tal como preparação da saída de uma aplicação para exibição em um monitor, ou impressora ou outro dispositivo. Para criar uma representação gráfica de computador 3-D, por exemplo, objetos a serem descritos são representados como modelos matemáticos dentro do computador, que são bem adequados para processamento matematicamente intensivo pela unidade de processamento gráfico (GPU) do subsistema gráfico. Por exemplo, modelos 3-D podem ser compostos de pontos geométricos dentro de um sistema de coordenadas consistindo de um eixo x, y e z, por exemplo, correspondendo com a largura, altura e profundidade, respectivamente. Os objetos são definidos por uma série de pontos, chamados vértices. A localização de um ponto, ou vértice, é definida por suas coordenadas x, y e z (ou outro sistema de coordenada). Na terminologia gráfica, um vértice é um ponto, dois vértices definem uma linha, ou um segmento de linha e três vértices definem um triângulo onde todos os três são "primitivas". Quando três ou mais desses pontos são conectados, um polígono é formado, com o triângulo sendo o polígono mais simples, que pode ser usado para aproximar a geometria 3-D de um objeto e aplicar dados gráficos na geometria 3-D para criar uma variedade de efeitos artísticos e realísticos e transformações de cor. A canalização gráfica, usando suas várias subunida-des computacionais, pode processar vértices e outros fluxos de dados de maneira muito rápida e eficiente para representar finalmente objetos 3-D muito complexos em um espaço de exibição 2-D.

Assim, certas tarefas, tais como renderização e exibição de gráficos tridimensionais (3-D) na tela, tipicamente envolvem muitos cálculos e computações que são bem a-dequados para serem executados por um subsistema gráfico. Em um sistema gráfico simples, tais computações ocorrem de a-cordo com algum nível de processamento cooperativo ou compartilhado pela unidade de processamento central (CPU) e a unidade de processamento gráfico (GPU). Em um cenário exemplar, depois que as instruções são processadas e algumas computações iniciais ocorrem na CPU, um conjunto de pontos ou vértices de coordenadas que definem o objeto a ser rende-rizado é armazenado na memória do vídeo para processamento adicional pela GPU na canalização gráfica. Se os dados são dados gráficos 3-D, por exemplo, um mosaico ("tessellator") pode decompor os dados gráficos em polígonos simples de a-cordo com algoritmos predeterminados projetados para eficientemente cobrir a superfície do objeto sendo representado -um processo conhecido como mosaico. Atualmente, na maior parte das canalizações gráficas, os dados podem então ser operados por uma ou mais subunidades computacionais de uma GPU, tal como sombreadores procedurais, dependendo das instruções que são entregues para a GPU, que em cooperação com a memória de vídeo, isto é, o armazenamento intermediário do quadro, processa os dados de acordo com as instruções de trabalho para os dados, e produz como saída os dados onde apropriadamente direcionados, por exemplo, em um mostrador ou dispositivo de impressora.

Como ilustrado na Fig. 1, com relação aos sistemas de computação tendo sistemas de coprocessamento gráfico, os sistemas de computação são divididos entre a CPU hospedeira e o hardware gráfico. A CPU facilita a criação de chamadas para APIs gráficas por aplicações e serviços que solicitam seu uso. Convencionalmente, a aplicação e acionadores estão localizados no lado da CPU e a informação dessas fontes é enviada como itens de trabalho para a canalização gráfica, tal como exibição de dados em um monitor. Primeiro, a informação é enviada da CPU para a GPU, como empacotada pela CPU de acordo com as APIs. A seguir, a informação da aplicação aguarda na memória até que ela é programada e processada pelas subunidades computacionais da GPU, tal como o(s) sombre-ador(es) de vértice se dados gráficos 3-D estão sendo processados. Depois que o(s) sombreador(es) de vértice conclui (em) as suas operações, a informação ê tipicamente produzida do(s) sombreador(es) de vértice através de uma trajetória de dados especial para o(s) sombreador(es) de pixel até que ela é acessada pelo(s) sombreador(es) de pixel para processamento adicional. Depois que o(s) sombreador(es) de pixel executaram as suas operações, a informação é colocada em um armazenamento temporário de quadro para ser varrida para fora para um mostrador, ou enviada de volta para o hospedeiro para operação adicional. 0 termo "armazenamento provisório de quadro" nas arquiteturas gráficas atuais geralmente se refere a qualquer memória (geralmente memória de vídeo incluída para a íntero-peração com a GPU) usada em conjunto com a rasterização e/ou processos para fora do conversor de digital para analógico (DAC). Sob esse aspecto, embora o termo rasterização seja algumas vezes usado de forma mais geral, o processamento e-xecutado em conjunto com o processamento do pixel ou processamento do mecanismo de configuração na canalização gráfica é geralmente citado como rasterização. A varredura para fora ou para fora do DAC, por outro lado, é o processo de transmissão de sinais para um monitor ou LCD com base nos conteúdos do armazenamento temporário do quadro.

Devido à especialização da tarefa e os recursos computacionais implicados, subsistemas gráficos de sistemas de computador são geralmente usados para exibir objetos gráficos em uma tela de mostrador. A finalidade dos gráficos de computador tridimensionais (3-D) é geralmente criar imagens bidimensionais (2-D) em uma tela de computador que representa de modo realístico um objeto ou objetos em três dimensões. No mundo real, os objetos ocupam três dimensões tendo uma altura real, uma largura real e uma profundidade real. Uma fotografia é um exemplo de uma representação 2-D de um espaço 3-D. Gráficos de computador 3-D são geralmente como uma fotografia já que eles representam um mundo 3-D no espaço 2-D de uma tela de computador, exceto que a imagem subjacente é geralmente modelada com geometria 3-D e texturas de superfície.

As imagens criadas com gráficos de computador 3-D são usadas em uma ampla faixa de aplicações, de jogos de entretenimento de vídeo até simuladores de vôo de aeronave, para representar em uma maneira realística a visão de um indivíduo de uma cena em um dado ponto no tempo. Exemplos bem conhecidos de gráficos de computador 3-D incluem os efeitos especiais nos filmes de Hollywood tais como Exterminador II, Parque dos dinossauros, Toy Story e semelhantes. Uma indústria que observou um aumento de crescimento particularmente enorme nos últimos poucos anos é a indústria de jogos de computador e a geração atual de jogos de computador que a-plicam técnicas gráficas 3-D em um modo cada vez mais crescente. Ao mesmo tempo, a velocidade da reprodução está cada vez mais rápida. Essa combinação impulsionou uma necessidade genuína pela renderização rápida e flexível de gráficos 3-D em sistemas relativamente baratos.

De acordo com essas linhas de tendências em rápido movimento associadas com subsistemas gráficos, entretanto, a compatibilidade, segurança e controle dos direitos evoluíram de maneira correspondente como preocupações. Como cada nova geração de GPUs e hardware associado suplanta a geração prévia, além do hardware, as interfaces para a canalização (por exemplo, DirectXS, DirectX9, GDI, GDI+, etc.) têm que evoluir e se é esperado que elas manipulem chamadas para interfaces "antigas", então um código separado precisa ser escrito que garanta o suporte para o hardware mais antigo. Depois de mais do que umas poucas gerações, a probabilidade que o código da interface gráfica de qualquer sistema operacional particular permaneça controlável diminui, e a probabilidade de erros na manipulação devido a chamadas de função incompatíveis aumenta quando os efeitos da ("fan-out") do código de compatibilidade se tornam enraizados. Um problema adicional é que "raças" inteiramente separadas de código de interface gráfica se desenvolvem em virtude da existência de sistemas operacionais diferentes ou plataformas (Macintosh, Linux, Windows, etc.) ou até mesmo raças diferentes incluídas na mesma plataforma {por exemplo, OpenGL, GDI+, DirectX, etc.). Assim, ainda permanecem problemas por meio dos quais diferentes versões de sistemas operacionais, interfaces gráficas e hardware associado não podem ser todas co-suportadas, e esses problemas estão se tornando mais complicados com o tempo. Seria desejável amenizar esse problema sem ter que modificar o código do núcleo provido com qualquer sistema operacional particular ou conjunto de interfaces.

Com o mesmo pano de fundo, os problemas de segurança e proteção de conteúdo/controle de direitos digitais (DRM) estão se tornando mais complicados para resolver em relação à canalização gráfica. Com sistemas operacionais, interfaces e hardware diferentes, não existe mecanismo comum que imponha a segurança dos dados ou imponha a proteção do conteúdo/condições de controle dos direitos digitais através de todas as canalizações conhecidas. Assim, é desejada uma maneira comum ou camada para tratar os interesses sobre a segurança de dados e/ou DRM que funcione independentemente da canalização gráfica.

Assim seria desejável virtualizar a canalização gráfica de um sistema de computador provendo uma máquina virtual como uma camada de interação entre o processador hospedeiro e a GPU. Seria adicionalmente desejável implementar sistemas e métodos que superam os inconvenientes das presentes preocupações de compatibilidade, segurança e proteção de conteúdo/DRM que são encontradas quando várias ver- soes de sistemas operacionais ou interfaces ou várias arquiteturas de GPUs são utilizadas.

SUMARIO DA INVENÇÃO

Em consideração aos inconvenientes acima identificados e outros da técnica, a presente invenção provê sistemas e métodos para aplicação de máquinas virtuais no espaço do hardware gráfico. Em várias modalidades da invenção, embora código de supervisão funcione na CPU, os itens de trabalho gráfico atuais são executados diretamente no hardware gráfico. Em uma modalidade não limitadora, o código de supervisão é estruturado como um monitor de máquina virtual gráfica. A compatibilidade da aplicação é mantida usando tecnologia de monitor de máquina virtual (VMM) para executar um primeiro sistema operacional (OS), tal como uma versão de OS original, simultaneamente com um segundo OS, tal como uma nova versão de OS, em máquinas virtuais (VMs) separadas. Em uma modalidade, a tecnologia do VMM aplicada nos processadores hospedeiros é estendida para unidades de processamento de gráficos (GPUs) para permitir acesso de hardware aos aceleradores gráficos, garantindo que as aplicações legadas o-perem em desempenho total. A invenção também provê métodos para tornar a experiência do usuário cosmeticamente direta enquanto executando múltiplas aplicações em diferentes VMs. Em outros aspectos da invenção, pela utilização da tecnologia do VMM, a arquitetura gráfica virtualizada da invenção é estendida para prover serviços confiáveis e proteção de conteúdo .

Outras vantagens e aspectos da invenção são descritos abaixo.

BREVE DESCRIÇÃO DOS DESENHOS

Os sistemas e métodos para virtualizar GPUs de a-cordo com a presente invenção são adicionalmente descritos com referência aos desenhos acompanhantes nos quais: A Figura 1 é um diagrama de blocos ilustrando uma implementação da técnica anterior de uma canalização gráfica? A Figura 2A é um diagrama de blocos representando a divisão em camadas lógica do hardware e arquitetura de software para um ambiente operacional emulado em um sistema de computador; A Figura 2B é um diagrama de blocos representando um sistema de computação virtualizado onde a emulação é executada pelo sistema operacional hospedeiro (diretamente ou através de um hipervisor); A Figura 2C é um diagrama de blocos representando um sistema de computação virtualizado alternativo onde a e-mulação é executada por um monitor de máquina virtual funcionando lado a lado com um sistema operacional hospedeiro; A Figura 3A ilustra uma primeira arquitetura não limitadora para aplicação de máquinas virtuais no espaço do hardware gráfico por meio do que o código de supervisão funciona na CPU, mas os itens de trabalho gráfico são manipulados diretamente pelo hardware gráfico; A Figura 3B ilustra uma outra arquitetura exemplar não limitadora provida para virtualizar a canalização gráfi- ca de acordo com a invenção; A Figura 4A ilustra uma modalidade para exibir uma "única área de trabalho de cada vez" de acordo com a invenção; A Figura 4B ilustra uma modalidade alternativa de "área de trabalho em uma janela", por meio da qual todas as áreas de trabalho podem ser simultaneamente exibidas de a-cordo com a invenção; A Figura 4C ilustra uma arquitetura exemplar para a mistura de dados de aplicação confiáveis e não confiáveis de acordo com a invenção; A Figura 4D ilustra uma extensão de uma partição confiável para incluir uma porta de interoperabilidade de meios, como uma camada separada de proteção para o conteúdo; A Figura 4E ilustra a interação exemplar onde uma aplicação legada de OS Hóspede executando em um OS hospedeiro interage com um componente de serviços legados do OS hóspede para emular o comportamento legado; A Figura 5 é um diagrama de fluxo representando uma seqüência não limitadora exemplar de processamento de dados gráficos de acordo com uma ou mais modalidades das arquiteturas gráficas virtualizadas providas de acordo com a invenção; A Figura 6A é um diagrama de blocos representando um ambiente de rede exemplar tendo uma variedade de dispositivos de computação nos quais a presente invenção pode ser implementada e A Figura 6B é um diagrama de blocos representando um dispositivo de computação não limitador exemplar no qual a presente invenção pode ser implementada. DESCRIÇÃO DETALHADA DA MODALIDADE ILUSTRATIVA, Visão geral Como mencionado, a presente invenção provê sistemas e métodos para aplicação de máquinas virtuais no espaço do hardware gráfico. Em várias modalidades da invenção, enquanto o código de supervisão, tal como um monitor de máquina virtual gráfica, funciona na CPU, os itens de trabalho gráfico reais são executados diretamente no hardware gráfico.

Em um aspecto não limitador da invenção, sistemas e métodos são providos para separar as funções de hardware gráfico em operações privilegiadas e não privilegiadas e para virtualizar eficientemente as operações privilegiadas, enquanto mantendo uma experiência de usuário direta. Em um outro aspecto não limitador da invenção, a virtualização e-ficiente do processamento de interrupção do hardware é atingida. Em aspectos adicionais, a invenção provê capacidades de gerenciamento de recurso na camada de emulação para atribuir a alocação pré-fixada de recursos, tais como memória, ciclos de processamento, estado real da tela, etc., para partições e/ou para atribuir dinamicamente tais recursos de acordo com os parâmetros compatíveis com várias plataformas e compatíveis com várias aplicações/necessidades do sistema.

Um outro resultado benéfico da arquitetura é que a presente invenção permite que uma partição virtual tenha a-cesso direto ao hardware gráfico sem exigir mudanças no sis- tema operacional hóspede ou aplicações. Muitas aplicações também derivam da arquitetura básica da invenção. Por exemplo, o código legado pode ser deixado nos sistemas operacionais antigos usando uma instância do sistema operacional legado para execução de aplicações dependentes do código legado. Um outro exemplo é a idéia de construção de serviços confiáveis e não confiáveis, que por sua vez podem ser usados para suportar saída gráfica confiável ou técnicas de proteção de conteúdo.

Outros sistemas e métodos providos de acordo com a invenção referem-se à experiência do usuário. Com múltiplas partições, uma experiência de usuário provida pela invenção é a introdução da "área de trabalho em uma janela" onde a área de trabalho exibida para cada sistema operacional hóspede é redirecionada para uma janela (ou visualização de á-rea de trabalho alternada) no dispositivo de exibição (ou múltiplos dispositivos de exibição no caso de múltiplos monitores, algumas vezes conhecidos como "multimon"). Em outras modalidades, a invenção possibilita uma experiência do usuário que permite que as janelas de sistemas operacionais hóspedes diferentes sejam misturadas em uma única exibição unificada, por meio do que os "pixels" associados com qualquer janela particular são identificados. Em uma modalidade, a invenção atinge a identificação dos pixels e suas associações de janela adicionando "programas auxiliares" nos sistemas operacionais hóspedes para identificar as partes de várias janelas. Em outras modalidades, a invenção possibilita a interação com o "gerenciador de janela" hóspede para ga- rantir que as janelas abertas na área de trabalho principal fiquem abertas na área de trabalho dos sistemas operacionais hóspedes virtuais, de modo que elas possam ser extraídas e exibidas na área de trabalho principal. Em outras modalidades, o suporte do hardware gráfico é provido para ajudar a identificar, de modo parcial ou inteiro, as localizações da memória de pixels de janelas diferentes. A invenção também inclui modalidades provendo suporte de hardware gráfico adicional para auxiliar no controle das janelas na área de trabalho virtual. Durante uma área onde sistemas operacionais futuros podem adicionar suporte para tornar essa tarefa mais fácil, a idéia é possibilitar uma estrutura que identifica janelas individuais de sistemas operacionais hóspedes diferentes e tornar esses dados disponíveis para um serviço de apresentação unificado (também algumas vezes citado como um mecanismo de composição da área de trabalho) que compõe as múltiplas fontes. Esse mecanismo tem acesso ao estado da memória gráfica de múltiplos hóspedes, enquanto que os hóspedes normalmente não podem ver as chamadas de função e atividades um do outro.

Um caminho que possibilita os efeitos de composição em camadas complexos na saída da exibição em relação ao conteúdo dos OSs hóspedes respectivos ê ter um mecanismo de apresentação "extraindo" o conteúdo da janela de OSs hóspedes diferentes de modo a construir a área de trabalho composta. Um caminho alternado é permitir que os OSs hóspedes renderizem diretamente em uma única área de trabalho principal, isto é, renderizem para essa memória, porém usem supor- te de hardware especial para restringir as partes da área de trabalho nas quais os OSs hóspedes podem desenhar. Por exemplo, as regiões permissíveis podem ser controladas usando um mecanismo privilegiado separado similar ao mecanismo usado para recorte da janela do hardware onde uma lista de retângulos, ou um mapa de bits, define uma máscara que indica quais pixels podem ser escritos. Alguém poderia implementar isso como uma operação de "empurrar" onde os OSs hóspedes desenham diretamente na área de trabalho e o mecanismo de apresentação controla onde a(s) região(ões) que pode(m) ser escrita(s) está(ão) para cada OS hóspede.

Em várias outras modalidades, a invenção provê sistemas e métodos para identificar e localizar pixels de janelas renderizadas por um primeiro OS e janelas renderiza-das por um segundo OS e apresentar as janelas uma de cada vez ou combinadas em algum modo para exibição. A invenção também inclui sistemas e métodos para alocar e atribuir recursos físicos, tais como memória de vídeo ou sistema, em um segundo OS, tal que os recursos atribuídos ficam diretamente acessíveis e recursos não atribuídos não ficam acessíveis pelo segundo OS. A invenção adicionalmente provê sistemas e métodos para interceptar e eficientemente emular operações privilegiadas.

Outros aspectos mais detalhados da invenção são descritos abaixo, mas primeiro, a descrição seguinte provê uma visão geral de e algum vocabulário comum para máquinas virtuais e terminologia associada como os termos ficaram conhecidos em conjunto com sistemas operacionais e as técnicas de virtualização do processador hospedeiro ("CPU"). Ao fazer isso, um conjunto de vocabulário é apresentado que alguém de conhecimento comum na técnica pode achar útil para a descrição que segue do aparelho, sistemas e métodos para prover capacidades de emulação para o lado do subsistema gráfico de sistemas de computação de acordo com a invenção.

Visão Geral das Máquinas Virtuais Computadores incluem unidades de processamento central (CPUs) de uso geral ou "processadores" que são projetados para executar um conjunto específico de instruções do sistema. Um grupo de processadores que têm arquitetura ou especificações de projeto similares pode ser considerado como membros da mesma família de processador. Exemplos de famílias de processador atuais incluem a família do processador da Motorola 680X0, fabricada por International Business Machines (IBM) ou Motorola, Inc. de Phoenix, Arizona; a família de processador Intel 80X86, fabricada por Intel Corporation de Sunnyvale, Califórnia e a família de processador PowerPC, que é fabricada por Motorola, Inc. e usada nos computadores fabricados por Apple Computer, Inc. de Cupertino, Califórnia. Embora um grupo de processadores possa estar na mesma família por causa da sua arquitetura similar e considerações de projeto, os processadores podem variar amplamente dentro de uma família de acordo com sua velocidade de relógio e outros parâmetros de desempenho.

Cada família de microprocessadores executa instruções que são únicas para a família do processador. O conjunto coletivo de instruções que um processador ou família de processadores pode executar é conhecido como conjunto de instruções do processador. Como um exemplo, o conjunto de instruções usado pela família de processador Intel 80X86 é incompatível com o conjunto de instruções usado pela família de processador PowerPC. 0 conjunto de instruções de Intel 80X86 é baseado no formato de computador de conjunto de instruções complexo (CISC). O conjunto de instruções do PowerPC da Motorola é baseado no formato de computador de conjunto de instruções reduzido (RISC). Os processadores CISC usam um grande número de instruções, algumas das quais podem executar funções muito complicadas, mas que exigem geralmente muitos ciclos de relógio para executar. Os processadores RISC usam um número menor de instruções disponíveis para e-xecutar um conjunto mais simples de funções que são executadas em uma taxa muito mais alta. A singularidade da família de processador entre os sistemas de computador também tipicamente resulta em incompatibilidade entre os outros elementos da arquitetura de hardware dos sistemas de computador. Um sistema de computador fabricado com um processador da família de processador Intel 80X86 terá uma arquitetura de hardware que é diferente da arquitetura de hardware de um sistema de computador fabricado com um processador da família de processador do PowerPC. Por causa da singularidade do conjunto de instruções do processador e da arquitetura de hardware do sistema de computador, programas de software aplicativo são tipicamente escritos para funcionar em um sistema de computador particular executando um sistema operacional particular.

Falando de forma geral, fabricantes de computador tentam maximizar sua porção de mercado tendo preferivelmente mais do que menos aplicações funcionando na família de microprocessador associada com a linha de produto dos fabricantes de computador. Para expandir o número de sistemas o-peracíonais e programas aplicativos que podem funcionar em um sistema de computador, um campo da tecnologia foi desenvolvido no qual um dado computador tendo um tipo de CPU, chamado um hospedeiro, incluirá um programa virtualizador que permite que o computador hospedeiro emule as instruções de um tipo não relacionado de CPU, chamado um hóspede. Assim, o computador hospedeiro executará uma aplicação que fará com que uma ou mais instruções do hospedeiro sejam chamadas em resposta a uma dada instrução do hóspede, e dessa maneira o computador hospedeiro pode executar ambos o software planejado para sua própria arquitetura de hardware e o software escrito para computadores tendo uma arquitetura de hardware não relacionada.

Como um exemplo mais específico, um sistema de computador fabricado por Apple Computer, por exemplo, pode executar sistemas operacionais e programas escritos para sistemas de computador com base em PC. Também pode ser possível usar programas virtualizadores para executar simultaneamente em uma única CPU múltiplos sistemas operacionais incompatíveis. Nesse último arranjo, embora cada sistema o-peracional seja incompatível com o outro, os programas virtualizadores podem hospedar cada um dos vários sistemas operacionais e dessa maneira permitir que sistemas operacionais de outra forma incompatíveis funcionem simultaneamente no mesmo sistema de computador hospedeiro.

Quando um sistema de computador hóspede é emulado em um sistema de computador hospedeiro, o sistema de computador hóspede é dito ser uma "máquina virtual" já que o sistema de computador hóspede somente existe no sistema do computador hospedeiro como uma representação de software puro da operação de uma arquitetura de hardware específica. Os termos virtualizador, emulador, executor direto, máquina virtual e emulação do processador são algumas vezes usados de modo permutável para representar a capacidade de imitar ou emular a arquitetura de hardware de todo um sistema de computador usando um ou vários caminhos conhecidos e apreciados por esses de conhecimento na técnica. Além do mais, todos os usos do termo "emulação" em qualquer forma é planejado para transportar seu significado amplo e não é planejado para distinguir entre conceitos de execução de instrução de emulação contra execução direta das instruções do sistema operacional na máquina virtual. Assim, por exemplo, o software do PC virtual criado por Connectix Corporation de San Mateo, Califórnia "emula" (pela emulação da execução da instrução e/ou execução direta) um computador inteiro que inclui um processador Intel 80X86 e vários componentes de placa -mãe e placas, e a operação desses componentes é "emulada" na máquina virtual que está sendo executada na máquina hospedeira. Um programa virtualizador executando no software do sistema operacional e arquitetura de hardware do computador hospedeiro, tal como um sistema de computador tendo um pro- cessador PowerPC, imita a operação de todo o sistema de computador hóspede. 0 caso geral de virtualização permite que uma arquitetura de processador execute OSs e programas de outras arquiteturas de processador (por exemplo, programas Mac PowerPC no x86 Windows e vice-versa), mas um caso especial importante é quando as arquiteturas de processador básicas são as mesmas (executam várias versões do x86 Linux ou versões diferentes do x86 Windows no x86). Nesse último caso, existe o potencial de executar o OS hóspede e suas aplicações mais eficientemente desde que o conjunto de instruções básicas é o mesmo. Em um tal caso, as instruções do hóspede podem ser executadas diretamente no processador sem perder o controle ou deixar o sistema aberto ao ataque (isto é, o OS hóspede é colocado no área de segurança ("sandbox")). Como descrito em detalhes abaixo, isso é onde a separação de privilegiado contra não privilegiado e as técnicas para controlar o acesso à memória entram em jogo. Para virtualização onde existe um desacordo arquitetônico (PowerPC <-> x86), dois caminhos poderíam ser usados: a emulação de instrução por instrução (relativamente lenta) ou tradução do conjunto de instrução do hóspede para o conjunto de instrução nativo (mais eficiente, mas usa a etapa de tradução). Se a emulação da instrução é usada, então é relativamente fácil tornar o ambiente robusto; entretanto, se a tradução é usada, então ela mapeia de volta para o caso especial onde as arquiteturas do processador são as mesmas.

De acordo com a invenção, as plataformas gráficas são virtualizadas e assim um cenário exemplar de acordo com a invenção se aplicando âs arquiteturas gráficas seria a e-mulação de uma placa ATI usando hardware NVidia. Para o caso de virtualização gráfica, em várias modalidades, a invenção focaliza na execução direta de comandos da mesma arquitetura gráfica. No contexto gráfico, o equivalente da tradução realmente não existe, ou preferencialmente a emulação e a tradução correspondem a mesma coisa. A tradução funciona no processador porque depois que o código é traduzido, o código pode ser executado múltiplas vezes, dessa maneira amortizando o custo da tradução. Entretanto, devido à maneira como as aplicações gráficas são estruturadas, o equivalente de um programa para traduzir (ignorando sombreadores) não existe necessariamente. No lugar, o fluxo de comando (lista de i-tens de trabalho) é constantemente regenerado, então não e-xiste necessariamente qualquer reutilização que possa amortizar o custo da tradução. Em uma modalidade mais complexa, listas de itens de trabalho poderiam ser examinadas para determinar se elas correspondem com uma lista pré-traduzida.

Como descrito em várias modalidades abaixo, de a-cordo com várias modalidades da invenção, a virtualização enquanto executando diretamente as instruções do hóspede (da tradução ou porque a mesma arquitetura de processador está envolvida) tem o benefício de desempenho se a segurança do sistema pode ser mantida. Em várias modalidades, a invenção assim descreve sistemas e métodos para controlar o acesso do hóspede a alguns ou todos os recursos físicos subjacentes (memória, dispositivos, etc.). 0 programa virtualizador age como a troca entre a arquitetura de hardware da máquina hospedeira e as instruções transmitidas pelo software (por exemplo, sistemas operacionais, aplicações, etc.) funcionando dentro do ambiente emulado. Esse programa virtualizador pode ser um sistema o-peracional hospedeiro (HOS), que é um sistema operacional funcionando diretamente no hardware do computador físico (e que pode compreender um hipervisor, discutido em maiores detalhes posteriormente aqui). Alternadamente, o ambiente emulado podería também ser um monitor de máquina virtual (VMM) que é uma camada de software que funciona diretamente acima do hardware, talvez funcionando lado a lado e trabalhando em conjunto com o sistema operacional hospedeiro, e que pode virtualizar todos os recursos da máquina hospedeira (bem como certos recursos virtuais) expondo interfaces que são as mesmas que o hardware que o VMM está virtualizando. Essa virtualização possibilita que o virtualizador (bem como o próprio sistema de computador hospedeiro) passe despercebido pelas camadas do sistema operacional funcionando acima dele. A emulação do processador, dessa maneira, permite que um sistema operacional hóspede execute em uma máquina virtual criada por um virtualizador funcionando em um sistema de computador hospedeiro compreendendo ambos o hardware físico e um sistema operacional hospedeiro.

De uma perspectiva conceituai, sistemas de computador geralmente compreendem uma ou mais camadas de software funcionando em uma camada fundamental do hardware. Essa divisão em camadas é feita por razões de abstração. Pela defi- nição da interface para uma dada camada de software, essa camada pode ser implementada diferentemente por outras camadas acima dela. Em um sistema de computador bem projetado, cada camada somente sabe sobre (e somente conta com) a camada imediata abaixo dela. Isso permite que uma camada ou uma "pilha" (múltiplas camadas adjacentes) seja substituída sem negativamente causar impacto nas camadas acima da dita camada ou pilha. Por exemplo, aplicações de software (camadas superiores) tipicamente contam com níveis inferiores do sistema operacional (camadas inferiores) para escrever arquivos em alguma forma de armazenamento permanente, e essas aplicações não precisam entender a diferença entre escrever os dados em um disco flexível, uma unidade rígida ou uma pasta de rede. Se essa camada inferior é substituída com novos componentes do sistema operacional para escrever arquivos, a operação das aplicações de software da camada superior permanece intacta. A flexibilidade do software em camadas permite que uma máquina virtual (VM) apresente uma camada de hardware virtual que é na realidade uma outra camada de software. Dessa maneira, uma VM pode criar a ilusão para as camadas de software acima dela que as camadas de software estão funcionando no seu próprio sistema de computador privado, e assim VMs podem permitir que múltiplos "sistemas hóspedes" funcionem simultaneamente em um único "sistema hospedeiro". Esse nível de abstração é representado pela ilustração da Fig. 2A. A Fig. 2A é um diagrama representando a divisão em camadas lógica da arquitetura de hardware e software para um ambiente operacional emulado em um sistema de computador. Na figura, um programa de emulação 94 funciona direta ou indiretamente na arquitetura de hardware físico 92. 0 programa de emulação 94 pode ser (a) um monitor de máquina virtual que funciona lado a lado com um sistema operacional hospedeiro, (b) um sistema operacional hospedeiro especializado tendo capacidades de emulação nativas ou (c) um sistema operacional hospedeiro com um componente hipervisor onde o dito componente hipervisor executa a dita emulação. 0 programa de emulação 94 emula uma arquitetura de hardware hóspede 96 (mostrada como linhas tracejadas para ilustrar o fato que esse componente é a "máquina virtual", isto é, hardware que não existe na realidade, mas é no lugar disso, emulado pelo dito programa de emulação 94) . Um sistema operacional hóspede 98 executa na dita arquitetura de hardware hóspede 96, e a aplicação de software 100 funciona no sistema operacional hóspede 98. No ambiente operacional emulado da Fig. 2A - e por causa da operação do programa de emulação 94 - a aplicação de software 100 pode funcionar no sistema de computador 90 mesmo se a aplicação de software 100 é projetada para funcionar em um sistema operacional que é geralmente incompatível com o sistema operacional hospedeiro e a arquitetura de hardware 92. A Fig. 2B ilustra um sistema de computação virtua-lizado compreendendo uma camada de software do sistema operacional hospedeiro 104 funcionando diretamente acima do hardware de computador físico 102 onde o sistema operacional hospedeiro (OS hospedeiro) 104 provê acesso aos recursos do hardware do computador físico 102 expondo interfaces que são as mesmas que o hardware que o OS hospedeiro está emulando (ou "virtualizando") - o que, por sua vez, possibilita que o OS hospedeiro passe despercebido pelas camadas do sistema operacional executando acima dele. Novamente, para executar a emulação, o sistema operacional hospedeiro 102 pode ser um sistema operacional especialmente projetado com capacidades de emulações nativas ou, alternadamente, ele pode ser um sistema operacional padrão com um componente hipervisor incorporado para executar a emulação (não mostrado).

Com referência novamente à Fig. 2B, acima do OS hospedeiro 104 estão duas implementações de máquina virtual (VM), VM A 108, que pode ser, por exemplo, um processador Intel 386 virtualizado e VM B 110, que pode ser, por exemplo, uma versão virtualizada de um da família de processadores da Motorola 680X0. Acima de cada VM 108 e 110 estão sistemas operacionais hóspedes (OSs hóspedes) A 112 e B 114, respectivamente. Funcionando acima do OS hóspede A 112 estão duas aplicações, aplicação Al 116 e aplicação A2 118, e funcionando acima do OS hóspede B 114 está a aplicação BI 120.

Com relação à Fig. 2B, é importante observar que a VM A 108 e a VM B 110 (que são mostradas em linhas tracejadas) são representações de hardware de computador virtuali-zadas que existem somente como construções de software e que são possíveis devido à execução de software(s) de emulação especializado(s) que não somente apresentam a VM A 108 e a VM B 110 para o OS hóspede A 111 e OS hóspede B 114, respec- tivamente, mas que também executa todas as etapas do software necessárias para o OS hóspede A 112 e o OS hóspede B 114 para interagir indiretamente com o hardware de computador físico real 102. A Fig. 2C ilustra um sistema de computação virtua-lizado alternativo onde a emulação é executada por um monitor de máquina virtual (VMM) 104' funcionando lado a lado com o sistema operacional hospedeiro 104". Para certas modalidades, o VMM pode ser uma aplicação funcionando acima do sistema operacional hospedeiro 104 e interagindo com o hardware de computador somente através do dito sistema operacional hospedeiro 104. Em outras modalidades, e como mostrado na Fig. 2C, o VMM pode, no lugar disso, compreender um sistema de software parcialmente independente que em alguns níveis interage indiretamente com o hardware do computador 102 através do sistema operacional hospedeiro 104, mas em outros níveis o VMM interage diretamente com o hardware de computador 102 (similar à maneira que o sistema operacional hospedeiro interage diretamente com o hardware do computador). E em ainda outras modalidades, o VMM pode compreender um sistema de software totalmente independente que em todos os níveis interage diretamente com o hardware do computador 102 (similar à maneira que o sistema operacional hospedeiro interage diretamente com o hardware do computador) sem utilizar o sistema operacional hospedeiro 104 (embora ainda interagindo com o dito sistema operacional hospedeiro 104 contanto que coordenando o uso do dito hardware de computador 102 e evitando conflitos e semelhantes).

Todas essas variações para implementar a máquina virtual são esperadas formar modalidades alternativas da presente invenção como descrito aqui, e nada aqui deve ser interpretado como limitando a invenção a qualquer modalidade de emulação particular. Além disso, qualquer referência à interação entre as aplicações 116,118 e 120 através da VM A 108 e/ou VM B 110, respectivamente (presumivelmente em um cenário de emulação de hardware) deve ser interpretada para ser na realidade uma interação entre as aplicações 116,118 e 120 e o virtualizador que criou a virtualização. Da mesma forma, qualquer referência à interação entre as aplicações VM A 108 e/ou VM B 110 com o sistema operacional hospedeiro 104 e/ou o hardware do computador 102 (presumivelmente para executar instruções de computador direta ou indiretamente no hardware do computador 102) deve ser interpretada para ser na realidade uma interação entre o virtualizador que criou a virtualização e o sistema operacional hospedeiro 104 e/ou o hardware de computador 102 como apropriado.

Sistemas e Métodos para Virtualizar GPUs e a Canalização Gráfica Como mencionado, a presente invenção provê sistemas e métodos para aplicação de máquinas virtuais no espaço do hardware gráfico por meio do que o código de supervisão funciona na CPU, mas os itens de trabalho gráfico são manipulados diretamente pelo hardware gráfico. A Fig. 3A ilustra uma primeira arquitetura não limitadora que ilustra alguns conceitos gerais. Por exemplo, como ilustrado, existe um monitor de máquina virtual 304 em camadas no topo do hardware gráfico 302 de um dispositivo de computação. Em modo não limitador, essa modalidade trata o OS do hospedeiro similar a um OS do hóspede já que cada um recebe uma máquina virtual. 0 OS do hospedeiro 310 executando a App H1 e a Αρρ H2 é hospedado pela máquina virtual hospedeira 308. 0 OS do hóspede A 330 executando a App Al é hospedado pela máquina virtual A 328. O OS do hóspede B 340 executando a App BI é hospedado pela máquina virtual B 338. Em uma modalidade não limitadora, o código de supervisão é estruturado como um monitor de máquina virtual gráfica. É um objetivo da invenção prover suporte contínuo para o software gráfico antigo nos sistemas operacionais mais novos, e as várias arquiteturas virtualizadas da invenção atingem esse objetivo, As soluções que transportam a funcionalidade antiga para dentro do sistema operacional novo meramente complicam o sistema operacional novo, um resultado a ser evitado de acordo com as arquiteturas da invenção. As soluções providas de acordo com a invenção incluem executar uma versão virtual de um sistema operacional antigo junto com o sistema operacional novo e somente suportar o software gráfico antigo na instância do sistema operacional antigo. Isso ocasiona a noção de máquinas virtuais e monitores de máquina virtual, como descrito na seção acima, e usado em produtos comercialmente disponíveis como Virtual PC e VMware. Entretanto, nessas arquiteturas com base em PC, o software gráfico em uma "partição" do sistema operacional virtual é freqüentemente emulado e funciona muito mais lentamente do que na implementação não virtualizada original.

Assim, de acordo com a invenção, a pilha de software gráfico pode continuar a ter o acesso direto ao hardware gráfico básico enquanto funcionando sob o sistema operacional antigo (isto é, hóspede). Isso é similar ao que é conhecido como um monitor de máquina virtual do Tipo II onde um sistema operacional do hóspede pode funcionar diretamente no processador sem emulação cara pelo monitor da máquina virtual, 0 suporte é requerido no hardware gráfico para permitir que múltiplas partições do sistema operacional executem no hardware gráfico sem conhecimento um do outro e não ciente que o hardware gráfico foi virtualizado. Assim, de acordo com modalidades da invenção, um monitor de máquina virtual gráfico gerencia recursos e controles que a partição está executando no hardware gráfico. Usando a invenção, múltiplos sistemas operacionais do hóspede podem funcionar em paralelo e cada um tem acesso direto de velocidade (quase) total ao hardware gráfico. Alguns hóspedes podem ser sistemas operacionais legados executando software mais antigo, enquanto que outros hóspedes podem fazer outras tarefas específicas. A extensão da invenção leva a modalidades que proveem processamento seguro, onde o processamento seguro pode ser executado nos sistemas operacionais do "hospedeiro" ou do "hóspede". A obtenção disso de acordo com a invenção é um efeito vantajoso da virtualização robusta e segura do hardware gráfico, tal que sistemas operacionais do hóspede não podem interferir um com o outro. Se sistemas operacionais do hóspede não podem interferir um com o outro, então a possi- bílidade de software perigoso operando sem conhecimento do usuário em um sistema operacional de hóspede diferente é e-liminada. 0 sistema trata o monitor da máquina virtual como uma base de confiança ou "núcleo de confiança". Em várias modalidades da invenção, a base de confiança pode ser estendida para um outro sistema operacional de hóspede {ou do hospedeiro) para prover serviços gráficos de confiança adicionais {ao invés de colocar todos os serviços no monitor da máquina virtual ou núcleo). Esses serviços podem incluir o controle sobre o que está visível na exibição, por exemplo, com um gerenciador de janela seguro ou de confiança ou mecanismo de composição da área de trabalho. Isso permite que uma mistura de aplicações funcione em partições do sistema operacional de confiança e não confiável com saída unificada através de um único (ou múltiplos) dispositivo gráfico físico. A base segura pode ser adicionalmente estendida de acordo com a invenção para prover um sistema mais robusto para possibilitar a proteção do conteúdo, por exemplo, para defender direitos digitais anexos a um documento, vídeo, áudio, etc. Um tal sistema alavanca os serviços de confiança operando no monitor da máquina virtual de confiança e partição (ões) de segurança para impor os direitos digitais. Entretanto, a interface do usuário e outras funções nas aplicações de reprodução (gerenciamento da biblioteca de mídia, listas de execução, etc.) podem ser separadas e funcionar em uma partição não confiável se comunicando com os serviços seguros nas partições de confiança. À medida que os consumidores se movem para novos sistemas operacionais e novas versões do sistema operacional, a compatibilidade foi primariamente garantida pela preservação diligente de interfaces de software obsoletas e comportamentos, necessitando de uma penalidade cada vez mais crescente durante os ciclos de desenvolvimento. A complexidade de projeto e da implementação aumenta e o risco de i-nadvertidamente romper um comportamento legado persiste por todo o ciclo de desenvolvimento. Dessa maneira, a invenção propõe uma estratégia de desenvolvimento alternada na qual o comportamento legado pode ser escolhido do novo desenvolvimento, de maneira estratégica e segura, enquanto ainda protegendo os investimentos do consumidor. A compatibilidade da aplicação é mantida usando a tecnologia do monitor de máquina virtual (VMM) para executar a versão do OS original simultaneamente com o novo OS em máquinas virtuais (VMs) separadas. A tecnologia do VMM tradicional de uma máquina hospedeira é estendida às unidades de processamento gráfico (GPUs) para permitir acesso do hardware aos aceleradores gráficos, garantindo que as aplicações legadas operem em desempenho total. A invenção também provê métodos para tornar a experiência do usuário cosmeticamente direta enquanto executando múltiplas aplicações em VMs diferentes. Em outros aspectos da invenção, pela utilização da tecnologia do VMM, a arquitetura gráfica virtualizada da invenção é estendida para prover serviços de confiança e a proteção de conteúdo/controle dos direitos digitais. 0 sucesso do software a longo prazo inevitavelmen- te leva às interfaces de software legado e comportamentos. As exigências contraditórias da nova inovação do software e compatibilidade obtusa levam a ciclos de projeto de software mais complexos e longos. Tentativas para aperfeiçoar a complexidade crescente descartando bits selecionados de legado usam mais recursos para avaliar as decisões, adicionam risco se as decisões erradas são tomadas e invariavelmente proveem alívio marginal, 0 resultado líquido é um ritmo glacial de inovação e entrega em tecnologias de núcleo e a atenção focaliza nas inovações que não perturbam o estado atual.

Um caminho alternativo é aceitar versões mais antigas de software do sistema operacional transportando-o enquanto ao mesmo tempo mantendo-o fora do novo desenvolvimento. A invenção, dessa maneira, usa um monitor de máquina virtual para executar versões de OS prévias simultaneamente com a última versão de OS em máquinas virtuais separadas, enquanto simultaneamente liberando uma experiência de usuário atrativa onde, diretamente ou quase díretamente, as a-plicaçÕes usando as versões mais antigas das interfaces funcionam nos mesmos ambientes para os quais elas foram projetadas e se comportam da mesma maneira.

Antes de esboçar as várias modalidades da invenção, um exemplo é instrutivo. Assim, assuma que para uma segunda versão de um OS, isto é OS_B, é desejável ficar livre de um certo conjunto de APIs gráficas suportadas na primeira versão do OS, isto é OS_A. Entretanto, o objetivo é executar o 0S_B e o 0S_A simultaneamente, isto é, aplicações usando as interfaces gráficas do OS_A funcionam na "visualização" virtual do 0S_A enquanto novas aplicações funcionam na visualização do OS_B, ambas com experiências de usuário igualmente "boas". A definição do que constitui uma experiência de usuário boa ê um pouco nebulosa, mas algumas regras básicas variavelmente podem incluir (A) entrada direta do usuário (teclado, mouse, etc.} e saída da aplicação (exibição, impressão, multimídia, etc.) quando usando a visualização do OS, (B) pouca ou nenhuma diferença de desempenho perceptível . Uma medida que pode ser aplicada é que o desempenho de qualquer aplicação de OS_A funcionando na visualização do OS_A deve ficar dentro de 5% da mesma aplicação funcionando em uma primeira versão nativa do OS sem um monitor virtual e (C) a visualização virtual do OS_A deve usar software inalterado que é usado para a primeira versão do OS. Isso ê desejável, desde que uma vez que a porta abre para permitir mudanças nos sistemas operacionais do hóspede, os riscos de romper a compatibilidade ressurge através da ("fan-out") descrita nos antecedentes. Uma maneira para relaxar essa e-xigência é permitindo que aplicações auxiliares adicionais funcionem sob o OS do hóspede inalterado para facilitar a operação direta.

Um das preocupações em prover mínima degradação de desempenho na experiência do usuário é prover aceleração de hardware dos serviços de renderização gráfica. Para uma API como a interface do dispositivo gráfico (GDI), pode ser prático emular toda a pilha no software, mas para APIs mais novas que dependem da aceleração do hardware, a degradação do desempenho pode ser inaceitável. Uma possibilidade é redire- cionar as solicitações de processamento gráfico do OS do hóspede para o OS do hospedeiro, por exemplo, usando emulação do software/captura das interfaces de hardware de nível inferior de um dispositivo de hardware gráfico bem conhecido.

Embora esse caminho tradicional seja bem sucedido para dispositivos com um alto nível de abstração (muito trabalho por solicitação) ou dispositivos simples (por exemplo, portas seriais), ele não é prático para hardware gráfico moderno. A captura de solicitações nesse nível é geralmente muito ineficiente (o hardware gráfico é projetado para receber mais do que lGB/s de dados de entrada) e o hardware gráfico moderno é geralmente muito complicado para emular fielmente nesse nível de detalhes (lembre-se que um dispositivo gráfico moderno tem -200 milhões de transistores). Antes, esse caminho pode ter sido prático para um dispositivo com menos do que 10 milhões de transistores e para aplicações menos intensivas graficamente, mas mesmo sob essas circunstâncias, o grau de desempenho necessário não seria conseguido.

Uma outra escolha é interceptar o fluxo do protocolo gráfico em um ponto superior (independente do dispositivo) no fluxo e redirecionar esse para o OS do hospedeiro. Embora isso elimine o problema emulando um dispositivo complexo, sérias preocupações de desempenho podem resultar se fluxos de protocolos de largura de banda elevada são implicados. Um outro problema que podería resultar pertence ao cenário onde os fluxos de protocolo não são acessíveis ã in- tercepção sem mudanças significativas no OS do hóspede. Um caminho podería ser substituir as bibliotecas da ligação dinâmica (DLLs) do sistema contendo APIs gráficas com comentários ("stubs") de protocolo para redirecionar para o OS do hóspede, embora existam ainda preocupações significativas com esse caminho quando os métodos para controlar o estado nas APIs originais não foram projetados com esse caminho em mente. Embora qualquer API que foi projetada para ser remotamente executada ("remota") provavelmente tenha comportamento razoável que pode ser usado para atingir isso, nem todo gráfico e APIs de mídia foram projetados com essa solução em mente. Novamente, esse caminho exige modificação (substituição) de componentes ao nível do sistema e assim introduz os riscos de compatibilidade. 0 caminho das várias modalidades da invenção é empurrar o problema para o hardware e continuar a permitir que o OS do hóspede tenha acesso de hardware direto similar às técnicas de VMM usadas para a CPU. Existem várias vantagens para essa técnica quando eficientemente implementada. A primeira é eliminar a necessidade de fazer mudanças no OS do hóspede. A segunda provê oa mesmos níveis de desempenho ou altamente similares como se o OS do hóspede estivesse funcionando nativamente no hardware. Também deve ser observado que o esquema permite que OSs legados suportem hardware gráfico mais novo contanto que os fornecedores de hardware gráfico continuem a despachar suporte de acionador para o novo hardware nos OSs legados. Assim, as várias arquiteturas vir-tualizadas da invenção, hardware gráfico é construído que pode ser virtualizado, o OS do hospedeiro & VMM são estruturados para explorar eficientemente o hardware, e a apresentação (exibição) é virtualízada tal que ela pode ser integrada em uma área de trabalho composta. A invenção assim permite que cada acesso da VM aos recursos de renderização gráfica, crie um ambiente de VMM na GPU, para virtualização de extremidade a extremidade da canalização. Em particular, isso inclui a idéia de virtualizar eficientemente a GPU para muitos clientes gráficos. Em várias modalidades, as arquiteturas de virtualização da invenção se conformam com uma ou mais das exigências seguintes: um estado de execução claramente definido (contexto), suporte de mudança de contexto com pequena latência, espaços de endereço virtual protegidos, controle de memória paginada em demanda e modos de execução privilegiados. Essas exigências são usadas para prover compartilhamento eficiente, seguro e robusto dos recursos de hardware da GPU entre múltiplos clientes (aplicações).

Para simplificar a discussão de virtualização, ê útil resumir o grau de suporte de virtualização que é considerado de acordo com a invenção. A analogia mais simples é que aproximadamente o mesmo nível de compartilhamento de GPU deve ser encontrado que é encontrado em uma CPU moderna para compartilhar a CPU entre múltiplos clientes (aplicações). Essa é uma conseqüência natural da evolução da GPU - ela é um recurso computacional poderoso que deve ser eficientemente compartilhado entre múltiplos clientes independentes. Uma diferença da CPU é que a GPU é controlada pelo código execu- tãvel funcionando na CPU ao invés de na GPU. Em alguns modelos de acionador, em contraste, o subsistema gráfico do núcleo age como um mini-executivo provendo serviços de programação e de controle de memória e controle sobre recursos globais tais como configuração da exibição de vídeo, controle de energia, etc. Esse mini-executivo opera independentemente do executivo do núcleo, tomando suas próprias decisões de programação e de controle de memória com algoritmos e estratégias sintonizadas com as exigências dos clientes da GPU, Depois que as exigências de virtualização foram satisfeitas, torna-se possível permitir que o acionador de um cliente acesse diretamente o hardware da GPU. As regras são similares a essas para virtualização de outras funções do núcleo, isto é, o acionador hospedado não deve ser capaz de detectar que ele está executando em um VMM e ele não deve ser capaz de enganar qualquer um dos mecanismos de proteção colocados no local pelo VMM. Para finalidades dessa discussão, é assumido que o VMM da GPU está embutido no VMM do núcleo e para todas as finalidades práticas opera como um a-cionador no VMM do núcleo. 0 VMM gráfico pode incluir uma porção independente do dispositivo e uma porção dependente do dispositivo (a última provida pelo fabricante do hardware gráfico}. A Fig, 3B ilustra uma outra arquitetura não limitadora exemplar provida para virtualizar a canalização gráfica de acordo com a invenção. Um monitor de máquina virtual 304 inclui um componente de VMM gráfico que manipula a fun- cionalidade gráfica e o controle de acordo com a invenção. Qualquer um de um OS do hospedeiro com acionador gráfico hospedeiro HGF, OS do hóspede A com acionador gráfico AGD e OS do hóspede B com acionador gráfico BGD pode interagir com o VMM gráfico através do VMM 304.

Desde que uma das motivações para usar um VMM é a eficiência, faz sentido implementar diretamente um VMM gráfico do tipo II com suporte de hardware. Prover um modelo de acionador de exibição (DDM) avançado adiciona suporte de hardware para espaços de endereço virtual de acesso controlado, preempção e operações privilegiadas. Um teste de tor-nassol para suporte de VMM eficiente é executar um acionador DDM avançado existente no topo do VMM gráfico sem mudanças no acionador. Isso significa que as operações do núcleo do subsistema gráfico que inicializam a placa, configuram tabelas de página, programam controladores de exibição, configuram a abertura da PCI, manipulam entradas interpretadas como endereços físicos, etc. devem gerar armadilhas para o VMM para a interpretação eficiente. As interrupções devem ser interceptáveis pelo VMM e enviadas para o acionador apropriado (hóspede). Operações não privilegiadas de alta frequência, tal como operações de renderização, devem ser executáveis pelo hardware gráfico sem intervenção pelo VMM. 0 hardware do modelo do acionador avançado suporta múltiplos contextos de execução, cada um com um espaço de endereço virtual separado e fila de entrada (armazenamento temporário em anel) para controlar armazenamentos temporários de DMA que chegam de fluxos de comando. Recursos de me- mória física local e de sistema são mapeados para o espaço de endereço virtual de um contexto inicíalizando entradas de tabela de página para apontar para os endereços físicos. A conclusão das operações do fluxo de comando é sinalizada u-sando escritas de memória (réplicas) e interrupções.

Um método para controlar a proteção da memória é dividir o espaço do endereço físico da memória gráfica local e alocar uma partição contígua fixa em cada máquina virtual (OS do hóspede). A memória fora da alocação não fica visível para a máquina virtual. Esse mecanismo podería ser implementado usando um nível simples de desorientação através de re-gistradores de base e de limite programados pelo VMM gráfico. Isso pode exigir o controle dos conteúdos dos registra-dores de configuração do barramento PCI visíveis para o a-cionador (leituras capturadas pelo VMM). Nesse esquema de controle de memória, cada hóspede vê uma alocação de memória fixa para o tempo de duração do hóspede. Isso elimina a necessidade do VMM capturar operações de tabela de página (que podem ser freqüentes) desde que a janela do espaço de endereço físico visível para o hardware é cuidadosamente controlada pelo VMM. Esse á um primeiro caminho razoável para implementar o suporte de memória virtualizada desde que ele deixa o VMM fora do controle de memória detalhado enquanto provendo discutivelmente a utilização menos eficiente dos recursos de memória. É concebível um prazo mais longo para ter o VMM mais envolvido nas operações de controle de memória detalhadas. Essa parte torna-se mais complicada desde que as opera- ções usadas pelo acionador para programar as entradas da tabela de página são para serem capturadas pelo VMM. Dependendo dos objetivos de desempenho para paginação, o projeto do hardware pode precisar ser mais cuidadosamente projetado para melhorar a eficiência da detecção e emulação dessas operações. Por exemplo, pode ser benéfico projetar a operação de mapeamento da página (comandos) , de modo que múltiplos mapeamentos podem ser especificados como um grupo e eles podem ser facilmente reconhecidos e decodificados como um grupo no VMM gráfico. Isso minimiza o número de armadilhas a-través do VMM. Também, o VMM pode usar serviços (de confiança) em uma partição do hóspede para suportar as operações de paginação para memória auxiliar (um outro nível de memória auxiliar além do que um acionador DDM do hóspede implementa) . Embora esse esquema seja mais complicado, ele permite que cada hóspede faça uso de todos os recursos de memória do hardware. 0 caminho descrito com relação a essas modalidades da invenção implica no uso de tabelas de página com software virtualizado. Um caminho alternativo âs tabelas de página com software virtualizado é adicionar um outro conjunto de tabelas de página privilegiadas, isto é, um outro nível de desorientação, no hardware gráfico para uso diretamente pelo VMM. Essa é uma generalização do caminho do registrador de base e de limite descrito para partições fixas, permitindo que o VMM controle a visualização do hardware gráfico do(s) recurso(s) físico(s) na granularidade ao nível da página. A discussão de controle de memória, até o momento, focalizou no controle do mapeamento da memória gráfica local para os contextos gráficos. Existem exigências similares no mapeamento das páginas de memória do sistema para o hardware, desde que essas também usam endereços de memória fixa. A maneira pela qual o VMM processador controla a memória física aparece. Geralmente, dispositivos que usam endereços físicos são cuidadosamente controlados para manter o controle total sobre os seus mapeamentos. Um esquema simples de partição fixa proposto para memória de vídeo podería ser estendido para funcionar para memória de sistema novamente pela adição de controles de hardware gráfico para limitar a janela da memória do sistema disponível. Entretanto, ele é ina-plícãvel se o VMMM processador aloca memória física não contígua quando prestando serviço para as operações de alocação para hóspedes. Isso significa que o esquema mais complicado para o controle de memória detalhado deve ser implementado para recursos de memória do sistema (isso sugere fazer a solução de memória gráfica local ao mesmo tempo). Existem provavelmente algumas suposições adicionais feita pelo VMM processador com relação ao controle da memória física e interações potenciais com o VMM gráfico que precisam ser cuidadosamente examinadas.

Para permitir que as interrupções sejam processadas mais eficientemente, tipos de interrupção poderíam ser divididos nesses que precisam ser processados pelo VMM e esses que não precisam. A última categoria podería incluir conclusões de comando, etc. e esses podem ser processados diretamente pelo acíonador do hóspede. A outra categoria principal de controle é a programação dos recursos de processamento. 0 modelo de aciona-dor avançado suporta preempção de contextos, então o modelo de controle mais simples tem o VMM alocando espaços de tempo em partições, apropriando-se antecipadamente do contexto gráfico em execução atual da partição em execução atual. 0 modelo do acionador avançado atual usa uma lista de execução em armazenamento temporário duplo quando especificando uma nova lista de contextos a executar. Existe a suposição que não existirá mais do que uma lista de execução pendente. 0 modelo de planejamento virtualizado exigirá algumas modificações para tornar mais fácil para o VMM alternar partições nos limites de lista de execução e para garantir ainda que quando uma transição é feita para uma nova partição que o estado do contexto é salvo na partição antiga e restaurado da nova partição (por exemplo, os recursos de memória da partição apropriada são mapeados nos tempos certos durante o salvamento e restauração do contexto). Movamente, existirão suposições e interações com o controlador do VMM processador que devem ser consideradas.

Um esquema de planejamento mais elaborado pode ser implementado onde o VMM gráfico é mais ciente da carga de trabalho e prioridades de contextos diferentes. Essa informação pode ficar disponível para o VMM processador para tomar decisões de planejamento mais inteligentes. Existem algumas preocupações de projeto interessantes quanto a se o VMM gráfico pode estar executando um contexto de uma partição diferente do que o VMM processador está executando. É possível e pode ser necessário permitir alguma sobreposição no processamento durante transições entre partições para maximizar a utilização do hardware. Entretanto, isso exige consideração mais cuidadosa de como os recursos são controlados e mapeados durante as transições.

Com relação à virtualização da apresentação e interação, em uma primeira modalidade, depois que o hardware gráfico é virtualizado, então cada hóspede cria sua própria área de trabalho e renderiza as janelas das aplicações do hóspede para essa área de trabalho. Essa área de trabalho do hóspede é armazenada na memória gráfica local e sob um ambiente normal é varrida para fora para o dispositivo de exibição (CRT ou painel plano). No ambiente virtualizado, os conteúdos de múltiplas áreas de trabalho do hóspede são coletados e exibidos em uma única exibição. Existem vários caminhos para criar essa exibição incluindo a provisão de múltiplas áreas de trabalho virtuais (área de trabalho única de cada vez), a provisão de uma área de trabalho na sua própria janela ou uma única área de trabalho unificada.

Na primeira modalidade, uma única área de trabalho do hóspede é escolhida como a área de trabalho "atual" e é exibida. Usando algum controle de UI, o usuário pode selecionar entre hóspedes diferentes, porém somente um é exibido de cada vez. Esse caminho ê o mais simples desde que as imagens da área de trabalho do hóspede individuais podem simplesmente ser exibidas. Na realidade, o controle da UI determina qual hóspede pode ajustar os registradores da saída de varredura do controlador de exibição. A Fíg. 4A ilustra a modalidade exibindo uma "única área de trabalho de cada vez". Uma pessoa pode ver que cada máquina virtual recebe seu próprio espaço da área de trabalho na memória gráfica local onde cada espaço é independente dos outros, por meio do que somente a área de trabalho 'ativa' selecionada pelo usuário é varrida para fora para exibição. Os hóspedes são assim capazes de converter em mapa de bits os seus itens de trabalho respectivos e deixá-los na memória em algum lugar e um mecanismo de apresentação é capaz de controlar qual memória (contendo os bits convertidos em mapa de bits) é exibida, o que implicaria em processamento de rasterização adicional para redimensionar ou mover os conteúdos.

Por definição, essa primeira modalidade não permite que múltiplas áreas de trabalhos fiquem visíveis simultaneamente (embora em uma configuração ("multimon"), diferentes controladores de exibição poderíam exibir áreas de trabalho de hóspedes diferentes ao invés de todas do mesmo hóspede) . Um caminho alternado é a segunda modalidade na qual áreas de trabalho individuais são exibidas em janelas de contêiner separadas na área de trabalho do hospedeiro. Isso usa um serviço a ser executado no hospedeiro que tem acesso aos conteúdos de cada área de trabalho do hóspede. 0 serviço executa uma operação de composição para construir a área de trabalho do hospedeiro usando as áreas de trabalho do hóspede como entrada. Uma janela substituta é usada para cada á-rea de trabalho do hóspede, controlando o tamanho e localização da área de trabalho. Os conteúdos de uma área de tra- balho do hóspede podem ser extraídos diretamente dos conteúdos de memória de vídeo interceptando as mudanças nos ajustes do controlador de exibição para essa área de trabalho (usando-as para determinar o endereço da memória, dimensões e outros parâmetros) . A área de trabalho do hospedeiro composta é construída da mesma maneira como uma área de trabalho típica é construída usando o mecanismo de composição de área de trabalho (DCE) - também usando aceleração gráfica do hardware. Essa segunda modalidade pode ser combinada com a primeira para suportar um modo com uma única visualização direta de uma área de trabalho do hóspede ou um modo como uma visualização composta de múltiplas áreas de trabalho em janelas separadas. A Fig. 4B ilustra uma modalidade alternativa de "área de trabalho em uma janela", por meio da qual todas as áreas de trabalho podem ser simultaneamente exibidas por um mecanismo de apresentação considerando a oclusão. Por exemplo, uma área de trabalho do hospedeiro podería por definição ser a janela da área de trabalho de fundo na exibição, e as áreas de trabalho do hóspede, cada uma exibida dentro da sua própria janela de contêíner, recebem uma janela separada na exibição no topo da janela da área de trabalho de fundo.

Essa segunda modalidade começa a introduzir algumas complicações com a coordenação da entrada quando sincronizando a posição e o tamanho das janelas da área de trabalho do hóspede. Quando as janelas são manipuladas na janela do contêíner do hospedeiro para a área de trabalho do hóspede, essas interações são capturadas e enviadas para o hóspe- de para processamento. 0 hóspede, por exemplo, seu gerenciador de janela, atualiza a área de trabalho do hóspede e as novas posições da janela são refletidas na área de trabalho do hospedeiro quando ele é reconstruído. Esse tipo de coordenação de entrada já foi tratado em outros produtos de vir-tualização que implementam a "área de trabalho em uma janela" e não deve ser afetado pela virtualização do hardware gráfico. A segunda modalidade é uma melhora significativa, mas ainda seria desejável misturar as janelas de múltiplas áreas de trabalho do hóspede, isto é, ocultar o fato que e-xistem áreas de trabalho do hóspede. Esse problema corresponde com a localização dos conteúdos de janela individuais em cada área de trabalho do hóspede, mas é mais difícil do que localizar os conteúdos da área de trabalho desde que a informação da janela individual não é facilmente interceptada do fluxo de dados enviado para o hardware gráfico. Entretanto, se a regra com relação à modificação do sistema operacional do hóspede é propositadamente violada, é possível adicionar algumas armadilhas para auxiliar na identificação dos pixels (localizações de memória) para janelas individuais. Existem alguns caminhos diferentes que podem ser adotados aqui.

Um caminho é manter as janelas na área de trabalho do hóspede preenchidas lado a lado (sem sobreposição), de modo que todos conteúdos ficam sempre disponíveis enquanto mantendo a informação sobre o tamanho e a localização de cada janela na área de trabalho do hóspede para uso pelo ge- renciador da janela do hospedeiro/mecanismo de composição. Esse caminho envolve manter dois conjuntos separados de informação de janela: a informação virtual (na área de trabalho do hospedeiro) e a localização física na área de trabalho do hóspede. Ele também complica a coordenação da entrada desde que as operações que manipulam a janela virtual podem ou não afetar a janela física (por exemplo, se a janela virtual está oclusa, pode ser benéfico recuperar a situação real na área de trabalho do hóspede). Interações dentro da janela virtual são traduzidas para interações apropriadas para a janela física (isso podería ser tão simples quanto um desvio para as coordenadas da entrada).

Um caminho alternado e redirecionar as janelas da área de trabalho do hóspede para a memória que é mais facilmente controlada. Isso é análogo ao redirecionamento feito para a interface do dispositivo gráfico (GDI) onde um "armazenamento temporário auxiliar" separado é mantido para cada janela. Os conteúdos desses armazenamentos temporários auxiliares ficam disponíveis para o gerenciador da janela do hospedeiro/mecanismo de composição. Um mapeamento similar entre coordenadas de entrada virtual e coordenadas de entrada física é então executado quando o usuário interage com os conteúdos de uma janela virtual.

Com alguma previsão e planejamento, é possível formar sistemas operacionais futuros para facilitar mais tais intercepções quando esses sistemas operacionais são e-xecutados como hóspedes. A disposição da interface em cada área de trabalho do hóspede (se e quando elas cessam de e- xistir da perspectiva do usuário), manipulação da extensão da interface, opções do menu iniciar, atalhos de aplicação, área de transferência, etc. foi intercalada em uma visualização de área de trabalho unificada. Esses são problemas que podem ser resolvidos, mas envolvem o entendimento de mais detalhes sobre as implementações correspondentes em cada um dos hóspedes e provavelmente (estaticamente) a extração e intercalação dessa informação para produzir uma visualização unificada. Perguntas similares surgem para suportar a acessibilidade unificada.

Preocupações similares podem existir no fornecimento de uma visualização direta de outras partes de um sistema de múltiplos hóspedes, por exemplo, armazenamento, a-plicações instaladas, colocação em rede, etc. Uma estratégia provisória de exposição de múltiplos hóspedes como áreas de trabalho em janela com impressões digitais independentes permitiría focalizar na tarefa de construção de uma infra-estrutura de virtualização robusta. Em paralelo, é possível tratar alguns aspectos adicionais tais como processamento de confiança e proteção de conteúdo para controle dos direitos digitais.

Como a base para o processamento gráfico seguro (de confiança), os sistemas gráficos virtualizados acima descritos são compatíveis com outros modelos para processamento seguro usando máquinas virtuais. As características do ambiente gráfico virtualizado facilmente permitem que uma mistura de processamento confiável e não confiável ocorra no mesmo sistema em um modo confiável em desempenho total. Um tal modelo exige que o VMM gráfico autentique e carregue de modo robusto o dispositivo gráfico. Naturalmente, ele conta com outros componentes de confiança para carregar com segurança o VMM gráfico. Desde que o ambiente de virtualização protege de maneira robusta múltiplos hóspedes e a partição do hospedeiro um do outro, ê possível construir uma partição de confiança que pode fazer processamento gráfico de confiança. Se o gerenciador da janela e o mecanismo de composição funcionam como serviços em uma partição de confiança, então eles podem misturar os dados de aplicação confiáveis e não confiáveis em um modo confiável usando os métodos de apresentação descritos previamente. A Fig. 4C ilustra uma arquitetura exemplar para mistura de dados de aplicação confiáveis e não confiáveis de acordo com a invenção. Como descrito, similar ao OS do hospedeiro com acionador gráfico HGD, um OS T de confiança é provido como uma partição de confiança com acionador gráfico TGD. 0 OS T de confiança inclui um gerenciador de janela, ou compositor de janela, componente que pega a entrada do código do VMM gráfico com relação a quaisquer restrições no armazenamento e renderização dos dados de confiança contra os dados não confiáveis, antes de renderizar pela canalização gráfica. 0 serviço de confiança realmente exige acesso aos dados de exibição na área de trabalho do hóspede separados, mas essa informação não é interpretada como dados de controle pelo serviço de composição. Ela é usada como entrada ren-derizada, então não existe risco de ataque dos conteúdos dos dados compartilhados. Se o hardware gráfico é virtualizado corretamente, não existe risco do código em uma partição a-tacando um outro. Acionadores do hóspede não podem tomar o controle do hardware nem interferir com outros hóspedes. O código de aplicação funcionando dentro do hardware gráfico não pode interferir com outras aplicações na mesma partição de hóspede, muito menos com outras partições do hóspede. 0 suporte de virtualização da invenção não elimina as necessidades de autenticação do hardware, controle robusto sobre as saídas da exibição ou outras exigências para garantir que uma única partição de confiança possa entregar com segurança os dados de exibição para o dispositivo de e-xibição, mas ele permite que múltiplas partições compartilhem robustamente o hardware gráfico com pouco impacto no desempenho.

Com relação à base para a proteção de conteúdo durante o processamento e exibição de acordo com a invenção, a execução dos direitos digitais para os dados de vídeos de movimento completo é atualmente realizada usando uma "trajetória de vídeo protegida" para proteger o conteúdo. A trajetória de vídeo protegida integra vários dos métodos seguintes para prover transporte seguro e processamento de dados de vídeo de um dispositivo de fonte para o dispositivo de exibição: (1) 0 ambiente do núcleo é acostumado a desativar depuradores de núcleo, etc., e somente componentes de confiança podem operar no modo do núcleo ("anel 0") enquanto o conteúdo protegido está sendo reproduzido; (2) Processos no modo do usuário manipulando conteúdo protegido são adicionalmente acostumados de ataque externo (ambiente protegido). Os dados de vídeo arranjados no (ou exibidos do) sistema ou memória gráfica não podem ser acessados de outros processos; (3) Os dados de vídeo enviados através de barra-mentos acessíveis pelo usuário são criptografados; (4) 0 acionador gráfico deve ser certificado para reproduzir conteúdo protegido e ele, por sua vez, valida que o hardware gráfico é uma sincronização válida para o conteúdo protegido e (5) A proteção da saída de exibição é suportada pelo hardware gráfico (Macrovision, CGSM-A, HDCP) e pode ser robustamente manipulada pelo subsistema de reprodução de mídia, Os mecanismos (1) e (2) podem ser substituídos por uma base de computação segura mais geral de acordo com a invenção. Essa base de computação segura deve também impedir a fraude através da tecnologia de virtualização tornando impossível subverter um processo de carregamento seguro. Os mecanismos (3) a (5) são ainda exigidos para continuar a prover o processamento seguro e o transporte dos dados de vídeo à medida que eles se movem da memória do sistema através do hardware gráfico e para a exibição. Os métodos de virtualização do hardware gráfico da invenção não substituem qualquer um dos métodos de proteção de conteúdo relacionados com a trajetória gráfica específica; ao invés disso, eles servem como uma base para a construção de serviços gráficos de confiança. Esses serviços de confiança podem ser expandidos para incluir os componentes de processamento dos meios protegidos (porta de interoperabilidade de mídia, ou MIG para abreviar), e executando-os na partição de confiança "segura" ao invés de em uma partição de hóspede hostil. A infra-estrutura de vídeo protegida existente já separou o processamento protegido (negociação dos direitos, estratégia de ação, decodificação, decriptografia) do processamento desprotegido (GUI da aplicação de reprodução, etc.). Essa separação permanece intacta no ambiente virtualizado, com os componentes protegidos executando em uma partição de confiança (um ambiente [melhor] protegido diferente) e os componentes desprotegidos permanecem em uma partição de hóspede não confiável. A Fig. 4D, assim, ilustra a extensão da noção da partição de confiança T desenvolvida com relação à Fig. 4C para incluir uma porta de interoperabilidade de mídia MIG, como uma camada separada de proteção para o conteúdo sendo renderizado por uma aplicação executora de mídia funcionando no OS do hóspede A.

Da mesma maneira que o produto Virtual PC pode e-xecutar um grande número de OSs, o ambiente gráfico virtualizado da invenção é capaz de suportar os acionado-res/modelos de acionador para um número pré-definido de sistemas operacionais ou versões. 0 sucesso de cada sistema operacional é medido pela amplitude das aplicações que ele pode executar e a eficiência dessas aplicações. Evitando implacavelmente o desejo de modificar os sistemas operacionais do hóspede, deve ser possível executar qualquer aplicação sob o sistema operacional virtualizado que funciona sob o sistema operacional executando nativamente. Locais onde podem existir diferenças situam-se em como os recursos são divididos. Por exemplo, se somente um subconjunto dos recursos (parte da memória gráfica local) fica disponível para uma partição, então a aplicação não pode operar também. Nos sistemas operacionais futuros, isso pode ser menos preocupante como a virtualização de "primeira ordem" - a virtualização dos recursos para compartilhamento entre múltiplas aplicações se torna a norma. A inspiração para a progressão em direção ao hardware gráfico totalmente virtualizado é para que companhias de software fiquem liberadas das preocupações do código legado enquanto ainda provendo uma trajetória prática para compatibilidade de aplicação contínua. Como um efeito secundário, a invenção também provê um ambiente excelente para processamento gráfico de confiança e proteção de conteúdo.

Essa segunda medida de sucesso significa que as aplicações em progressão devem parar de usar o código legado e progredir também. Para grandes bases de código de aplicação, isso pode ser excessivamente difícil. Por exemplo, pode não ser possível deixar o software GDI para trás como código legado se, por exemplo, uma base de código de aplicação legado que evolui com versões de OS, tal como a base de código do Office da Microsoft, é inextricavelmente dependente dele. Em tais casos, poderíam existir talvez modelos híbridos que podem ser explorados. Por exemplo, os sistemas operacionais do hóspede podem ser vistos como provedores de serviço geral. Novamente usando a GDI como um exemplo, um sistema operacional legado poderia ser imaginado como provendo um serviço de renderização de GDI. A aplicação usa um mecanismo semelhante ao remoto que usa o serviço. 0 objetivo em um tal caso não é necessariamente executar a aplicação sem quaisquer mudanças de código, mas ao contrário fazer um mínimo de mudanças que possibilitariam que a aplicação continuasse a usar o código da GDI legado como um serviço compatível com várias partições enquanto adquirindo tempo para sair completamente para fora da API. A Fig. 4E ilustra a interação exemplar onde uma aplicação legada de OS do hóspede A funcionando no OS do hospedeiro H interage com um componente de serviços legados do OS do hóspede A para, entretanto, emular o comportamento legado da perspectiva do OS do hospedeiro H. A Fig. 5 ilustra uma sequência exemplar na qual uma aplicação funcionando em um OS do hóspede, de acordo com qualquer uma das arquiteturas virtualizadas mostradas ou descritas aqui, emite um comando implicando em recursos de subsistema gráfico. Em 500, uma aplicação funcionando em um OS de hóspede produz como saída um item de trabalho gráfico (por exemplo, desenhar o círculo azul na tela na coordenada "x,y"). Em 510, o OS do hóspede manipula a solicitação, enviando-a para a fila de trabalho gráfico e controlador associado. Em 520, quando o item de trabalho gráfico está pronto (programado), um ponteiro para os dados do item do trabalho gráfico é passado para o hardware pelos acionadores gráfi- cos. Era 530, se o item de trabalho gráfico é uma operação privilegiada, então o VMM gráfico recebe e manipula a solicitação do trabalho com base nas estratégias (OS do hóspede contra OS do hospedeiro, estratégias de memória, tipo de comando, etc.). Se o item de trabalho gráfico não é privilegiado, então no lugar em 540, o hardware gráfico prossegue para manipular a solicitação diretamente. A invenção assim virtualiza o hardware do processador para o acelerador gráfico com a intenção de prover os benefícios de renderização em alto desempenho para múltiplos sistemas operacionais do hóspede funcionando em um ambiente virtualizado. Um tal ambiente pode ser usado para eficientemente resolver vários problemas: (A) eliminar código legado no desenvolvimento de sistema operacional novo enquanto mantendo a compatibilidade da aplicação executando a aplicação legada no sistema operacional legado em um ambiente de máquina virtual; (B) prover infra-estrutura misturando seguramente o processamento confiável e não confiável no mesmo ambiente virtualizado e (C) alavancando o ambiente de confiança para prover proteção de conteúdo para controle dos direitos digitais.

Ambientes Exemplares de Rede e Distribuídos Alguém de conhecimento comum na técnica pode verificar que a invenção pode ser implementada em conjunto com qualquer computador ou outro dispositivo cliente ou servidor, que pode ser disposto como parte de uma rede de computador, ou em um ambiente de computação distribuído. Sob esse aspecto, a presente invenção diz respeito a qualquer sistema ou ambiente de computador tendo qualquer número de unidades de memória ou armazenamento, e qualquer número de aplicações e processos ocorrendo através de qualquer número de unidades de armazenamento ou volumes, que podem ser usados em conjunto com a virtualização da canalização gráfica de acordo com a presente invenção. A presente invenção pode ser aplicada a um ambiente com computadores servidores e computadores clientes dispostos em um ambiente de rede ou ambiente de computação distribuído, tendo armazenamento remoto ou local. A presente invenção pode também ser aplicada em dispositivos de computação independentes, tendo funcionalidade de linguagem de programação, capacidades de interpretação e execução para geração, recepção e transmissão de informação em conjunto com serviços remotos ou locais. Em um ambiente de jogos, uma canalização gráfica é particularmente relevante para esses dispositivos de computação operando em um ambiente de computação de rede ou distribuído, e assim a virtualiza-ção da canalização gráfica de acordo com a presente invenção pode ser aplicada com grande eficácia nesses ambientes. A computação distribuída provê o compartilhamento de recursos de computador e serviços pela troca entre dispositivos e sistemas de computação. Esses recursos e serviços incluem a troca de informação, armazenamento em cache e armazenamento em disco para arquivos. A computação distribuída tira vantagem da conectividade de rede, permitindo que clientes alavanquem sua energia coletiva para se beneficiarem de todo o empreendimento. Sob esse aspecto, uma variedade de dispositivos pode ter aplicações, objetos ou recursos que podem envolver os processos gráficos da invenção. A Fig. 6A provê um diagrama esquemãtico de um ambiente de computação exemplar em rede ou distribuído. 0 ambiente de computação distribuído compreende objetos de computação 10a,10b, etc. e objetos de computação ou dispositivos 610a,610b,610c, etc. Esses objetos podem compreender programas, métodos, memórias de dados, lógica programável, etc. Os objetos podem compreender porções do mesmo ou diferentes dispositivos tais como PDAs, dispositivos de ãu-dio/vídeo, tocadores de MP3, computadores pessoais, etc. Cada objeto pode se comunicar com um outro objeto por meio da rede de comunicações 14. Essa rede pode, ela própria, compreender outros objetos de computação e dispositivos de computação que proveem serviços para o sistema da Fig. 6A, e pode, ela própria, representar múltiplas redes interligadas. De acordo com um aspecto da invenção, cada objeto 10a,10b, etc. ou 610a,610b,610c, etc. pode conter uma aplicação que poderia fazer uso de uma API, ou outro objeto, software, programação em hardware e/ou hardware, para solicitar o uso dos processos de virtualização gráficos da invenção.

Também pode ser verificado que um objeto, tal como 610c, pode estar hospedado em um outro dispositivo de computação 10a,10b, etc. ou 610a,610b, etc. Assim, embora o ambiente físico representado possa mostrar os dispositivos conectados como computadores, tal ilustração é meramente exemplar e o ambiente físico pode ser alternativamente representado ou descrito compreendendo vários dispositivos digitais tais como PDAs, televisões, tocadores de MP3, etc., objetos de software tais como interfaces, objetos COM e semelhantes.

Existe uma variedade de sistemas, componentes e configurações de rede que suportam ambientes de computação distribuídos. Por exemplo, sistemas de computação podem ser conectados por sistemas ligados por fiação ou sem fio, por redes locais ou redes amplamente distribuídas. Atualmente, muitas das redes são acopladas na Internet, que provê uma infra-estrutura para computação amplamente distribuída e a-brange muitas redes diferentes. Qualquer uma das infra-estruturas pode ser usada para comunicações exemplares tornadas incidentes aos processos de virtualização do hardware gráfico da presente invenção.

Nos ambientes de rede residencial, existem pelo menos quatro meios de transporte de rede diferentes que podem suportar, cada um, um protocolo único, tal como Power line, dados (tanto sem fio quanto ligados por fiação), voz (por exemplo, telefone) e meios de entretenimento. A maior parte dos dispositivos de controle residenciais tais como interruptores de luz e eletrodomésticos pode usar linhas de energia para conectividade. Serviços de dados podem entrar na casa como banda larga (por exemplo, ou DSL ou modem a cabo) e ficam acessíveis dentro da casa usando conectividade sem fio (por exemplo, HomeRF ou 802.11B) ou ligada por fiação (por exemplo, Home PNA, Cat 5, Ethernet, até mesmo linha de força). O tráfico de voz pode entrar na casa como ligada por fiação (por exemplo, Cat 3) ou sem fio (por exemplo, telefones celulares) e pode ser distribuído .dentro da casa u-sando fiação Cat 3. Meios de entretenimento, ou outros dados gráficos, podem entrar na casa através de satélite ou cabo e são tipicamente distribuídos na casa usando cabo coaxial. IEEE 1394 e DVI são também interligações digitais para grupos de dispositivos de meios. Todos esses ambientes de rede e outros que podem surgir como padrões de protocolo podem ser interligados para formar uma rede, tal como uma intranet, que pode ser conectada ao mundo exterior por meio da Internet. Em resumo, uma variedade de fontes diferentes e-xiste para o armazenamento e transmissão de dados, e conse-qüentemente, na progressão, dispositivos de computação exigirão maneiras de compartilhar dados, tal como dados acessados ou utilizados incidentes aos objetos de programa, que fazem uso de serviços gráficos virtualizados de acordo com a presente invenção. A Internet geralmente se refere à coleção de redes e portas que utilizam o conjunto TCP/IP de protocolos, que são bem conhecidos na técnica de rede de computador. TCP/IP é um acrônimo para "protocolo de controle de transmis-são/protocolo da Internet". A Internet pode ser descrita como um sistema de redes de computador remotas geograficamente distribuídas interligadas por computadores executando protocolos de colocação em rede que permitem que usuários interajam e compartilhem informação através da(s) rede(s). Por causa de tal compartilhamento de informação difundido, redes remotas tal como a Internet têm até o momento geralmente e-voluído para um sistema aberto para o qual os desenvolvedores podem projetar aplicações de software para execução de operações ou serviços especializados, essencialmente sem restrição.

Assim, a infra-estrutura da rede possibilita um hospedeiro de topologias de rede tais como arquiteturas de cliente/servidor, não hierárquicas ou híbridas. 0 "cliente" é um elemento de uma classe ou grupo que usa os serviços de uma outra classe ou grupo ao qual ele não está relacionado. Assim, na computação, um cliente é um processo, isto é, a-proximadamente um conjunto de instruções ou tarefas, que solicita um serviço provido por um outro programa. 0 processo do cliente utiliza o serviço solicitado sem ter que "conhecer" quaisquer detalhes de trabalho sobre o outro programa ou o próprio serviço. Em uma arquitetura de cliente/servidor, particularmente um sistema de rede, um cliente é geralmente um computador que acessa recursos de rede compartilhados providos por um outro computador, por exemplo, um servidor. No exemplo da Fig. 6A, os computadores 610a,610b, etc. podem ser imaginados como clientes e os computadores 10a,10b, etc. podem ser imaginados como o servidor onde o servidor 10a, 10b, etc. mantém os dados que são então replicados nos computadores do cliente 610a,610b, etc., embora qualquer computador possa ser considerado um cliente, um servidor ou ambos, dependendo das circunstâncias. Qualquer um desses dispositivos de computação pode estar processando dados ou solicitando serviços ou tarefas que podem envolver uma implementação das arquiteturas gráficas virtuali-zadas da invenção.

Um servidor é tipicamente um sistema de computador remoto acessível através de uma rede remota ou local, tal como a Internet. 0 processo do cliente pode ficar ativo em um primeiro sistema de computador, e o processo do servidor pode ficar ativo em um segundo sistema de computador, se comunicando através de um meio de comunicações, assim provendo funcionalidade distribuída e permitindo que múltiplos clientes tirem vantagem das capacidades de reunião de informação do servidor. Quaisquer objetos de software utilizados em conformidade para fazer uso da(s) arquitetura{s) virtualiza-da(s) da invenção podem ser distribuídos através de múltiplos dispositivos de computação ou objetos.

Cliente(s) e servidor(es) se comunicam utilizando a funcionalidade provida pela(s) camada(s) de protocolo. Por exemplo, o protocolo de transferência de hipertexto (HTTP) é um protocolo comum que é usado em conjunto com a World Wide Web (WWW) ou "a Rede". Tipicamente, um endereço da rede de computador tal como um endereço do protocolo da Internet (IP) ou outra referência tal como uma localização constante de recursos (URL) pode ser usado para identificar os computadores servidores ou clientes um para o outro. 0 endereço de rede pode ser citado como um endereço de URL. A comunicação pode ser provida através de um meio de comunicações, por exemplo, cliente(s) e servidor(es) podem ser acoplados entre si através de conexão (ões) TCP/IP para comunicação de alta capacidade.

Assim, a Fig. 6A ilustra um ambiente exemplar de rede ou distribuído, com um servidor em comunicação com computadores clientes através de uma rede/barramento, no qual a presente invenção pode ser utilizada. Em mais detalhes, um número de servidores 10a,10b, etc. é interligado através de uma rede de comunicações/barramento 14, que pode ser uma LAN, WAN, intranet, a Internet, etc,, com um número de dispositivos de computação de cliente ou remotos 610a,610b,610c,610d,610e, etc., tais como um computador portátil, computador manual, cliente fino, utensílio de rede ou outro dispositivo, tais como um VCR, TV, forno, luz, aquecedor e semelhantes de acordo com a presente invenção. É considerado, assim, que a presente invenção pode se aplicar a qualquer dispositivo de computação em conjunto com o qual é desejável implementar interfaces gráficas de hóspede e sistemas operacionais de acordo com a invenção.

Em um ambiente de rede no qual a rede de comunicações/barramento 14 é a Internet, por exemplo, os servidores 10a, 10b, etc. podem ser servidores da Rede com os quais os clientes 610a,610b,610c,610d,610e, etc. se comunicam através de qualquer um de um número de protocolos conhecidos tais como HTTP. Os servidores 10a,10b, etc. podem também servir como clientes 610a,610b,610c,610d,610e, etc., como pode ser característico de um ambiente de computação distribuído.

As comunicações podem ser ligadas por fiação ou sem fio, onde apropriado. Dispositivos clientes 610a, 610b, 610c, 610d, 610e, etc. podem se comunicar ou não através da rede de comunicações/barramento 14, e podem ter comunicações independentes associadas com eles. Por exemplo, no caso de uma TV ou VCR, pode existir ou não um aspecto de rede para o seu controle. Cada computador cliente 610a,610b,610c,610d,610e, etc. e computador servidor 10a, 10b, etc. pode ser equipado com vários módulos de programa de aplicação ou objetos 635 e com conexões ou acesso a vários tipos de elementos de armazenamento ou objetos, através dos quais arquivos ou fluxos de dados podem ser armazenados ou nos quais porção(ões) de arquivos ou fluxos de dados podem ser transferidos, transmitidos ou migrados. Qualquer um ou mais dos computadores 10a,10b,610a,610b, etc. podem ser responsáveis pela manutenção e atualização de um banco de dados 20 ou outro elemento de armazenamento, tal como um banco de dados ou memória 20 para armazenar dados processados de acordo com a invenção. Assim, a presente invenção pode ser utilizada em um ambiente de rede de computador tendo computadores clientes 610a,610b, etc. que podem acessar e interagir com uma rede de computador/barramento 14 e computadores servidores 10a,10b, etc. que podem interagir com computadores clientes 610a,610b, etc. e outros dispositivos semelhantes e bancos de dados 20.

Dispositivo de Computação Exemplar A Fig. 6B e a discussão seguinte são planejadas para prover uma breve descrição geral de um ambiente de computação adequado em conjunto com o qual a invenção pode ser implementada. Deve ser entendido, entretanto, que dispositivos de computação de mão, portáteis e outros e objetos de computação de todos os tipos são considerados para uso em conjunto com a presente invenção, isto é, em qualquer lugar onde uma GPU exista em um ambiente de computação. Embora um computador de uso geral seja descrito abaixo, isso é apenas um exemplo, e a presente invenção pode ser implementada com um cliente fino tendo interoperabilidade e interação de re-de/barramento. Assim, a presente invenção pode ser implementada em um ambiente de serviços hospedados em rede nos quais muito pouco ou mínimos recursos de cliente são envolvidos, por exemplo, um ambiente de rede no qual o dispositivo cliente serve meramente como uma interface para a rede/barramento, tal como um objeto colocado em um utensílio. Essencialmente, em qualquer lugar que os dados possam ser armazenados ou do qual os dados possam ser recuperados ou transmitidos para um outro computador é um ambiente desejável, ou adequado, para operação das técnicas de virtualiza-ção gráfica de acordo com a invenção.

Embora não requerido, a invenção pode ser implementada totalmente ou em parte através de um sistema operacional, para uso por um desenvolvedor de serviços para um dispositivo ou objeto, e/ou incluída dentro do software a-plicativo que opera em conjunto com a(s) canalização(ões) gráfica(s) virtualizada(s) da invenção. 0 software pode ser descrito no contexto geral de instruções executáveis pelo computador, tal como módulos de programa, sendo executados por um ou mais computadores, tais como estações de trabalho de cliente, servidores ou outros dispositivos. De forma geral, módulos do programa incluem rotinas, programas, objetos, componentes, estruturas de dados e semelhantes que executam tarefas particulares ou implementam tipos de dados abstratos particulares. Tipicamente, a funcionalidade dos módulos do programa pode ser combinada ou distribuída como desejado em várias modalidades. Além do mais, esses versados na técnica verificarão que a invenção pode ser praticada com outras configurações de sistema de computador e protocolos. Outros sistemas de computação, ambientes e/ou configurações bem conhecidos que podem ser adequados para uso com a invenção incluem, mas não são limitados a, computadores pessoais (PCs), máquinas contadoras automáticas, computadores servidores, dispositivos de mão ou laptops, sistemas de multipro-cessador, sistemas com base em microprocessador, eletrônica de consumidor programável, PCs de rede, utensílios, luzes, elementos de controle ambiental, minicomputadores, computadores de grande porte e semelhantes. A invenção pode também ser praticada nos ambientes de computação distribuídos onde as tarefas são executadas por dispositivos de processamento remoto que são ligados através de uma rede de comunica-ções/barramento ou outro meio de transmissão de dados. Em um ambiente de computação distribuído, módulos do programa podem estar localizados em ambos os meios de armazenamento de computador local e remoto incluindo dispositivos de armazenamento de memória, e nós de cliente podem, por sua vez, se comportar como nós de servidor. A Fig. 6B assim ilustra um exemplo de um ambiente do sistema de computação adequado 600 no qual a invenção pode ser implementada, embora como tornado claro acima, o ambiente do sistema de computação 600 é somente um exemplo de um ambiente de computação adequado e não é planejado para sugerir qualquer limitação quanto ao escopo de uso ou funcionalidade da invenção. Nem deve o ambiente de computação 600 ser interpretado como tendo qualquer dependência ou exi- gêncía relacionada com qualquer um ou combinação de componentes ilustrados no ambiente de operação exemplar 600.

Com referência à Fig. 6B, um sistema exemplar para implementar a invenção inclui um dispositivo de computação de uso geral na forma de um computador 610. componentes do computador 610 podem incluir, mas não são limitados a, uma unidade de processamento 620, uma memória do sistema 630 e um barramento do sistema 621 que une vários componentes do sistema incluindo a memória do sistema na unidade de processamento 620. 0 barramento do sistema 621 pode ser qualquer um de vários tipos de estruturas de barramento incluindo um barramento de memória ou controlador de memória, um barramento periférico e um barramento local usando qualquer uma de uma variedade de arquiteturas de barramento. Por meio de exemplo, e não limitação, tais arquiteturas incluem barramento da arquitetura padrão industrial (ISA), barramento da arquitetura de micro canal (MCA), barramento ISA aperfeiçoado (EISA), barramento local da associação dos padrões eletrônicos de vídeo (VESA), barramento de interligação de componente periférico (PCI) (também conhecido como barramento Mezanino) e PCI Express(PCIe). 0 computador 610 tipicamente inclui uma variedade de meios legíveis pelo computador. Meios legíveis pelo computador podem ser quaisquer meios disponíveis que possam ser acessados pelo computador 610 e incluem ambos os meios voláteis e não voláteis, meios removíveis e não removíveis. Por meio de exemplo, e não limitação, meios legíveis por computador podem compreender meios de armazenamento no computador e meios de comunicação. Meios de armazenamento no computador incluem ambos meios voláteis e não voláteis, removíveis e não removíveis implementados em qualquer método ou tecnologia para armazenamento de informação tais como instruções legíveis pelo computador, estruturas de dados, módulos do programa ou outros dados. Meios de armazenamento no computador incluem, mas não são limitados a, RAM, ROM, EEPROM, memória flash ou outra tecnologia de memória, CD-ROM, discos versáteis digitais (DVD) ou outro armazenamento de disco ó-tico, cassetes magnéticos, fita magnética, armazenamento de disco magnético ou outros dispositivos de armazenamento magnético ou qualquer outro meio que possa ser usado para armazenar a informação desejada e que possa ser acessado pelo computador 610. Meios de comunicação tipicamente personificam instruções legíveis pelo computador, estruturas de dados, módulos do programa ou outros dados em um sinal de dados modulado tal como uma onda portadora ou outro mecanismo de transporte e incluem quaisquer meios de entrega de informação. 0 termo "sinal de dados modulado" significa um sinal que tem uma ou mais de suas características ajustadas ou mudadas em uma tal maneira de modo a codificar a informação no sinal. Por meio de exemplo, e não limitação, meios de comunicação incluem meios ligados por fio tal como uma rede ligada por fio ou conexão ligada por fio direta e meios sem fio tais como meios sem fio acústicos, de RF, de infravermelho e outros. A combinação de qualquer um dos acima deve também ser incluída dentro do escopo de meios legíveis por computador. A memória do sistema 630 incluí meios de armazenamento no computador na forma de memória volátil e/ou não volátil tais como memória somente de leitura (ROM) 631 e memória de acesso aleatório (RAM) 632. Um sistema básico de en-trada/saída 633 (BIOS), contendo as rotinas básicas que ajudam a transferir a informação entre elementos dentro do computador 610, tal como durante a partida, é tipicamente armazenado na ROM 631. A RAM 632 tipicamente contém dados e/ou módulos de programa que são imediatamente acessíveis para e/ou atualmente sendo operados pela unidade de processamento 620. Por meio de exemplo, e não limitação, a Fig. 6B ilustra o sistema operacional 634, programas de aplicação 635, outros módulos de programa 636 e dados do programa 637.

O computador 610 pode também incluir outros meios de armazenamento no computador removíveis/não removíveis, voláteis/não voláteis. Por meio de exemplo somente, a Fig. 6B ilustra uma unidade de disco rígido 641 que lê de ou escreve em meios magnéticos não voláteis, não removíveis, uma unidade de disco magnético 651 que lê de ou escreve em um disco magnético removível, não volátil 652 e uma unidade de disco ótico 655 que lê de ou escrever em um disco ótico removível, não volátil 656, tal como um CD-ROM ou outros meios óticos. Outros meios de armazenamento no computador removí -veis/não removíveis, voláteis/não voláteis que podem ser u-sados no ambiente operacional exemplar incluem, mas não são limitados a, cassetes de fita magnética, placas de memória flash, discos versáteis digitais, fita de vídeo digital, RAM de estado sólido, ROM de estado sólido e assim por diante. A unidade de disco rígido 641 é tipicamente conectada no bar-ramento do sistema 621 através de uma interface de memória não removível tal como a interface 640 e a unidade de disco magnético 651 e a unidade de disco ótico 655 são tipicamente conectadas no barramento do sistema 621 por uma interface de memória removível, tal como a interface 650.

As unidades e seus meios de armazenamento no computador associados, discutidos acima e ilustrados na Fig. 6B, provêem armazenamento das instruções legíveis por computador, estruturas de dados, módulos do programa e outros dados para o computador 610. Na Fig-. 6B, por exemplo, a unidade de disco rígido 641 é ilustrada como armazenando o sistema operacional 644, programas de aplicação 645, outros módulos de programa 646 e dados do programa 647. Observe que esses componentes podem ser os mesmos que ou diferentes do sistema operacional 634, programas de aplicação 635, outros módulos do programa 636 e dados do programa 637. 0 sistema operacional 644, programas de aplicação 645, outros módulos do programa 646 e dados do programa 647 são fornecidos com números diferentes aqui para ilustrar que, no mínimo, eles são cópias diferentes. Um usuário pode inserir comandos e informação no computador 610 através de dispositivos de entrada tais como um teclado 662 e um dispositivo de indicação 661, geralmente citado como um mouse, trackball ou base sensível ao toque. Outros dispositivos de entrada (não mostrados) podem incluir um microfone, joystick, base de jogos, disco de satélite, scanner, ou semelhantes. Esses e outros dispositivos de entrada são freqüentemente conectados na u- nidade de processamento 620 através de uma interface de entrada do usuário 660 que é acoplada no barramento do sistema 621, mas pode ser conectada por outra interface e estruturas de barramento, tais como uma porta paralela, porta de jogos ou um barramento serial universal (USB). Esses são os tipos de estruturas que são virtualizadas pelas arquiteturas da invenção. Uma interface gráfica 682, tal como uma das interfaces implementadas por Northbridge, pode também ser conectada no barramento do sistema 621. Northbridge é um conjunto de circuitos integrados que se comunica com a CPU, ou unidade de processamento hospedeira 620, e assume a responsabilidade pelas comunicações tais como PCI, PCIe e comunicações de porta gráfica acelerada (AGP). A invenção considera ambas as implementações gráficas integradas (dentro de Northbridge) e discretas (fora de Northbridge) . Uma ou mais unidades de processamento gráfico (GPUs) 684 podem se comunicar com a interface gráfica 682. Sob esse aspecto, GPUs 684 geralmente incluem um armazenamento de memória no circuito integrado, tal como armazenamento do registrador e as GPUs 684 se comunicam com uma memória de vídeo 686. As GPUs 684, entretanto, são apenas um exemplo de um co-processador e assim uma variedade de dispositivos de co-processamento pode ser incluída no computador 610, e podem incluir uma variedade de sombrea-dores procedurais, tal como sombreadores de pixel e vértice. Um monitor 691 ou outro tipo de dispositivo de exibição é também conectado no barramento do sistema 626 através de uma interface, tal como uma interface de vídeo 690, que pode, por sua vez, se comunicar com a memória de vídeo 686. Além do monitor 691, os computadores podem também incluir outros dispositivos de saída periférica tais como alto-falantes 697 e impressora 696, que podem ser conectados através de uma interface periférica de saída 695. 0 computador 610 pode operar em um ambiente de rede ou distribuído usando conexões lógicas para um ou mais computadores remotos, tal como um computador remoto 680. 0 computador remoto 680 pode ser um computador pessoal, um servidor, um roteador, um PC de rede, um dispositivo par ou outro nó de rede comum, e tipicamente inclui muitos ou todos os elementos descritos acima em relação ao computador 610, embora somente um dispositivo de armazenamento de memória 681 tenha sido ilustrado na Fig. 6B. As conexões lógicas representadas na Fig. 6B incluem uma rede de área local (LAN) 671 e uma rede de longa distância (WAN) 673, mas podem também incluir outras redes/barramentos. Tais ambientes de rede são comuns em casas, escritórios, redes de computador empresariais, intranets e na Internet.

Quando usado em um ambiente de rede LAN, o computador 610 é conectado na LAN 671 através de uma interface de rede ou adaptador 670. Quando usado em um ambiente de rede WAN, o computador 610 tipicamente inclui um modem 672 ou outro dispositivo para estabelecer as comunicações através da WAN 673, tal como a Internet. 0 modem 672, que pode ser interno ou externo, pode ser conectado no barramento do sistema 621 através da interface de entrada do usuário 660 ou outro mecanismo apropriado. Em um ambiente de rede, módulos do programa representados em relação ao computador 610, ou por- ções do mesmo, podem ser armazenados no dispositivo de armazenamento de memória remoto. Por meio de exemplo, e não limitação, a Fig. 6B ilustra programas de aplicação remotos 685 como residindo no dispositivo de memória 681. Será verificado que as conexões de rede mostradas são exemplares e outros modos de estabelecimento de um elo de comunicações entre os computadores podem ser usados.

Existem múltiplas maneiras para implementar a presente invenção, por exemplo, uma API apropriada, conjunto de ferramentas, código de acionador, sistema operacional, controle, objeto de software independente ou transferível, etc. que possibilitam que aplicações e serviços usem a(s) arquiteturais) virtualizada(s), sistemas e métodos da invenção. A invenção considera o uso da invenção do ponto de vista de uma API (ou outro objeto de software), bem como de um objeto de software ou hardware que recebe qualquer uma das técnicas anteriormente mencionadas de acordo com a invenção. Assim, várias implementações da invenção descrita aqui podem ter aspectos que são totalmente em hardware, parcialmente em hardware e parcialmente em software, bem como no software.

Como mencionado acima, embora modalidades exemplares da presente invenção tenham sido descritas em conjunto com vários dispositivos de computação e arquiteturas de rede, os conceitos básicos podem ser aplicados a qualquer dispositivo de computação ou sistema no qual é desejável utilizar uma GPU. Por exemplo, o(s) vários algoritmo(s) e implementações de hardware da invenção podem ser aplicados no sistema operacional de um dispositivo de computação, provido como um objeto separado no dispositivo, como parte de um outro objeto, como um controle reutilizável, como um objeto transferível de um servidor, como um "homem intermediário" entre um dispositivo ou objeto e a rede, como um objeto distribuído, como hardware, na memória, uma combinação de qualquer um dos precedentes, etc. Alguém de conhecimento comum na técnica verificará que existem numerosas maneiras de prover código de objeto e nomenclatura que atingem a mesma funcionalidade, similar ou equivalente atingida pelas várias modalidades da invenção.

Como mencionado, as várias técnicas descritas aqui podem ser implementadas em conjunto com hardware ou software ou, onde apropriado, com uma combinação de ambos. Assim, os métodos e aparelhos da presente invenção, ou certos aspectos ou porções dos mesmos, podem tomar a forma de código de programa (isto é, instruções) personificado em meios tangíveis, tais como discos flexíveis, CD-ROMs, unidades rígidas ou qualquer outro meio de armazenamento legível por máquina, onde, quando o código de programa é carregado em e executado por uma máquina, tal como um computador, a máquina se torna um aparelho para a prática da invenção. No caso da execução do código do programa em computadores programáveis, o dispositivo de computação inclui geralmente um processador, um meio de armazenamento legível pelo processador (incluindo memória volátil e não volátil e/ou elementos de armazenamento) , pelo menos um dispositivo de entrada e pelo menos um dispositivo de saída. Um ou mais programas que podem implementar ou utilizar as técnicas de virtualização da GPU da presente invenção, por exemplo, através do uso de uma API de processamento de dados, controles reutilizãveis ou semelhantes, são preferivelmente implementados em uma linguagem de programação orientada por objeto ou procedural de alto nível para se comunicar com um sistema de computador. Entretanto, o(s) programa(s) pode(m) ser implementado(s) em linguagem assembly ou de máquina, se desejado. Em qualquer caso, a linguagem pode ser uma linguagem compilada ou interpretada, e combinada com implementações de hardware.

Os métodos e aparelhos da presente invenção podem também ser praticados através de comunicações personificadas na forma de código de programa que é transmitido através de algum meio de transmissão, tal como através de fiação ou ca-beamento elétrico, através de fibra ótica ou através de qualquer outra forma de transmissão, onde, quando o código do programa é recebido e carregado em e executado por uma máquina, tal como uma EPROM, um conjunto de portas lógicas, um dispositivo lógico programável (PLD), um computador cliente, etc., a máquina se torna um aparelho para a prática da invenção. Quando implementado em um processador de uso geral, o código do programa combina com o processador para prover um aparelho único que opera para chamar a funcionalidade da presente invenção. Adicionalmente, quaisquer técnicas de armazenamento usadas em conjunto com a presente invenção podem ser invariavelmente uma combinação de hardware e software.

Embora a presente invenção tenha sido descrita em conjunto com as modalidades preferidas das várias figuras, é para ser entendido que outras modalidades similares podem ser usadas ou modificações e adições podem ser feitas na modalidade descrita para executar a mesma função da presente invenção sem se desviar da mesma. Por exemplo, embora ambientes de rede exemplares da invenção sejam descritos no contexto de um ambiente de rede, tal como um ambiente de rede não hierárquico, alguém versado na técnica reconhecerá que a presente invenção não é limitada a ele, e que os métodos, como descritos no presente pedido podem se aplicar a qualquer dispositivo de computação ou ambiente, tais como um console de jogos, computador de mão, computador portátil, etc., quer ligado por fiação ou sem fio, e pode ser aplicado a qualquer número de tais dispositivos de computação conectados através de uma rede de comunicações, e interagindo a-través da rede. Além do mais, deve ser enfatizado que uma variedade de plataformas de computador, incluindo sistemas operacionais de dispositivo de mão e outros sistemas operacionais específicos da aplicação são considerados, especialmente à medida que o número de dispositivos de rede sem fio continua a proliferar.

Embora modalidades exemplares se refiram à utilização da presente invenção no contexto de uma canalização gráfica, a invenção não é de tal maneira limitada, mas preferencialmente pode ser implementada para virtualizar uma segunda unidade de processamento especializada cooperando com um processador principal por outras razões também. Além do mais, a invenção considera o cenário onde múltiplas instâncias da mesma versão ou lançamento de um OS estão operan- do em máquinas virtuais separadas de acordo com a invenção. Pode ser verificado que a virtualização da invenção é independente das operações para as quais a GPU é usada. É também planejado que a invenção se aplique a todas as arquiteturas de GPU, incluindo mas não limitado a múltiplas implementações de GPU, bem como modalidades de múltiplas GPU que pro-vêem a ilusão de uma única interface de GPU. Ainda adicionalmente, a presente invenção pode ser implementada em ou através de uma pluralidade de circuitos integrados de processamento ou dispositivos, e o armazenamento pode ser similarmente efetuado através de uma pluralidade de dispositivos. Portanto, a presente invenção não deve ser limitada a qualquer modalidade única, mas preferivelmente deve ser interpretada na amplitude e escopo de acordo com as reivindicações anexas.

REIVINDICAÇÕES

Claims (16)

1. Método para processar comandos compreendendo itens de trabalho gráficos em um sistema computacional tendo uma primeira máquina virtual (VM), e uma segunda máquina virtual (VM), caracterizado pelo fato de que compreende: dividir um espaço de endereço real de uma unidade de processamento gráfica (GPU) em pelo menos uma primeira porção e uma segunda porção; fornecer à primeira VM um primeiro espaço de endereço virtual de gráficos, o primeiro espaço de endereço virtual de gráficos estando mapeado para a primeira porção do espaço de endereço real; receber, por uma unidade de processamento central (CPU), um primeiro comando a ser processado pela GPU, o primeiro comando tendo um primeiro endereço virtual no primeiro espaço de endereço virtual de gráficos, o primeiro comando originado pela primeira VM; traduzir, pela CPU, o primeiro endereço virtual para um primeiro endereço real correspondente na primeira porção real; instruir a GPU, pela CPU, para processar o primeiro comando no primeiro endereço real; em que instruir a GPU, pela CPU, para processar o primeiro comando no primeiro endereço real compreende o processamento, pela GPU, do primeiro comando no primeiro endereço real; proporcionar à segunda VM um segundo espaço de endereço virtual de gráficos, o segundo espaço de endereço virtual de gráficos estando mapeado para a segunda porção do espaço de endereços real; receber, pela CPU, um segundo comando a ser processado pela GPU, o segundo comando tendo um segundo endereço virtual no segundo espaço de endereço virtual de gráficos, o segundo comando originado pela segunda VM; traduzir, pela CPU, o segundo endereço virtual para um segundo endereço real correspondente na segunda porção real; e instruir o GPU, pela CPU, para processar o segundo comando no segundo endereço real; em que instruir a GPU, pela CPU, para processar o segundo comando no segundo endereço real compreende o processamento, pela GPU, do segundo comando no segundo endereço real; em que instruir a GPU, pela CPU, para processar o segundo comando no segundo endereço real, compreende ainda a composição, por um compositor, de uma imagem de exibição que compreende um resultado gráfico de processamento do primeiro comando, e um resultado gráfico do processamento do segundo comando, o compositor tendo acesso às primeira e segunda porções do espaço de endereço real; e em que instruir a GPU, pela CPU, para processar o segundo comando no segundo endereço real, além disso, exibe a imagem de exibição em um dispositivo de exibição.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o espaço de endereços real da GPU compreende uma memória de video.

3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que proporcionar à primeira VM um primeiro espaço de endereçamento virtual de gráficos, o primeiro espaço de endereços virtual de gráficos estando mapeado para a primeira porção do espaço de endereços real compreende: proporcionar uma primeira sub-porção do primeiro espaço de endereço virtual de gráficos em uma primeira aplicação sendo executa na primeira VM; e proporcionar uma segunda sub-porção do primeiro espaço de endereço virtual de gráficos em uma segunda aplicação sendo executada na primeira VM.

4. Método de acordo com a reivindicação 1, caracterizado pelo fato de que instruir a GPU, pela CPU, para processar o primeiro comando no primeiro endereço real compreende: determinar que o primeiro comando é privilegiado; e processar, pela CPU, o primeiro comando baseado em um conjunto de regras; e em que instruir a GPU, pela CPU, para processar a chamada de comando no segundo endereço real compreende : determinar que o segundo comando não é privilegiado; e instruir a GPU, pela CPU, para processar o segundo comando sem que a CPU processasse o segundo comando com base no conjunto de regras.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o compositor compreende : uma base de código confiável criada por um componente de monitor de máquina virtual que permite a execução da primeira VM e da segunda VM.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda: processar a saida de um aplicativo não confiável em execução na primeira VM, incluindo a utilização de pelo menos um serviço confiável sendo executado em uma terceira VM para proteger a saida.

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que traduzir, pela CPU, o primeiro endereço virtual para um primeiro endereço real correspondente na primeira porção real compreende : alocar uma porção contígua do espaço de endereço real da GPU para a primeira VM; identificar um registo de base e um registo de limite para o espaço de endereço virtual do primeiro espaço de endereço virtual de gráficos baseado na porção contígua do espaço de endereço real; e traduzir o primeiro endereço virtual para o primeiro endereço real correspondente com base no registo de base e no registo de limite.

8. Sistema de computação para processar um comando que compreende um item de trabalho gráfico, caracterizado pelo fato de que compreende: uma unidade de processamento central (CPU); uma máquina virtual (VM); um monitor de máquina virtual (VMM) que suporta a VM; uma unidade de processamento de gráficos (GPU) tendo um espaço de endereço real; e uma memória que suporta instruções que, após a execução pelo sistema de computação, fazem com que o sistema de computação compreenda operações que compreendem: proporcionar à VM um espaço de endereço de gráficos virtuais compreendendo uma entrada de tabela de páginas, o espaço de endereço de gráficos virtuais estando mapeado para uma porção do espaço de endereço real; aprisionar, pelo VMM, uma operação originada pela VM para programar a entrada da tabela de páginas, a operação compreendendo o comando que compreende o item de trabalho de gráficos; mapear, pela CPU, um endereço virtual da entrada da tabela de páginas para um endereço real correspondente na porção do espaço de endereço real; instruir a GPU, pela CPU, a processar a operação para programar a entrada da tabela de página no endereço real; identificar, pelo VMM, uma imagem de exibição que compreende um resultado gráfico que compreende o resultado da GPU que processa a operação para programar a entrada de tabela de página, tendo o VMM acesso à porção do espaço de endereço real; e transmitir, pelo VMM, o resultado para um sistema operacional hospedeiro para composição e exibição em um dispositivo de exibição.

9. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que o espaço de endereço real da GPU compreende a memória do sistema.

10. Sistema de acordo com a reivindicação 9, caracterizado pelo fato de que proporcionar à VM um espaço de endereço de gráficos virtuais compreendendo uma entrada de tabela de páginas, o espaço de endereço de gráficos virtuais estando mapeado para uma porção do espaço de endereço real compreende: proporcionar uma primeira sub-porção do espaço de endereço de gráficos virtuais para uma primeira aplicação executa na VM; e proporcionar uma segunda sub-porção do espaço de endereço de gráficos virtuais para uma segunda aplicação executada na VM.

11. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que instruir a GPU, pela CPU, a processar a operação para programar a entrada da tabela de página no endereço real compreende: determinar que a operação para programar a entrada da tabela de páginas é privilegiada; e processar, pela CPU, a operação para programar a entrada da tabela de páginas com base em um conjunto de regras; e compreendendo ainda: instruir a GPU, pela CPU, a processar uma segunda operação para programar a entrada da tabela de páginas no segundo endereço real, compreendendo: determinar que a segunda operação para programar a entrada da tabela de páginas é não privilegiada; e instruir a GPU, pela CPU, a processar a segunda operação para programar a entrada da tabela de página sem que a CPU processe a segunda operação para programar a entrada da tabela de página com base no conjunto de regras.

12. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que compreende ainda um sistema operativo hospedeiro que compreende uma base de código confiável que habilita a VM.

13. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que a memória possui ainda instruções que, após a execução pelo sistema de computação, fazem com que o sistema de computação execute operações compreendendo: processar, pelo VMM, uma saida de um aplica- tivo não confiável executado na VM, incluindo a utilização de pelo menos um serviço confiável sendo executado em uma segunda VM para proteger a saida.

14. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que a GPU é dedicada ao cálculo de operações de ponto flutuante.

15. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que o VMM é separado do sistema operativo hospedeiro.

16. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que a memória possui ainda instruções que, após a execução pelo sistema de processamento, fazem com que o sistema de computação execute operações compreendendo: transmitir, pelo VMM, a entrada da primeira tabela de página diretamente para um pipeline gráfico da GPU.