CUDA para AMD no Windows Funciona, mas Apenas por Meio de um Caminho Estreito de Compatibilidade

Usuários de AMD agora têm uma configuração reproduzível de CUDA para AMD no Windows, embora CUDA continue sendo uma plataforma da NVIDIA. O projeto comunitário traduz chamadas CUDA selecionadas por meio do ZLUDA e depois as executa pelas bibliotecas HIP da AMD. Seu criador relata uma carga de trabalho concluída de treinamento de IA em uma Radeon RX 9060 XT.

Essa conquista é relevante porque atravessa uma fronteira difícil. Desenvolvedores podem começar com um aplicativo Windows criado para a pilha de software da NVIDIA e executá-lo em uma configuração AMD compatível. Eles não precisam primeiro reescrever esse aplicativo para HIP.

No entanto, o resultado não torna CUDA independente de hardware. A configuração depende de uma camada de compatibilidade, versões de software fixadas e substituições incompletas de bibliotecas. Atualmente, apenas um modelo de GPU tem status validado no projeto.

A disputa real, portanto, não é simplesmente entre hardware AMD e NVIDIA. Trata-se da compatibilidade com aplicativos CUDA existentes versus a confiabilidade do suporte nativo do fornecedor. A nova configuração avança o primeiro objetivo sem entregar o segundo.

O Projeto Transforma um Binário CUDA em uma Carga de Trabalho AMD

A mudança importante é um caminho documentado e repetível de um aplicativo Windows voltado a CUDA para uma GPU AMD.

O projeto de compatibilidade de código aberto reúne scripts de instalação, preparação do ambiente de execução, diagnósticos e validação. Ele se baseia no ZLUDA e no software HIP para Windows da AMD, em vez de implementar outro runtime de GPU do zero.

ZLUDA é uma camada de tradução que apresenta interfaces compatíveis com CUDA a um aplicativo. Ela redireciona operações compatíveis para funções correspondentes disponíveis na pilha de GPU hospedeira.

HIP, a Heterogeneous-compute Interface for Portability, é o runtime C++ e a linguagem de kernels da AMD para software portátil de GPU. Nesta configuração, HIP fornece a camada inferior que, em última instância, se comunica com a GPU Radeon.

O caminho começa com um programa Windows que espera componentes NVIDIA CUDA. ZLUDA recebe essas chamadas e direciona operações de bibliotecas compatíveis para equivalentes da AMD.

Por exemplo, operações cuBLAS podem chegar ao rocBLAS, enquanto chamadas cuSPARSE podem chegar ao rocSPARSE. Essas bibliotecas lidam com cargas de trabalho comuns de álgebra linear e matrizes esparsas.

O repositório inclui um instalador PowerShell que verifica a GPU detectada, o driver, o HIP SDK e as bibliotecas matemáticas necessárias. Em seguida, ele baixa uma compilação fixada do ZLUDA e verifica os arquivos baixados por meio de hashes SHA-256.

O instalador também pode obter o LibTorch 2.3.0 compilado para CUDA 11.8. LibTorch é a distribuição C++ do PyTorch, usada quando aplicativos incorporam funções do PyTorch sem um runtime Python.

Esse download tem cerca de 2,66 GB, segundo o repositório. Usuários que não precisam de LibTorch podem ignorá-lo.

Após a instalação, os scripts criam relatórios específicos da máquina sobre o runtime e a GPU. Outro diagnóstico executa o utilitário cuda_check do ZLUDA na pilha AMD instalada.

Iniciar um aplicativo exige o script wrapper do projeto. Ele coloca as bibliotecas de compatibilidade necessárias ao lado do executável de destino e configura os caminhos do runtime HIP para esse processo.

Esse modelo de preparação local limita mudanças em todo o sistema. Também expõe uma fraqueza central: cada aplicativo ainda depende das funções e bibliotecas CUDA exatas que o ZLUDA consegue traduzir.

O projeto relata verificações bem-sucedidas para a interface do driver CUDA, cuBLAS, cuBLASLt, cuSPARSE e cuFFT. Esses resultados se aplicam à máquina validada e à combinação de software usadas pelo projeto.

Eles não estabelecem compatibilidade geral entre aplicativos Windows. Um programa pode passar em verificações básicas de runtime e posteriormente atingir uma função incompatível durante outra carga de trabalho.

O repositório afirma que apenas a Radeon RX 9060 XT, identificada pelo destino gfx1200 da AMD, possui status de referência validada. Outras arquiteturas Radeon detectadas permanecem candidatas não verificadas.

Essa linguagem é importante. Detecção significa que um script reconhece o dispositivo e sua arquitetura. Não significa que o aplicativo, a camada de tradução e as bibliotecas funcionarão juntos.

Por Que CUDA para AMD no Windows É Importante Agora

O projeto ataca o custo de migração em torno de aplicativos CUDA, não a propriedade de CUDA nem a vantagem de hardware da NVIDIA.

CUDA é a plataforma e o modelo de programação de computação paralela da NVIDIA. Seu modelo de programação abrange execução de kernels, gerenciamento de memória, sincronização e bibliotecas otimizadas para GPUs NVIDIA.

Muitos aplicativos dependem de mais do que código-fonte com estilo CUDA. Eles chamam bibliotecas como cuBLAS, cuFFT, cuSPARSE e cuDNN, enquanto dependem de comportamentos específicos do runtime.

Esse software acumulado cria custos de troca. Comprar uma GPU diferente não torna automaticamente portátil um programa Windows direcionado a CUDA.

Normalmente, desenvolvedores têm três opções amplas. Podem permanecer no hardware NVIDIA, portar o programa para outra interface ou colocar uma camada de tradução entre o aplicativo e o hardware.

A AMD oferece suporte à rota de portabilidade por meio do HIP. Suas ferramentas HIPIFY traduzem muitas construções de código-fonte CUDA para C++ HIP portátil.

A conversão de código-fonte pode ser uma escolha sólida de longo prazo quando os desenvolvedores controlam o aplicativo. Ela também exige testes, manutenção e, às vezes, alterações manuais em torno de APIs não compatíveis.

Essa rota pouco ajuda um usuário que possui apenas um binário Windows compilado. Ela também cria trabalho para pequenas equipes que mantêm dependências específicas de CUDA.

ZLUDA mira essa lacuna. Ele tenta preservar a interface voltada a CUDA que o aplicativo espera, enquanto traduz operações em tempo de execução.

Essa abordagem se assemelha mais a uma ponte de compatibilidade do que a um novo padrão de programação. O aplicativo continua falando CUDA, enquanto a ponte mapeia solicitações compatíveis para a pilha de software da AMD.

O Windows torna o problema particularmente relevante. A AMD expandiu seu suporte a computação por GPU nessa plataforma, mas sua pilha Windows historicamente expôs menos componentes que o ROCm no Linux.

A AMD descreve o Windows HIP SDK como um subconjunto da plataforma ROCm mais ampla. Suas matrizes de suporte também limitam a cobertura oficial aos sistemas operacionais e GPUs listados.

Lançamentos recentes do ROCm melhoraram as opções nativas no Windows, incluindo suporte ao PyTorch em hardware Radeon selecionado. O suporte nativo reduz a necessidade de tradução quando os aplicativos já oferecem um caminho AMD.

Ainda assim, o suporte nativo ao PyTorch não resolve todas as dependências CUDA. Um aplicativo Windows pode incluir uma compilação LibTorch específica para CUDA ou carregar diretamente bibliotecas NVIDIA.

O novo repositório aborda essa situação menos conveniente. Sua motivação declarada foi um aplicativo de treinamento LibTorch voltado a CUDA que precisava ser executado em uma GPU AMD de desktop.

O projeto relata que seu aplicativo de teste concluiu inferência, atualizações de aprendizado por reforço e trabalho de otimizador. A rede continha 2.216.347 parâmetros e executou uma iteração de validação cobrindo 65.536 timesteps.

Esses números descrevem uma carga de trabalho real, e não uma sonda sintética de API. Eles dão ao projeto mais credibilidade do que um launcher que apenas abre uma janela de aplicativo.

Ainda assim, o teste permanece restrito. Uma rede de aprendizado por reforço relativamente pequena não pode representar todos os transformers, geradores de imagens, simulações científicas ou pipelines de renderização.

A pressão de desenvolvimento recai mais diretamente sobre a experiência de software Windows da AMD. Cada experimento de compatibilidade bem-sucedido evidencia a demanda por aplicativos que ainda assumem CUDA.

A NVIDIA também enfrenta um tipo diferente de pressão. Camadas de tradução testam quanto da base de aplicativos CUDA depende de interfaces essenciais que outro runtime consegue reproduzir.

Nenhuma das duas pressões produz uma mudança imediata de plataforma. Elas mostram, porém, que desenvolvedores continuam procurando formas de contornar fronteiras de aplicativos específicas de fornecedores.

O Mecanismo Preserva APIs, Não a Plataforma CUDA Completa

ZLUDA pode traduzir interfaces selecionadas, mas aplicativos CUDA frequentemente dependem de comportamentos que vão muito além dessas interfaces.

Um aplicativo CUDA normalmente contém código hospedeiro executado na CPU e trabalho de dispositivo executado na GPU. O hospedeiro aloca memória, transfere dados e inicia kernels.

O binário também pode chamar bibliotecas otimizadas. Essas bibliotecas frequentemente determinam se um aplicativo de IA ou científico funciona a uma velocidade útil.

ZLUDA apresenta substitutos para componentes voltados a CUDA e os conecta a backends não NVIDIA. Em hardware AMD, esses backends usam bibliotecas HIP e ROCm.

Esse modelo pode funcionar bem quando um programa permanece dentro das funções de runtime implementadas e das bibliotecas mapeadas. Ele se torna frágil quando o aplicativo espera comportamentos ausentes.

A compatibilidade de versões adiciona outra camada. Aplicativos CUDA podem ter como alvo diferentes toolkits, formatos binários, bibliotecas e pressupostos de compilador.

O repositório fixa ZLUDA v6 preview 69, AMD HIP SDK 6.4 e LibTorch 2.3.0 com CUDA 11.8. A fixação transforma uma coleção dinâmica de dependências em uma combinação testável.

Essa disciplina melhora a reprodutibilidade. Ela também significa que os usuários não devem presumir que componentes mais novos são intercambiáveis.

Um HIP SDK mais recente pode alterar caminhos de bibliotecas, símbolos exportados ou destinos de dispositivo compatíveis. Um aplicativo mais recente voltado a CUDA pode chamar funções que sua camada de compatibilidade fixada não implementa.

O projeto relata que cuBLAS, cuBLASLt, cuSPARSE e cuFFT passaram em sua verificação de runtime. Esses componentes abrangem operações importantes de matrizes, computação esparsa e transformadas de Fourier.

A peça ausente mais significativa é cuDNN. A biblioteca CUDA Deep Neural Network da NVIDIA fornece primitivas otimizadas usadas por muitas cargas de trabalho de redes neurais.

O repositório afirma que cuDNN não está disponível em sua configuração validada com o Windows HIP SDK estável. Ele também observa que o SDK não possui a coleção completa de bibliotecas ROCm AI disponível em outros ambientes.

Essa omissão cria uma fronteira rígida para aplicativos. Softwares com forte uso de convoluções que esperam cuDNN podem falhar, exigir uma pilha de desenvolvimento mais recente ou necessitar de trabalho adicional de compatibilidade.

A carga de trabalho bem-sucedida de aprendizado por reforço não exigiu cuDNN em seu caminho testado. Operações de matrizes densas foram suficientes para as funções que ela executou.

Esse detalhe explica tanto o resultado quanto seus limites. O projeto selecionou uma carga de trabalho compatível com as bibliotecas disponíveis em sua máquina.

A tradução em runtime também difere da portabilidade de código-fonte. O código HIP pode ser compilado e otimizado para diferentes backends, enquanto uma camada de compatibilidade binária precisa inferir e redirecionar comportamentos existentes.

O trabalho em nível de código-fonte dá aos desenvolvedores mais controle sobre ajustes específicos de arquitetura. A tradução oferece acesso inicial mais rápido quando modificar o aplicativo original é impraticável.

Nenhum dos métodos garante desempenho idêntico. GPUs diferem em largura de execução, comportamento de memória, suporte a instruções e hardware especializado.

Uma função traduzida pode produzir saída correta usando um caminho menos eficiente. Por outro lado, uma biblioteca do fornecedor mapeada pode ter bom desempenho porque a AMD já otimizou a operação subjacente.

Isso explica por que um único benchmark não pode resolver a questão mais ampla de desempenho. A sobrecarga de tradução é apenas um fator, enquanto a seleção de bibliotecas e o comportamento dos kernels podem dominar o tempo total de execução.

O repositório registrou uma comparação controlada em 13 de setembro de 2026. Ele executou dez iterações por runtime na mesma carga de trabalho de aprendizado por reforço da RX 9060 XT.

Após remover a primeira iteração de aquecimento de cada teste, o caminho upstream alcançou uma mediana reportada de 13.278 etapas totais por segundo. Uma sobreposição personalizada recuperada alcançou 12.876.

O repositório calcula que a sobreposição personalizada foi cerca de 3,03% mais lenta nesse teste. Por isso, mantém o caminho upstream público como padrão.

Esta comparação avalia duas configurações de compatibilidade em uma única máquina. Ela não compara a placa Radeon com uma GPU NVIDIA nem com uma implementação HIP nativa.

Os números históricos no repositório usaram outra configuração de treinamento. Eles não podem ser comparados diretamente com o teste controlado.

Para desenvolvedores, o resultado útil é mais simples. Os componentes públicos concluíram a carga de trabalho escolhida sem arquivos binários privados ou recuperados.

Isso torna o procedimento mais fácil de inspecionar e reproduzir. Resultados independentes em outro hardware determinarão se ele se tornará mais do que uma referência de uma única máquina.

Uma GPU Verificada Deixa uma Grande Lacuna de Compatibilidade

A configuração é um experimento com evidências, não um suporte geral a CUDA para placas Radeon.

A RX 9060 XT é atualmente o único dispositivo validado listado pelo projeto. Os scripts reconhecem famílias adicionais de arquiteturas AMD, mas as classificam como candidatas.

A matriz de suporte oficial da AMD é uma limitação separada. A empresa afirma que GPUs ausentes de sua tabela atual não são oficialmente compatíveis com a distribuição Windows relevante.

Mesmo uma GPU listada não herda a validação do repositório. O suporte oficial ao HIP e um teste bem-sucedido de tradução de CUDA avaliam camadas diferentes do sistema.

Um usuário precisa de um driver AMD compatível, uma instalação HIP funcional, bibliotecas compatíveis, comportamento correto do ZLUDA e um aplicativo que permaneça dentro da cobertura implementada.

A falha em qualquer camada pode produzir um erro ou resultado incorreto. Alguns problemas surgirão durante a instalação, enquanto outros aparecerão apenas após computação prolongada.

A correção merece mais atenção do que o simples sucesso na inicialização do aplicativo. Cargas de trabalho numéricas podem ser concluídas produzindo resultados diferentes devido ao comportamento de precisão, bibliotecas ou implementação.

Um plano de validação sério deve comparar resultados esperados, comportamento do treinamento e repetibilidade. Ele também deve testar pressão de memória, execuções longas e recuperação de erros.

O repositório fornece scripts e uma carga de trabalho documentada, o que ajuda outros usuários a iniciar esse processo. A validação independente continua escassa porque o projeto é novo e a cobertura de hardware é limitada.

O próprio ZLUDA descreve seu software como um substituto direto de CUDA para GPUs que não são da NVIDIA. Seu repositório público também traz uma longa lista de mudanças de implementação e versões de prévia.

No entanto, uma interface direta não equivale a compatibilidade comportamental completa. O histórico de versões do ZLUDA reflete correções contínuas para carregadores, comportamento do compilador, tipos de dados e tratamento de versões de CUDA.

Software de prévia pode introduzir regressões. Um projeto que fixa uma versão funcional evita parte dessas mudanças, mas também deixa de receber correções posteriores de compatibilidade.

Softwares de segurança do Windows criam outro risco prático. A interceptação em tempo de execução e o redirecionamento de bibliotecas podem se assemelhar a técnicas usadas por software malicioso.

Os usuários devem obter binários apenas de versões upstream identificadas e verificar hashes. Eles não devem desativar controles amplos de segurança apenas para forçar a execução de um pacote desconhecido.

A verificação de hash do repositório é útil nesse caso. Ela reduz a chance de que um download alterado entre silenciosamente no ambiente de execução.

Ela não audita o código upstream nem estabelece a segurança de cada dependência. As organizações devem aplicar seus procedimentos normais de revisão de software e controle de artefatos.

O licenciamento também exige tratamento cuidadoso. O repositório inclui sua própria licença e avisos de terceiros, enquanto o ZLUDA usa licenças de código aberto.

CUDA continua sendo uma plataforma NVIDIA com componentes proprietários e termos de licenciamento. Os usuários precisam entender quais arquivos redistribuíveis seu aplicativo contém e o que a configuração de compatibilidade baixa.

O repositório enfatiza um caminho apenas com upstream público. Essa escolha ajuda a separar o método atual de arranjos experimentais anteriores que envolviam bibliotecas recuperadas ou privadas.

Equipes corporativas enfrentam outra questão: quem oferece suporte. A AMD não oferece suporte oficial a uma receita comunitária de compatibilidade com CUDA simplesmente porque ela usa o SDK HIP.

A NVIDIA não oferece suporte a aplicativos CUDA executados em GPUs AMD. O mantenedor do projeto não pode substituir os compromissos de serviço de nenhum dos fornecedores.

Isso torna a configuração pouco adequada para cargas de trabalho que exigem disponibilidade garantida sem uma extensa qualificação interna. Ela permanece mais atraente para laboratórios, entusiastas e desenvolvedores que testam portabilidade.

As equipes que a avaliam devem preservar relatórios da máquina, versões exatas dos pacotes, resultados de validação e logs do aplicativo. Uma base de conhecimento de engenharia pesquisável pode manter esses artefatos vinculados a cada teste.

Elas também devem isolar os testes dos ambientes de produção. Uma máquina dedicada ou uma imagem descartável do Windows facilita a reversão quando drivers ou bibliotecas entram em conflito.

A questão central não é se uma amostra inicia. É se o aplicativo exato produz resultados corretos e repetíveis no hardware exigido pela equipe.

Camadas de Compatibilidade Colocam a Vantagem de Software do CUDA Sob um Novo Teste

O projeto desafia a dependência de aplicativos em CUDA nas margens, ao mesmo tempo que reforça o quanto a compatibilidade completa continua difícil.

A vantagem da NVIDIA inclui hardware, drivers, compiladores, ferramentas de depuração, bibliotecas otimizadas, documentação e anos de integração com aplicativos. CUDA é a interface que conecta essas peças.

Um projeto de compatibilidade pode reproduzir chamadas selecionadas sem reproduzir todo esse ambiente de desenvolvimento. Essa diferença explica por que esses projetos atraem atenção antes de alcançar ampla confiabilidade.

Para a AMD, a compatibilidade oferece uma forma de alcançar aplicativos que os fornecedores não portaram. O suporte nativo a ROCm e HIP continua sendo a rota mais limpa quando os desenvolvedores mantêm ambos os backends.

As duas estratégias podem coexistir. A tradução atende a binários CUDA existentes, enquanto HIP oferece suporte a software projetado ou convertido para implantação entre fornecedores.

DirectML e outras interfaces do Windows oferecem alternativas adicionais. Elas podem fornecer aceleração independente de fornecedor, mas os aplicativos precisam adotá-las explicitamente.

OpenCL e SYCL também buscam portabilidade em níveis diferentes. Sua presença não eliminou as bibliotecas específicas de CUDA nem as premissas dos aplicativos.

A discussão no Hacker News expôs essa tensão. Alguns comentaristas argumentaram que padrões abertos merecem mais atenção porque interfaces fechadas restringem a escolha de hardware.

Outros enfatizaram que interfaces portáveis frequentemente oferecem experiências piores para desenvolvedores. Outra visão crítica sustentou que a otimização específica de hardware impede que uma camada genérica corresponda a todos os fornecedores.

Ambas as posições descrevem limitações reais. Os desenvolvedores querem portabilidade, mas kernels de alto desempenho dependem de detalhes de arquitetura e bibliotecas ajustadas.

ZLUDA escolhe compatibilidade em vez de pureza. Ele permite que o aplicativo mantenha suas premissas voltadas para CUDA e traduz o que consegue.

Essa abordagem reduz o trabalho inicial de migração. Ela também preserva CUDA como a linguagem esperada pelo aplicativo, em vez de substituí-la por um padrão independente.

Essa é a inversão central do projeto. Executar um programa voltado para CUDA em AMD pode enfraquecer a dependência de hardware, enquanto mantém intacta a dependência de software em CUDA.

Se mais aplicativos funcionarem, CUDA poderá atuar como uma interface amplamente visada cujos binários alcançam vários backends. Esse resultado pressionaria a exclusividade de hardware da NVIDIA.

Se a compatibilidade continuar específica a cada carga de trabalho, os experimentos poderão, em vez disso, demonstrar a profundidade da integração de software da NVIDIA. Cada biblioteca ausente se torna mais um motivo para que desenvolvedores permaneçam em hardware CUDA compatível.

O progresso nativo da AMD no Windows altera esse cálculo. Melhores bibliotecas HIP e suporte mais amplo ao PyTorch oferecem uma base mais forte para projetos de tradução.

Eles também reduzem a necessidade de tradução quando aplicativos podem adotar pacotes oficiais da AMD. Essa é uma forma saudável de sobreposição, não necessariamente um conflito.

O sinal competitivo importante será o comportamento do aplicativo. Matrizes de suporte importam, mas os usuários vivenciam a compatibilidade por meio de programas que instalam, concluem o trabalho e retornam resultados corretos.

Uma lista de nomes de APIs traduzidas não pode substituir essa evidência. Tampouco um benchmark isolado sem implementação nativa comparável.

Os relatórios futuros mais valiosos descreverão a versão do aplicativo, GPU, driver, SDK HIP, versão do ZLUDA, bibliotecas exercitadas, verificações de saída e desempenho sustentado.

Relatos negativos serão igualmente importantes. Uma falha documentada identifica a função ausente ou a premissa incompatível que os mantenedores precisam corrigir.

Essa evidência também pode orientar fornecedores de aplicativos. Falhas repetidas em torno de uma dependência podem justificar um backend HIP nativo ou outro caminho de execução portátil.

Portanto, o repositório importa mesmo que nunca se torne um runtime universal. Ele cria uma superfície de teste reproduzível para medir onde a dependência de CUDA começa e termina.

Três Sinais Determinarão o Que Acontece a Seguir

Relatos de hardware mais amplo, cobertura mais profunda de bibliotecas e resultados estáveis de aplicativos decidirão se isso se tornará uma opção prática no Windows.

O primeiro sinal é a validação independente em GPUs Radeon adicionais. O resultado da RX 9060 XT precisa ser replicado em hardware RDNA3 e RDNA4 oficialmente compatível.

Relatos bem-sucedidos devem incluir versões exatas e verificações de saída. Uma simples captura de tela ou o nome do dispositivo detectado não estabelecerá compatibilidade com a carga de trabalho.

Vários resultados consistentes reforçariam a alegação de que a configuração é portátil entre os dispositivos Windows da AMD. Falhas frequentes específicas de arquitetura a restringiriam a uma configuração de referência.

O segundo sinal é a cobertura de cuDNN ou equivalente para redes neurais. Muitos aplicativos de IA dependem de operações que a pilha estável validada atualmente não fornece por esse caminho.

O suporte pode chegar por uma distribuição HIP mais recente, mapeamentos adicionais do ZLUDA, mudanças no aplicativo ou outra ponte de biblioteca. Cada rota acarreta custos de manutenção diferentes.

Aplicativos funcionais com uso intenso de convolução ampliariam materialmente a relevância do projeto. A ausência contínua manteria muitas cargas de trabalho de imagens e modelos fora de seu alcance prático.

O terceiro sinal é a estabilidade entre atualizações de aplicativos e toolkits. O sucesso atual depende de versões fixadas do ZLUDA, HIP e LibTorch voltado para CUDA.

Os desenvolvedores devem observar se versões posteriores do ZLUDA preservam o teste, se pacotes HIP mais novos para Windows continuam compatíveis e se aplicativos mais recentes introduzem chamadas não suportadas.

Um projeto de compatibilidade ganha valor quando atualizações não exigem redescobrir uma combinação frágil. Regressões indicariam que a abordagem ainda necessita de manutenção manual intensiva.

O desempenho deve vir depois da correção nessa avaliação. Um aplicativo traduzido que ocasionalmente retorna resultados errados tem pouco valor, independentemente da taxa de processamento.

Após a correção, as comparações devem incluir uma compilação HIP nativa quando houver uma disponível. Elas também devem usar configurações equivalentes do aplicativo e o mesmo hardware.

Comparações com NVIDIA podem responder a uma questão de compra, mas não isolam a sobrecarga de tradução. A arquitetura da GPU, a capacidade de memória e as bibliotecas do fornecedor podem afetar o resultado.

O projeto atual já ultrapassou um limiar significativo. Ele transformou uma coleção de componentes upstream em um procedimento reproduzível no Windows e concluiu sua carga de trabalho motivadora.

Ele ainda não atingiu o patamar sugerido por seu título marcante. CUDA para AMD no Windows continua sendo uma promessa de compatibilidade vinculada a softwares específicos e a uma GPU validada.

Desenvolvedores interessados em testar devem começar pelas versões documentadas no repositório e pelos scripts de diagnóstico. Antes de instalar qualquer coisa, devem verificar se sua GPU consta na lista atual de suporte da AMD.

Em seguida, devem escolher uma carga de trabalho com um resultado de referência comprovadamente correto. Essa referência importa mais do que o fato de o programa detectar um dispositivo chamado CUDA.

As equipes devem registrar falhas e publicar relatórios de compatibilidade reproduzíveis sempre que possível. Evidências compartilhadas mostrarão se a ponte é compatível com uma categoria de aplicações ou apenas com exemplos isolados.

A questão mais ampla agora pode ser medida: quanto software CUDA pode migrar para hardware AMD sem alterações no código-fonte, e o que falha primeiro?

Nos próximos meses, acompanhe a matriz de compatibilidade, o progresso relacionado ao cuDNN e os resultados de aplicações reais no Windows. Esses sinais determinarão se CUDA para AMD no Windows se tornará confiável ou continuará sendo um experimento instrutivo.