BRPI0716969A2 - Sistemas gráficos de computador compostos por múltiplos processadores paralelos. - Google Patents

Description

"SISTEMA DE PROCESSAMENTO GRÁFICO ACELERADO, MÉTODO PARA EQUILIBRAR CARGAS PARA UMA PLURALIDADE DE PROCESSADORES GRÁFICOS CONFIGURADOS PARA OPERAR EM PARALELO E SISTEMA DE PROCESSAMENTO GRÁFICO"

Referência Cruzada a Pedidos Relacionados

O presente pedido é uma continuação em parte do pedido de patente não provisória número serial U.S. 10/620.150, depositado em 15 de julho de 2003, o assunto do qual é aqui incorporado em sua totalidade a título de referência.

Desenvolvimento ou Pesquisa Patrocinada pelo Estado Não aplicável.

Referência à Listagem Seqüencial

Não aplicável.

Campo da Invenção

A presente invenção refere-se ao processamento de instruções gráficas em compu- tadores. Especificamente, a modalidade preferencial da presente invenção descreve um subsistema de processamento gráfico acelerado para uso em computadores que utiliza múl- tiplas placas de vídeo prontas para uso, cada uma tendo uma ou mais unidades de proces- samento gráfico (GPUs), e atribui a cada placa de vídeo gerar alternadamente instruções para desenhar uma exibição. As placas de vídeo a serem usadas na invenção descrita não necessitam ser modificadas em qualquer forma substancial.

Fundamentos da Invenção

Mesmo antes do início do uso freqüente de computadores pessoais, os gráficos de computador já eram um dos aspectos de computação mais promissores, e mais desafiado- res. Os primeiros computadores pessoais gráficos desenvolvidos para mercados de massa contavam com uma unidade de processamento de computador principal (CPU) para contro- lar cada aspecto da saída gráfica. As placas gráficas, ou placas de vídeo, em sistemas ante- riores, atuaram como interfaces simples entre a CPU e o dispositivo de tela (display), e não conduziram qualquer processamento próprio. Em outras palavras, estas placas de vídeo anteriores simplesmente traduziam comandos de hardware de baixo nível emitidos pela CPU em sinais analógicos que os dispositivos de tela transformavam em imagens na tela. Devido a todo processamento conduzido pela CPU, os aplicativos com intensivos gráficos tinham uma tendência de utilizar em demasia os ciclos de processamento e impedir que a CPU executasse outras responsabilidades. Isto leva à lentidão demasiada e ao desempenho degradado do sistema.

Para mover a carga de trabalho gráfica da CPU, os desenvolvedores de hardware

introduziram subsistemas de processamento gráfico para renderizar as imagens animadas realistas em tempo real, por exemplo, em 30 quadros ou mais por segundo. Esses subsis- temas são mais freqüentemente implementados em placas de expansão que podem ser inseridos em encaixes configurados apropriadamente em uma placa-mãe de um sistema de computador e geralmente incluem uma ou mais unidades de processamento gráfico (GPUs) dedicadas e memórias gráficas dedicadas. As GPUs são capazes de aceitar os comandos gráficos de alto nível e processá-los internamente nos sinais de vídeo exigidos pelos dispo- sitivos de tela. A GPU típica é um dispositivo de circuito integrado altamente complexo oti- mizado para executar os cálculos gráficos (por exemplo, transformações por matrizes, con- versão de varredura e/ou outras técnicas de rasterização, mistura de textura, etc.) e escreve os resultados na memória gráfica. A GPU é um processador "escravo" que opera em res- posta aos comandos recebidos a partir de programa acionador que executa em um proces- sador "mestre", geralmente a unidade de processamento central (CPU) do sistema. A título de um exemplo extremamente simples, se um aplicativo exige que um triângulo seja dese- nhado na tela, ao invés de exigir que a CPU instrua a placa de vídeo onde desenhar pixels individuais na tela (isto é, comandos de hardware de baixo nível), o aplicativo poderia sim- plesmente enviar um comando "desenhar triângulo" à placa de vídeo, junto com certos pa- râmetros (tal como a localização dos vértices do triângulo), e a GPU poderia processar tais comandos de alto nível em um sinal de vídeo. Desta forma, o processamento gráfico execu- tado anteriormente pela CPU é executado agora pela GPU. Essa inovação permite que a CPU manipule de forma mais eficaz as responsabilidades não relacionadas a gráfico. A desvantagem primária com as placas de vídeo baseadas em GPU anteriores era

que não existia um conjunto padrão para a "linguagem" dos vários comandos de alto nível que as GPUs poderiam interpretar e então processar. Como um resultado, cada aplicativo que procurou utilizar as funções de alto nível de uma placa de vídeo baseada em GPU exi- giu uma parte especializada de software, comumente referida como um acionador, que po- deria entender a linguagem da GPU. Com centenas de diferentes placas de vídeo baseadas em GPU disponíveis no mercado, os desenvolvedores de aplicativo ficaram espantados em escrever esses acionadores especializados. De fato, não era comum que um programa de software particularmente popular incluísse centenas, se não milhares, de acionadores de placas de vídeo com seus códigos executáveis. Isso diminuiu enormemente o desenvolvi- mento e adoção de novos softwares.

Esse problema de linguagem foi resolvido pela adoção, em sistemas operacionais de computador modernos, de métodos padrão de interface de placa de vídeo. Os sistemas operacionais modernos, tal como o sistema operacional Windows® (comercializado pela Mi- crosoft Corporation de Redmond, WA), exige que somente um único acionador de hardware seja escrito para uma placa de vídeo. A interação entre os vários aplicativos de software, a CPU e a placa de vídeo é mediada por uma camada de software intermediária chamada uma Interface de Programação de Aplicativo (API ou módulo de API). Tudo o que é exigido é que os acionadores de vídeo e os aplicativos sejam capazes de interpretar uma API gráfi- ca comum. As duas APIs gráficas mais comuns em uso atualmente nos computadores pes- soais são o DirectX®, distribuído pela Microsoft Corporation de Redmond1 WA, e o OpenGL®, distribuído por um consórcio de interesses de hardware e software de computador.

Desde o advento do subsistema de processamento gráfico baseado em GPU, mais

esforços em aumentar o rendimento de subsistemas gráficos de computador pessoal (isto é, tornar a informação de processo do subsistema mais rápida) têm sido gerados, de forma completamente natural, voltados à produção de GPUs mais complexas e poderosas, e oti- mizando e aumentando as capacidades de suas APIs correspondentes. Outra forma na qual os desenvolvedores de hardware têm procurado aumentar o

rendimento do subsistema gráfico é usando múltiplas GPUs em uma única placa de vídeo para processar a informação gráfica em paralelo. A operação paralela aumenta substanci- almente o número de operações de renderização que podem ser executadas por segundo sem exigir avanços significativos no projeto da GPU. Para minimizar os conflitos de recursos entre as GPUs1 cada GPU é geralmente fornecida com sua própria área de memória dedi- cada, incluindo um armazenador temporário de tela no qual a GPU escreve os dados de pixel que ela renderiza. Um exemplo é conhecido por processar os sinais de comando de vídeo a partir das APIs tal como o DirectX e o OpenGL , usando múltiplas GPUs. Uma GPU é projetada como uma GPU primária e a outra como uma GPU secundária. Embora ambas as GPUs processem independentemente os comandos gráficos que derivam de um API, a GPU secundária precisa ainda direcionar a informação que ela processa (isto é, a represen- tação digital para a parte de tela atribuída a ela) através da GPU primária que, por sua vez, transfere um único sinal de vídeo de saída combinado ao dispositivo de exibição de vídeo. Uma desvantagem significativa e óbvia com este sistema é que um canal de largura de ban- da alta precisa existir entre as duas GPUs.

Nenhum dispositivo, sistema ou método conhecido fornece um subsistema de pro- cessamento gráfico para uso em um computador que combine a potência de processamento de múltiplas placas de vídeo prontas para uso, cada uma tendo uma ou mais GPUs, e atribui cada placa de vídeo para processar as instruções para desenhar uma parte pré-determinada de tela que é exibida ao usuário através de um monitor ou outro dispositivo de saída visual. Em adição, nenhum dos dispositivos acima descreve um subsistema de processamento grá- fico capaz de combinar múltiplas placas de vídeo prontas para uso sem substancial modifi- cação às placas de vídeo.

Então, existe uma necessidade na técnica anterior por um subsistema de proces- samento gráfico para uso em um computador que combine a potência de processamento de múltiplas placas de vídeo, cada uma tendo uma ou mais GPUs, e atribui cada placa de ví- deo para processar as instruções para desenhar uma parte pré-determinada de tela que é exibida ao usuário através de um monitor ou outro dispositivo de saída visual.

Há uma necessidade adicional na técnica anterior por um subsistema de proces- samento gráfico capaz de combinar múltiplas placas de vídeo prontas para uso sem modifi- cação substancial à placa de vídeo.

Há uma necessidade adicional na técnica anterior por um subsistema de proces-

samento gráfico que possa combinar a potência de processamento de múltiplas placas de vídeo e que não exija uma conexão de largura de banda alta entre as placas de vídeo.

Sumário da Invenção

A invenção em questão resolve as necessidades e os problemas descritos acima fornecendo um subsistema de processamento gráfico para uso em um computador que combine a potência de processamento de múltiplas placas de vídeo prontas para uso, com cada placa de vídeo tendo uma ou mais GPUs, e designa cada placa de vídeo para proces- sar as instruções para desenhar uma parte pré-determinada de tela que é exibida ao usuário através de um monitor ou outro dispositivo de saída visual tal como uma tela de tubo de rai- os catódicos, uma tela de cristal liquido, uma tela de plasma, uma tela de projeção, uma tela OLED, telas montadas na cabeça, ou um híbrido dessas.

Os componentes básicos da presente invenção são: (1) módulo Replicador de Co- mando Gráfico de software (GCR); (2) múltiplas placas de vídeo, cada uma equipada com ao menos uma GPU; (3) um mecanismo para assegurar que as saídas de sinal de vídeo de múltiplas placas de vídeo sejam sincronizadas; e (4) um componente hardware/software de boca de conexão de fusão de vídeo ("VMH" - video merger hub).

Em termos gerais, a presente invenção opera interceptando os comandos gráficos emitidos por um aplicativo de computador e replicando aqueles comandos através do módu- lo GCR em múltiplos fluxos de comando gráfico. O número de fluxos de comando corres- ponde ao número de placas de vídeo presentes no sistema. Cada fluxo de comando gráfico gerado pelo módulo GCR faz com que cada placa de vídeo gere somente uma imagem para uma parte particular da tela. As múltiplas placas de vídeo são sincronizadas no mesmo qua- dro de vídeo através de um de um número de mecanismos disponíveis bem conhecidos por aqueles versados na técnica. Os sinais de vídeo resultantes de múltiplas placas de vídeo são então coletados no VMH e montados em uma tela completa que é então exibida por um monitor ou outro dispositivo de saída de vídeo.

Os versados na técnica observarão através de experimentação que utilizando múl- tiplas placas de vídeo, cada uma processando somente uma parte da tela, o rendimento total do subsistema gráfico é aumentado em proporção ao número de placas de vídeo. O aumento de rendimento, entretanto, não é infinitamente extensível à medida que o módulo GCR introduz ao menos as quantidades de processamentos auxiliares que também aumen- tam em proporção ao número de placas de vídeo. Consequentemente, em uma modalidade, a presente invenção consiste de um sub- sistema de processamento gráfico acelerado que compreende um replicador de comandos gráficos (CGR) consistindo de um módulo de software que intercepta os comandos gráficos emitidos por um aplicativo e gera múltiplos fluxos de comandos gráficos modificados; uma pluralidade de placas de vídeo, cada uma equipada com uma ou mais GPUs, onde o núme- ro dos múltiplos fluxos de comandos gráficos modificados é igual ao número da pluralidade de placas de vídeo; um mecanismo para sincronizar a saída de sinal pela pluralidade de placas de vídeo; e uma boca de conexão de fusão de vídeo; onde o replicador de comandos gráficos (GCR) gera os múltiplos fluxos de comandos gráficos modificados tal que cada um dos múltiplos fluxos de comandos gráficos modificados contém comandos para desenhar somente uma parte de uma tela gráfica; cada um dos múltiplos fluxos de comandos gráficos modificados é recebido por uma placa de vídeo separada selecionada a partir da pluralidade de placas de vídeo; os sinais de saída da pluralidade de placas de vídeo são recebidos pelo comutador de vídeo e partes selecionadas desses são seqüencialmente direcionadas à saí- da de vídeo e exibidos em um dispositivo de saída visual; e o comutador de vídeo é contro- lado pelo controlador de comutador de vídeo através do disparo de comutadores de rotea- mento em intervalos apropriados determinados pela taxa de restauração vertical e resolução vertical dos sinais de saída a partir da pluralidade de placas de vídeo e através da relação de equilíbrio de carga atribuída a cada placa na pluralidade de placas de vídeo. É também descrito um método para acelerar o processamento das instruções gráfi-

cas em um computador através do uso de uma pluralidade de placas de vídeo, que compre- endem as etapas de: interceptar comandos gráficos emitidos por um aplicativo e gerar múl- tiplos fluxos de comandos gráficos modificados onde o número dos múltiplos fluxos de co- mandos gráficos modificados é igual ao número da pluralidade de placas de vídeo; sincroni- zar a saída de sinal através da pluralidade de placas de vídeo; combinar o sinal de saída a partir da pluralidade de placas de vídeo em um único sinal de saída gráfica através do uso de uma boca de conexão de fusão de vídeo que compreende um comutador de vídeo, um controlador de comutador de vídeo, um microcontrolador e uma saída de vídeo; e exibir o único sinal de saída gráfica em um dispositivo de saída visual; onde cada um dos múltiplos fluxos de comandos gráficos contém comandos para desenhar somente uma parte de uma tela gráfica; cada um dos múltiplos fluxos de comandos gráficos modificados é recebido por uma placa de vídeo separada selecionada a partir da pluralidade de placas de vídeo; os si- nais de saída da pluralidade de placas de vídeo são recebidos pelo comutador de vídeo e partes selecionadas desse são seqüencialmente direcionadas à saída de vídeo e exibidas em um dispositivo de saída visual; e o comutador de vídeo é controlado pelo controlador de comutador de vídeo através do disparo de comutações de rotina em intervalos apropriados determinados pela taxa de restauração vertical e resolução vertical dos sinais de saída a partir da pluralidade de placas de vídeo e através da relação de equilíbrio de carga atribuída a cada placa na pluralidade de placas de vídeo.

Então, as modalidades da presente invenção fornecem um subsistema de proces- samento gráfico acelerado para uso em computadores que combina a potência de proces- samento de múltiplas placas de vídeo, cada uma tendo uma ou mais GPUs1 e atribui a cada placa de vídeo processar as instruções para desenhar uma parte pré-determinada da tela que é exibida ao usuário através de um monitor ou outro dispositivo de saída visual. As mo- dalidades da presente invenção fornecem um subsistema de processamento gráfico capaz de acelerar a saída gráfica de vídeo combinando múltiplas placas de vídeo prontas para uso sem modificação substancial. Outras modalidades da presente invenção fornecem um sub- sistema de processamento gráfico que não exige uma conexão de largura de banda alta entre as placas de vídeo.

Em outra modalidade, a presente invenção organiza o processamento de vídeo a- través de múltiplas placas de vídeo (ou GPUs) tal que cada uma das placas de vídeo é res- ponsável pelo processamento de vídeo durante diferentes períodos de tempo. Por exemplo, duas placas de vídeo podem cooperar para fornecer os dados de vídeo a uma tela alterna- das, com a primeira placa de vídeo controlando a exibição por um certo período de tempo e a segunda placa de vídeo assumindo seqüencialmente as responsabilidades de processa- mento de vídeo por um período subseqüente. Essa configuração fornece a vantagem que enquanto uma placa de vídeo está fornecendo os dados de vídeo processados, a segunda placa de vídeo está executando seu processamento dos próximos dados de vídeo pelo pró- ximo período de tempo, minimizando, desse modo, os atrasos visto que o processamento dos dados de vídeo pode ser completado antes do início do próximo período de tempo.

Breve Descrição das Várias Vistas dos Desenhos Esses e outros aspectos, características e vantagens da presente invenção podem

ser mais claramente entendidos e apreciados a partir de uma revisão da seguinte descrição detalhada das modalidades alternativas e preferenciais e por referência aos desenhos e reivindicações em anexo.

A Figura 1 mostra um diagrama de blocos de um único subsistema gráfico de placa de vídeo típico (técnica anterior).

As Figuras 2 e 6 mostram um diagrama de blocos do subsistema gráfico de múlti- plas placas de vídeo de modalidades da presente invenção.

A Figura 3 mostra uma ilustração do aplicativo de múltiplos fluxos de comando ge- rados pelo Replicador de Comandos Gráficos da presente invenção. As Figuras 4 a 5 e 7 a 8 mostram uma representação esquemática da operação de

uma boca de conexão de fusão de vídeo das modalidades da presente invenção.

Descrição Detalhada da Invenção Enquanto a presente invenção será descrita de forma mais completa aqui com rela- ção aos desenhos em anexo, nos quais uma modalidade preferencial da presente invenção é mostrada, entende-se que no início da descrição que segue, os versados nas técnicas apropriadas podem modificar a invenção descrita aqui enquanto ainda alcançando os resul- tados favoráveis desta invenção. Consequentemente, a descrição que segue é para ser en- tendida como uma descrição de ensinamento amplo direcionada aos versados em técnicas apropriadas, e não tão Iimitantes mediante a presente invenção.

A FIG. 1 é um diagrama de bloco que ilustra um subsistema gráfico moderno dentro de um computador tipicamente configurado sem a presente invenção, e sua interação com o software de computador pessoal típico para gerar uma imagem.

Sob circunstâncias típicas, um aplicativo de computador 150, tal como um jogo, a- plicativo gráfico 3D ou outro programa, gerará comandos de API 152 para os vários gráficos que ele exige que sejam exibidos no dispositivo de exibição 168. Os comandos da API 152 serão emitidos tal que eles possam ser interpretados de acordo com uma das várias APIs disponíveis instaladas no computador, tais como o DirectX ou OpenGL. O módulo de API apropriado 154 recebe os comandos de API 152 emitidos pelo aplicativo e, por sua vez, pro- cessará e transmitirá os comandos do acionador 156 a um acionador de placa de vídeo 158. O acionador de placa de vídeo 158 emite, por sua vez, os comandos da GPU 160 a uma placa de vídeo 162. A placa de vídeo 162 então receberá os comandos da GPU 160 e, atra- vés de seu circuito interno, traduzirá os comandos em um sinal de vídeo 164 que é recebido pelo dispositivo de tela 168 e é exibido ao usuário.

A FIG. 2 é um diagrama de bloco que ilustra um subsistema gráfico configurado de acordo com a presente invenção e sua interação com o software de computador pessoal típico para gerar uma imagem. Somente para propósitos ilustrativos, a FIG. 2 ilustra um sis- tema equipado com duas placas de vídeo, cada uma tendo uma única GPU. Entretanto, se- rá entendido por aqueles versados na técnica que placas de vídeo adicionais podem ser adicionadas ao sistema desse modo aumentando sua eficácia. A eficácia adicional pode ser aplicada incorporando-se múltiplas placas de vídeo, cada uma tendo mais de uma GPU e/ou incluindo-se uma mistura de placas de vídeo, algumas tendo uma única GPU e algumas tendo múltiplas GPUs.

Sob a presente invenção, o módulo o GCR 204 é um programa de software que re- side entre o aplicativo de computador e múltiplas ocorrências do módulo de API 203, 205. O GCR identifica e intercepta os comandos da API 202 emitidos pelo aplicativo 200 antes da- queles comandos alcançarem as ocorrências do módulo de API 203, 205. Uma vez intercep- tado, o módulo de GCR 204 gera múltiplos fluxos de comando de API modificados 206, 208. Os fluxos de comando de API modificados 206, 208 são recebidos pelas ocorrências do módulo de API 203, 205 que, por sua vez, geram múltiplos fluxos de comando 207, 209 que são recebidos e processados por seus acionadores de placas de vídeo atribuídos 210, 212. O número de fluxos de comando de API modificados 206, 208, e das ocorrências do módulo de API 203, 205, neste caso dois (2), é igual ao número de placas de vídeo sendo emprega- das no sistema. Os fluxos da API são gerados de tal forma que cada placa de vídeo gerará somente os pixels que estão contidos dentro de uma região particular da tela atribuída à essa placa de vídeo.

Para o melhor entendimento deste conceito de "múltiplos fluxos de comando", a FIG. 3 ilustra como ele é aplicado à presente invenção. Como mostrado na FIG. 3, uma tela gráfica completa 250 é composta de uma pluralidade de pixels. Os pixels são arranjados em uma grade X-Y e cada pixel na tela pode ser endereçado usando sua coordenada X1Y ex- clusiva. A faixa de coordenadas para a tela inteira se estende de XeSquerda. Ysuperior para o can- to superior esquerdo 252 até Xdireita, Yinferior para o canto inferior direito 254 de tela. Se, a títu- lo do exemplo mais simples, a presente invenção fosse aplicada usando duas placas de vídeo, a tela poderia ser dividida em uma metade superior 256 e uma metade inferior 258. As coordenadas de pixel para a metade superior de tela estariam na faixa de XeSquerda· Ysuperi- or (252) a Xdireita, Ymetade (260), e as coordenadas de pixel para a metade inferior de tela esta- riam na faixa de Xesquerda, Ymetade (262) ao Xdireita, Yinferior (254).

Consequentemente, e retornando à FIG. 2, o fluxo de comando 207 correspondente à placa de vídeo 218 atribuída para desenhar a parte superior da tela poderia instruir a placa de vídeo a processar e desenhar somente aqueles pixels que estão dentro do retângulo de- limitado pelas coordenadas Xesquerda, Ysuperior (252) a Xdireita, Ymetade (260). Similarmente, o flu- xo de comando 209 correspondente à placa de vídeo 220 atribuída para desenhar a parte inferior da tela instruiria a placa de vídeo a processar e desenhar somente aqueles pixels que estão dentro do retângulo delimitado pelas coordenadas Xdireita, Ymetade (262) a Xdireita, Yinferior (254).

A modificação de "múltiplos fluxos de comando" pode ser executada através de uma variedade de técnicas bem conhecidas, uma discussão detalhada da qual está além do escopo desta patente. A título de exemplo, uma forma usada para gerar os múltiplos fluxos de comando é inserir em cada fluxo um comando "Corte 2D" ou "Corte 3D" exclusivo que instrui a placa de vídeo atribuída ao fluxo para "desenhar" somente aqueles pixels que estão contidos dentro de uma área retangular contínua particular da tela atribuída a essa placa. Por exemplo, em um sistema de duas placas onde a primeira placa é atribuída à parte supe- rior da tela e uma segunda placa à parte inferior, o fluxo correspondente à primeira placa receberia o fluxo de vídeo para a tela inteira, mas também receberia um comando de corte 2D ou 3D instruindo-o a "cortar" (isto é, não desenhar) quaisquer pixels que estejam dentro da parte superior da tela. De forma oposta, a segunda placa também receberia o fluxo de vídeo para a tela inteira, mas receberia o comando de corte 2D ou 3D instruindo-o a "cortar" quaisquer pixels que não estejam dentro da parte inferior da tela.

O GCR 204 pode também modificar dinamicamente os vários fluxos de comando tal que cada placa de vídeo receba os comandos de vídeo que pertençam somente a uma par- te particular da tela. Em termos simples, cada placa de vídeo não recebe o fluxo de coman- do inteiro necessário para pintar a imagem inteira. Por exemplo, em um sistema de duas placas de vídeo com cada placa sendo responsável por 50 por cento da tela (isto é, superi- or/inferior), o GCR 204 receberia, interpretaria e processaria os comandos da API 202 a par- tir do aplicativo de computador 200 e emitiria dois conjuntos de fluxos de comando de API modificados 206, 208. A placa de vídeo responsável pela "parte superior" receberia os co- mandos exigidos para desenhar somente aqueles pixels relevantes à parte superior da tela de vídeo. A placa de vídeo responsável pela "parte inferior" receberia os comandos exigidos para desenhar somente aqueles pixels relevantes à parte inferior da tela de vídeo.

Os versados na técnica entenderão que as partes diferentes da tela atribuídas a cada placa de vídeo não necessitam ser iguais em tamanho, nem cada placa precisa ser atribuída a uma parte contígua da tela de vídeo. Sob a maior parte das circunstâncias, mas não todas, seria desejável garantir que cada parte da tela fosse responsável e atribuída a uma placa de vídeo. Entretanto, as situações podem ser facilmente visualizadas onde as regiões da tela permaneçam graficamente totalmente estáticas e assim o rendimento gráfico seria aumentado se tais regiões fossem desenhadas uma vez e então deixadas não atribuí- das.

Continuando com a FIG. 2, cada fluxo de comando 207, 209 é então processado por seu acionador de placa de vídeo designado 210, 212 que, por sua vez, emite os coman- dos da GPU 214, 216 a uma respectiva placa de vídeo 218, 220. Cada placa de vídeo 218, 220 gera um sinal de vídeo 222, 224 correspondente à sua respectiva parte da tela. Os múl- tiplos sinais de vídeo 222, 224 gerados pelas várias placas de vídeo são enviados a uma boca de conexão de fusão de vídeo (VMH) 226 que os combina em um único sinal de vídeo de saída 228 que é recebido pelo dispositivo de tela 168.

Cada placa de vídeo 218, 220 inclui geralmente uma ou mais GPUs configuradas para executar várias funções de renderização em resposta às instruções (comandos) rece- bidas via um barramento de sistema. Em algumas modalidades, as funções de renderização correspondem às várias etapas em um canal de processamento gráfico pelo qual os dados de geometria que descrevem uma cena são transformados em dados de pixel para exibição no dispositivo de tela 168. Essas funções podem incluir, por exemplo, transformações de iluminação, transformações de coordenadas, conversão de varredura de primitivas geomé- tricas a dados rasterizados, cálculos de sombreamento, renderização de sombra, misturas de texturas, e assim por diante. Numerosas implementações de funções de renderização são conhecidas na técnica e podem ser implementadas pelas GPUs nas placas de vídeo 218, 220. Cada GPU nas placas de vídeo 218, 220 tem uma memória gráfica associada que pode ser implementada usando um ou mais dispositivos de memória de circuito integrado de modelo geralmente convencional. As memórias gráficas podem conter várias subdivisões lógicas ou físicas, tais como armazenadores temporários de tela e armazenadores temporá- rios de comandos. Os armazenadores temporários de tela armazenam os dados de pixel para uma imagem (ou para uma parte de uma imagem) que são lidos e transmitidos ao dis- positivo de tela 168 para exibição. Como descrito acima, esses dados de pixel podem ser gerados a partir de dados de cena gerados pelo aplicativo 150. Em algumas modalidades, os armazenadores temporários de tela podem ser duplamente armazenados tal que enquan- to os dados para uma primeira imagem estão sendo lidos para exibição a partir de um arma- zenador temporário frontal, os dados para a segunda imagem podem ser escritos em um armazenador temporário de fundo sem afetar a imagem que está atualmente exibida. Os armazenadores temporários de comandos nas placas de vídeo 219, 220 são usados para enfileirar comandos para execução pelas respectivas placas de vídeo 218, 220, como des- crito abaixo. Outras partes de memórias gráficas nas placas de vídeo 218, 220 podem ser usadas para armazenar os dados exigidos pelas respectivas GPUs (tal como dados de tex- tura, tabelas de pesquisa de cores, etc.), código de programa executável, e assim por dian- te. Para cada memória gráfica nas placas de vídeo 218, 220, uma interface de memória po- de também ser fornecida para controlar o acesso à respectiva memória gráfica. As interfa- ces de memória podem ser integradas com as respectivas GPUs ou memórias, ou interfaces de memória podem ser implementadas como dispositivos de circuito integrado separados. Em uma implementação conhecida, todas as solicitações de acesso à memória que se ori- ginam da GPU, são enviadas à interface de memória. Se o endereço alvo da solicitação cor- responde a uma localização na memória da GPU, a interface de memória pode acessar a localização apropriada.

Um sincronizador 232 garante que as múltiplas placas de vídeo estão sincronizadas para gerar os dados de vídeo para a mesma saída de vídeo ao mesmo tempo. Existem múl- tiplos métodos conhecidos pelos versados na técnica para alcançar esse tipo de sincroniza- ção, mas uma discussão detalhada destes está além do escopo desta patente. A título de exemplo, uma forma de alcançar a sincronização é usar um mecanismo genlock (curto para travar gerador). Um mecanismo genlock geralmente sincroniza múltiplos dispositivos para um sinal de tempo específico. Outro método para alcançar a sincronização entre as múlti- plas placas de vídeo é atribuir um dispositivo de regulação de tempo a uma das placas de vídeo como um dispositivo de regulação de tempo mestre e modificar o circuito nas outras placas tal que os dispositivos de regulação de tempo nessas placas atuem como escravos dos dispositivos de regulação de tempo mestres. Os dispositivos de regulação de tempo geralmente utilizam cristais programáveis, cristais piezoelétricos, osciladores ou osciladores programáveis como fontes de referência de tempo. Usando esse método, as placas escra- vas seriam periodicamente reinicializadas pelo cristal mestre tal que seu intervalo de tempo seria substancialmente sincronizado durante a operação do sistema.

A FIG. 4 mostra uma representação esquemática que detalha a operação do VMH 226. Os principais componentes do VMH 226 são um comutador de vídeo 322, um controla- dor de comutador de vídeo 320, um microcontrolador 316, e uma saída de vídeo 330. Tipi- camente, cada sinal de vídeo recebido pelo VMH 226 é composto de um componente de dados de vídeo 308, 310 e um componente de sincronização 312, 314. O componente de dados de vídeo 308, 310 é compreendido valores de vermelho, verde e azul ("RGB") (ou alguma outra representação de cores de pixel) para o pixel que está sendo desenhado em um tempo particular. O componente de sincronização 312, 314 é compreendido de sinais de sincronização vertical e horizontal (Vsinc e Hsinc) que determinam a posição horizontal e verti- cal (isto é, as coordenadas) do pixel que está sendo desenhado em um tempo particular. Devido às saídas das placas de vídeo serem sincronizadas (como descrito acima), os com- ponentes de sincronização 312, 314 dos vários sinais de vídeo 222, 224 são substancial- mente idênticos o tempo todo.

À medida que os sinais de vídeo 222, 224 chegam ao VMH 226, seus componentes de dados de vídeo 308, 310 são guiados ao comutador de vídeo 322. O comutador de vídeo 322 é, por sua vez, controlado pelo controlador de comutador de vídeo 320 que recebe os componentes de sincronização 312, 314. Durante cada ciclo de restauração de tela, o comu- tador de vídeo 322 guia inteligentemente e seqüencialmente o componente de dados de vídeo dos vários sinais de vídeo 222, 224 de tal forma que um único sinal de vídeo combi- nado contínuo 228 é então transferido da saída de vídeo 330 do VMH 226 ao dispositivo de tela 168 junto com os componentes de sincronização 312, 314 que essencialmente "passam através" do controlador de comutador de vídeo 320.

Como determinado acima, o comutador de vídeo faz ciclos através de suas múlti- plas entradas seqüencialmente, produzindo uma única saída contínua. O tempo da comuta- ção de um sinal de vídeo ao próximo é crucial e deve ser feito precisamente no momento correto para fazer com que o sinal de vídeo combinado 228 pareça contínuo. Em um siste- ma de duas placas de vídeo, tal como o usado anteriormente como um exemplo na FIG. 2, no início do ciclo de restauração de tela, os componentes de dados de vídeo da placa de vídeo 218 atribuída para desenhar a metade superior da tela 256 são guiados à saída de vídeo 330 do VMH 226 pelo comutador de vídeo. Então, exatamente no ponto onde a meta- de inferior da tela começa a ser desenhada pela segunda placa de vídeo 220, o comutador de vídeo 322 é ativado, ou "disparado", e a saída de vídeo 330 então começa a receber os componentes de dados de vídeo a partir da placa de vídeo 220 atribuída para desenhar a metade inferior da tela 258. À medida que a metade inferior da tela é completada, o ciclo de restauração de tela inicia-se novamente, o comutador de vídeo 322 é novamente disparado, e a saída de vídeo 330 começa novamente a receber os dados de vídeo a partir da placa de vídeo responsável pela "parte superior" 218. Esse ciclo é continuamente repetido para al- cançar um sinal de vídeo combinado contínuo 228.

O comutador de vídeo 322 é controlado pelo controlador de comutador de vídeo

320 que determina qual deveria ser a duração de um intervalo de tempo entre os "dispara- dores" do comutador de vídeo. O controlador 320 determina o intervalo de disparo usando três elementos de dados. O primeiro elemento de dados é a taxa de restauração vertical na qual as placas de vídeo estão operando. A taxa de restauração vertical é expressa em Hertz (Hz) ou ciclos por segundo. Por exemplo, uma placa de vídeo que opera em uma taxa de restauração vertical de 50 Hz redesenha a tela inteira 50 vezes a cada segundo. Colocando de forma diferente, uma placa de vídeo que opera em 50 Hz desenha uma tela completa em milisegundos. O controlador de comutador de vídeo 320 calcula dinamicamente a taxa de restauração vertical da parte Vsinc do componente de sincronização 312, 314 que ele recebe a partir dos múltiplos sinais de placa de vídeo 222, 224.

O segundo elemento de dados é a resolução vertical. Uma forma de determinar a resolução vertical é contar o número de pulsos de sincronização horizontal por quadro (a duração do quadro é calculada com base na taxa de restauração). Por exemplo, uma placa de vídeo que opera em uma resolução vertical de 1600 χ 1200 tem uma resolução vertical de 1200 linhas de varredura. Isso significa que em cada quadro existem 1200 linhas de var- redura de dados de vídeo.

O terceiro elemento de dados usado pelo controlador do comutador de vídeo 320 é a porcentagem da tela que é atribuída a cada placa de vídeo 218, 220. Em certas situações, pode ser desejável dividir igualmente a tela entre as placas de vídeo. Em outras situações, tal como quando uma placa de vídeo é mais poderosa que as outras, pode ser desejável atribuir uma proporção maior à tela para uma ou mais placas de vídeo. Esse elemento, chamado "relação de equilíbrio de carga", é atribuído através de software e, opcionalmente, através da entrada de usuário, e é obtido pelo microcontrolador 316 a partir do barramento de dados do computador 110. A relação de equilíbrio de carga é, por sua vez, obtida pelo controlador do comutador de vídeo 320 a partir do microcontrolador do VMH 316.

Os versados na técnica reconhecerão que usando um simples programa de laço de retomo de teste que ajusta dinamicamente a relação de equilíbrio de carga com base na carga de cada uma das placas de vídeo, em uma base quadro a quadro ou dinâmica, pode maximizar o rendimento das GPUs combinadas. Tipicamente, o programa de laço de retorno de teste interage entre o módulo de GCR 204 que divide as atribuições de processamento gráfico em fluxos de comando de API separados 207, 209 e o VMH 226 que combina os sinais de vídeo processados resultantes 222, 224 a partir das placas de vídeo 218, 220. Es- pecificamente, o programa de laço de retorno pode monitorar a capacidade de processa- mento relativa de cada uma das placas de vídeo e redimensiona dinamicamente a parte de tela atribuída a cada uma das placas de vídeo o necessário para maximizar o rendimento de processamento de vídeo total.

Uma vez que a taxa de restauração vertical, a resolução vertical e a relação de e-

quilíbrio de carga são conhecidas pelo controlador de comutador de vídeo 320, ele pode facilmente calcular os intervalos de disparo a serem usados para gerar o sinal de vídeo combinado 228. A título de ilustração, em um sistema de duas placas de vídeo que opera em 50 Hz (isto é, 20 milisegundos para desenhar uma tela inteira) com uma resolução verti- cal de 1200 e na qual as placas de vídeo atribuídas para desenhar as metades superior e inferior da tela foram respectivamente alocadas em uma relação de equilíbrio de carga de 25% e 75%, a seqüência de comutação seria a seguinte: (1) no início do ciclo de restaura- ção de tela, o comutador de vídeo 322 direcionaria os componentes de dados de vídeo 308 a partir da placa de vídeo responsável pela parte superior 218 à saída de vídeo 330 do VMH 226; (2) após as 300 linhas de varredura (25% da 1200 linhas de varredura), o comutador seria disparado pelo controlador 320 e começaria a direcionar os componentes de dados de vídeo 310 a partir da placa de vídeo responsável pela parte inferior 220 à saída de vídeo 330 do VMH 226; (3) após 900 linhas de varredura adicionais (75% de 1200 linhas de varre- dura), o comutador de vídeo 322 seria disparado para sua posição original para iniciar um novo ciclo de restauração de tela. Para evitar a introdução de quaisquer objetos na imagem final, todos os comutadores entre as várias placas de vídeo são determinados para ocorrer durante o período de supressão horizontal dos sinais de vídeo.

Assim, pode-se ver que as modalidades da presente invenção fornecem múltiplas GPUs em uma única placa de vídeo ou múltiplas placas de vídeo 218, 220 operando ao mesmo tempo para compartilhar as responsabilidades de processamento de vídeo e des- crevem especificamente a divisão de uma área de tela 250 em duas ou mais áreas discretas 256, 258 com uma das placas de vídeo 218, 220 que é dedicada ao processamento para cada uma das áreas discretas 256, 258, tal como um número de linhas de uma tela baseada em varredura. A imagem é exibida lendo-se os dados de pixel de um armazenador temporá- rio de tela para cada GPU ou placa de vídeo em uma seqüência apropriada. Para preservar a consistência interna da imagem exibida ("coerência de quadro"), cada GPU é impedida de renderizar um quadro subseqüente até que outra GPU também tenha finalizado o quadro atual, tal que ambas as partes da imagem exibida sejam atualizadas no mesmo passo de varredura.

Enquanto a discussão acima da presente invenção descreve a área de tela que es-

tá sendo dividida em duas áreas separadas 256, 258, dever-se-ia apreciar que a área de tela 250 pode ser dividida usando as diferentes técnicas e as duas ou mais placas de vídeo 218, 220 operam ao mesmo tempo para compartilhar as responsabilidades de processa- mento de vídeo manipulando diferentes áreas. Por exemplo, a área de tela 250 pode ser dividida em quatro áreas, com cada uma das placas de vídeo 218, 220 manipulando duas seções separadas, ou com uma das placas de vídeo 218, 220 manipulando três das quatro áreas de tela necessárias para o equilíbrio de carga. Igualmente, é possível, emparelhar as placas de vídeo 218, 220 tendo cada uma manipulando, respectivamente, linhas de tela pa- res e ímpares, tal como usadas em uma tela entrelaçada onde a imagem projetada se alter- na rapidamente entre as linhas pares e as linhas ímpares de cada imagem. Por exemplo, em transmissão de televisão padrão por ar, somente a metade das linhas de cada quadro é transmitida, o que é conhecido como um campo, com um campo (campo ímpar) contendo somente as linhas ímpares e o próximo (o campo par) contendo somente as linhas pares.

Nas modalidades descritas acima da presente invenção, pode-se ver que o VMH 226 recebe e combina a saída de sinal de vídeo simultânea 222, 224 a partir de múltiplas GPUs ou placas de vídeo 218, 220 e organiza os dados de vídeo disjuntos 308, 310 em uma saída de vídeo coerente 330 que usa os dados sincronizados 312, 314 para controlar a ope- ração do comutador 322 que aceita seletivamente os dados de vídeo 308, 310 para derivar a saída de vídeo 330. Referindo-se agora à FIG. 5, em uma modalidade alternativa da pre- sente invenção, o VMH 226 compreende adicionalmente um armazenador temporário de vídeo 340 que recebe e armazena os dados de vídeo disjuntos 308, 310. Especificamente, o armazenador temporário de vídeo 340 armazena os dados de vídeo não ordenados 308, 310 à medida que recebidos a partir de placas de vídeo 218, 220. Um aplicativo de acesso ao armazenador temporário 342 então acessa seletivamente o armazenador temporário de memória de vídeo, de acordo com os dados sincronizados 312, 314 à medida que necessá- rio para formar a saída de vídeo coerente 330. Especificamente, durante cada ciclo de res- tauração de tela, o aplicativo de acesso ao armazenador temporário 342 acessa inteligen- temente o armazenador temporário de vídeo 340 que contém o componente de dados de vídeo 308, 310, tal que um único sinal de vídeo combinado contínuo 228 seja então transfe- rido a partir da saída de vídeo 330 do VMH 226 ao dispositivo de tela 168 junto com os componentes de sincronização 312, 314 que essencialmente "passam através" do aplicativo de acesso ao armazenador temporário 342.

Alternativamente, o armazenador temporário de vídeo 340 pode armazenar o com- ponente de dados de vídeo 308, 310 de acordo com os dados sincronizados 312, 314 de uma forma ordenada, tal que durante cada ciclo de restauração de tela, o aplicativo de a- cesso ao armazenador temporário 342 possa já acessar meramente o componente de da- dos de vídeo ordenado 308, 310 à medida que necessário para formar a saída de vídeo composto 330 que combina as várias regiões de tela processadas por cada uma das placas de vídeo 318, 220. Dever-se-ia apreciar que os outros métodos para organizar os dados de vídeo em uma tela podem ser usados na presente invenção, onde cada uma das placas de vídeo 218, 220 é responsável por partes separadas do fluxo de dados de vídeo ao invés de uma parte separada da área de tela 250. Por exemplo, as duas placas de vídeo 218, 220 podem coo- perar para fornecer os dados de vídeo a uma tela de forma alternada, com a primeira placa de vídeo 218 controlando a tela por um certo período de tempo e tendo a segunda placa de vídeo 220 assumindo seqüencialmente as responsabilidades de processamento de vídeo no final desse período. Essa configuração fornece vantagens pelo fato de que uma placa de vídeo 218 pode fornecer os dados de vídeo processados enquanto a segunda placa de ví- deo 220 está completando seu processamento dos próximos dados de vídeo para o próximo período de tempo.

Com relação à FIG. 6, o processamento de um sinal de vídeo por múltiplas GPUs ou placas de vídeo através da divisão de tempo é descrito em mais detalhes. A FIG. 6 é um diagrama de bloco que ilustra um subsistema gráfico configurado de acordo com a presente invenção e sua interação com software de computador pessoal típico para gerar uma ima- gem usando múltiplas placas de vídeo ou múltiplas GPUs localizadas em uma única placa. Para propósitos ilustrativos somente, a FIG. 6 ilustra um sistema equipado com duas placas de vídeo 418, 420, cada uma tendo uma única GPU. Entretanto, os versados na técnica en- tenderiam que as placas de vídeo adicionais tendo múltiplas GPUs independentes podem ser adicionadas ao sistema, aumentando, desse modo, sua eficácia. Igualmente, a eficácia adicional pode ser alcançada incorporando-se múltiplas placas de vídeo, cada uma tendo mais de uma GPU e/ou incluindo-se uma mistura de placas de vídeo, algumas tendo uma única GPU e algumas tendo múltiplas GPUs.

Na presente invenção, o módulo gráfico 404 é um programa de software que reside entre o aplicativo de computador e múltiplas ocorrências dos módulos de API 403, 405. O GCR identifica e intercepta comandos de API 402 emitidos por um aplicativo 400. Uma vez interceptados, o módulo de GCR 404 gera múltiplos fluxos de comando de API modificados 406, 408, geralmente operando algum tipo de comutador de sinal que seletivamente direcio- na os comandos de API 402 entre os módulos de API 403, 405 de acordo com vários crité- rios, tais como uma estampa de tempo associada com os comandos de API 402. Os fluxos de comando de API modificados 406, 408, cada um representando partes discretas dos co- mandos de API 402, são recebidos pelas ocorrências de módulo de API 403, 405 que, por sua vez, geram, respectivamente, fluxos de comando 407, 409, que são recebidos e proces- sados por seu respectivo acionador de placa de vídeo atribuído 410, 414. O número de flu- xos de comando de API modificados 406, 408 e os módulos de API 403, 405, nesse caso dois (2), é geralmente igual ao número de placas de vídeo ou GPUs sendo empregadas no sistema. Os fluxos de comando 406, 408 são gerados de tal forma que cada placa de vídeo 418, 420 gera os pixels que estão contidos dentro da tela de exibição durante períodos de tempo atribuídos a essa respectiva placa de vídeo. A divisão de tempo de um fluxo de co- mando de API 402 em múltiplos fluxos de comando separados pode ser executada através de uma variedade de técnicas bem conhecidas, uma discussão detalhada das quais está além do escopo desta patente.

Como sugerido acima, o módulo gráfico 404 pode dinamicamente alocar os vários fluxos de comando, tal que cada placa de vídeo recebe comandos de vídeo pertencentes somente à faixas de tempo particulares da tela. Em termos simples, cada placa de vídeo 418, 420 recebe o fluxo de comando inteiro necessário para pintar a imagem inteira durante períodos de tempo discretos. Por exemplo, em um sistema de duas placas de vídeo com cada placa sendo responsável por cinqüenta por cento dos períodos de tempo discretos, tal como períodos de tempo pares e ímpares, o módulo gráfico 404 receberia, interpretaria e processaria os comandos de API 402 a partir do aplicativo de computador 400 e emitiria dois conjuntos de fluxos de comando de API modificados 406, 408. A placa de vídeo responsável pelo "período ímpar" receberia os comandos exigidos para desenhar somente aqueles pixels relevantes para os períodos ímpares (períodos 1, 3, 5, etc.) da tela de exibição de vídeo. A placa de vídeo responsável pelo "período par" receberia os comandos exigidos para dese- nhar somente aqueles pixels relevantes aos períodos pares (períodos 2, 4, 6, etc.) da tela de exibição de vídeo. Os versados na técnica entenderão que os diferentes períodos de tempo da tela de exibição atribuídos a cada placa de vídeo não necessitam ser iguais em tamanho, nem precisa ser atribuído um período de tempo contínuo da tela de vídeo a cada placa de vídeo.

Cada um dos fluxos de comando 407, 409 é então processado por seu acionador de placa de vídeo atribuído 410, 414, que, por sua vez, emite comandos da GPU 414, 416 a uma respectiva placa de vídeo 418, 420. Cada placa de vídeo 418, 420, por sua vez, gera um sinal de vídeo 422, 424 correspondendo a seus respectivos períodos de tempo para ge- renciar a saída da tela de exibição de vídeo 168.

Um sincronizador 434 assegura que as múltiplas placas de vídeo 418, 420 são co- ordenadas para gerar dados de vídeo que integram para formar uma tela visual 168 que apresenta continuamente os dados de vídeo a partir de diferentes períodos de tempo. Há múltiplos métodos conhecidos pelos versados na técnica para alcançar esse tipo de sincro- nização, mas uma discussão detalhada dos quais está além do escopo desta patente. A título de exemplo, uma forma de alcançar a sincronização é usando um mecanismo genlock (curto para travar gerador). Um mecanismo genlock geralmente sincroniza múltiplos disposi- tivos em um sinal de tempo específico. Outro método de alcançar a sincronização entre as múltiplas placas de vídeo é designar o dispositivo de regulação de tempo em uma das pla- cas de vídeo como um dispositivo de regulação de tempo mestre e modificar o circuito nas outras placas tal que os dispositivos de regulação de tempo nessas placas atuem como es- cravos dos dispositivos de regulação de tempo mestres. Os dispositivos de regulação de tempo geralmente utilizam cristais programáveis, cristais piezoelétricos, osciladores ou osci- Iadores programáveis como fontes de referência de tempo. Usando esse método, cristais de tempo em placas escravas seriam periodicamente reinicializados pelo cristal mestre tal que seu intervalo de tempo seria substancialmente sincronizado durante a operação do sistema. Dessa forma, uma das placas de vídeo pode produzir um sinal de sincronização que dire- ciona a operação das placas de vídeo restantes, tal que quaisquer irregularidades no tempo são rapidamente compensadas em cálculos subseqüentes. Os múltiplos sinais de vídeo 444, 444 gerados pelas varias placas de vídeo são en-

viados a uma boca de conexão de fusão de vídeo (VMH) 426 que os combina em um único sinal de vídeo de saída 428 que é recebido pela tela de exibição 168.

A FIG. 7 mostra uma representação esquemática detalhando a operação do VMH 426 em uma modalidade da presente invenção. Os componentes principais do VMH 426 são um comutador de vídeo 522, um controlador de comutador de vídeo 520, e uma saída de vídeo 530. Tipicamente, cada sinal de vídeo recebido pelo VMH 226 é composto de um componente de dados de vídeo 508, 510 e um componente de sincronização 512, 514. O componente de dados de vídeo 508, 510 é compreendido valores de vermelho, verde e azul ("RGB") (ou alguma outra representação de cores de pixel) para o pixel que está sendo de- senhado em um tempo particular. O componente de sincronização 512, 514 é compreendido de sinais de sincronização de tempo (Tsinc) que determinam os tempos particulares dos pi- xels associados aos componentes de dados de video 508, 510.

À medida que os sinais de vídeo 422, 424 chegam ao VMH 426, seus componentes de dados de vídeo 508, 510 são guiados ao comutador de vídeo 522. O comutador de vídeo 522 é, por sua vez, controlado pelo controlador de comutador de vídeo 520 que recebe os componentes de sincronização 512, 514. O comutador de vídeo 522 guia inteligentemente e seqüencialmente o componente de dados de vídeo dos vários sinais de vídeo 422, 424 de tal forma que um único sinal de vídeo combinado contínuo 428 é então transferido da saída de vídeo 530 do VMH 426 ao dispositivo de tela 168 junto com os componentes de sincroni- zação 512, 514 que essencialmente "passam através" do controlador de comutador de vídeo 520.

Como determinado acima, o comutador de vídeo 522 faz ciclos através de suas múltiplas entradas seqüencialmente, produzindo uma única saída contínua. O tempo da co- mutação de um sinal de vídeo ao próximo como o momento correto faz o sinal de vídeo combinado 428 parecer contínuo, isto é, a tela 168 não recebe diferentes instruções ao mesmo tempo, e não há pausa entre o fim de um fluxo de dados de vídeo e o início do pró- ximo fluxo de dados. Em um sistema de duas placas de vídeo, tal como o usado anterior- mente como um exemplo na FIG. 6, os componentes de dados de vídeo da placa de vídeo 418 atribuída para desenhar a tela durante um certo período de tempo são guiados à saída de vídeo 530 do VMH 426 pelo comutador de vídeo 422 durante o período de tempo apro- priado como indicado pelos dados de sincronização. Então, no ponto onde o período de tempo para a primeira placa de vídeo 418 termina e o período de tempo em que a segunda placa de vídeo 420 inicia, o comutador vídeo 522 é ativado, e a saída de vídeo 530 então começa a receber os componentes de dados de vídeo a partir da outra placa de vídeo 420. À medida que o período de tempo para a segunda placa de vídeo 420 é completado, o ciclo inicia-se novamente, o comutador de vídeo 522 opera novamente tal que a saída de vídeo 530 recebe agora os dados de vídeo a partir da placa de vídeo do primeiro período 418. Es- se ciclo é continuamente repetido para alcançar um sinal de vídeo combinado contínuo 428.

O comutador de vídeo 522 é controlado pelo controlador de comutador de vídeo 520 que determina qual deveria ser um intervalo entre os disparadores de comutador de vídeo. O controlador 520 determina o intervalo de disparo usando o componente de sincro- nização 512, 514 recebido dentro dos múltiplos sinais de placa de vídeo 422, 424. O ele- mento primário de dados usado pelo controlador de comutador de vídeo 520 é a duração dos períodos de tempo para cada placa de vídeo 418, 420. Em certas situações pode ser desejável dividir igualmente os períodos de tempo entre as placas de vídeo. Em outras situ- ações, tal como quando uma placa de vídeo é mais poderosa do que outra(s) ou possui uma conexão de largura de banda relativamente maior, pode ser desejável atribuir um período de tempo maior a uma das placas de vídeo. Essa relação de equilíbrio de carga é atribuída a- través de software e, opcionalmente, através da entrada de usuário, e é obtida por um mi- crocontrolador 516 a partir do barramento de dados do computador 110. Essa relação de equilíbrio de carga é, por sua vez, obtida pelo controlador do comutador de vídeo 520 a par- tir do microcontrolador 516.

Os versados na técnica reconhecerão que usando um simples programa de laço de retorno de teste que ajusta dinamicamente a relação de equilíbrio de carga com base na carga de cada uma das placas de vídeo, em uma base quadro a quadro ou dinâmica, pode maximizar o rendimento das GPUs combinadas. Tipicamente, o programa de laço de retorno de teste interage entre o módulo de GCR 404 que divide as atribuições de processamento gráfico em fluxos de comando de API separados 407, 409 e o VMH 426 que combina os sinais de vídeo processados resultantes 422, 424 a partir das placas de vídeo 418, 420. Es- pecificamente, o programa de laço de retorno pode monitorar a capacidade de processa- mento relativa de cada uma das placas de vídeo 418, 420 e redimensionar dinamicamente o comprimento dos períodos de tempo atribuídos a cada uma das placas de vídeo 418, 420 o necessário para maximizar o rendimento de processamento de vídeo total minimizando a ociosidade das placas de vídeo 418, 420. Assim, pode-se ver que as modalidades da presente invenção fornecem múltiplas GPUs em uma única placa de vídeo ou múltiplas placas de vídeo 418, 420 operando ao mesmo tempo para compartilhar as responsabilidades de processamento de vídeo e des- crevem especificamente a divisão de período de tempo da área de tela 450 em dois ou mais períodos de tempo discretos, onde cada uma das placas de vídeo 418, 420 é especifica- mente dedicada ao processamento de períodos de tempo separados. A imagem é exibida lendo-se os dados de pixel de um armazenador temporário de tela para cada GPU ou placa de vídeo em uma seqüência apropriada. Para preservar a consistência interna da imagem exibida, cada GPU é impedida de renderizar uma tela subseqüente até que outra GPU tenha finalizado a exibição atual.

É possível emparelhar as placas de vídeo 418, 420 tendo cada uma manipulando, respectivamente, linhas de tela pares e ímpares, tal como usadas em uma tela entrelaçada onde a imagem projetada se alterna rapidamente entre as linhas pares e as linhas ímpares de cada imagem. Por exemplo, em transmissão de televisão padrão por ar, somente a me- tade das linhas de cada quadro é transmitida, o que é conhecido como um campo, com um campo (campo ímpar) contendo somente as linhas ímpares e o próximo (o campo par) con- tendo somente as linhas pares.

Com relação agora à FIG. 8, em uma modalidade alternativa da presente invenção, o VMH 426 adicionalmente compreende um armazenador temporário de vídeo 540 que re- cebe e armazena os dados de vídeo disjuntos 508, 510. O armazenador temporário de ví- deo 540 armazena os dados de vídeo não ordenados 508, 510 à medida que recebidos a partir de placas de vídeo 418, 420. Um aplicativo de acesso ao armazenador temporário 542 então acessa seletivamente o armazenador temporário de memória de vídeo, de acordo com os dados sincronizados 512, 514 à medida que necessário para formar a saída de ví- deo 530 durante os períodos de tempo associados com cada uma das placas de vídeo 418, 420. Por exemplo, dever-se-ia apreciar que cada uma das placas de vídeo 418, 420 está ao mesmo tempo transmitindo continuamente os dados de vídeo processados para diferentes períodos de tempo. O armazenador temporário 540 pode armazenar esses dados, se rece- bidos, em uma condição desorganizada, com esses dados sendo seletivamente acessados de acordo com os dados de sincronização 512, 514 à medida que necessário para produzir um fluxo de dados de vídeo ordenado. Especificamente, durante cada um dos períodos atri- buídos, o aplicativo de acesso ao armazenador temporário 542 acessa inteligentemente o armazenador temporário de vídeo 540 que contém o componente de dados de vídeo 508, 510 a partir dos vários sinais de vídeo 422, 424 de tal maneira que um único sinal de vídeo combinado contínuo 428 é então transferido a partir da saída de vídeo 530 do VMH 426 ao dispositivo de tela 168.

Alternativamente, o armazenador temporário de vídeo 540 pode armazenar o com- ponente de dados de vídeo 508, 510 de uma forma ordenada usando os dados sincroniza- dos 512, 514, tal que o aplicativo de acesso ao armazenador temporário 542 pode já aces- sar meramente o componente de dados de vídeo ordenado 508, 510 sem processamento adicional, se necessário, para formar saídas de vídeo seqüenciais 530 que combinam os vários períodos de tempo processados por cada uma das placas de vídeo 518, 520.

Consequentemente entende-se que a modalidade preferencial da presente inven- ção foi descrita a título de exemplo e que outras modificações e alterações podem ocorrer aos versados na técnica em abandonar o escopo e espírito das reivindicações em anexo.

Claims (17)

1. Sistema de processamento gráfico acelerado, CARACTERIZADO pelo fato de que compreende: um módulo de interface de programação de aplicativos (API) gráfica recebendo co- mandos a partir de um aplicativo de computador, em que o dito módulo de API gráfica divide os ditos comandos em uma pluralidade de comandos de API compreendendo primeiros co- mandos de API relacionados a um primeiro período de tempo, e segundos comandos de API relacionados a um segundo período de tempo; uma pluralidade de unidades de processamento gráfico (GPUs) adaptadas para re- ceber os ditos primeiros e segundos comandos de API a partir do módulo de API gráfica, em que a pluralidade de GPUs compreende uma primeira GPU e uma segunda GPU, em que a primeira GPU recebe os primeiros comandos de API e a segunda GPU recebe os segundos comandos de API1 em que a primeira GPU processa os primeiros comandos de API para produzir um primeiro sinal de vídeo compreendendo primeiros dados de vídeo relacionados ao primeiro período de tempo e primeiros dados de sincronização associando os ditos pri- meiros dados de vídeo ao dito primeiro período de tempo, e em que a segunda GPU pro- cessa os segundos comandos de API para produzir um segundo sinal de vídeo compreen- dendo segundos dados de vídeo relacionados ao segundo período de tempo e segundos dados de sincronização associando os ditos segundos dados de vídeo ao dito segundo pe- ríodo de tempo; e uma boca de conexão de fusão de vídeo para receber os ditos primeiros e segun- dos sinais de vídeo a partir da dita pluralidade de GPUs, em que a dita boca de conexão de fusão de vídeo analisa os ditos primeiros e segundos dados de sincronização e encaminha a um dispositivo de tela os ditos primeiros dados de vídeo durante o dito primeiro período de tempo e os ditos segundos dados de vídeo durante o dito segundo período de tempo.

2. Sistema de processamento gráfico acelerado, de acordo com a reivindicação1, CARACTERIZADO pelo fato de que a dita primeira GPU está localizada em uma primeira placa de vídeo e a dita segunda GPU está localizada em uma segunda placa de vídeo, em que as ditas primeira e segunda placas de vídeo estão acopladas a um computador.

3. Sistema de processamento gráfico acelerado, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a dita boca de conexão de fusão de vídeo compreende um comutador de vídeo, um controlador de comutador de vídeo, um microcontrolador, e uma saída de vídeo.

4. Sistema de processamento gráfico acelerado, de acordo com a reivindicação 3, CARACTERIZADO pelo fato de que o dito comutador de vídeo recebe os ditos primeiros dados de vídeo e os ditos segundos dados de vídeo a partir da dita pluralidade de GPUs e seqüencialmente direciona os ditos primeiros dados de vídeo e os ditos segundos dados de vídeo à dita saída de vídeo.

5. Sistema de processamento gráfico acelerado, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de que o dito comutador de vídeo é controlado pelo dito con- trolador de comutador de vídeo, e em que o dito controlador de comutador de vídeo controla o dito comutador de vídeo disparando comutadores de roteamento em intervalos apropria- dos correspondentes aos ditos primeiro e segundo períodos de tempo.

6. Sistema de processamento gráfico acelerado, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que os ditos primeiro e segundo períodos de tempo são definidos por uma relação de equilíbrio de carga, em que a dita relação de equilíbrio de car- ga é dinamicamente ajustada por um programa de laço de retorno de teste que mede uma carga de processamento em cada uma das ditas GPUs.

7. Método para equilibrar cargas para uma pluralidade de processadores gráficos configurados para operar em paralelo, CARACTERIZADO pelo fato de que compreende: fornecer uma área de tela compreendendo uma seqüência de quadros compreendendo N quadros, os N quadros compreendendo K quadros a serem renderizados por um primeiro processador da pluralidade de processadores gráficos e os N-K quadros restantes a serem renderizados por um segundo processador da pluralidade de processadores gráficos, em que uma relação de K/(N-K) é uma relação de equilíbrio de carga dos primeiro e segundo processadores gráficos; instruir a pluralidade de processadores gráficos a renderizar os qua- dros, em que os primeiro e segundo processadores gráficos executam renderização, respec- tivamente, dos K quadros e dos N-K quadros; receber dados de retorno para os quadros a partir dos primeiro e segundo processadores gráficos, os dados de retorno refletindo respec- tivos tempos de renderização para os primeiro e segundo processadores gráficos; determi- nar, com base nos dados de retorno, se existe um desequilíbrio entre respectivas cargas dos primeiro e segundo processadores gráficos; e no caso de existir um desequilíbrio: identi- ficar, com base nos dados de retorno, qual dos primeiro e segundo processadores gráficos está mais fortemente carregado, e diminuir um número de quadros que é renderizado pelo processador mais fortemente carregado dentre os primeiro e segundo processadores gráfi- cos selecionando um novo valor para K para ajustar a relação de equilíbrio de carga.

8. Método, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que a etapa de diminuir um número de quadros que é renderizado pelo processador mais forte- mente carregado dentre os primeiro e segundo processadores gráficos adicionalmente inclui selecionar um novo valor para N para ajustar a relação de equilíbrio de carga.

9. Método, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que a etapa de receber os dados de retorno inclui receber os dados de retorno para cada um de uma pluralidade de quadros.

10. Método, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que compreende adicionalmente: gerar um fluxo de comando para cada um dos primeiro e se- gundo processadores gráficos, o fluxo de comando incluindo um conjunto de comandos de renderização para os quadros; e inserir um comando notificador de escrita em um fluxo de comando para cada um dos primeiro e segundo processadores gráficos seguindo o conjunto de comandos de renderização, em que cada um dos primeiro e segundo processadores grá- ficos responde ao comando notificador de escrita transmitindo os dados de retorno a uma localização de armazenamento.

11. Método, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que cada um dos N quadros é alternativamente renderizado por cada um dos primeiro e segun- do processadores gráficos.

12. Sistema de processamento gráfico, CARACTERIZADO pelo fato de que com- preende: um módulo acionador gráfico; e uma pluralidade de processadores gráficos confi- gurados para operar em paralelo para renderizar respectivos conjuntos de quadros em uma seqüência de quadros e para fornecer dados de retorno ao módulo acionador gráfico, o mó- dulo acionador gráfico sendo adicionalmente configurado para detectar, com base nos da- dos de retomo, um desequilíbrio entre respectivas cargas de dois da pluralidade de proces- sadores gráficos e, em resposta à detecção de um desequilíbrio, diminuir o tamanho de um primeiro conjunto de quadros que é renderizado por um processador mais fortemente carre- gado dos dois processadores gráficos e aumentar o tamanho de um segundo conjunto de quadros que é renderizado pelo outro dos dois processadores gráficos.

13. Sistema de processamento gráfico, de acordo com a reivindicação 12, CARACTERIZADO pelo fato de que compreende adicionalmente uma pluralidade de memó- rias gráficas, cada memória gráfica acoplada a um respectivo processador dos processado- res gráficos e armazenando dados de pixel para quadros renderizados pelo processador gráfico acoplado a ela.

14. Sistema de processamento gráfico, de acordo com a reivindicação 12, CARACTERIZADO pelo fato de que o módulo acionador gráfico é adicionalmente configu- rado para gerar um fluxo de comando para a pluralidade de processadores gráficos, o fluxo de comandos incluindo um conjunto de comandos de renderização para quadros e uma ins- trução para cada um dos dois processadores gráficos para transmitir dados de retorno indi- cando que o processador de transmissão executou o conjunto de comandos de renderiza- ção.

15. Sistema de processamento gráfico, de acordo com a reivindicação 12, CARACTERIZADO pelo fato de que os dados de retorno incluem uma indicação de qual dos dois processadores gráficos foi o último a terminar de renderizar o respectivo conjunto de quadros.

16. Sistema de processamento gráfico, de acordo com a reivindicação 15, CARACTERIZADO pelo fato de que os dados de retorno incluem um identificador numérico de um dos dois processadores gráficos que foi o último a terminar, e o módulo acionador gráfico é adicionalmente configurado para computar um coeficiente de carga a partir dos identificadores numéricos por uma pluralidade de quadros.

17. Sistema de processamento gráfico, de acordo com a reivindicação 16, CARACTERIZADO pelo fato de que o módulo acionador gráfico é adicionalmente configu- rado para detectar um desequilíbrio no caso de o coeficiente de carga ser maior do que um limite alto ou menor do que um limite baixo.