BRPI0902504A2 - técnicas de ordenação de threads - Google Patents

Abstract

São descritas técnicas que podem ser usadas para assegurar a computação ordenada e/ou encerramento de tarefas em ambiente com várias threads. Threads podem conter conjuntos de tarefas, cada uma delas com restrições de ordenação relacionadas a outras tarefas que se encontrem em outras threads do sistema. Quando aplicados a gráficos 3D, os domínios de processamento de video e imagens permitem o processamento irrestrito de threads até que sejam atingidas as suas seções críticas. A ordenação pode ser necessária antes da execução de seções críticas e posteriormente.

Description

TÉCNICAS DE ORDENAÇÃO DE THREADS"

Campo

O assunto aqui tratado relaciona-se aadministração da ordem de operações e, mais particularmente,ordenação do processamento em threads.

Técnica correlacionada

Em várias aplicações de computadores, há umparalelismo inerente que é fornecido por uma rotina e a umconjunto de dados aos quais a rotina em questão é aplicada. Oparalelismo pode incluir o processamento de elementos distintos doconjunto de dados pela rotina com minima necessidade de ordenação,de forma que a rotina possa ser aplicada a vários elementos doconjunto de dados ao mesmo tempo, desde que haja recursos decomputação suficientes para tanto. Neste caso, os dados einstruções são reunidos em threads e enviados a um sistema decomputação para processamento. Devido ao paralelismo, váriasthreads podem existir no sistema de computação em um determinadomomento e algumas destas threads podem apresentar processamentoadiantado ou atrasado em relação a outras threads semelhantes nosistema, dependendo de vários fatores de nivel do sistema.Portanto, a conclusão das threads pode não ser feita na ordem emque foram emitidas. Nos casos em que a ordenação seja necessária,podem ser necessárias técnicas que assegurem que requisitos deordenação sejam atendidos; deseja-se também que as técnicas tenhamo menor impacto negativo no desempenho geral.

Por exemplo, o paralelismo está particularmentepresente no processamento gráfico, fazendo com que este apresenteum grande número de processos. Em alguns sistemas de processamentográfico, há uma necessidade de ordenação para que séries de pixelsde uma determinada coordenada XY de local da tela sejam encerradasna ordem em que foram apresentadas pelo aplicativo. Uma série depixels encerrados é aquela em que a computação tenha completada eos pixels estejam disponíveis para exibição. Por exemplo, pixelsencerrados podem ser armazenados èm um "frame buffer". Emalgoritmos tridimensionais de processamento de pixels, devido aovolume de pixels processados simultaneamente e sua interação comos recursos de sistema, o processamento dos pixels pode sercompletado fora de ordem, o que pode fazer que pixels das mesmascoordenadas XY sejam encerrados fora de ordem.

Em alguns casos, um fluxo de locais XY de pixelstem tempo significativo entre qualquer série XY, de forma quequaisquer computações envolvendo escrita nesta XY não esteja maissendo realizada "in flight" antes que as computações envolvendo amesma XY sejam solicitadas. Independente da ordenação natural outipica em um sistema, é necessário um mecanismo para garantir aordenação correta.

Não obstante o contexto, o sistema com divisão emthreads pode usar técnicas para obter a ordenação correta decomputação e/ou saida. No caso geral de computação com divisão dethreads, um sistema de ordenação conhecido obtém a ordenação doprocessamento e/ou saida com o bloqueio da emissão (ou "despacho")de threads a uma unidade computacional até que todos os requisitosde ordenação sejam satisfeitos. Neste caso, um placar é usado paraacompanhar o estados das threads no sistema e lógica é usada paradetectar dependências entre threads. Outro sistema conhecido, emcasos em que apenas a ordenação de saida é necessária, utiliza umbuffer que temporariamente armazenada a saida de threads e nãoencerra a saida até que todas as regras de ordenação sejamsatisfeitas para a thread associada.

BREVE DESCRIÇÃO DOS DESENHOS

Configurações da presente invenção estãoilustradas como exemplo e não como limitação nas ilustrações, enelas, números de referência semelhantes se referem a elementos similares.

A FIG. 1 mostra uma configuração de exemplo desistema de acordo com algumas configurações da presente invenção.

A FIG. 2 mostra um diagrama de blocos de altonivel de um sistema de ordenação com divisão em threads, de acordocom uma configuração da presente invenção.

A FIG. 3 mostra um exemplo de linha do tempo deum ordenador de threads, de acordo com uma configuração dapresente invenção.A FIG. 4 mostra um exemplo de formato de tabelade placar, de acordo com uma configuração da presente invenção.

Á FIG. 5 mostra um exemplo de implementação doplacar (SB - Scoreboard) e a lógica de acúmulo de dependências, deacordo com uma configuração da presente invenção.

A FIG. 6 mostra um exemplo de formato de registroTDR de acordo com uma configuração da presente invenção.

A FIG. 7 mostra um exemplo de formato de célulabásica de dependência em um registro TDR de acordo com umaconfiguração da presente invenção.

A FIG. 8 mostra um exemplo de fluxograma deacordo com uma configuração da presente invenção.

DESCRIÇÃO DETALHADA

As referências, nestas especificações, a "umaconfiguração" tratam de uma determinada função, estrutura oucaracterística descrita em relação à configuração que estejaincluída em pelo menos uma configuração da presente invenção.Portanto, a expressão "em uma configuração" ou "uma configuração"em várias partes destas especificações pode não se referir à mesmaconfiguração. Além disso, as funções, estruturas oucaracterísticas podem estar combinadas em uma ou maisconfigurações.

A FIG. 1 mostra um diagrama de blocos do sistemade computador 100. Algumas configurações da presente invençãopodem ser usadas com o sistema de computador 100. O sistema decomputador 100 pode incluir o sistema host 102, o barramento 116 eo componente de rede 120.

O sistema host 102 pode incluir o chipset 105, oprocessador 110, a memória de host 112, a unidade de armazenamento114 e õ subsistema gráfico 115. O chipset 105 pode fornecerintercomunicação entre o processador 110, a memória do host 112, aunidade de armazenamento 114, o subsistema gráfico 115 e obarramento 116. Por exemplo, o chipset 105 pode incluir umadaptador de armazenamento (não exibido), capaz de - fornecerintercomunicação com a unidade de armazenamento 114. Por exemplo,o adaptador de armazenamento pode ser capaz de se comunicar com aunidade de armazenamento 114 com um destes protocolos: SmallComputer Systems Interface (SCSI), Fibre Channel (FC) e/ou SerialAdvanced Technology Attachment (S-ATA).

Em algumas configurações, o chipset 105 podeincluir lógica de movimentação de dados capaz de executartransferências de informação dentro da memória do host 112 ouentre o componente de rede 120 e a memória do host 112 ou, emgeral, entre qualquer conjunto de componentes no sistema decomputador 100.

O processador 110 pode ser implementado comprocessadores do tipo SISC (Complex Instruction Set Computer) ouRISC (Reduced Instruction Set Computer), com vários núcleos ouqualquer outro microprocessador unidade central de processamento.

A memória do host 112 pode ser implementada comoum dispositivo de memória volátil incluindo, entre outros, ascategorias RAM (Random Access Memory), DRAM (Dynamic Random AccessMemory) ou SRAM (Static RAM).

A unidade de armazenamento 114 pode serimplementada como um dispositivo de armazenamento não volátilincluindo, entre outros, uma unidade de disco magnético, umaunidade de disco óptico, unidade de fita, dispositivo dearmazenamento interno, dispositivo de armazenamento anexado,memória flash, SDRAM (synchronous DRAM) alimentada por bateriae/ou um dispositivo de armazenamento acessível por rede.

O subsistema gráfico 115 pode executar oprocessamento de imagens fixas ou em video para exibição. Osubsistema gráfico 115 pode estar integrado ao processador 110 ouchipset 105. O subsistema gráfico 115 pode ser uma placaindependente acoplada de forma comunicativa ao chipset 105.

Uma aplicação executada pelo processador 110 podesolicitar um compilador para compilação do kernel que, ao serexecutado pelo subsistema gráfico 115, execute a exibição degráficos. Em uma configuração, o compilador introduz uma instrução"sendc" em uma thread e transfere a thread compilada para umsubsistema de computação capaz de lidar com threads, como umsubsistema gráfico 115. Em uma configuração, o subsistema gráfico115 inclui a capacidade de receber threads que especifiquemsubspans a serem processados e exibidos. Um subspan pode ser umaregião de dois pixels por dois pixels associada a coordenadas XY.A instrução "sendc" pode não ser executada até que todos ossubspans precedentes que possuam as mesmas coordenadas ouidentificadores, e que tenham sido enviados para processamento,anterior, tenham sido encerrados anteriormente. Pixels de um mesmosubspan podem ser processados até o ponto de quase encerramento eesperar até que a próxima solicitação de ordenação sejasatisfeita. Desta forma, a maior parte do processamento de umathread pode ser completado anteriormente para assegurar aordenação adequada do encerramento de subspans.

0 barramento 116 pode proporcionarintercomunicação entre, pelo menos, o sistema host 102 e ocomponente de rede 120, assim como outros dispositivos periféricos(não ilustrados). O barramento 116 pode ser compatível comcomunicações em série ou em paralelo. O barramento 116 pode sercompatível com comunicações nó-para-nó ou nó-para-vários nós. Obarramento 116 pode, pelo menos, ser compatível com o padrão PCI(Peripheral Component Interconnect) descrito, por exemplo emPeripheral Component Interconnect (PCI) Local Bus Specification,revisão 3.0, de 2 de fevereiro de 2004, disponível no PCI SpecialInterest Group, Portland, Oregon, Estados Unidos (assim como suasrevisões); a descrição PCI Express descrita na especificação-basedo PCI Special Interest Group, revisão 1.0a (assim como suasrevisões); descrição PCI-x conforme PCI-X Specification Rev. 1.1,de 28 de março 2005, disponível no supradito PCI Special InterestGroup, Portland, Oregon, Estados Unidos (assim como suasrevisões); e/ou USB (Universal Serial Bus) (e padrõesrelacionados), assim como outros padrões de interconexão.

O componente de rede 120 pose ser capaz deoferecer intercomunicação entre o sistema host 102 e a rede 150 deacordo com quaisquer protocolos aplicáveis. O componente de rede120 pode se intercomunicar com o sistema host 102 usando obarramento 116. Em uma configuração, o componente de rede 120 podeestar integrado ao chipset 105. O "componente de rede" podeincluir qualquer combinação de hardware e/ou software, digitale/ou analógico, em um subsistema de E/S (entrada/saida) que possaprocessar uma ou mais unidades de protocolos de rede a seremtransmitidas e/ou recebidas por meio de uma rede. Em umaconfiguração, o subsistema de E/S pode incluir, por exemplo, umaplaca de componente de rede (NIC) e o componente de rede podeincluir, por exemplo, uma camada MAC (media access control) dacamada Data Link Layer, conforme definição do modelo OSI (OpenSystem Intercommunication) para protocolos de rede. 0 modelo OSI édefinido pela International Organization for Standardization(ISO), situada em 1 rue de Varembé, Case postale 56 CH-1211Genebra 20, Suíça.

A FIG. 2 mostra um diagrama de blocos de altonível de um sistema de ordenação de threads 200 de acordo com umaconfiguração da presente invenção. Em uma configuração, o sistemade ordenação de threads 200 inclui um ou mais geradores dethreads, como o gerador de threads 202, o despachador de threads(TD) 204, unidades de execução (EU) 206 e um processador deencerramento de threads 208. Geradores de threads adicionais,similares ao gerador de threads 202 podem ser adicionados aosistema 200. Um exemplo de operação do sistema de ordenação dethreads 200 está descrito em relação à FIG. 3.

Segue a descrição de um exemplo de configuraçãona qual o sistema de ordenação 200 é usado em um pipeline degráficos 3D. O sistema de ordenação de threads 200 permite quevários subspans que cubram as mesmas coordenadas sejam emitidospara o conjunto de unidades de execução, fazendo que os subspanssejam encerrados em ordem. O processamento de tamanhos de pixeldiferentes dos subspans pode ser realizado. A seqüência deinstruções a serem executadas para cada thread inclui um comando"sendc" que faz com que a EU transfira a saída computada da threadprocessada para o processador de encerramento de threads 208. Noentanto, a EU não executa o comando "sendc" até o encerramento detodos os subspans previamente processados com as mesmascoordenadas, se houver, em uma ou mais threads. Em umaconfiguração, um registro de dependência de threads (TDR) (exibidocomo TDR 0-3, para um sistema de quatro threads) para cada uma dasthreads contém informações de uma ou mais dependências, se houver,que devem ser satisfeitas antes que seja permitido à threadassociada executar sua instrução "sendc". Um caso de dependênciapode ser se outra thread fizer com que o processamento dascoordenadas do subspan não tenha sua execução completada, fazendoque o subspan das mesmas coordenadas seja transferido para oprocessador de encerramento de threads 208. Quando não houverdependência para uma thread, é permitido à EU executar o comando"sendc" da thread, quando encontrado. Em resposta a uma instrução"sendc" para a thread, enquanto dependências associadas aindadevam, ser eliminadas para a thread em questão, a EU faz com que athread paralise quaisquer execuções de instruções até que todas asdependências sejam eliminadas, aguardando efetivamente no conjuntode EU, e não no rasterizador ou em outro local.

Em uma configuração, um simples campo de bitidentificando uma seção especialmente importante pode seradicionado a cada dependência mantida no TDR de forma a comportarvárias seções criticas, para que a ordenação adequada doprocessamento de threads e subspans possa ser obtida nas váriasetapas da seqüência de execução de uma thread. Neste caso, athread identificaria qual seção critica ela estava executando, eapenas as dependências no TDR associadas à seção seriam usadaspara determinar se a execução da instrução "sendc" e subsequentesterão permissão para ocorrer.

A FIG. 3 mostra um exemplo de linha do tempo deum ordenador de threads 200, de acordo com uma configuração dapresente invenção. Na região A, o gerador de threads 202, podepreparar uma thread para despacho, alocar um identificador dethreads de função fixa (FFTID) para que a thread identifique ogerador 202, verificar o placar para obter a dependência de cadaunidade de trabalho da thread e, então, emitir uma solicitação dedespacho para o TD 204. Por exemplo, quando o ordenador de threads200 for usado em um pipeline 3D, uma unidade de trabalho poderáincluir um subspan. Em uma configuração, quando o ordenador dethreads 200 for usado em um pipeline 3D, o conteúdo de uma threadpoderá incluir subspans de pixels, tipicamente numerando-os até 8,mas outros números de subspans poderão ser usados.

Para alocar um FFTID para uma thread, o geradorde threads 202 pode selecionar um FFTID de uma lista de FFTIDsdisponíveis, que podem ter sido previamente utilizados, mas nãoestão mais em uso. 0 FFTID é usado a partir de então parareferenciar todo o trabalho contido na nova thread. Um FFTID podeincluir um número associado a uma thread e pode incluir umindicador "válido" que pode indicar que determinada comunicaçãoseja uma informação válida. Por exemplo, um FFTID pode incluir umbit válido e 8 bits do FFTID.

0 agente de ordenação 205 pode executar: (1) areunião das informações de threads dependentes e (2) a eliminaçãodas informações dependentes relacionadas ao encerramento dethreads. Para executar as operações (1) e (2), o placar pode seracessado conforme descrito em relação à FIG. 4. Para assistir nasoperações (1) e (2), a fila de dependência (Dep Q) e o CAM dedependência (Dep CAM) (FIG. 2) podem ser usados.

A fila de dependência pode armazenar informaçõesde dependência associadas a uma unidade de trabalho. Partindo daoperação de busca do placar, as informações de dependência podemser pareadas com uma unidade de trabalho; o par será transmitidoem conjunto. O CAM de dependência pode comparar envios demensagens de threads "eliminadas" com informações de dependênciajá enfileiradas para despacho. Se houver correspondência, adependência será eliminada antes do despacho. O CAM de dependênciapode evitar a condição em que uma dependência seja detectada atempo da pesquisa do placar, mas eliminada antes do despacho real.

O gerador de threads 202 pode incluir acapacidade de despachar sem informações de dependência ou seja,identificadores de outras threads que processem trabalhosemelhante, mas dos quais nenhuma seção critica seja necessária.Por exemplo, o caminho que passa pela fila de threads e fila dedespacho (DispQ) (FIG. 2) possibilita o despacho de threads seminformações de dependência. Além disso a fila de threads poderáconter outras unidades de dados relacionados a trabalho enquanto oplacar estiver sendo pesquisado para a unidade de trabalho emquestão (por ex., subspan). Além disso, a fila de despacho (DispQ)pode ser usada para manusear informações sobre threads (por ex.,subspan) e relacionadas que completarem a pesquisa do placarenquanto esperam sua inclusão em uma thread para despacho para umaunidade de execução.Na região B, o TD 204 pode selecionar uma threadpara despacho. A fila de dependência (DepQ) do TD 204 podearmazenar informações de dependência associadas a threads paradespacho. Em uma configuração, o despachador de threads 204 podedespachar uma thread para a EU 206 se o número de dependências forinferior à capacidade do TDR associado na EU de armazenardependências. Se a capacidade do TDR for excedida, o TD 204 poderáesperar por threads em aberto para eliminar as dependências até omomento em que a capacidade do TDR não estiver mais sendoexcedida.

Digno de nota, o CAM de dependência (Dep CAM) doTD 204 poderá eliminar quaisquer dependências de despachos queestejam ocorrendo ao mesmo tempo que a operação de eliminação queenvolve o despacho de threads. A eliminação de dependências poderáser usada com o barramento Pclr.

O MUX do TD 204 pode ser usado caso haja váriosagentes de ordenação no sistema. Por exemplo, o MUX podeselecionar entre solicitações enfileiradas de geradores de threadsque não sejam do gerador de threads 202 ou solicitaçõesenfileiradas do gerador de threads 202.

Na região C, o TD 204 pode despachar uma threadcom informações de dependência. As informações de dependênciapodem ser enviadas em um cabeçalho de despacho de threads. Em umaconfiguração, o cabeçalho de despacho de threads pode incluir 256bits do cabeçalho de despachos e um campo que identifique o FFTIDde quaisquer threads dependentes da thread sendo despachada. Emuma configuração, até oito dependências podem ser identificadaspor cabeçalho de despacho de threads. Um registro de dependênciade threads (TDR) entre os TDRs 207-0 e 207-3 podem ser alocadospara cada thread na EU 206 e pode ser preenchido com asinformações de dependência do cabeçalho de despacho de threads. AsFIGs. 6 e 7 apresentam uma descrição dos aspectos possíveis de umTDR.

Digno de nota, o TD 204 inclui a capacidade dedespachar threads sem informações de dependência. Além disso, o TD204 inclui a capacidade de despachar threads com informações dedependência e uma identificação para eliminação de um registro dedespacho de threads.

Na região D, a EU 206 pode executar uma threadmas não executar uma seção critica da thread, o que é indicadopela instrução "sendc".

Na região E, o processador de encerramento dethreads 208 pode transmitir uma indicação quando cada unidade detrabalho for encerrada no gerador de threads 202 por meio dobarramento de encerramento. Este é um formato de comunicaçãopossivel rio barramento de encerramento.

<table>table see original document page 11</column></row><table>

No caso em que o sistema de ordenação de threads200 for usado em um pipeline 3D, o processador de encerramento dethreads 208 poderá ser implementado como um cache de renderizaçãode porta de dados (DAP/RC).

Na região F, o gerador de threads 202 poderádeterminar que alguma thread emitida por ele tenha encerrado todasas suas unidades de trabalho e poderá enviar o FFTID da thread pormeio do TD 204 para todas as EUs 206 usando o barramento Pclr.Este é um formato possivel da comunicação de envio no barramento<table>table see original document page 12</column></row><table>

Após a detecção de sinalização válida nobarramento PClr, a lógica da EU pode determinar qual TDR seráusado para eliminação das informações de dependência. A lógica daEU pode capturar a comunicação de envio no PClr e comparar o FFTIDcom qualquer FFTID armazenado nos TDRs. Se a combinação de (FFID,FFTID) na comunicação de envio for igual à combinação (FFID,FFTID) de qualquer entrada válida em qualquer TDR na EU, a entradaem questão poderá ser eliminada.

Em alguns casos, uma thread será despachada paraas EUs sem informações de dependência anexadas e as informações dedependência poderão ser obtidas algum tempo depois. O TDRassociado com a thread em questão tem informações inválidas e estacondição não deve permitir que a thread adentre a seção critica amenos que informações de dependência sejam recebidas e asdependências, se houver, sejam resolvidas. O bit inflightassociado ao TDR da tal thread pode indicar se o TDR armazenainformações de dependência da thread.

Na região G, uma EU 206 pode tentar executar umainstrução "sendc" de uma thread. A EU 206 não executará ainstrução "sendc" se o TDR da thread não for válido, ou for válidomas não for completamente eliminado, o que indica que todotrabalho que dependa da thread deve ser processado à medida quefor completado por outras threads.

Na região H, é permitido à EU 206 executar a"sendc" e instruções subsequentes da thread. O bloqueio H podeocorrer em resposta ao recebimento de uma mensagem no barramentoPClr (terceira região F) no qual a entrada final dependente dathread é eliminada no TDR da thread. A thread agora pode adentrara seção crítica com todo o trabalho dependente precedente completado.

Se a seção crítica tiver gerado dados deencerramento, por ex., subspans sendo escritos em um frame buffer,no caso de um pipeline 3D, uma outra lógica do sistema poderáassegurar que a ordem de encerramento estabelecida neste pontoseja mantida. Por exemplo, no caso de um pipeline 3D, subspanspoderão ser eliminados em ordem até o frame buffer porque eles sãoapresentados ao processador de encerramento de threads 208 emordem, graças às técnicas apresentadas aqui, assim como tendo oprocessador de encerramento de threads 208 uma política deprocessamento de acordo com a ordem de entrega.

Na região I, a thread é concluída.

Na região J, o processador de encerramento dethreads 208 pode sinalizar para o agente de ordenação 205 indicaro encerramento de uma unidade de trabalho. O agente de ordenação205 pode atualizar o placar 203 para eliminar informações dedependência de threads concluídas. Além disso, o agente deordenação 205 pode gerar uma mensagem no barramento PClr para o TD204 para comunicar o encerramento do subspan para as EUs 206 pormeio do envio do FFTID da thread do subspan via TD 204 nobarramento PClr.

A FIG. 4 mostra um exemplo de formato de tabelade placar, de acordo com uma configuração da presente invenção.Para recuperar entradas do placar, no caso em que o placar forusado em um pipeline de gráficos 3D, estas atividades poderãoocorrer. Na reinicialização, o placar inicializa todas as suasentradas de placar para um estado "inválido". Isto pode serindicado por um bit válido por entrada ou um código de FFTIDreservado, como o valor OFFh, por exemplo. Mais tarde, um agentede ordenação 205 (FIG. 2) pode pesquisar o placar para obterinformações de dependência usando um ID único para a parte dotrabalho em questão e o FFTID associado que será atribuído àthread que contém o trabalho. No caso de um pipeline 3D, um localXY de subspan é usado como o ID único com o qual a pesquisa doplacar será feita, juntamente com os FFTIDs associados aossubspans. No caso de um pipeline 3D, o placar usa as coordenadasXY de uma parte de cada subspan para executar uma pesquisa edeterminar se uma entrada de FFTIDs nas coordenadas está presente.Por exemplo, os bits mais significativos das coordenadas XY decada subspan podem ser usados para classificar o conjunto. Aentrada de FFTID presente nas coordenadas identifica a threaddependente se o FFTID for indicado como válido. As implementaçõespodem escolher usar uma parte do endereço XY para endereçamento doplacar; neste caso nomes alternativos (aliasing) são possíveis euma falsa dependência pode ser indicada. Isto pode não ser umproblema porque a busca na tabela de pesquisa só é necessária paraidentificar casos conhecidos de XY não dependente.

Se a entrada do placar for válida e seu FFTIDcorresponder ao apresentado na pesquisa, o placar transmitirá oFFTID para o agente de ordenação 205 para indicar uma dependênciado subspan para o qual a pesquisa foi realizada. O placarsubstituirá o FFTID no conjunto com o FFTID do subspan para o qualuma pesquisa foi feita.

Se os bits usados na identificação do subspan sereferirem a uma entrada inválida, não haverá outro thread noconjunto EU que tenha o mesmo subspan e, portanto, não haverádependência para tal subspan. A entrada FFTID será feita de formaválida e atualizada com o FFTID do subspan para o qual a pesquisafoi feita.

A tabela do placar pode ser usada em ambientesque não sejam um pipeline de gráficos 3D. Nesses cenários,unidades de trabalho serão usadas no lugar de subspans.

A FIG. 5 mostra um exemplo de implementação deplacar (SB) 500 de acordo com uma configuração da presenteinvenção. Esta descrição do SB 500 destina-se a utilização em umpipeline 3D. No entanto, o SB 500 pode ser usado em outroscenários além do pipeline 3D. A tabela do placar é endereçadamediante parte do local XY de um subspan e armazena as entradasFFTID; uma entrada FFTID poderá identificar a dependência de umendereço de subspan mediante indicação da "thread no qual oendereço de subspan tenha sido despachado. Por exemplo, se um bitválido de um FFTID for verdadeiro, uma thread existirá no conjuntoEU que esteja processando atualmente o local XY e, portanto, umathread dependente estará pendente para tal subspan. 0 FFTIDidentificará a dependência anterior e, quando encadeado,identificará a ordem na qual os subspans devam ser encerrados.

0 SB 500 inclui lógica para encerramento deentradas do placar. Em um encerramento, o conteúdo da RAM do SB écomparado com o FFTID da thread encerrada e, se houvercorrespondência, isto indica que não há mais subspans do XY noconjunto e que a entrada foi devolvida ao estado inválido. Se nãohouver correspondência, nenhuma ação será tomada. Independente dacorrespondência ou não, quando o último subspan for encerrado, oFFTID será enfileirado no TD 204 para eventual envio no barramentoPClr. O processamento de pesquisas do placar podem ser uma segundaprioridade em relação ao processamento de operações deencerramento de placar.

De maneira geral, uma entrada de placarrepresenta um "bloco de cobertura" de trabalho que mapeia para oID exclusivo do trabalho e contém o FFTID ao qual o trabalho foiatribuído, se houver. Blocos com pequena cobertura posem causar umnúmero excessivo de buscas, mas blocos com cobertura ampla podemprovocar excesso de aliasing e falsas dependências. Umaimplementação pode ser flexível o bastante para permitir aconfiguração do tamanho dos blocos de cobertura. No entanto, oplacar só pode acompanhar um tamanho de bloco de cobertura de cadavez. Se for necessária alteração no bloco de cobertura, o geradorde threads 202 permite que todas as threads em aberto sejamcompletadas antes que seja feita a pesquisa com o novo tamanho debloco de cobertura. Em uma configuração, há três diferentestamanhos de blocos de cobertura, e qualquer alteração no tamanhopode envolver o esvaziamento (flush) do placar. O ID de meta éusado para classificar a RAM e depende do tamanho do bloco decobertura. A tabela a seguir lista os vários modos de despacho deplacar de pixels, qual a meta para despacho e, portanto, o quedeve ser acompanhado em termos de dependências.<table>table see original document page 16</column></row><table>

Estes são esquemas possíveis de ordenaçãorelacionados a atualizações e envios de placares. Atualizações deplacares encerrados podem ocorrer antes de envios no barramentoPclr para impedir que travamentos ocorram em casos que umapesquisa de placar seja dependente de uma comunicação dobarramento Pclr que já tenha sido enviada. Além disso, um envio nobarramento Pclr pode não passar por uma dependência não-CAM. Alémdisso, o PClr pode ser enviado para a EU antes que um FFTID sejareutilizado para evitar uma competição entre a reutilização doFFTID e o PClr antigo, gerando um PClr falso na segunda utilizaçãodo FFTID.

A FIG. 5 também mostra lógica de acúmulo dedependências 550 que executa o acúmulo de dependências, de acordocom uma configuração da presente invenção. Cada nova dependência éverificada em relação a dependências previamente acumuladas eapenas as novas dependências são consideradas. Da mesma forma,durante o acúmulo de dependências, o barramento PClr é monitoradoe qualquer thread em encerramento é retirada como dependência.

A FIG. 6 mostra um exemplo de formato de registrode TDR 600, de acordo com uma configuração da presente invenção. Oregistro pode ser preenchido com até 16 campos, com cada célulaportando as informações para uma dependência de threads. Em umaimplementação, um registro de TDR armazena oito dependências, Dep.7 a Dep. 0.

A FIG. 7 mostra um exemplo de formato de célulade dependência básica em um registro TDR 700, de acordo com umaconfiguração da' presente invenção. Cada célula pode armazenar 16bits. Um bit "Valid" (V) pode ser a posição de bit maissignificativa e um campo n-bit de FFTID pode estar localizado nosbits menos significativos. O bit Valid indica a validade do campoFFTID, e é inicialmente definido mediante a nova entrega de thread(conforme transmitida pela linha "New_thread").

Um comparador realiza a comparação do valor FFTIDdo registro com os FFTIDs transmitidos no barramento PCLR. Se umFFTID enviado corresponder ao que está na célula e o FFIDcorresponder ao FFID da EU/thread, o bit Valid da célula seráredefinido para eliminar uma dependência.

A determinação de uma dependência pode ocorrerquando todos os bits Valid (V) de todas as células for falso, comoquando os bits Valid não estiverem preenchidos ou forempreenchidos e posteriormente eliminados. 0 resultado dedependência por thread é enviado para a unidade de verificação dedependência ("Ver. dep.") para utilização ma determinação de umainstrução "sendc" tenha sua execução permitida.

A FIG. 8 mostra um exemplo de fluxograma de umprocesso 800, de acordo com uma configuração da presente invenção.O bloco 802 pode incluir a alocação de um identificador único paraum despacho de thread que inclua ao menos uma unidade de trabalho.

Nos casos em que um processo 800 for utilizado em um pipeline 3D,uma unidade de trabalho poderá incluir um subspan.

O bloco 804 poderá incluir a identificação detrabalho in-flight que corresponda ao trabalho designado para odespacho de thread recentemente alocado. Por exemplo, no caso emque o processo 800 for utilizado em um pipeline 3D, o rasterizadorfará uma pesquisa no placar com um conjunto de coordenadas XY desubspans no despacho atual e o ID do despacho. O placar compararáas coordenadas em relação à lista de coordenadas subspan in-flightque permanecerem no estado in-flight nas EUs. Para coordenadascorrespondentes, o placar registrará a ID da thread do despacho eretornará para o windower do ID da thread em aberto que contiver acorrespondência. Para todas as coordenadas, o placar armazenará oID da thread de despacho para comparação com pesquisasposteriores.

O bloco 806 poderá incluir o acúmulo de quaisquerIDs independentes para o despacho atual e a anexação dos IDsdependentes ao despacho atual. Por exemplo, o rasterizadoradicionará à carga do despacho, a lista de IDs de threadsdevolvidas pelo placar e sinalizará ao despachador de threads queenvie a thread para uma EU.

O bloco 808 poderá incluir o despacho da threadatual para uma unidade de execução.

O bloco 810 poderá incluir o armazenamento deidentificadores de threads que processam unidades similares detrabalho. No caso em que o processo 800 for usado em um pipeline3D, unidades de trabalho similares serão as mesmas coordenadas dosubspan. Por exemplo, a EU capturará as entradas de threads eregistrará os IDs de dependência de threads no registro dedependência de threads (TDR).O bloco 812 poderá incluir a eliminação deidentificadores de threads encerradas em resposta a uma indicaçãode encerramento de thread. Por exemplo, a EU monitorará o envio,por parte do placar, de IDs de threads encerradas e comparará osIDs de threads enviados com aqueles mantidos no registro dedependência de threads. Se houver correspondência, a dependênciaserá eliminada.

0 bloco 814 poderá incluir a execução da threadatual até a obtenção de sua região critica. Por exemplo, o inicioda região critica poderá ser indicado pela instrução "sendc".

Os blocos 816 e 818 poderão incluir a espera atéque todas as dependências da thread atual sejam eliminadas antesda execução da instrução de região critica da thread atual. Porexemplo, se todas as dependências do registro de dependência dethreads forem inválidas ou tiverem sido eliminadas, será permitidaa execução de uma instrução "sendc" e o processamento continuará.No caso em que o processo 800 for utilizado em um pipeline 3D, aeliminação de todas as dependências indicará que não há nenhumoutro subspan não encerrado com as mesmas coordenadas de qualqueroutro subspan da thread atual. Nos casos em que o processo 8 00 forusado em um sombreador de pixels, o "sendc" fará com que ossubspans processados da thread atual sejam enviados para o framebuffer e a thread será completada.

O bloco 820 poderá incluir a sinalização de que athread atual está completada. Por exemplo, mediante recebimentodos pixels processados, o frame buffer sinaliza para o despachadorde threads, o placar e o rasterizador que a thread atual estácompletada com a indicação da ID da thread completada.

O Bloco 822 poderá incluir a eliminação dedependências da thread completada. Por exemplo, o bloco 822 poderáincluir a eliminação de dependências de um ID de thread completadaem um placar e o envio das EUs a eliminar quaisquer dependênciasnos registros de dependência de threads. Por exemplo, no caso emque o processo 800 for usado em um pipeline 3D, o placar marcaráas coordenadas XY de subspans associados com a ID de threadcompletada como completa e o placar enviará uma mensagem"eliminada" para os registros de dependência de threads das EUspara eliminar quaisquer dependências nas threads pendentes.

Configurações da presente invenção podem serimplementadas como uma combinação de: um ou mais microchips oucircuitos integrados interconectados usando uma placa-mãe, lógicahardwired, software armazenado por um dispositivo de memória eexecutado por um microprocessador, firmware, circuito integradoespecifico para aplicação (ASIC) e/ou do tipo FPGA (FieldProgrammable Gate Array). O termo "lógica" pode incluir, comoexemplo, software ou hardware e/ou combinações de software ehardware.

Configurações da presente invenção podem serfornecidas, por exemplo, como um programa de computador que poderáincluir um ou mais componentes de midia legíveis por máquina quetenham armazenadas instruções executáveis por máquina que, quandoexecutadas por uma ou mais máquinas, como computadores, redes decomputadores ou outros dispositivos eletrônicos, possam resultarem uma ou mais máquinas executando operações de acordo com asconfigurações da presente invenção. Um meio legivel por máquinapode incluir, entre outros, disquetes, discos ópticos, CD-ROMs(Compact Disc-Read Only Memories) e discos opto-magnéticos, ROMs(Read Only Memories), RAMs (Random Access Memories) , EPROMs(Erasable Programmable Read Only Memories), EEPROMs (ElectricallyErasable Programmable Read Only Memories), cartões magnéticos ouópticos, memória flash, ou outro tipo de midia, meio legivel pormáquina adequado para o armazenamento de instruções executáveispor máquina.

As ilustrações e a descrição precedente deramexemplos da presente invenção. Embora descrito como um número deitens funcionais dispares, aqueles versados na área apreciarão ofato de que um ou mais elementos possam efetivamente sercombinados em elementos funcionais únicos. De forma alternativa,alguns elementos podem ser divididos em vários elementosfuncionais. Elementos de uma configuração podem ser adicionados aoutra configuração. Por exemplo, ordens de processos aquidescritas podem ser alteradas e não estão limitadas às formas aquidescritas. Além disso, as ações de qualquer fluxograma nãoprecisam ser implementadas na ordem mostrada; e nem todas as açõesdevem necessariamente ser executadas. Além disso, as ações que nãosejam dependentes de outras poderão ser executadas em paralelo comoutras. O escopo da presente invenção, no entanto, não está deforma alguma limitado por esses exemplos específicos. Numerosasvariações, sejam ou não fornecidas explicitamente naespecificação, como diferenças de estrutura, dimensão e utilizaçãode materiais, são possíveis. O escopo da invenção é pelo menos tãoamplo como o determinado por estas reivindicações.

Claims (23)

1. Método caracterizado pelo fato de que inclui:em resposta a uma tentativa de execução de umainstrução de uma thread, determinar se nenhuma outra unidade detrabalho precedente associada à thread, fora requisitada paraprocessamento; epermissão da execução da instrução em resposta aoprocessamento completo de cada uma das unidades de trabalhoprecedentes.

2. Método, de acordo com a reivindicação 1,caracterizado pelo fato de que a instrução é formada por umainstrução de solicitação de prosseguimento com a execução doprograma caso as dependências tenham sido satisfeitas.

3. Método, de acordo com a reivindicação 1,caracterizado pelo fato de que inclui ainda:armazenamento de um conjunto de identificadoresde threads, no qual os identificadores de threads identificamthreads no processamento de uma unidade de trabalho.

4. Método, de acordo com a reivindicação 3,caracterizado pelo fato de que inclui ainda:em resposta a todas as unidades de trabalhoagrupadas dentro de um segundo encerramento de threads, acomunicação seletiva da identificação da segunda thread.

5. Método, de acordo com a reivindicação 4,caracterizado pelo fato de que inclui ainda:em resposta à comunicação da identificação dasegunda thread, a eliminação seletiva da identificação da segundathread, usada para indicar uma solicitação pendente para oprocessamento de uma unidade de trabalho com uma solicitação deordem.

6. Método, de acordo com a reivindicação 4,caracterizado pelo fato de que inclui ainda:eliminação seletiva de um identificador de threadno conjunto armazenado, em resposta à identificação da segundathread, correspondente ao identificador de threads.

7. Método, de acordo com a reivindicação 3,caracterizado pelo fato de que inclui ainda:o recebimento de uma solicitação de identificaçãode uma thread associada a uma unidade de trabalho e um segundoidentificador de thread para uma unidade de trabalho precedente;o fornecimento da identidade da thread associadacom a unidade de trabalho eo armazenamento do segundo identificador dethread para a unidade de trabalho do conjunto.

8. Método, de acordo com a reivindicação 1,caracterizado pelo fato de que a unidade de trabalho inclui pelomenos um subspan.

9. Método, de acordo com a reivindicação 1,caracterizado pelo fato de que as execuções permissoras incluem atransferência de pelo menos um subspan processado a um cache derenderização de porta de dados.

10. Aparato caracterizado pelo fato de queconsiste em:um placar para armazenar pelo menos umidentificador de thread usado no processamento de uma unidade detrabalho;um gerador de threads para identificar cadathread pendente que processe uma unidade de trabalho que possua umrequisito de ordenação com trabalho associado a uma primeirathread;um registro de dependência de threads paraarmazenar um identificador de threads pendentes associadas à cadaunidade de trabalho da primeira thread;uma unidade de execução que execute a primeirathread, na qual a unidade de execução deva executar a primeirathread até a obtenção de uma instrução, na qual a unidade deexecução deverá executar de forma seletiva a instrução em respostaao registro de dependência de threads para a primeira thread quenão apresentar identificadores de threads pendentes eum processador de encerramento de threads paramonitoração das threads completadas.

11. Aparato, de acordo com a reivindicação 10,caracterizado pelo fato de que a execução da instrução causa atransferência de uma saída da primeira thread para o processadorde encerramento de threads.

12. Aparato, de acordo com a reivindicação 10,caracterizado pelo fato de que o processador de encerramento dethreads comunica o encerramento de uma segunda thread e no qual oplacar elimina de forma seletiva um identificador da segundathread em resposta à comunicação.

13. Aparato, de acordo com a reivindicação 12,caracterizado pelo fato de que trata ainda de um barramento paratransferência da comunicação de encerramento da segunda thread aogerador de threads.

14. Aparato, de acordo com a reivindicação 12,caracterizado pelo fato de que trata ainda de um barramento paratransferência da comunicação para o registro de dependência dethreads.

15. Aparato, de acordo com a reivindicação 14,caracterizado pelo fato de que o registro de dependência dethreads deve eliminar de forma seletiva o identificador de threadpendente, com base na comunicação.

16. Aparato, de acordo com a reivindicação 10,caracterizado pelo fato de que o placar deve:receber uma solicitação para identificação de umathread associada a uma unidade de trabalho e um identificador dathread que irá conter o trabalho;fornecer a identidade da thread associada com aunidade de trabalho; earmazenar o identificador da thread para aunidade de trabalho.

17. Aparato, de acordo com a reivindicação 10,caracterizado pelo fato de que a unidade de trabalho contém pelomenos um subspan.

18. Aparato, de acordo com a reivindicação 10,caracterizado pelo fato de que o processador de encerramento dethreads contém um cache de renderização de porta de dados.

19. Sistema caracterizado pelo fato de que écomposto por:um sistema host composto por um dispositivo dearmazenamento;um subsistema gráfico, acoplado de formacomunicativa ao sistema host, no qual o subsistema gráfico deveencerrar as unidades de trabalho processadas mediante amonitoração da inexistência de processos de threads pendentesenvolvendo unidades de trabalho direcionadas para operaçõessimilares; eum display acoplado de forma comunicativa aosubsistema gráfico.

20. Sistema, de acordo com a reivindicação 19,caracterizado pelo fato de que o subsistema gráfico é formado por:um placar para armazenar pelo menos umidentificador de thread usado no processamento de uma unidade detrabalho;um gerador de threads para identificar cadathread pendente que processe uma unidade de trabalho que possua umrequisito de ordenação com trabalho associado a uma primeirathread;um registro de dependência de threads paraarmazenar um identificador de threads pendentes associadas à cadaunidade de trabalho da primeira thread;uma unidade de execução que execute a primeirathread, na qual a unidade de execução deva executar a primeirathread até a obtenção de uma instrução, na qual a unidade deexecução deverá executar de forma seletiva a instrução em respostaao registro de dependência de threads para a primeira thread quenão apresentar identificadores de threads pendentes eum processador de encerramento de threads paramonitoração das threads completadas.

21. Sistema, de acordo com a reivindicação 20,caracterizado pelo fato de que o placar deve:receber uma solicitação para identificação de umathread associada a uma unidade de trabalho e um identificador dathread que irá conter o trabalho;fornecer a identidade da thread associada com aunidade de trabalho; earmazenar o identificador da thread para aunidade de trabalho.

22. Sistema, de acordo com a reivindicação 19,caracterizado pelo fato de que a unidade de trabalho inclui pelomenos um subspan.

23. Sistema, de acordo com a reivindicação 19,caracterizado pelo fato de que as unidades de trabalhodirecionadas para operações similares contêm subspans direcionadospara coordenadas coincidentes.