Pela patente de RTRT da RDNA3 a AMD continuará 'reciclando' os CUs para calcular tudo ao invés de dedicar núcleos, mas dessa vez será mais inteligente e agressivo... caso alguém esteja curioso depois posso trazer para cá algumas palavras sobre
Não sei se eu já tinha dito isso aqui ou num outro fórum do qual participo, mas o sistema RTRT da AMD é muito interessante a longo prazo.
O limite no curto prazo é dado pelo numero de DCUs, mas com o aumento das mesmas, podemos ter performances excelentes e muito mais flexibilidade.
Isso porque no caso da nvidia, além de ter um número fixo de unidades específicas, tem que seguir um algoritmo temporal pra usar Shader, RT e TC ao mesmo tempo.
Não vão lançar placas RX 6800 dual fan? Até agora só tem placas gigantes de 30cm+, fica complicado pra quem tem gabinete pequeno (cabe até de 26cm). Quero chutar logo o pau da placa e pegar logo uma 6800, pois não se encontra 5700 XT em lugar algum!
guys, few days ago i posted about bad performance on Ori and Will of the Wisps on this driver, and even on the previous one. My fps in game was like...
Baixei aqui o novo driver (ainda não dá pra atualizar direto pelo software porque não é WHQL?) e notei redução da temperatura da VGA. Agora no CP não passa dos 60ºC (antes ficava na casa dos 64ºC).
Ela apareceu duas vezes na semana q eu vi uma foi na quarta as 14hrs e eu até boletei pra mim e a outra foi ontem e eu vi era 15hrs deu tempo de avisar um amigo q estava enchendo o saco pra pegar a q eu tinha boletado
Na quarta eu boletei duas uma foi por R$4780 pois nenhum cupom funcionava ai pra não perder peguei ela por esse valor, depois no tópico das nvidia 30xx a galera falou os cupons q funcionavam q no meu caso foi o emersonbr18 ai deu tempo de boletar outra por R$4560, os boletos venceram ontem e essa de R$4780 como eu não paguei deve voltar por estoque da Kabum hj ou amanhã
Não vão lançar placas RX 6800 dual fan? Até agora só tem placas gigantes de 30cm+, fica complicado pra quem tem gabinete pequeno (cabe até de 26cm). Quero chutar logo o pau da placa e pegar logo uma 6800, pois não se encontra 5700 XT em lugar algum!
Parece muito, e realmente é, mas a NVIDIA vai vir com força também e a AMD quer tomar a liderança nem que para isso faça uma GPU que chegue aos 375W e use HBM novamente. O pior é que quanto mais se olha para essa meta, mais ela se torna palpável (não, sou cético, para mim ela nunca será palpável): O RGT deixou seu parecer e ele disse que acredita veemente nesse valor, para ele será o dobro de núcleos, IPC e clocks maiores, chiplet, maior eficiência energética, 5nm e mudanças na arquitetura, tudo isso somado entregará os 250%.
Se colocarmos na balança que uma escalabilidade nunca é perfeita, então a AMD conseguirá uns 300% ou mais de ganho, e com a perda de se fazer chiplets esse valor cairá para esse número, e isso é incrível. Junte isso com o rumor mais antigo de que ela possivelmente terá memória expansível e BOOM, sem comentários. O _rogame fez um thread no twitter levantando como esse número pode ser realista.
Complete Patent Searching Database and Patent Data Analytics Services.
www.freepatentsonline.com
Ok, o nome não deixo nada claro, para que ela serve? Basicamente ela aborda um método para reduzir divergências no controle de fluxo ao se executar RTRT, que por si só pode dobrar ou quadruplicar o desempenho dos CUs ao utilizar os RAs. Vamos olhar como?
Problema: Processadores SIMD (aka, GPUs) alcançam paralelização utilizando um módulo de controle fluxo, onde este possui múltiplos itens (dados). Acontece que é possível que este controle de fluxo crie divergências de dados quando ele é dependente do que está sendo processado, e quando múltiplos threads de execução têm valores diferentes para o dados de outros controles de fluxo a dependência torna-se generalizada. Quando isso acontece o caminho desse fluxo torna-se serial, causando slowdowns e subutilizando o pipeline.
Exemplificando o problema: Na imagem abaixo eu tenho um wavefront em quatro linhas de execução de um CU, cada linha fica com um conjunto de dados (16 itens). Devido à uma dependência parcial de dados e em como o workset veio ao CU ele será executado de forma completamente serial, onde a linha 1 executa a função 1 (F1) e entra em repouso, a F2 só é feita quando a F1 acaba (logo no próximo ciclo de clock) e depois que conclui entra em espera, e assim por diante. Percebam então que houve uma divergência em fator de 4, onde 4 conjunto de itens foram processados por 4 linhas de execução um de cada vez, um após o outro, no caso completamente serial (o mesmo repete-se no wavefront 2, afinal o RDNA funciona com DCUs).
Solução: Em um ponto de divergência do controle de fluxo identifica-se os alvos para diferentes itens de execução, ordena-os baseando-se nas metas do controle de fluxo, reorganiza-os baseado na ordenação sugerida e executa-os após a divergência no fluxo de controle com os itens reorganizados. Soou difícil né? Simplificadamente a GPU irá analisar os dados que entrarem na fila de execução e procurará por possíveis dependências, caso não existam ele ordena esses itens para serem executados de forma paralela nas unidades computacionais; caso existam dependências ele organizará a execução da melhor forma possível para evitar o máximo de perda de desempenho.
Exemplificando a solução: Na imagem abaixo aquele mesmo wavefront será distribuído no mesmo DCU, em quatro linhas de execução por CU. A mesma dependência parcial ocorre mas aqui, antes de começar a execução dessa onda o CU analisa a lista de tarefas de forma espacial e/ou temporal e, após perceber que há como otimizar a execução, ele ordena o(s) wavefront(s) para serem executados de forma paralela. Após a ordenação a função 1 é processada simultaneamente pelas linhas de execução 1 e 3, enquanto a F2 executa as linhas 2 e 4, e em apenas dois ciclos eu acabo todo meu wavefront. Como há dependência parcial o outro CU fica em repouso até o CU vizinho terminar, e ai ele começa a funcionar da mesma maneira que seu vizinho. Aqui tivemos uma redução de divergência de um fator de 4 para 2, cortando então pela metade o tempo necessário para se acabar uma tarefa. Percebam, porém, que neste exemplo em específico não houve redução no tempo pois apenas 2 wavefronts foram utilizados, mas se colocarmos uma wavegroup completo (32 wavefronts) ao invés dos CUs entrarem em repouso (SKIP) eles irão consumir a próxima onda e assim farão até o grupo ser consumido por completo. Neste caso, considerando que cada onda exija 10s para ser concluída, esta solução acabaria o grupo de ondas em 160s (2m40s) enquanto que sem ela este grupo acabaria em 320s (5m20s), ou seja o dobro de eficiência sem alterar nada além de organizar a fila.
E quem fará essa redução de divergência? A unidade computacional, ela que cuidará de resolver as divergências de forma intra-wavefront (entre os dados de um único wavefront) e/ou de forma inter-wavefront (entre os wavefronts em um wavegroup). Literalmente uma solução tirada do C.U. (péssimo trocadilho, sei) xD
Por fim vale ressaltar que essa ordenação será aplicada a toda e qualquer tarefa da GPU, então trará ganhos no geral na RDNA3, mas o foco é em RTRT porque ele é realizado de forma compartilhada com outras tarefas nos CUs (inclusive os RA reciclam/ocupam os TMUs) e por isso essas pausas e serializações são comuns com traçados de raios, causando esperas nas filas e reduzindo o desempenho do pipeline e principalmente do RT, visto que ele depende de muitos dados para iniciar e concluir seus cálculos, então essa ordenação permitirá que o cálculo seja feito de forma paralela o máximo que puder, rendendo um boost de 2x à 4x em relação ao método atual. Quanto ao custo no silício para essa ordenação? Nenhum, a reformulação dos CUs que virá no RDNA3 cuidará de incorporar isso ao modo de funcionar deles, mas caso o desenvolvedor queira a GPU permitirá essa ordenação também via software, podendo ambos se auxiliarem (sw+hw sort) ou cada um tomar as rédeas (apenas "hw sort" ou apenas "sw sort") dessa ordenação, e vai além! Também tem a possibilidade dessa ordenação vir na hora de compilar o código ou até o próprio driver pode ordenar caso perceba que o workgroup está em uma forma não otimizada.
Isso significa que a AMD está explorando o máximo resolver problemas oriundos de terceiros (software, compiladores) por conta própria para que sua arquitetura não seja subutilizada como a GCN foi
PS: Quem quiser entender o problema mais a fundo, vai um spoiler com algo mais baixo-nível (só para quem for curioso ou quiser arriscar entender
Vejam o pseudocódigo abaixo:
add r1, r2, r3
mul r4, r1, r5
store [r6], r4
(...)
para quem nunca viu assembler x86, uma aula rápida: Código imperativo, operação seguida de registradores e endereços de memória. Ordem de leitura com três operandos é sempre de "operação destino, origem1, origem2".
Nesse exemplo o "add r1, r2, r3" significa que estou mandando ser feita uma soma do valor contido no registrador 2 com o valor contido no registrador 3, e o resultado deve ser armazenado no registrador 1. O mesmo repete-se com o mul (multiplicar), enquanto que o store (guardar/armazenar) tem como operandos uma posição na memória (endereçamento) entre colchetes e o valor a ser armazenado.
Esse pseudocódigo não é x86, esta mais para MIPS, porque em x86 algumas operações possuem operandos implícitos, como o MUL: Se você escrever daquela maneira vai levar um bom erro na cara, o MUL do x86 tem apenas um operando, "mul origem", porque o segundo operando fica implícito em um registrador, e o resultado é armazenado neste mesmo registrador. Um exemplo correto de como seria uma multiplicação em x86 (ponto-e-vírgula indica comentário):
mov ax, valor ; ax = multiplicando
mov cx, valor ; cx = multiplicador
mul cx ; dx:ax = produto
O que é aquele "dx:ax"? Multiplicar valores 16bits pode... argh! perdi o foco! Isso aqui não é aula de assembler! xD
Esse código é simples e altamente paralelizável, não possui dependências significativas, ao ser feito o "add" a próxima linha de processo já vai ter o resultado e fará o "mul" e assim por diante, até a onda de trabalhos acabar. Mas as vezes o controle de fluxo diverge entre essas linhas de processos e com isso vários itens de um wavefront acabam modificando o ponteiro de instruções, justamente por causa do valor que carregam. Por exemplo, um branch condicional é uma instrução em que o alvo de um salto é baseado no resultado... de uma condicional. Quando essa divergência ocorre o SIMD funciona de forma serial. Vejamos um pseudocódigo com divergência:
Aqui estou fazendo uma soma, se o valor do registrador 1 for menor que zero a operação "blz" (branch less zero) retorna verdadeiro e salta para o rótulo "LESS_THAN_ZERO" (algo como GOTO, do CMD), mas se o valor retornar falso nada é feito e o código continua sua execução para a seção 1 (aka, retornou maior que zero) e depois dá um "jmp" (salto) para o rótulo "RECONVERGE", nada difícil aqui, seguimos.
Vamos supor que a primeira linha de execução comece seu wavefront com um valor "-10" armazenado no r2, após a primeira operação o valor no r1 será de "-5" e com isso o "blz" levará essa execução para a segunda parte do código (section 2). Em seguida vem a segunda linha de execução e ela começa sua wavefront com o valor "1" em r2, resultando em "6" no r1 e fazendo o "blz" jogar a execução para a primeira parte do código (section 1).
Percebam que, com esse código, cada linha de execução será feita de forma serial, ou seja, enquanto a segunda linha de execução fica com a "section 1" a linha dois fica desativada esperando a linha 1 concluir, e quando ela acaba a linha 2 executa a "section 2" enquanto que a linha 1 fica esperando a linha 2 concluir. Temos aqui uma redução na eficiência porque várias linhas de execução que podiam estar executando ao mesmo tempo funcionarão em série, mas esse exemplo ai ainda é fraco, vejamos esse aqui:
Essas reticências entre parêntesis indicam uma sequência de códigos que não nos interessam nesse exemplo. Seguindo, aqui cada linha de execução esará fazendo traçados de raios, detectando interseções com triângulos. Cada linha identifica o material dos triângulos intersecionados e armazena o endereço desse MS (Material Shader) no registrador "r1". Então cada linha de execução salta para o endereçamento armazenado no "r1", e esse conteúdo apontado pode conter vários tipos de MS, representados por "MS_(n)" no pseudocódigo acima, e após ir para deu destino e executar a sequência de código correspondende ele salta para o rótulo "END_MS"... perceberam o problema já? Se cada linha de execução acertar um triângulo com um MS diferente o slowdown resultante será igual ao número de linhas de execução nesse wavefront (que pode ser até 32 no RDNA2) e isso significa que esse simples código poderia serializar todo o pipeline da GPU.
Não sei se eu já tinha dito isso aqui ou num outro fórum do qual participo, mas o sistema RTRT da AMD é muito interessante a longo prazo.
O limite no curto prazo é dado pelo numero de DCUs, mas com o aumento das mesmas, podemos ter performances excelentes e muito mais flexibilidade.
Isso porque no caso da nvidia, além de ter um número fixo de unidades específicas, tem que seguir um algoritmo temporal pra usar Shader, RT e TC ao mesmo tempo.
Isso, exatamente isso, alguém conseguiu olhar bem no ponto certo: A forma de RTRT da AMD atualmente "dá errado" porque ela compartilha TMUs e DCUs com outros cálculos simultaneamente. Se eu tiver núcleos sobrando, o que acontece? Atualmente nada, mas com CUs sobrando todos eles poderão ser utilizados para RTRT, então em uma placa com 160CUs seria possível limitar um jogo a rasterizar utilizando 100 desses CUs e os outros 60 ficariam vagos para calcular exclusivamente cálculos de RT.
Parece muito, e realmente é, mas a NVIDIA vai vir com força também e a AMD quer tomar a liderança nem que para isso faça uma GPU que chegue aos 375W e use HBM novamente. O pior é que quanto mais se olha para essa meta, mais ela se torna palpável (não, sou cético, para mim ela nunca será palpável): O RGT deixou seu parecer e ele disse que acredita veemente nesse valor, para ele será o dobro de núcleos, IPC e clocks maiores, chiplet, maior eficiência energética, 5nm e mudanças na arquitetura, tudo isso somado entregará os 250%.
Se colocarmos na balança que uma escalabilidade nunca é perfeita, então a AMD conseguirá uns 300% ou mais de ganho, e com a perda de se fazer chiplets esse valor cairá para esse número, e isso é incrível. Junte isso com o rumor mais antigo de que ela possivelmente terá memória expansível e BOOM, sem comentários. O _rogame fez um thread no twitter levantando como esse número pode ser realista.
Ok, vamos lá, tentarei ser breve: A patente em questão é esta aqui, Unidade Computacional com Ordenação para uma Redução de Divergências.
Complete Patent Searching Database and Patent Data Analytics Services.
www.freepatentsonline.com
Ok, o nome não deixo nada claro, para que ela serve? Basicamente ela aborda um método para reduzir divergências no controle de fluxo ao se executar RTRT, que por si só pode dobrar ou quadruplicar o desempenho dos CUs ao utilizar os RAs. Vamos olhar como?
Problema: Processadores SIMD (aka, GPUs) alcançam paralelização utilizando um módulo de controle fluxo, onde este possui múltiplos itens (dados). Acontece que é possível que este controle de fluxo crie divergências de dados quando ele é dependente do que está sendo processado, e quando múltiplos threads de execução têm valores diferentes para o dados de outros controles de fluxo a dependência torna-se generalizada. Quando isso acontece o caminho desse fluxo torna-se serial, causando slowdowns e subutilizando o pipeline.
Exemplificando o problema: Na imagem abaixo eu tenho um wavefront em quatro linhas de execução de um CU, cada linha fica com um conjunto de dados (16 itens). Devido à uma dependência parcial de dados e em como o workset veio ao CU ele será executado de forma completamente serial, onde a linha 1 executa a função 1 (F1) e entra em repouso, a F2 só é feita quando a F1 acaba (logo no próximo ciclo de clock) e depois que conclui entra em espera, e assim por diante. Percebam então que houve uma divergência em fator de 4, onde 4 conjunto de itens foram processados por 4 linhas de execução um de cada vez, um após o outro, no caso completamente serial (o mesmo repete-se no wavefront 2, afinal o RDNA funciona com DCUs).
Solução: Em um ponto de divergência do controle de fluxo identifica-se os alvos para diferentes itens de execução, ordena-os baseando-se nas metas do controle de fluxo, reorganiza-os baseado na ordenação sugerida e executa-os após a divergência no fluxo de controle com os itens reorganizados. Soou difícil né? Simplificadamente a GPU irá analisar os dados que entrarem na fila de execução e procurará por possíveis dependências, caso não existam ele ordena esses itens para serem executados de forma paralela nas unidades computacionais; caso existam dependências ele organizará a execução da melhor forma possível para evitar o máximo de perda de desempenho.
Exemplificando a solução: Na imagem abaixo aquele mesmo wavefront será distribuído no mesmo DCU, em quatro linhas de execução por CU. A mesma dependência parcial ocorre mas aqui, antes de começar a execução dessa onda o CU analisa a lista de tarefas de forma espacial e/ou temporal e, após perceber que há como otimizar a execução, ele ordena o(s) wavefront(s) para serem executados de forma paralela. Após a ordenação a função 1 é processada simultaneamente pelas linhas de execução 1 e 3, enquanto a F2 executa as linhas 2 e 4, e em apenas dois ciclos eu acabo todo meu wavefront. Como há dependência parcial o outro CU fica em repouso até o CU vizinho terminar, e ai ele começa a funcionar da mesma maneira que seu vizinho. Aqui tivemos uma redução de divergência de um fator de 4 para 2, cortando então pela metade o tempo necessário para se acabar uma tarefa. Percebam, porém, que neste exemplo em específico não houve redução no tempo pois apenas 2 wavefronts foram utilizados, mas se colocarmos uma wavegroup completo (32 wavefronts) ao invés dos CUs entrarem em repouso (SKIP) eles irão consumir a próxima onda e assim farão até o grupo ser consumido por completo. Neste caso, considerando que cada onda exija 10s para ser concluída, esta solução acabaria o grupo de ondas em 160s (2m40s) enquanto que sem ela este grupo acabaria em 320s (5m20s), ou seja o dobro de eficiência sem alterar nada além de organizar a fila.
E quem fará essa redução de divergência? A unidade computacional, ela que cuidará de resolver as divergências de forma intra-wavefront (entre os dados de um único wavefront) e/ou de forma inter-wavefront (entre os wavefronts em um wavegroup). Literalmente uma solução tirada do C.U. (péssimo trocadilho, sei) xD
Por fim vale ressaltar que essa ordenação será aplicada a toda e qualquer tarefa da GPU, então trará ganhos no geral na RDNA3, mas o foco é em RTRT porque ele é realizado de forma compartilhada com outras tarefas nos CUs (inclusive os RA reciclam/ocupam os TMUs) e por isso essas pausas e serializações são comuns com traçados de raios, causando esperas nas filas e reduzindo o desempenho do pipeline e principalmente do RT, visto que ele depende de muitos dados para iniciar e concluir seus cálculos, então essa ordenação permitirá que o cálculo seja feito de forma paralela o máximo que puder, rendendo um boost de 2x à 4x em relação ao método atual. Quanto ao custo no silício para essa ordenação? Nenhum, a reformulação dos CUs que virá no RDNA3 cuidará de incorporar isso ao modo de funcionar deles, mas caso o desenvolvedor queira a GPU permitirá essa ordenação também via software, podendo ambos se auxiliarem (sw+hw sort) ou cada um tomar as rédeas (apenas "hw sort" ou apenas "sw sort") dessa ordenação, e vai além! Também tem a possibilidade dessa ordenação vir na hora de compilar o código ou até o próprio driver pode ordenar caso perceba que o workgroup está em uma forma não otimizada.
Isso significa que a AMD está explorando o máximo resolver problemas oriundos de terceiros (software, compiladores) por conta própria para que sua arquitetura não seja subutilizada como a GCN foi
PS: Quem quiser entender o problema mais a fundo, vai um spoiler com algo mais baixo-nível (só para quem for curioso ou quiser arriscar entender
Vejam o pseudocódigo abaixo:
add r1, r2, r3
mul r4, r1, r5
store [r6], r4
(...)
para quem nunca viu assembler x86, uma aula rápida: Código imperativo, operação seguida de registradores e endereços de memória. Ordem de leitura com três operandos é sempre de "operação destino, origem1, origem2".
Nesse exemplo o "add r1, r2, r3" significa que estou mandando ser feita uma soma do valor contido no registrador 2 com o valor contido no registrador 3, e o resultado deve ser armazenado no registrador 1. O mesmo repete-se com o mul (multiplicar), enquanto que o store (guardar/armazenar) tem como operandos uma posição na memória (endereçamento) entre colchetes e o valor a ser armazenado.
Esse pseudocódigo não é x86, esta mais para MIPS, porque em x86 algumas operações possuem operandos implícitos, como o MUL: Se você escrever daquela maneira vai levar um bom erro na cara, o MUL do x86 tem apenas um operando, "mul origem", porque o segundo operando fica implícito em um registrador, e o resultado é armazenado neste mesmo registrador. Um exemplo correto de como seria uma multiplicação em x86 (ponto-e-vírgula indica comentário):
mov ax, valor ; ax = multiplicando
mov cx, valor ; cx = multiplicador
mul cx ; dx:ax = produto
O que é aquele "dx:ax"? Multiplicar valores 16bits pode... argh! perdi o foco! Isso aqui não é aula de assembler! xD
Esse código é simples e altamente paralelizável, não possui dependências significativas, ao ser feito o "add" a próxima linha de processo já vai ter o resultado e fará o "mul" e assim por diante, até a onda de trabalhos acabar. Mas as vezes o controle de fluxo diverge entre essas linhas de processos e com isso vários itens de um wavefront acabam modificando o ponteiro de instruções, justamente por causa do valor que carregam. Por exemplo, um branch condicional é uma instrução em que o alvo de um salto é baseado no resultado... de uma condicional. Quando essa divergência ocorre o SIMD funciona de forma serial. Vejamos um pseudocódigo com divergência:
Aqui estou fazendo uma soma, se o valor do registrador 1 for menor que zero a operação "blz" (branch less zero) retorna verdadeiro e salta para o rótulo "LESS_THAN_ZERO" (algo como GOTO, do CMD), mas se o valor retornar falso nada é feito e o código continua sua execução para a seção 1 (aka, retornou maior que zero) e depois dá um "jmp" (salto) para o rótulo "RECONVERGE", nada difícil aqui, seguimos.
Vamos supor que a primeira linha de execução comece seu wavefront com um valor "-10" armazenado no r2, após a primeira operação o valor no r1 será de "-5" e com isso o "blz" levará essa execução para a segunda parte do código (section 2). Em seguida vem a segunda linha de execução e ela começa sua wavefront com o valor "1" em r2, resultando em "6" no r1 e fazendo o "blz" jogar a execução para a primeira parte do código (section 1).
Percebam que, com esse código, cada linha de execução será feita de forma serial, ou seja, enquanto a segunda linha de execução fica com a "section 1" a linha dois fica desativada esperando a linha 1 concluir, e quando ela acaba a linha 2 executa a "section 2" enquanto que a linha 1 fica esperando a linha 2 concluir. Temos aqui uma redução na eficiência porque várias linhas de execução que podiam estar executando ao mesmo tempo funcionarão em série, mas esse exemplo ai ainda é fraco, vejamos esse aqui:
Essas reticências entre parêntesis indicam uma sequência de códigos que não nos interessam nesse exemplo. Seguindo, aqui cada linha de execução esará fazendo traçados de raios, detectando interseções com triângulos. Cada linha identifica o material dos triângulos intersecionados e armazena o endereço desse MS (Material Shader) no registrador "r1". Então cada linha de execução salta para o endereçamento armazenado no "r1", e esse conteúdo apontado pode conter vários tipos de MS, representados por "MS_(n)" no pseudocódigo acima, e após ir para deu destino e executar a sequência de código correspondende ele salta para o rótulo "END_MS"... perceberam o problema já? Se cada linha de execução acertar um triângulo com um MS diferente o slowdown resultante será igual ao número de linhas de execução nesse wavefront (que pode ser até 32 no RDNA2) e isso significa que esse simples código poderia serializar todo o pipeline da GPU.
Isso, exatamente isso, alguém conseguiu olhar bem no ponto certo: A forma de RTRT da AMD atualmente "dá errado" porque ela compartilha TMUs e DCUs com outros cálculos simultaneamente. Se eu tiver núcleos sobrando, o que acontece? Atualmente nada, mas com CUs sobrando todos eles poderão ser utilizados para RTRT, então em uma placa com 160CUs seria possível limitar um jogo a rasterizar utilizando 100 desses CUs e os outros 60 ficariam vagos para calcular exclusivamente cálculos de RT.
E toda esta implementação que poderemos ver na RDNA3 poderia trazer o ganho de até 250% que você mencionou anteriormente? Será que teremos também alguma implementação de FPGA nas GPUs?
A programação em Assembly me fez lembrar do comando "Debug" do MsDos.
E toda esta implementação que poderemos ver na RDNA3 poderia trazer o ganho de até 250% que você mencionou anteriormente? Será que teremos também alguma implementação de FPGA nas GPUs?
Primeiro não: Apenas essa patente não vai dobrar o desempenho, dependendo do caso ela pode dar de 5% a 30% mais em rasterização, mais tendendo aos 5% que aos 30% visto que a GPU já cuida de organizar suas filas para ter o mínimo de código serial possível, essa tomada é uma nova maneira de fazer isso bem antes de se executar os dados nos CUs. Isso significa que teremos a adição de latência e isso é ruim, mas se o ganho final for bom essa latência acaba sendo mascarada (exatamente o que aconteceu com o Zen3, ao dobrar a cache L3 o tempo de acesso aumentou, mas como agora cada núcleo acessa o dobro de dados na cache esse ganho foi maior que a perda, mascarando a latência adicional).
A grande vantagem que essa patente trás é justamente no ray-tracing, pois a forma dele funcionar congestiona o pipeline e gera muita dependência, e essa tomada acaba por eliminar o máximo de dependências possíveis. Especificamente no RTRT esse método aumenta o desempenho entre 50% e 200% (mais tendendo aos 200% que aos 50%), ou seja, no melhor caso essa tomada dobra o desempenho dos RA e é por isso que o exemplo na patente é focado em RTRT pois é onde será utilizada (mas nada impede da AMD reformar o DCU para implementar isso, tudo depende se a latência adicional impactará mais que o ganho).
Segundo não: FPGA nas GPUs virá mas não para o usuário comum, no caso o mercado gamer, se vier será mais futuramente porque FPGA é caro e porque não há muito onde utilizar (talvez uma unidade de RA via FPGA renda bem, mas fora isso só vejo a área de codificação/decodificação de videos). O foco do FPGA é colocar onde quem compre a placa possa utiliza-lo em sua finalidade, ou seja, reprograma-lo de acordo com seu uso.
Aquilo ali foi só exemplo mesmo, e esses debuggers costumam ser disassemblers, aka transformam o código em assembly para você xeretar o baixo nível xD
Quer assembly x86 mesmo? Então saiba que esse exemplo nem funciona mais por ser 16bit DOS, para ser 32bit ou 64bit os registradores ganham prefixos (ax -> eax [32b] ou rax [64b]). Um exemplo clássico de "olá mundo" abaixo só por curiosidade
Código:
org 0x100 ; salto de 256bytes para o segmento
mov dx, msg ; dx = endereço de msg
mov cx, len ; cx = tamanho de msg
mov bx, 1 ; bx = stdout (tela)
mov ah, 9 ; ah = comando de escrever
int 0x21 ; syscall do DOS
mov ah, 0x4c ; sub-função de término
int 0x21 ; syscall do DOS
msg db 'Hello, World!', 0x0d, 0x0a ; texto, CR, CL
len equ $ - msg ; tamanho texto
Código:
global _start
section .text
_start:
mov edx, len ; edx = tamanho de msg
mov ecx, msg ; ecx = endereço de msg
mov ebx, 1 ; ebx = stdout (tela)
mov eax, 4 ; eax = sys_write
int 0x80 ; syscall do linux
mov ebx, 0 ; ebx = código de saída, 0=ok
mov eax, 1 ; eax = sys_exit
int 0x80 ; syscall
section .data
msg db 'Hello, world!', 0xa ; texto, NL
len equ $ - msg ; tamanho do texto
Código:
global _start
section .text
_start:
mov rax, 1 ; rax = syscall (escrever)
mov rdi, 1 ; rdi = stdout
mov rsi, msg ; rsi = endereço de msg
mov rdx, 13 ; rdx = n[umero de bytes a ser escrito
syscall ; interrupção para o syscall
mov rax, 60 ; rax = syscall (sair)
xor rdi, rdi ; limpando 'rdi' com código de saída
syscall ; invoke operating system to exit
section .data
msg db "Hello, World", 10 ; texto, NL
Isso, eu estou bem cético com esses 250% porque desse total são 50% de evolução perf/watt (o que aconteceu do RDNA1 -> RDNA2) e 200% por serem dois chips de 80CUs em MCM, mas quem entende disso sabe que escalar perfeitamente o desempenho com tantos núcleos é quase impossível, ainda mais com metade desses núcleos em outro die. A patente da forma de comunicação entre esses MCM e a outra sobre um novo protocolo de transferência de alta largura de banda e baixo overhead são incríveis e quase certo serão utilizadas no RDNA3, mas não creio que apenas isso fará 2x CUs == 2x perf. Se me dissessem 150% eu acreditaria, 200% ainda acharia estranho mas procuraria justificativas mas 250% é algo além do meu ceticismo, se vir isso irei aplaudir de pé.
PS: O hype da Ampere morreu porque acreditava-se que ela viria como uma arquitetura focada em jogos, mas acabou vindo uma focada em computação que joga (aka, GCN). A RDNA, porém, é só focada em jogos então o número que for prometido vai ser convertido em desempenho real. A questão aqui é... esses 2.5x são COM ray-tracing ou puramente rasterização? Se for o segundo caso ficarei muito surpreso, se for o primeiro ai já começo a crer de agora xD
Sim, seria, para a uArch RDNA qualquer largura de banda é bem vinda, veja a sede pelo InfinityCache, algo próximo aquela velocidade renderia muito bem para a GPU como um todo.
Posso nem falar nada da Azul, já que extraviáram meu último pedido. (no natal)
Tinha comprado uma JBL Charge 4 de presente pra minha mãe e a caixa chegou vazia, com o lacre violado e uma fita transparente por cima.
Felizmente notei logo o baixo peso, abri a caixa na frente do entregador e mandei tudo de volta.
Atualizei do 20.9.2 para a 20.11.2, e está bem melhor em estabilidade dos clocks, no geral tive um pouco de ganho de desempenho, mas coisa mínima. Acho que pras 5000 deve ser o melhor driver, e provavelmente nem deve ter mais foco...
forums.guru3d.com
www.freepatentsonline.com
