HSA para desenvolvedores: computação heterogênea para as massas

Publicados: 2022-03-11

O que fabricantes de chips como AMD, ARM, Samsung, MediaTek, Qualcomm e Texas Instruments têm em comum? Bem, além das semelhanças óbvias entre esses gigantes da fabricação de chips, eles também são fundadores da HSA Foundation. O que é HSA e por que ela precisa de uma base apoiada por pesos-pesados ​​do setor?

Neste post vou tentar explicar por que HSA pode ser um grande negócio em um futuro próximo, então vou começar com o básico: O que é HSA e por que você deveria se importar ?

HSA significa Arquitetura de Sistema Heterogêneo, o que soa meio chato, mas acredite em mim, pode se tornar muito empolgante, de fato. HSA é essencialmente um conjunto de padrões e especificações projetados para permitir maior integração de CPUs e GPUs no mesmo barramento. Este não é um conceito inteiramente novo; CPUs de desktop e SoCs móveis vêm empregando gráficos integrados e usando um único barramento há anos, mas a HSA leva isso para o próximo nível.

Mesma carga, arquiteturas diferentes: CPUs e GPUs se destacam em tarefas diferentes. O que acontece quando eles começam a compartilhar a carga, sem entrada do desenvolvedor?

Mesma carga, arquiteturas diferentes: CPUs e GPUs se destacam em tarefas diferentes. O que acontece quando eles começam a compartilhar a carga, sem entrada do desenvolvedor?
Tweet

Em vez de simplesmente usar o mesmo barramento e memória compartilhada para CPU e GPU, o HSA também permite que essas duas arquiteturas muito diferentes trabalhem em conjunto e compartilhem tarefas . Pode não parecer grande coisa, mas se você olhar mais de perto e examinar os potenciais efeitos a longo prazo dessa abordagem, ela começará a parecer muito “doce” em um sentido técnico.

Ah não! Aqui está outro desenvolvedor padrão bobo que precisa implementar

Sim e não.

A ideia de compartilhar o mesmo barramento não é nova, nem a ideia de empregar GPUs altamente paralelizadas para certas tarefas de computação (que não envolvem renderização de headshots). Isso já foi feito antes, e acho que a maioria dos nossos leitores já está familiarizada com os padrões GPGPU como CUDA e OpenCL.

No entanto, ao contrário da abordagem CUDA ou OpenCL, o HSA efetivamente tiraria o desenvolvedor da equação, pelo menos quando se trata de atribuir cargas diferentes a diferentes núcleos de processamento. O hardware decidiria quando transferir os cálculos da CPU para a GPU e vice-versa. O HSA não deve substituir linguagens de programação GPGPU estabelecidas como OpenCL, pois elas também podem ser implementadas em hardware HSA.

Esse é o ponto principal da HSA: deve tornar todo o processo fácil, até mesmo perfeito. Os desenvolvedores não terão necessariamente que pensar em transferir os cálculos para a GPU. O hardware fará isso automaticamente.

Muitos grandes nomes apoiam a HSA. No entanto, os pesos-pesados ​​da indústria Intel e Nvidia não estão na lista.

Muitos grandes nomes apoiam a HSA. No entanto, os pesos-pesados ​​da indústria Intel e Nvidia não estão na lista.
Tweet

Para conseguir isso, a HSA terá que contar com o suporte de vários fabricantes de chips e fornecedores de hardware. Embora a lista de apoiadores da HSA seja impressionante, a Intel está visivelmente ausente desse verdadeiro quem é quem da indústria de chips. Dada a participação de mercado da Intel nos mercados de processadores para desktops e servidores, isso é um grande negócio. Outro nome que você não encontrará na lista é a Nvidia, que é focada em CUDA e atualmente é líder no mercado de computação de GPU.

No entanto, o HSA não foi projetado apenas para sistemas e aplicativos de alto desempenho, em hardware que geralmente exibe um adesivo Intel Inside . O HSA também pode ser usado em dispositivos móveis com eficiência energética, onde a Intel tem uma participação de mercado insignificante.

Então, o HSA deveria facilitar a vida, mas já é relevante? Será que vai pegar? Esta não é uma questão tecnológica, mas econômica. Vai depender da mão invisível do mercado. Então, antes de prosseguirmos, vamos começar dando uma olhada em como as coisas estão agora, e como chegamos aqui.

Desenvolvimento HSA, problemas de dentição e preocupações de adoção

Como eu disse na introdução, HSA não é exatamente um conceito novo. Ele foi originalmente idealizado pela Advanced Micro Devices (AMD), que tinha interesse em tirá-lo do papel. Há uma década, a AMD comprou a ATI, especialista em gráficos, e desde então a empresa vem tentando alavancar seu acesso à tecnologia de GPU de ponta para aumentar as vendas gerais.

À primeira vista, a ideia era bastante simples: a AMD não apenas continuaria desenvolvendo e fabricando GPUs discretas de ponta, mas também integraria a tecnologia GPU da ATI em seus processadores. O departamento de marketing da AMD chamou a ideia de 'Fusion', e a HSA foi chamada de Fusion System Architecture (FSA). Parece ótimo, certo? Obter um processador x86 decente com bons gráficos integrados parecia uma boa ideia, e foi.

Infelizmente, a AMD enfrentou vários problemas ao longo do caminho; Destaco alguns deles:

  • Qualquer boa ideia em tecnologia é fadada a ser adotada pelos concorrentes, neste caso – Intel.
  • A AMD perdeu a vantagem tecnológica para a Intel e achou cada vez mais difícil competir no mercado de CPU devido à liderança da tecnologia de fundição da Intel.
  • A execução da AMD foi problemática e muitos dos novos processadores chegaram tarde ao mercado. Outros foram totalmente descartados.
  • O colapso econômico de 2008 e a subsequente revolução móvel não ajudaram.

Esses e vários outros fatores conspiraram para diminuir a vantagem da AMD e impedir a adoção de seus produtos e tecnologias pelo mercado. A AMD começou a lançar processadores com a nova geração de gráficos integrados Radeon em meados de 2011, e começou a chamá-los de Unidades de Processamento Acelerado (APUs) em vez de CPUs.

Deixando de lado o marketing, a primeira geração de APUs da AMD (codinome Llano) foi um fracasso. Os chips estavam atrasados ​​e não conseguiam acompanhar as ofertas da Intel. Recursos sérios de HSA também não foram incluídos, mas a AMD começou a adicioná-los em sua plataforma de 2012 (Trinity, que foi essencialmente Llano feito corretamente). O próximo passo veio em 2014, com a introdução das APUs Kaveri, que suportavam gerenciamento de memória heterogênea (a GPU IOMMU e a CPU MMU compartilhavam o mesmo espaço de endereço). Kaveri também trouxe mais integração arquitetônica, permitindo memória coerente entre a CPU e a GPU (a AMD chama de hUMA, que significa Heterogeneous Unified Memory Access). A atualização subsequente do Carizzo adicionou ainda mais recursos HSA, permitindo que o processador alterne o contexto das tarefas de computação na GPU e faça mais alguns truques.

A próxima arquitetura de CPU Zen e as APUs construídas sobre ela prometem entregar ainda mais, se e quando aparecer no mercado.

Então qual é o problema?

A AMD não foi a única fabricante de chips a perceber o potencial das GPUs on-die. A Intel também começou a adicioná-los às suas CPUs Core, assim como os fabricantes de chips ARM, de modo que as GPUs integradas são usadas atualmente em praticamente todos os SoCs de smartphones, além da grande maioria dos PCs/Macs. Nesse meio tempo, a posição da AMD no mercado de CPU foi corroída. A queda na participação de mercado tornou as plataformas da AMD menos atraentes para desenvolvedores, empresas e até consumidores. Simplesmente não há muitos PCs baseados em AMD no mercado, e a Apple não usa processadores AMD (embora tenha usado gráficos AMD, principalmente devido à compatibilidade com OpenCL).

A AMD não compete mais com a Intel no mercado de CPUs de última geração, mas mesmo que o fizesse, não faria muita diferença nesse aspecto. As pessoas não compram estações de trabalho de US$ 2.000 ou PCs para jogos para usar gráficos integrados. Eles usam gráficos discretos e caros e não se preocupam muito com a eficiência energética.

Que tal alguns HSA para smartphones e tablets?

Mas espere. E as plataformas móveis? A AMD não poderia simplesmente lançar soluções semelhantes para chips de smartphones e tablets? Bem, não, não realmente.

Veja bem, alguns anos após a aquisição da ATI, a AMD se viu em uma situação financeira difícil, agravada pela crise econômica, então decidiu vender sua divisão de GPU móvel Imageon para a Qualcomm. A Qualcomm renomeou os produtos Adreno (anagrama de Radeon) e passou a se tornar o player dominante no mercado de processadores de smartphones, usando GPUs internas recém-repintadas.

Como alguns de vocês podem notar, vender um equipamento gráfico de smartphone quando a revolução do smartphone estava prestes a começar não parece uma jogada de negócios brilhante, mas acho que a retrospectiva é sempre 20/20.

O HSA costumava ser associado apenas à AMD e seus processadores x86, mas esse não é mais o caso. Na verdade, se todos os membros da HSA Foundation começassem a fornecer processadores para smartphones ARM habilitados para HSA, eles venderiam mais do que os processadores x86 da AMD em várias vezes, tanto em termos de receita quanto de unidades vendidas. Então, o que acontece se eles fizerem isso? O que isso significaria para a indústria e os desenvolvedores?

Bem, para começar, os processadores de smartphones já dependem de computação heterogênea, mais ou menos. A computação heterogênea geralmente se refere ao conceito de usar arquiteturas diferentes em um único chip e, considerando todos os componentes encontrados nos SoCs altamente integrados de hoje, essa pode ser uma definição muito ampla. Como resultado, quase todo SoC pode ser considerado uma plataforma de computação heterogênea, dependendo de seus padrões. Às vezes, as pessoas até se referem a diferentes processadores baseados no mesmo conjunto de instruções como uma plataforma heterogênea (por exemplo, chips móveis com núcleos ARM Cortex-A57 e A53, ambos baseados no conjunto de instruções ARMv8 de 64 bits).

Muitos observadores concordam que a maioria dos processadores baseados em ARM podem agora ser considerados plataformas heterogêneas, incluindo chips da série A da Apple, Samsung Exynos SoCs e processadores semelhantes de outros fornecedores, ou seja, grandes players como Qualcomm e MediaTek.

Mas por que alguém precisaria de HSA em processadores de smartphones? O objetivo de usar GPUs para computação geral não é lidar com cargas de trabalho profissionais, não Angry Birds e Uber?

Sim, mas isso não significa que uma abordagem quase idêntica não possa ser usada para aumentar a eficiência, que é uma prioridade no design de processadores móveis. Assim, em vez de processar inúmeras tarefas paralelizadas em uma estação de trabalho de ponta, o HSA também pode ser usado para tornar os processadores móveis mais eficientes e versáteis.

Poucas pessoas olham de perto esses processadores, geralmente verificam a folha de especificações quando estão comprando um novo telefone e pronto: olham os números e as marcas. Eles geralmente não olham para o próprio SoC , o que nos diz muito, e aqui está o porquê: GPUs em processadores de smartphones de última geração ocupam mais espaço de silício do que CPUs. Considerando que eles já estão lá, seria bom colocá-los em bom uso em outros aplicativos além de jogos, não é?

Um processador de smartphone hipotético e totalmente compatível com HSA pode permitir que os desenvolvedores aproveitem esse potencial sem aumentar muito os custos gerais de produção, implementar mais recursos e aumentar a eficiência.

Aqui está o que a HSA poderia fazer pelos processadores de smartphones, pelo menos em teoria:

  • Melhore a eficiência transferindo tarefas adequadas para a GPU.
  • Aumente o desempenho descarregando a CPU em algumas situações.
  • Utilize o barramento de memória com mais eficiência.
  • Reduza potencialmente os custos de fabricação de chips explorando mais silício de uma só vez.
  • Introduzir novos recursos que não podem ser manipulados pelos núcleos da CPU de maneira eficiente.
  • Simplifique o desenvolvimento em virtude da padronização.

Parece bom, especialmente quando você considera que é improvável que os desenvolvedores percam muito tempo na implementação. Essa é a teoria, mas teremos que esperar para vê-la em ação, e isso pode demorar um pouco.

Como o HSA funciona de qualquer maneira?

Eu já descrevi o básico na introdução e hesito em entrar em muitos detalhes por alguns motivos: ninguém gosta de novelas publicadas em um blog de tecnologia e as implementações de HSA podem ser diferentes.

Portanto, tentarei delinear o conceito em algumas centenas de palavras.

Em um sistema padrão, um aplicativo descarregaria os cálculos da GPU transferindo os buffers para a GPU, o que envolveria uma chamada de CPU antes do enfileiramento. A CPU então agendaria o trabalho e o passaria para a GPU, que o passaria de volta para a CPU após a conclusão. Em seguida, o aplicativo obteria o buffer, que novamente teria que ser mapeado pela CPU antes de estar pronto. Como você pode ver, essa abordagem envolve muitas idas e vindas.

Diferentes arquiteturas em um barramento de memória. Agilizar é a essência da HSA.

Diferentes arquiteturas em um barramento de memória. Agilizar é a essência da HSA.
Tweet

Em um sistema HSA, o aplicativo enfileiraria o trabalho, a CPU do HSA assumiria o controle, o entregaria à GPU, o receberia de volta e o levaria ao aplicativo. Feito.

Isso é possível compartilhando a memória do sistema diretamente entre a CPU e a GPU, embora outras unidades de computação também possam estar envolvidas (DSPs, por exemplo). Para atingir esse nível de integração de memória, o HSA emprega um espaço de endereço virtual para dispositivos de computação. Isso significa que os núcleos de CPU e GPU podem acessar a memória em igualdade de condições , desde que compartilhem tabelas de páginas, permitindo que diferentes dispositivos troquem dados por meio de ponteiros.

Isso obviamente é ótimo para eficiência, porque não é mais necessário alocar memória para a GPU e CPU usando memória virtual para cada uma. Graças à memória virtual unificada, ambos podem acessar a memória do sistema de acordo com suas necessidades, garantindo uma utilização superior dos recursos e mais flexibilidade.

Imagine um sistema de baixo consumo de energia com 4 GB de RAM, 512 MB dos quais são alocados para a GPU integrada. Esse modelo geralmente não é flexível e você não pode alterar a quantidade de memória da GPU em tempo real. Você está preso com 256 MB ou 512 MB, e é isso. Com o HSA, você pode fazer o que quiser: se você descarrega muitas coisas para a GPU e precisa de mais RAM para a GPU, o sistema pode alocá-la. Portanto, em aplicativos vinculados a gráficos, com muitos ativos de alta resolução, o sistema pode acabar alocando 1 GB ou mais de RAM para a GPU, sem problemas.

Se todas as coisas forem iguais, os sistemas HSA e não HSA compartilharão a mesma largura de banda de memória , terão acesso à mesma quantidade de memória , mas o sistema HSA poderá acabar usando-a com muito mais eficiência, melhorando o desempenho e reduzindo o consumo de energia. É tudo sobre como obter mais por menos.

Para que seria boa a computação heterogênea?

A resposta simples? A computação heterogênea, ou HSA como uma de suas implementações, deve ser uma boa escolha para todas as tarefas de computação mais adequadas para GPUs do que CPUs. Mas o que isso significa exatamente, no que as GPUs são boas?

As GPUs modernas e integradas não são muito poderosas em comparação com gráficos discretos (especialmente placas gráficas de jogos de ponta e soluções de estação de trabalho), mas são muito mais poderosas que seus antecessores.

Se você não acompanha, pode supor que essas GPUs integradas são uma piada e, durante anos, eram apenas isso: gráficos para caixas domésticas e de escritório baratas. No entanto, isso começou a mudar na virada da década, quando as GPUs integradas passaram do chipset para o pacote da CPU e morreram, tornando-se verdadeiramente integradas .

É assim que um processador AMD parece hoje em dia. Ainda os chamamos de processadores, mas a GPU ocupa substancialmente mais espaço de silício do que a CPU.

É assim que um processador AMD parece hoje em dia. Ainda os chamamos de processadores, mas a GPU ocupa substancialmente mais espaço de silício do que a CPU.
Tweet

Embora ainda com pouca potência em comparação com as GPUs principais, até as GPUs integradas têm muito potencial. Como todas as GPUs, elas se destacam em cargas de instrução única, vários dados (SIMD) e instrução única, vários segmentos (SIMT). Se você precisar processar muitos números em cargas repetitivas e paralelizadas, as GPUs devem ajudar. As CPUs, por outro lado, ainda são melhores em cargas de trabalho pesadas e ramificadas.

É por isso que as CPUs têm menos núcleos, geralmente entre dois e oito, e os núcleos são otimizados para processamento serial sequencial. As GPUs tendem a ter dezenas, centenas e, nas principais placas gráficas discretas, milhares de núcleos menores e mais eficientes. Os núcleos da GPU são projetados para lidar com várias tarefas simultaneamente, mas essas tarefas individuais são muito mais simples do que aquelas tratadas pela CPU. Por que sobrecarregar a CPU com essas cargas, se a GPU pode lidar com elas com eficiência e/ou desempenho superior?

Mas se as GPUs são tão boas nisso, por que não começamos a usá-las como dispositivos de computação geral anos atrás? Bem, a indústria tentou, mas o progresso foi lento e limitado a certos nichos. O conceito foi originalmente chamado de Computação de Propósito Geral em Unidades de Processamento Gráfico (GPGPU). Antigamente, o potencial era limitado, mas o conceito GPGPU era sólido e foi posteriormente adotado e padronizado na forma de CUDA da Nvidia e OpenCL da Apple/Khronos Group.

CUDA e OpenCL fizeram uma enorme diferença, pois permitiram que os programadores usassem GPUs de uma maneira diferente e muito mais eficaz. Eles eram, no entanto, específicos do fornecedor. Você poderia usar CUDA em hardware Nvidia, enquanto OpenCL era reservado para hardware ATI (e foi adotado pela Apple). A API DirectCompute da Microsoft foi lançada com o DirectX 11 e permitia uma abordagem limitada e independente do fornecedor (mas estava limitada ao Windows).

Vamos resumir listando alguns aplicativos para computação GPU:

  • Computação tradicional de alto desempenho (HPC) na forma de clusters de HPC, supercomputadores, clusters de GPU para cargas de computação, computação GRID, balanceamento de carga.

  • Cargas que exigem física , que podem, mas não necessariamente, envolver jogos ou gráficos em geral. Eles também podem ser usados ​​para lidar com cálculos de dinâmica de fluidos, física estatística e algumas equações e algoritmos exóticos.

  • Geometria , quase tudo relacionado à geometria, incluindo cálculos de transparência, sombras, detecção de colisão e assim por diante.

  • Processamento de áudio , usando uma GPU em vez de DSPs, processamento de fala, processamento de sinal analógico e muito mais.

  • Processamento de imagem digital , é para o que as GPUs são projetadas (obviamente), para que possam ser usadas para acelerar o pós-processamento e a decodificação de imagens e vídeos. Se você precisar decodificar um fluxo de vídeo e aplicar um filtro, até mesmo uma GPU de nível básico limpará o chão com uma CPU.

  • Computação científica , incluindo pesquisa climática, astrofísica, mecânica quântica, modelagem molecular e assim por diante.

  • Outras tarefas computacionalmente intensivas , nomeadamente encriptação/desencriptação. Se você precisa “minerar” criptomoedas, criptografar ou descriptografar seus dados confidenciais, quebrar senhas ou detectar vírus, a GPU pode ajudar.

Esta não é uma lista completa de aplicativos de computação GPU em potencial, mas os leitores não familiarizados com o conceito devem ter uma ideia geral do que torna a computação GPU diferente. Também deixei de fora aplicativos óbvios, como jogos e gráficos profissionais.

De qualquer forma, uma lista abrangente não existe, porque a computação da GPU pode ser usada para todos os tipos de coisas, desde finanças e imagens médicas até cargas de banco de dados e estatísticas. Você está limitado pela sua própria imaginação. A chamada visão computacional é outra aplicação em ascensão. Uma GPU capaz é uma boa coisa se você precisar “ensinar” um drone ou carro sem motorista a evitar árvores, pedestres e outros veículos.

Sinta-se à vontade para inserir sua piada favorita de Lindsay Lohan aqui.

Desenvolvendo para HSA: tempo para algumas más notícias

Esta pode ser minha opinião pessoal e não um fato, mas sou um crente da HSA. Acho que o conceito tem muito potencial, desde que seja implementado corretamente e ganhe bastante apoio entre fabricantes de chips e desenvolvedores. No entanto, o progresso tem sido dolorosamente lento, ou talvez seja apenas o meu sentimento, com uma pitada de pensamento positivo. Eu só gosto de ver novas tecnologias em ação, e sou tudo menos um indivíduo paciente.

O problema com o HSA é que ele ainda não está lá . Isso não significa que não vai decolar, mas pode demorar um pouco. Afinal, não estamos falando apenas de novas pilhas de software; O HSA requer um novo hardware para fazer sua mágica. O problema com isso é que muito desse hardware ainda está na prancheta, mas estamos chegando lá. Devagar.

Infelizmente, a pilha de soluções HSA inclui mais do que o conjunto padrão de ferramentas de software. A computação heterogênea é uma simbiose de software e hardware.

Infelizmente, a pilha de soluções HSA inclui mais do que o conjunto padrão de ferramentas de software. A computação heterogênea é uma simbiose de software e hardware.
Tweet

Isso não significa que os desenvolvedores não estejam trabalhando em projetos relacionados a HSA, mas não há muito interesse ou progresso nesse sentido. Aqui estão alguns recursos que você deve conferir se quiser dar uma chance ao HSA:

  • HSA Foundation @ GitHub é, obviamente, o local para recursos relacionados a HSA. A HSA Foundation publica e mantém vários projetos no GitHub, incluindo depuradores, compiladores, ferramentas HSAIL vitais e muito mais. A maioria dos recursos é projetada para hardware AMD.

  • Os recursos HSAIL fornecidos pela AMD permitem que você tenha uma ideia melhor da especificação HSAIL. HSAIL significa HSA Intermediate Language e é basicamente a ferramenta principal para escritores de compiladores de back-end e escritores de bibliotecas que desejam direcionar dispositivos HSA.

  • HSA Programmer's Reference Manual (PDF) inclui a especificação HSAIL completa, além de uma explicação abrangente da linguagem intermediária.

  • Os recursos da HSA Foundation são limitados por enquanto e o Programa de Desenvolvedores da fundação está “chegando em breve”, mas há várias ferramentas oficiais para desenvolvedores para conferir. Mais importante, eles lhe darão uma boa ideia da pilha que você precisa para começar.

  • O blog oficial da AMD também apresenta alguns conteúdos úteis de HSA.

Isso deve ser suficiente para você começar, desde que você seja do tipo curioso. A verdadeira questão é se você deve ou não se preocupar para começar.

O futuro da computação HSA e GPU

Sempre que cobrimos uma tecnologia emergente, somos confrontados com o mesmo dilema: devemos dizer aos leitores para gastar tempo e recursos nela, ou para se manterem afastados, adotando a abordagem de esperar para ver?

Já deixei claro que sou um pouco tendencioso porque gosto do conceito geral de computação por GPU, mas a maioria dos desenvolvedores pode ficar sem ele, por enquanto. Mesmo se decolar, o HSA terá um apelo limitado e não preocupará a maioria dos desenvolvedores. No entanto, pode ser importante no futuro. Infelizmente para a AMD, é improvável que seja um divisor de águas no mercado de processadores x86, mas pode ser mais importante em processadores móveis baseados em ARM. Pode ter sido ideia da AMD, mas empresas como Qualcomm e MediaTek estão melhor posicionadas para levar hardware habilitado para HSA a centenas de milhões de usuários.

Tem que ser uma simbiose perfeita de software e hardware. Se os fabricantes de chips móveis enlouquecerem com a HSA, seria um grande negócio. Uma nova geração de chips HSA borraria a linha entre os núcleos de CPU e GPU. Eles compartilhariam o mesmo barramento de memória em termos iguais, e acho que as empresas começarão a comercializá-los de maneira diferente. Por exemplo, a AMD já está comercializando suas APUs como “dispositivos de computação” compostos por diferentes “núcleos de computação” (CPUs e GPUs).

Os chips móveis podem acabar usando uma abordagem semelhante. Em vez de comercializar um chip com oito ou dez núcleos de CPU e tal GPU, os fabricantes de chips poderiam começar a falar sobre clusters, módulos e unidades. Portanto, um processador com quatro núcleos de CPU pequenos e quatro grandes seria um processador “dual-cluster” ou “dual-module”, ou um design “tri-cluster” ou “quad-cluster”, se levar em consideração os núcleos da GPU . Muitas especificações técnicas tendem a se tornar sem sentido ao longo do tempo, por exemplo, o DPI na impressora do escritório ou a contagem de megapixels na câmera barata do smartphone.

O HSA permite que diferentes arquiteturas tenham seu próprio peso e lidem com cargas muito diferentes com maior eficiência.

O HSA permite que diferentes arquiteturas tenham seu próprio peso e lidem com cargas muito diferentes com maior eficiência.
Tweet

Mas não é só marketing. Se as GPUs se tornam tão flexíveis quanto os núcleos da CPU e capazes de acessar os recursos do sistema em termos iguais à CPU, por que deveríamos nos preocupar em chamá-las pelo nome real? Duas décadas atrás, a indústria parou de usar coprocessadores matemáticos dedicados (FPUs) quando eles se tornaram um componente obrigatório de todas as CPUs. Apenas alguns ciclos de produtos depois, esquecemos que eles existiam.

Lembre-se de que o HSA não é a única maneira de usar GPUs para computação.

Intel e Nvidia não estão a bordo, e sua abordagem é diferente. A Intel aumentou discretamente o investimento em P&D em GPU nos últimos anos, e suas mais recentes soluções gráficas integradas são muito boas. À medida que as GPUs on-die se tornam mais poderosas e ocupam mais espaço de silício, a Intel terá que encontrar maneiras mais engenhosas de usá-las para computação geral.

A Nvidia, por outro lado, saiu do mercado de gráficos integrados anos atrás (quando parou de produzir chipsets para PC), mas tentou a sorte no mercado de processadores ARM com seus processadores da série Tegra. Eles não foram um grande sucesso, mas ainda são usados ​​em alguns hardwares, e a Nvidia está concentrando seus esforços em sistemas embarcados, principalmente automotivos. Nessa configuração, a GPU integrada tem seu próprio peso, pois pode ser usada para detecção de colisão, navegação interna, mapeamento 3D e assim por diante. Lembra do Projeto Tango do Google? Parte do hardware foi baseado em chips Tegra, permitindo detecção de profundidade e alguns outros truques interessantes. No lado oposto do espectro, a linha de produtos Tesla da Nvidia cobre o mercado de computação de GPU de ponta e garante o domínio da Nvidia nesse nicho nos próximos anos.

Linha inferior? No papel, a computação GPU é um grande conceito com muito potencial, mas o estado atual da tecnologia deixa muito a desejar. A HSA deve percorrer um longo caminho para resolver a maioria desses problemas. Além disso, não é suportado por todos os participantes do setor, o que deve retardar ainda mais a adoção.

Pode levar alguns anos, mas estou confiante de que as GPUs acabarão por assumir seu lugar de direito na arena geral da computação, mesmo em chips móveis. A tecnologia está quase pronta, e a economia fará o resto. Quão? Bem, aqui está um exemplo simples. Os processadores Atom da geração atual da Intel apresentam de 12 a 16 GPU Execution Units (EUs), enquanto seus antecessores tinham apenas quatro EUs, baseados em uma arquitetura mais antiga. À medida que as GPUs integradas se tornam maiores e mais poderosas, e à medida que sua área de matriz aumenta, os fabricantes de chips não terão escolha a não ser usá-las para melhorar o desempenho e a eficiência gerais. Não fazer isso seria ruim para as margens e os acionistas.

Não se preocupe, você ainda poderá desfrutar de jogos ocasionais nesta nova geração de GPU. No entanto, mesmo quando você não está jogando, a GPU fará muitas coisas em segundo plano, descarregando a CPU para aumentar o desempenho e a eficiência.

Acho que todos podemos concordar que isso seria um grande negócio, especialmente em dispositivos móveis baratos.

Relacionado: Uma breve visão geral da API Vulkan