Mod FSR 4 para AMD BC-250 reduz pela metade o tempo de upscaling, mas o verdadeiro teste é o gameplay

O processamento do AMD BC-250 com FSR 4 tornou-se drasticamente mais rápido, segundo benchmarks divulgados junto de uma DLL FidelityFX desenvolvida pela comunidade. Em 1440p, o custo de upscaling relatado caiu de 11,51 milissegundos para 5,92 milissegundos. Essa redução transforma o FSR 4 de um experimento caro em uma opção mais plausível para esta incomum placa baseada em RDNA.

O resultado importa porque o BC-250 nunca foi projetado como um PC gamer convencional. A AMD produziu seu processador semicustomizado para sistemas de mineração da ASRock, usando silício estreitamente relacionado ao processador do PlayStation 5. Posteriormente, entusiastas do Linux reaproveitaram placas descartadas como máquinas compactas para jogos por meio de firmware personalizado, drivers, refrigeração e ferramentas de instalação.

A nova versão desloca o problema central da compatibilidade básica para o desempenho prático. O trabalho anterior de otimização dependia de uma pilha gráfica Mesa modificada. A implementação mais recente reúne suas alterações em uma biblioteca FidelityFX portátil, que usuários podem instalar junto de ferramentas como OptiScaler e Proton.

No entanto, os números divulgados medem o próprio upscaler, e não o desempenho completo em jogos. O desenvolvedor publicou medições sintéticas da RC9, enquanto novos testes de gameplay ainda são limitados. A conquista é suficientemente real para ser analisada, mas seu valor ainda depende de estabilidade, qualidade de imagem e resultados em jogos reais.

Processamento FSR 4 do AMD BC-250 cai em três resoluções

A versão RC9 reduz aproximadamente pela metade o custo medido do FSR 4.1.1 em 1080p, 1440p e 4K.

O resultado mais importante vem de uma saída de 2560 x 1440 usando uma entrada Quality de 1706 x 960. Os shaders originais do FSR 4.1.1 supostamente exigiam 11,51 milissegundos para o dispatch completo de upscaling. A versão 4.0.0-rc9 concluiu a mesma carga de trabalho medida em 5,92 milissegundos.

Isso representa uma redução de cerca de 49 por cento. Também devolve quase 5,6 milissegundos ao restante do pipeline de renderização. Essa diferença é substancial quando um jogo voltado a 60 quadros por segundo dispõe de apenas 16,67 milissegundos para cada quadro.

As outras resoluções registradas seguem o mesmo padrão. Em 1920 x 1080, o tempo de processamento caiu de 7,13 milissegundos para 3,93 milissegundos. Em 3840 x 2160, recuou de 25,72 milissegundos para 12,08 milissegundos.

Esses resultados equivalem a reduções de aproximadamente 45 por cento e 53 por cento, respectivamente. Portanto, a melhoria não parece estar limitada a um único tamanho de saída. A economia absoluta se torna maior à medida que a resolução de saída aumenta e o upscaler processa mais pixels.

A versão RC9 do desenvolvedor disponibiliza o código otimizado como amd_fidelityfx_upscaler_dx12.dll. Essa biblioteca atua como o provedor de upscaling FidelityFX em caminhos de integração compatíveis. Ela substitui o componente relevante do upscaler sem exigir a compilação personalizada anterior do Mesa.

Segundo o resumo de testes publicado, esses números representam custos isolados de dispatch do FSR. Eles não são medições do tempo total de quadro nem do desempenho médio em jogos. Trabalho de CPU, renderização do jogo, compilação de shaders, camadas de tradução e sincronização de tela permanecem fora da medição.

Essa distinção impede uma conversão direta entre milissegundos economizados e quadros ganhos. Um jogo limitado pela CPU pode apresentar pouca melhora. Um jogo fortemente limitado pela GPU pode se beneficiar mais, especialmente quando o passe anterior de upscaling consumia uma grande parcela do orçamento de quadro.

Ainda assim, os números enfrentam um obstáculo específico. Executar o FSR 4 no BC-250 já era tecnicamente possível antes da RC9, mas o upscaler podia consumir a maior parte do orçamento de quadro em altas taxas de atualização. Cortar essa carga quase pela metade torna testes mais amplos justificáveis.

A versão, portanto, muda a pergunta. A comunidade não precisa mais perguntar apenas se o FSR 4 pode ser executado na placa. Agora ela pode perguntar se o caminho otimizado melhora a experiência completa de jogo o suficiente para justificar a instalação.

Uma DLL FidelityFX portátil substitui a rota Mesa personalizada

O principal avanço é a portabilidade, porque a otimização agora acompanha o upscaler em vez de um driver gráfico especializado.

A otimização original do BC-250 tinha como alvo o Mesa, a pilha gráfica de código aberto amplamente usada em sistemas Linux. Ela modificava o tratamento, pelo driver RADV Vulkan, das operações INT8 utilizadas pelo FSR 4. INT8 se refere à aritmética de inteiros de oito bits, usada por modelos de aprendizado de máquina para reduzir custos de processamento e memória.

Esse trabalho enfrentava uma limitação incomum do processador gráfico GFX1013 do BC-250. A placa consegue executar a carga de trabalho necessária, mas seu caminho de produto escalar de inteiros empacotados com sinal apresenta baixo desempenho. Um produto escalar combina múltiplas multiplicações e somas, o que o torna uma operação comum em modelos neurais de processamento de imagem.

O projeto anterior substituiu esse caminho custoso por uma sequência mais adequada ao BC-250. Seu repositório descreve uma compilação experimental do Mesa que usa instruções inteiras alternativas, em vez de depender da rota nativa problemática. A modificação visava um identificador de dispositivo específico e um conjunto de shaders validado.

Essa abordagem comprovou a oportunidade de desempenho, mas colocou a implantação dentro da pilha de drivers. Os usuários precisavam de uma compilação dedicada do Mesa e tinham de iniciar os jogos com a configuração Vulkan correta. Modificações no driver também acarretam custos de manutenção quando o Mesa, o Proton ou uma distribuição Linux muda.

A implementação portátil transfere a otimização para a DLL FidelityFX. Isso transforma o upscaler em um componente substituível, em vez de uma variação de driver para todo o sistema. Os usuários podem colocar a biblioteca em uma configuração compatível de jogo ou adaptador e removê-la sem recompilar o Mesa.

O guia de instalação do projeto afirma que a RC9 não exige a ferramenta de compatibilidade mais antiga nem uma instalação especial de driver. Seu escopo testado continua sendo o hardware BC-250 executando Linux por meio do Proton convencional. Proton é a camada de compatibilidade da Valve para executar jogos de Windows no Linux.

O OptiScaler pode atuar como adaptador entre um jogo e a biblioteca FidelityFX. Ele intercepta um caminho de upscaling disponível e fornece o backend selecionado. O menu de um jogo ainda pode exibir DLSS, FSR ou XeSS mesmo quando o provedor FidelityFX injetado realiza o upscaling final.

Esse arranjo oferece flexibilidade, mas também adiciona variáveis de configuração. O jogo precisa de uma entrada temporal compatível, ou seja, vetores de movimento e outros dados de quadro necessários para reconstruir uma imagem em resolução mais alta. A DLL, por si só, não pode adicionar essas informações a um título que nunca as produz.

Os usuários também precisam verificar se a RC9 é o provedor ativo. O projeto recomenda ativar a marca d'água integrada e procurar os rótulos FSR-INT8, 4.1.1R9 e de fonte local. Uma soma de verificação confirma o arquivo instalado, enquanto a marca d'água renderizada verifica qual provedor processou a imagem.

Isso importa porque vários componentes de upscaling podem coexistir dentro de um prefixo Proton ou de um diretório de jogo modificado. Atualizações automáticas de driver, arquivos existentes do OptiScaler e patches de jogos podem restaurar silenciosamente outra biblioteca. Um menu funcional não prova que o modelo otimizado está renderizando a cena.

Portabilidade, portanto, não significa compatibilidade universal. Significa que a otimização foi transferida para um pacote mais fácil de instalar, verificar, substituir e reverter. Trata-se de uma grande melhoria operacional para um projeto comunitário construído em torno de hardware sem suporte.

Por que o BC-250 torna esse resultado mais do que uma curiosidade de modding

O upscaler mais rápido amplia um esforço maior para recuperar hardware útil para jogos a partir de um produto especializado de mineração.

O BC-250 combina uma CPU Zen 2 de seis núcleos e 12 threads com um processador gráfico GFX1013 integrado. As placas de fábrica expõem 24 unidades de computação e incluem 16 GB de memória unificada GDDR6. Ao contrário de um desktop comum, o sistema não depende de módulos de memória DDR separados.

A documentação de hardware da comunidade descreve a placa como um projeto personalizado para mineração, com fator de forma não padronizado. O hardware de codificação e decodificação de vídeo não está disponível, e gabinetes ou coolers comuns de PC não se encaixam sem adaptação. A conectividade de armazenamento também é mais restrita do que em uma placa-mãe convencional.

O processador pertence à mesma ampla família de silício semicustomizado associada ao PlayStation 5 da Sony. No entanto, chamar o BC-250 de um PS5 de desktop exageraria essa relação. Seus núcleos de CPU ativos, configuração gráfica, firmware, I/O e ambiente operacional diferem do console.

A placa chegou ao mercado entusiasta depois que a demanda por mineração de criptomoedas enfraqueceu. Modders então desenvolveram patches de firmware, suporte a drivers Linux, controles de ventoinha, gabinetes e distribuições voltadas a jogos. Cada melhoria removeu uma limitação de um hardware que não possuía um canal convencional de suporte ao consumidor.

Projetos anteriores estabeleceram que a configuração de fábrica podia executar jogos exigentes de PC por meio do Linux. Membros da comunidade depois experimentaram restaurar núcleos de CPU desativados e expor mais unidades físicas de computação gráfica em processadores compatíveis. Essas modificações dependem do chip e não funcionam em todas as placas.

O FSR 4 adiciona outra camada a esse esforço de recuperação. O atual SDK FSR da AMD combina dados espaciais e temporais com modelos de aprendizado de máquina para reconstruir quadros em maior resolução. Ele visa plataformas gráficas mais recentes por meio de implementações oficialmente suportadas, enquanto o suporte ao BC-250 vem da engenharia da comunidade.

A tensão é evidente. O FSR 4 promete melhor qualidade de imagem reconstruída do que upscalers mais antigos, mas seu modelo traz um custo de processamento significativo. Em uma placa limitada, o upscaler pode eliminar o desempenho ganho ao renderizar em uma resolução de entrada menor.

Em 1440p, o custo original de 11,51 milissegundos consumia cerca de 69 por cento de um orçamento de quadro a 60 fps. Esse cálculo cobre apenas o dispatch do FSR. O jogo ainda precisava de tempo para geometria, iluminação, efeitos, simulação de CPU, trabalho do driver e apresentação final.

A RC9 reduz essa parcela para aproximadamente 36 por cento. O novo número continua caro, mas deixa muito mais espaço para o jogo em si. Em 4K, a redução de 25,72 milissegundos para 12,08 milissegundos coloca o upscaler abaixo do orçamento completo de quadro a 60 fps.

Isso não torna provável jogar em 4K a 60 fps no BC-250. O restante da carga de trabalho ainda precisa de tempo de processamento, e o desempenho gráfico da placa permanece limitado. Mas demonstra por que otimizar o upscaler importa mais do que simplesmente fazê-lo iniciar.

O projeto AMD BC-250 FSR 4 também ilustra o valor dos componentes abertos do Linux. Desenvolvedores puderam inspecionar o comportamento dos shaders, identificar o caminho de instrução caro, testar alternativas e empacotar o resultado. Esse processo seria mais difícil em uma cadeia de drivers e aplicações totalmente fechada.

Ainda assim, o projeto depende parcialmente de engenharia reversa e integração de terceiros. A AMD não apresentou a RC9 como uma versão oficial para o BC-250. Os usuários devem tratar a DLL como software experimental para um dispositivo de nicho, e não como um recurso de driver Radeon com suporte oficial.

O verdadeiro adversário é a compatibilidade sem desempenho prático

A RC9 desafia a diferença entre fazer o FSR 4 funcionar e torná-lo útil dentro de um quadro completo de jogo.

Demonstrações de compatibilidade frequentemente produzem capturas de tela convincentes. Um recurso carrega, uma marca d’água aparece e o hardware renderiza uma imagem que seu fornecedor nunca suportou oficialmente. Isso prova acesso técnico, mas diz pouco sobre latência, estabilidade ou jogabilidade sustentada.

O BC-250 já ultrapassou o limite da compatibilidade. Trabalhos anteriores da comunidade mostraram que o FSR 4.1.1 podia ser executado por meio da pilha gráfica Linux da placa. O problema era o tempo consumido por seus shaders de aprendizado de máquina, especialmente pelas operações de inteiros compactados com sinal.

Em 1440p, uma passagem de upscaling de 11,51 milissegundos exerce forte pressão sobre qualquer meta de desempenho. Um quadro a 30 fps permite 33,33 milissegundos, tornando essa sobrecarga mais fácil de absorver. A meta de 60 fps permite metade desse tempo, enquanto 120 fps permitem apenas 8,33 milissegundos.

O resultado de 5,92 milissegundos do RC9 cabe, por si só, no orçamento de um quadro a 120 fps. Evidentemente, o jogo completo não cabe nesse orçamento quando todo o restante do trabalho é incluído. Ainda assim, o despacho otimizado já não ultrapassa todo esse orçamento antes que o jogo renderize qualquer outra coisa.

Essa é a inversão central por trás do projeto. Normalmente, o FSR melhora o desempenho ao permitir que um jogo renderize menos pixels. No caminho não otimizado do BC-250, o processo de reconstrução podia consumir grande parte do tempo economizado. A solução do recurso corria o risco de se tornar outro gargalo.

A DLL otimizada reduz essa contradição. Ela não elimina o custo, mas diminui a distância entre o suporte teórico e o desempenho utilizável. Isso dá a desenvolvedores e usuários mais liberdade para comparar o FSR 4 com FSR 3, XeSS ou uma resolução nativa menor.

Essas comparações exigem controles cuidadosos. Cada upscaler usa uma lógica de reconstrução diferente e pode expor modos de qualidade distintos. Uma configuração Quality em uma implementação não necessariamente corresponde à resolução de entrada, à nitidez ou ao comportamento visual de outra.

A qualidade de imagem também importa mais do que apenas o tempo de despacho. Um shader mais rápido tem pouco valor se introduzir instabilidade, ghosting, cintilação, erros de desoclusão ou elementos de interface quebrados. Esses problemas costumam aparecer durante o movimento, e não em capturas estáticas.

O mesmo problema se aplica às taxas médias de quadros. Um benchmark pode mostrar uma média maior enquanto sofre com entrega irregular de quadros. Percentis de frame time e travamentos visíveis frequentemente determinam se um jogo realmente parece melhor.

Portanto, o RC9 precisa competir com opções mais simples. Usuários podem escolher uma implementação mais antiga do FSR, que custa menos, reduzir configurações nativas ou aceitar uma taxa de quadros menor. O caminho otimizado do FSR 4 só vence quando seu ganho de qualidade de imagem justifica sua sobrecarga restante e a complexidade de instalação.

O projeto não precisa superar todas as alternativas. Uma ferramenta da comunidade pode ser valiosa quando melhora alguns jogos exigentes em um dispositivo específico. Contudo, esse padrão mais restrito deve permanecer explícito ao interpretar o benchmark.

É por isso que a DLL portátil importa tanto quanto o número de destaque. Uma instalação mais fácil reduz o custo de realizar comparações reais. Mais usuários podem testar o mesmo binário, relatar resultados reproduzíveis e identificar títulos nos quais essa troca funciona.

O Que o Benchmark Ainda Não Estabelece

Os dados publicados mostram um despacho de upscaling mais rápido, mas ainda não estabelecem qualidade visual equivalente nem ganhos previsíveis entre jogos.

A primeira incerteza é o escopo dos testes. A documentação do projeto informa que suas sete verificações registradas em jogos usaram uma compilação RC7 anterior. O RC9 tem validação sintética e uma configuração instalada para Cyberpunk 2077, mas o guia não afirma haver uma nova rodada de jogabilidade com RC9 em todos os títulos.

Essa lacuna não invalida o benchmark. Testes sintéticos isolam o upscaler e facilitam comparações antes e depois. Eles apenas respondem a uma pergunta mais restrita do que um benchmark em jogo.

Uma avaliação completa precisa de taxas médias de quadros, resultados de um por cento mais baixo e gráficos de frame time em cenas reproduzíveis. Ela também deve comparar resoluções de entrada e saída idênticas. Sem esses controles, variação de CPU ou mudanças de renderização não relacionadas podem obscurecer o efeito da DLL.

A segunda incerteza diz respeito à equivalência visual. O benchmark indica que o caminho otimizado processa a carga de trabalho mais rapidamente. Ele não estabelece de forma independente que cada pixel de saída corresponde ao caminho original da AMD ou que o comportamento temporal permanece inalterado durante a jogabilidade.

Upscalers de aprendizado de máquina podem falhar de formas específicas a cada cena. Geometria fina pode cintilar, efeitos transparentes podem quebrar, partículas podem deixar rastros e superfícies recém-reveladas podem apresentar erros de reconstrução. Movimentos rápidos de câmera frequentemente expõem problemas que uma captura estática esconde.

A terceira questão é a compatibilidade com jogos. O OptiScaler oferece vários caminhos de injeção, mas cada jogo expõe APIs e dados temporais diferentes. Sistemas anti-cheat, launchers, atualizações e mudanças no renderizador podem impedir que uma instalação correta funcione.

As integrações nativas do FidelityFX também variam. Um jogo documentado exige uma biblioteca de carregamento renomeada especificamente, enquanto outro usa um backend do OptiScaler. O projeto alerta explicitamente contra aplicar a substituição de arquivos de um título a jogos não relacionados.

A quarta incerteza é o escopo da plataforma. O RC9 visa hardware BC-250 sob Linux com Proton. O guia não promete suporte para Windows nativo ou outras GPUs. Uma DLL portátil é mais fácil de mover, mas a portabilidade do arquivo não comprova a portabilidade de seu comportamento otimizado.

A implementação também é software de terceiros sem assinatura. Usuários devem obtê-la no lançamento indicado, verificar seu checksum e manter backups dos arquivos substituídos. Atualizações de jogos podem sobrescrever a biblioteca ou criar incompatibilidades que exigem reversão.

As implicações mais amplas para RDNA 2 permanecem especialmente incertas. O BC-250 usa um processador GFX1013 incomum, com comportamento específico de instruções. Uma solução alternativa que ajuda esse dispositivo não pode prever automaticamente o desempenho em placas Radeon RX 6000, hardware Steam Deck ou processadores de consoles.

O benchmark reportado também vem de um pequeno ecossistema de modding. A reprodução independente deve confirmar os números em diferentes placas, clocks, versões de firmware e condições térmicas.

A temperatura merece atenção porque cargas sustentadas de shader podem se comportar de modo diferente de testes curtos. Uma placa com refrigeração insuficiente pode reduzir os clocks após longas sessões de jogo. Isso poderia reduzir ou mascarar o benefício de desempenho observado durante uma breve execução sintética.

A variação entre placas adiciona outra complicação. Alguns processadores BC-250 toleram núcleos ou unidades de computação desbloqueados, enquanto outros permanecem estáveis apenas em sua configuração de fábrica. Benchmarks devem identificar claramente o hardware habilitado, clocks, limites de potência, firmware, versão do Mesa e compilação do Proton.

Nenhuma dessas limitações elimina a redução relatada. Elas definem o que as evidências atuais sustentam. O RC9 parece tornar o despacho do FSR substancialmente mais rápido em seu sistema-alvo, enquanto o valor em jogos completos continua sendo uma afirmação testável.

Essa leitura cautelosa serve melhor ao projeto do que tratar o resultado como suporte universal ao FSR 4. Limites claros ajudam usuários a reproduzir o trabalho e ajudam desenvolvedores a identificar quais problemas ainda exigem engenharia.

Três Sinais Mostrarão se o RC9 Muda os Jogos no BC-250

A próxima fase precisa conectar eficiência sintética a jogabilidade reproduzível, estabilidade visual e distribuição sustentável.

O primeiro sinal é uma suíte controlada de benchmarks em jogos com RC9. Cyberpunk 2077 e Control são pontos de partida sensatos, pois o projeto já documenta caminhos de instalação para ambos. Os testes devem comparar os shaders originais, RC9 e um upscaler mais antigo sob configurações idênticas.

Os relatórios mais úteis incluirão desempenho médio e percentis de frame time. Eles devem registrar o tempo de quadro completo junto do custo isolado do FSR. Se o RC9 produzir ganhos consistentes em cenas limitadas pela GPU, a conclusão atual baseada no mecanismo se tornará muito mais forte.

Se o desempenho do jogo completo quase não mudar, o benchmark ainda ensinará algo aos desenvolvedores. Isso indicaria que outra parte do pipeline de renderização domina. A otimização poderia continuar tecnicamente eficaz sem melhorar de forma material um jogo específico.

O segundo sinal é a validação independente da qualidade de imagem. Usuários devem capturar movimento, geometria fina, partículas, reflexos, elementos de interface e superfícies desocluídas. As comparações precisam usar trajetórias de câmera e resoluções de entrada idênticas, em vez de capturas não relacionadas.

Uma correspondência estável com a saída original reforçaria a afirmação de que o RC9 oferece praticamente a mesma reconstrução a um custo muito menor. Ghosting ou cintilação recorrentes enfraqueceriam seu caso prático, mesmo que a vantagem de tempo permaneça.

O terceiro sinal é a adoção por meio de pacotes Linux mantidos e ferramentas de instalação. A DLL já reduz a dependência de uma compilação personalizada do Mesa. A integração contínua em distribuições BC-250, fluxos de trabalho do Proton e pacotes fixados por checksum tornaria os testes mais reproduzíveis.

Um projeto Linux já expõe o fork como uma opção experimental do OptiScaler, enquanto alerta que compilações sem assinatura não são recomendações. Esse enquadramento é apropriado. Empacotamento reproduzível pode tornar software experimental mais seguro sem transformá-lo em suporte oficial.

A manutenção após atualizações de jogos, Proton e drivers revelará se a portabilidade resiste ao uso real. Uma biblioteca de substituição que quebra com frequência impõe um custo oculto. Um pacote estável, com instruções claras de reversão, transformaria a otimização em infraestrutura prática.

A resposta da AMD é menos importante no curto prazo, mas o suporte oficial continua merecendo atenção. A empresa controla o desenvolvimento do FSR e os caminhos suportados da Radeon. Descobertas da comunidade podem revelar demanda, mas não garantem que a AMD dará suporte a esse processador derivado de mineração.

Para proprietários de BC-250, o próximo passo sensato é a experimentação medida. Verifique o arquivo da versão, preserve as bibliotecas originais, confirme a marca d’água renderizada e faça benchmark de uma cena reproduzível. Compare o comportamento visual antes de decidir se a sobrecarga restante vale a pena.

Para desenvolvedores gráficos, o projeto oferece uma lição mais ampla sobre premissas de software. Um modelo projetado em torno de hardware inteiro mais recente pode se comportar mal em um processador incomum, mesmo quando esse processador executa as instruções necessárias. Trabalho direcionado em shaders pode recuperar desempenho que um caminho genérico deixa inutilizado.

O resultado do AMD BC-250 FSR 4 é, portanto, promissor por uma razão precisa. Ele transforma um experimento especializado de driver em um pacote portátil e reduz quase pela metade a carga de trabalho medida. Ele não estabelece suporte universal nem ganhos garantidos de taxa de quadros.

As evidências decisivas devem vir de jogos comuns, e não de outro número isolado. O RC9 melhora o ritmo de entrega de quadros em cenas exigentes enquanto preserva detalhes reconstruídos estáveis? Respostas reproduzíveis a essa pergunta determinarão se essa DLL se torna uma parte duradoura dos jogos no BC-250 ou permanece uma demonstração técnica impressionante.