La mod AMD BC-250 FSR 4 dimezza il tempo di upscaling, ma il vero test è il gameplay

L'elaborazione AMD BC-250 FSR 4 è diventata notevolmente più veloce, secondo i benchmark pubblicati insieme a una DLL FidelityFX sviluppata dalla community. A 1440p, il costo di upscaling riportato è sceso da 11,51 millisecondi a 5,92 millisecondi. Questa riduzione trasforma FSR 4 da un esperimento costoso a un'opzione più plausibile per questa insolita scheda basata su RDNA.

Il risultato è importante perché la BC-250 non è mai stata progettata come un PC da gaming convenzionale. AMD ha prodotto il suo processore semi-custom per i sistemi di mining ASRock, utilizzando silicio strettamente correlato al processore di PlayStation 5. Gli appassionati Linux hanno poi riutilizzato le schede dismesse per creare macchine da gaming compatte tramite firmware, driver, raffreddamento e strumenti di installazione personalizzati.

La nuova release sposta il problema centrale dalla compatibilità di base alle prestazioni pratiche. Il precedente lavoro di ottimizzazione dipendeva da uno stack grafico Mesa modificato. L'implementazione più recente integra le modifiche all'interno di una libreria FidelityFX portabile, che gli utenti possono installare insieme a strumenti come OptiScaler e Proton.

Tuttavia, le cifre riportate misurano l'upscaler stesso, non le prestazioni complete nei giochi. Lo sviluppatore ha pubblicato misurazioni sintetiche RC9, mentre i nuovi test di gameplay restano limitati. Il risultato è abbastanza concreto da meritare attenzione, ma il suo valore dipende ancora da stabilità, qualità dell'immagine e risultati nei giochi reali.

L'elaborazione AMD BC-250 FSR 4 cala a tre risoluzioni

La release RC9 riduce di circa la metà il costo misurato di FSR 4.1.1 a 1080p, 1440p e 4K.

Il risultato più importante deriva da un output 2560 x 1440 con input Quality a 1706 x 960. Gli shader FSR 4.1.1 originali richiedevano, secondo quanto riportato, 11,51 millisecondi per il dispatch di upscaling completo. La versione 4.0.0-rc9 ha completato lo stesso carico di lavoro misurato in 5,92 millisecondi.

Ciò rappresenta una riduzione di circa il 49%. Restituisce inoltre quasi 5,6 millisecondi al resto della pipeline di rendering. Si tratta di una differenza sostanziale quando un gioco che punta a 60 fotogrammi al secondo ha soltanto 16,67 millisecondi a disposizione per ciascun frame.

Le altre risoluzioni registrate seguono lo stesso schema. A 1920 x 1080, il tempo di elaborazione è sceso da 7,13 millisecondi a 3,93 millisecondi. A 3840 x 2160, è diminuito da 25,72 millisecondi a 12,08 millisecondi.

Questi risultati equivalgono a riduzioni rispettivamente di circa il 45% e il 53%. Il miglioramento non sembra quindi limitato a una singola dimensione di output. Il risparmio assoluto aumenta con la risoluzione di output e con il numero di pixel elaborati dall'upscaler.

La release RC9 dello sviluppatore include il codice ottimizzato come amd_fidelityfx_upscaler_dx12.dll. Questa libreria funge da provider di upscaling FidelityFX nei percorsi di integrazione supportati. Sostituisce il componente di upscaling pertinente senza richiedere la precedente build Mesa personalizzata.

Secondo il riepilogo dei test pubblicato, queste cifre rappresentano costi isolati del dispatch FSR. Non sono misurazioni del frame time completo né delle prestazioni medie nei giochi. Lavoro della CPU, rendering del gioco, compilazione degli shader, layer di traduzione e sincronizzazione del display restano al di fuori della misurazione.

Questa distinzione impedisce una conversione diretta dei millisecondi risparmiati in fotogrammi guadagnati. Un gioco limitato dalla CPU potrebbe mostrare pochi miglioramenti. Un gioco fortemente vincolato dalla GPU potrebbe beneficiarne di più, soprattutto quando il precedente passaggio di upscaling consumava una quota rilevante del budget del frame.

Ciononostante, i numeri affrontano un ostacolo specifico. Eseguire FSR 4 sulla BC-250 era tecnicamente possibile prima di RC9, ma l'upscaler poteva consumare gran parte del budget di un frame ad alta frequenza di aggiornamento. Dimezzare quasi questo carico rende più utile effettuare test più ampi.

La release cambia quindi la domanda. La community non deve più chiedersi soltanto se FSR 4 possa essere eseguito sulla scheda. Ora può chiedersi se il percorso ottimizzato migliori abbastanza l'esperienza di gioco complessiva da giustificarne l'installazione.

Una DLL FidelityFX portabile sostituisce la strada Mesa personalizzata

Il progresso centrale è la portabilità, perché l'ottimizzazione ora viaggia con l'upscaler anziché con un driver grafico specializzato.

L'ottimizzazione originale per BC-250 prendeva di mira Mesa, lo stack grafico open source comunemente usato dai sistemi Linux. Modificava la gestione del driver Vulkan RADV delle operazioni INT8 utilizzate da FSR 4. INT8 indica l'aritmetica intera a otto bit, che i modelli di machine learning utilizzano per ridurre i costi di elaborazione e memoria.

Quel lavoro affrontava una limitazione insolita del processore grafico GFX1013 della BC-250. La scheda può eseguire il carico di lavoro richiesto, ma il suo percorso per il prodotto scalare intero con segno impacchettato offre prestazioni modeste. Un prodotto scalare combina più moltiplicazioni e addizioni, rendendolo un'operazione comune nei modelli neurali di elaborazione delle immagini.

Il progetto precedente sostituiva quel percorso costoso con una sequenza più adatta alla BC-250. Il suo repository descrive una build Mesa sperimentale che usa istruzioni intere alternative invece di affidarsi al problematico percorso nativo. La modifica era rivolta a uno specifico identificatore di dispositivo e a un set di shader convalidato.

Questo approccio ha dimostrato l'opportunità in termini di prestazioni, ma ha collocato il deployment all'interno dello stack dei driver. Gli utenti avevano bisogno di una build Mesa dedicata e dovevano avviare i giochi tramite la corretta configurazione Vulkan. Le modifiche ai driver comportano inoltre costi di manutenzione quando cambiano Mesa, Proton o una distribuzione Linux.

L'implementazione portabile trasferisce l'ottimizzazione nella DLL FidelityFX. Questo rende l'upscaler un componente sostituibile anziché una variazione del driver a livello di sistema. Gli utenti possono inserire la libreria in un gioco supportato o in una configurazione con adattatore e rimuoverla senza ricompilare Mesa.

La guida di installazione del progetto afferma che RC9 non richiede il vecchio strumento di compatibilità né un'installazione speciale del driver. Il suo ambito testato resta l'hardware BC-250 in esecuzione su Linux tramite Proton standard. Proton è il layer di compatibilità di Valve per eseguire giochi Windows su Linux.

OptiScaler può fungere da adattatore tra un gioco e la libreria FidelityFX. Intercetta un percorso di upscaling disponibile e fornisce quindi il backend selezionato. Il menu di gioco potrebbe continuare a mostrare DLSS, FSR o XeSS anche quando il provider FidelityFX iniettato esegue l'upscaling finale.

Questa configurazione offre flessibilità, ma aggiunge anche variabili di configurazione. Il gioco necessita di un input temporale compatibile, ovvero vettori di movimento e altri dati dei frame richiesti per ricostruire un'immagine a risoluzione più alta. La DLL da sola non può aggiungere queste informazioni a un titolo che non le produce mai.

Gli utenti devono inoltre verificare che RC9 sia il provider attivo. Il progetto consiglia di abilitare il watermark integrato e controllare la presenza delle etichette FSR-INT8, 4.1.1R9 e della sorgente locale. Un checksum conferma il file installato, mentre il watermark renderizzato verifica quale provider ha elaborato l'immagine.

Questo è importante perché più componenti di upscaling possono coesistere all'interno di un prefisso Proton o di una directory di gioco modificata. Aggiornamenti automatici dei driver, file OptiScaler esistenti e patch dei giochi possono ripristinare silenziosamente un'altra libreria. Un menu funzionante non dimostra che il modello ottimizzato stia effettuando il rendering della scena.

La portabilità non significa dunque compatibilità universale. Significa che l'ottimizzazione è stata trasferita in un pacchetto più facile da installare, verificare, sostituire e ripristinare. Si tratta di un importante miglioramento operativo per un progetto della community costruito attorno a hardware non supportato.

Perché la BC-250 rende questo risultato più di una curiosità del modding

L'upscaler più veloce amplia un più vasto sforzo volto a recuperare hardware da gaming utile da un prodotto di mining specializzato.

La BC-250 combina una CPU Zen 2 a sei core e 12 thread con un processore grafico GFX1013 integrato. Le schede stock espongono 24 compute unit e includono 16 GB di memoria unificata GDDR6. A differenza di un normale desktop, il sistema non si affida a moduli di memoria DDR separati.

La documentazione hardware della community descrive la scheda come un progetto di mining personalizzato con un form factor non standard. L'hardware di codifica e decodifica video non è disponibile e normali case o dissipatori per PC non si adattano senza modifiche. Anche la connettività di archiviazione è più limitata rispetto a una scheda madre regolare.

Il processore proviene dalla stessa ampia famiglia di silicio semi-custom associata alla PlayStation 5 di Sony. Tuttavia, definire la BC-250 una PS5 desktop sovrastimerebbe questa relazione. I core CPU abilitati, la configurazione grafica, il firmware, l'I/O e l'ambiente operativo differiscono dalla console.

La scheda è entrata nel mercato degli appassionati dopo l'indebolimento della domanda di mining di criptovalute. I modder hanno quindi sviluppato patch firmware, supporto ai driver Linux, controlli delle ventole, case e distribuzioni orientate al gaming. Ogni miglioramento ha rimosso una limitazione da hardware privo di un normale canale di supporto consumer.

I progetti precedenti hanno dimostrato che la configurazione stock poteva eseguire giochi PC impegnativi tramite Linux. I membri della community hanno poi sperimentato il ripristino di core CPU disabilitati e l'esposizione di più unità fisiche di calcolo grafico su processori compatibili. Queste modifiche dipendono dal chip e non funzionano su ogni scheda.

FSR 4 aggiunge un ulteriore livello a questo sforzo di recupero. L'attuale FSR SDK di AMD combina dati spaziali e temporali con modelli di machine learning per ricostruire frame a risoluzione più elevata. Si rivolge a piattaforme grafiche più recenti tramite implementazioni ufficialmente supportate, mentre il supporto BC-250 deriva dall'ingegneria della community.

La tensione è evidente. FSR 4 promette una migliore qualità dell'immagine ricostruita rispetto agli upscaler meno recenti, ma il suo modello comporta un costo di elaborazione significativo. Su una scheda limitata, l'upscaler può annullare le prestazioni ottenute renderizzando a una risoluzione di input inferiore.

A 1440p, il costo originale di 11,51 millisecondi consumava circa il 69% del budget di un frame a 60 fps. Questo calcolo copre soltanto il dispatch FSR. Il gioco aveva ancora bisogno di tempo per geometria, illuminazione, effetti, simulazione CPU, lavoro del driver e presentazione finale.

RC9 riduce questa quota a circa il 36%. La nuova cifra resta costosa, ma lascia molto più spazio al gioco vero e proprio. A 4K, la riduzione da 25,72 millisecondi a 12,08 millisecondi porta l'upscaler al di sotto del budget completo di un frame a 60 fps.

Questo non rende probabile il gaming 4K a 60 fps sulla BC-250. Il resto del carico di lavoro necessita ancora di tempo di elaborazione e le prestazioni grafiche della scheda restano limitate. Mostra però perché ottimizzare l'upscaler sia più importante del semplice riuscire ad avviarlo.

Il progetto AMD BC-250 FSR 4 illustra inoltre il valore dei componenti Linux aperti. Gli sviluppatori hanno potuto ispezionare il comportamento degli shader, identificare il percorso di istruzioni costoso, testare alternative e distribuire il risultato in un pacchetto. Questo processo sarebbe più difficile all'interno di una catena completamente chiusa di driver e applicazioni.

Il progetto dipende tuttavia in parte dal reverse engineering e dall'integrazione di terze parti. AMD non ha presentato RC9 come una release ufficiale per BC-250. Gli utenti devono trattare la DLL come software sperimentale per un dispositivo di nicchia, non come una funzionalità supportata dei driver Radeon.

Il vero avversario è la compatibilità senza prestazioni pratiche

RC9 mette in discussione il divario tra far funzionare FSR 4 e renderlo utile all'interno di un frame di gioco completo.

Le dimostrazioni di compatibilità producono spesso screenshot convincenti. Una funzionalità si carica, compare un watermark e l'hardware renderizza un'immagine che il suo fornitore non ha mai supportato ufficialmente. Questo dimostra l'accesso tecnico, ma dice poco su latenza, stabilità o prestazioni di gioco sostenute.

Il BC-250 ha già superato la soglia della compatibilità. Precedenti lavori della community hanno dimostrato che FSR 4.1.1 poteva essere eseguito tramite lo stack grafico Linux della scheda. Il problema era il tempo richiesto dai suoi shader di machine learning, soprattutto dalle operazioni su interi packed con segno.

A 1440p, un passaggio di upscaling da 11,51 millisecondi esercita una forte pressione su qualsiasi obiettivo prestazionale. Un frame a 30 fps consente 33,33 millisecondi, rendendo l'overhead più facile da assorbire. Un obiettivo di 60 fps concede la metà del tempo, mentre 120 fps ne consentono solo 8,33.

Il risultato di 5,92 millisecondi di RC9 rientra da solo nel budget di un frame a 120 fps. Ovviamente il gioco completo non vi rientra una volta incluso tutto il resto del lavoro. Tuttavia, il dispatch ottimizzato non supera più l'intero budget prima che il gioco renderizzi qualunque altra cosa.

Questo è il ribaltamento centrale del progetto. FSR normalmente migliora le prestazioni consentendo a un gioco di renderizzare meno pixel. Nel percorso BC-250 non ottimizzato, il processo di ricostruzione poteva consumare gran parte del tempo risparmiato. La soluzione della funzionalità rischiava di diventare un altro collo di bottiglia.

La DLL ottimizzata riduce questa contraddizione. Non elimina il costo, ma restringe il divario tra supporto teorico e prestazioni utilizzabili. Questo offre a sviluppatori e utenti maggiore libertà nel confrontare FSR 4 con FSR 3, XeSS o una risoluzione nativa inferiore.

Questi confronti richiedono controlli accurati. Ogni upscaler utilizza una diversa logica di ricostruzione e può offrire differenti modalità qualitative. Un'impostazione Qualità in un'implementazione non corrisponde necessariamente alla risoluzione di input, alla nitidezza o al comportamento visivo di un'altra.

Anche la qualità dell'immagine conta più del solo tempo di dispatch. Uno shader più veloce offre poco valore se introduce instabilità, ghosting, sfarfallio, errori di disocclusione o elementi dell'interfaccia danneggiati. Questi problemi emergono spesso durante il movimento anziché negli screenshot statici.

Lo stesso problema riguarda i frame rate medi. Un benchmark può mostrare una media più alta pur soffrendo di una distribuzione irregolare dei frame. I percentili dei frame time e lo stuttering visibile spesso determinano se un gioco sembra davvero migliorato.

RC9 deve quindi competere con opzioni più semplici. Gli utenti possono scegliere un'implementazione FSR meno recente e meno costosa, ridurre le impostazioni native o accettare un frame rate inferiore. Il percorso FSR 4 ottimizzato vince solo quando il suo guadagno nella qualità dell'immagine giustifica l'overhead residuo e la complessità di installazione.

Il progetto non deve superare ogni alternativa. Uno strumento della community può essere prezioso quando migliora una manciata di giochi impegnativi su un dispositivo specifico. Tuttavia, questo standard più ristretto dovrebbe restare esplicito nell'interpretazione del benchmark.

Ecco perché la DLL portabile conta quanto il dato principale. Un'installazione più semplice riduce il costo dei confronti reali. Più utenti possono testare lo stesso binario, riportare risultati ripetibili e identificare i titoli nei quali il compromesso funziona.

Cosa il benchmark non dimostra ancora

I dati pubblicati mostrano un dispatch di upscaling più veloce, ma non dimostrano ancora una qualità visiva equivalente né guadagni prevedibili tra i vari giochi.

La prima incertezza riguarda l'ambito dei test. La documentazione del progetto afferma che i suoi sette controlli registrati nei giochi utilizzavano una precedente build RC7. RC9 dispone di una validazione sintetica e di una configurazione installata per Cyberpunk 2077, ma la guida non dichiara un nuovo test di gioco RC9 su ogni titolo.

Questa lacuna non invalida il benchmark. I test sintetici isolano l'upscaler e rendono più semplici i confronti prima e dopo. Rispondono semplicemente a una domanda più ristretta rispetto a un benchmark in gioco.

Una valutazione completa richiede frame rate medi, risultati one-percent-low e grafici dei frame time da scene ripetibili. Dovrebbe inoltre confrontare risoluzioni di input e output identiche. Senza questi controlli, le variazioni della CPU o modifiche di rendering non correlate possono nascondere l'effetto della DLL.

La seconda incertezza riguarda l'equivalenza visiva. Il benchmark indica che il percorso ottimizzato elabora il carico di lavoro più rapidamente. Non dimostra in modo indipendente che ogni pixel in uscita corrisponda al percorso originale di AMD o che il comportamento temporale resti invariato durante il gioco.

Gli upscaler basati sul machine learning possono fallire in modi specifici della scena. Le geometrie fini possono tremolare, gli effetti trasparenti possono rompersi, le particelle possono lasciare scie e le superfici appena rivelate possono mostrare errori di ricostruzione. I rapidi movimenti della telecamera spesso espongono problemi che un'immagine fissa nasconde.

La terza questione è la compatibilità con i giochi. OptiScaler offre diversi percorsi di injection, ma ogni gioco espone API e dati temporali differenti. Sistemi anti-cheat, launcher, aggiornamenti e modifiche al renderer possono impedire il funzionamento di un'installazione altrimenti corretta.

Anche le integrazioni native FidelityFX variano. Un gioco documentato richiede una libreria loader rinominata in modo specifico, mentre un altro utilizza un backend OptiScaler. Il progetto avverte esplicitamente di non applicare la sostituzione di file di un titolo a giochi non correlati.

La quarta incertezza riguarda l'ambito della piattaforma. RC9 è destinato all'hardware BC-250 su Linux con Proton. La guida non promette supporto per Windows nativo o altre GPU. Una DLL portabile è più facile da spostare, ma la portabilità del file non dimostra la portabilità del suo comportamento ottimizzato.

L'implementazione è inoltre software di terze parti non firmato. Gli utenti dovrebbero ottenerla dalla release indicata, verificarne il checksum e conservare backup dei file sostituiti. Gli aggiornamenti dei giochi possono sovrascrivere la libreria o creare incompatibilità che richiedono un rollback.

Le implicazioni più ampie per RDNA 2 restano particolarmente incerte. Il BC-250 utilizza un insolito processore GFX1013 con un comportamento specifico delle istruzioni. Una soluzione alternativa che aiuta questo dispositivo non può prevedere automaticamente le prestazioni sulle schede Radeon RX 6000, sull'hardware Steam Deck o sui processori per console.

Il benchmark riportato proviene inoltre da un piccolo ecosistema di modding. La riproduzione indipendente dovrebbe confermare le cifre su schede, frequenze, versioni firmware e condizioni termiche differenti.

Le temperature meritano attenzione perché carichi di lavoro shader sostenuti possono comportarsi diversamente dai test brevi. Una scheda con raffreddamento insufficiente può ridurre le frequenze dopo sessioni di gioco prolungate. Ciò potrebbe ridurre o mascherare il beneficio prestazionale osservato durante una breve esecuzione sintetica.

La variazione tra le schede aggiunge un'altra complicazione. Alcuni processori BC-250 tollerano core o unità di calcolo sbloccati, mentre altri rimangono stabili solo nella configurazione di fabbrica. I benchmark devono identificare chiaramente l'hardware abilitato, le frequenze, i limiti di potenza, il firmware, la versione Mesa e la build Proton.

Nessuna di queste limitazioni elimina la riduzione riportata. Definiscono ciò che le prove attuali supportano. RC9 sembra rendere il dispatch FSR sostanzialmente più veloce sul suo sistema di destinazione, mentre il valore nei giochi completi resta un'affermazione verificabile.

Questa lettura prudente serve il progetto meglio che trattare il risultato come supporto universale per FSR 4. Limiti chiari aiutano gli utenti a riprodurre il lavoro e gli sviluppatori a identificare i problemi che richiedono ancora interventi ingegneristici.

Tre segnali mostreranno se RC9 cambia il gaming su BC-250

La prossima fase deve collegare l'efficienza sintetica a gameplay ripetibile, stabilità visiva e distribuzione sostenibile.

Il primo segnale è una suite controllata di benchmark nei giochi con RC9. Cyberpunk 2077 e Control sono punti di partenza sensati perché il progetto documenta già i percorsi di installazione per entrambi. I test dovrebbero confrontare gli shader originali, RC9 e un upscaler precedente con impostazioni identiche.

I report più utili includeranno prestazioni medie e percentili dei frame time. Dovrebbero registrare il frame time completo insieme al costo FSR isolato. Se RC9 produce guadagni costanti nelle scene limitate dalla GPU, l'attuale conclusione basata sul meccanismo diventerà molto più solida.

Se le prestazioni complessive del gioco cambiano appena, il benchmark insegnerà comunque qualcosa agli sviluppatori. Indicherebbe che un'altra parte della pipeline di rendering domina. L'ottimizzazione potrebbe restare tecnicamente efficace senza migliorare materialmente un gioco specifico.

Il secondo segnale è una validazione indipendente della qualità dell'immagine. Gli utenti dovrebbero catturare movimento, geometrie fini, particelle, riflessi, elementi dell'interfaccia e superfici disoccluse. I confronti richiedono percorsi di telecamera e risoluzioni di input identici, anziché screenshot non correlati.

Una corrispondenza stabile con l'output originale rafforzerebbe l'affermazione che RC9 offre una ricostruzione quasi identica a un costo molto inferiore. Ghosting o sfarfallio ricorrenti ne indebolirebbero l'utilità pratica, anche se il vantaggio nei tempi restasse.

Il terzo segnale è l'adozione tramite pacchetti Linux mantenuti e strumenti di installazione. La DLL riduce già la dipendenza da una build Mesa personalizzata. Un'integrazione continuativa nelle distribuzioni BC-250, nei workflow Proton e nei pacchetti con checksum fissati renderebbe i test più ripetibili.

Un progetto Linux espone già il fork come opzione sperimentale di OptiScaler, avvertendo al contempo che le build non firmate non costituiscono raccomandazioni. Questa impostazione è appropriata. Il packaging riproducibile può rendere più sicuro il software sperimentale senza trasformarlo in supporto ufficiale.

La manutenzione dopo gli aggiornamenti di giochi, Proton e driver rivelerà se la portabilità resiste all'uso reale. Una libreria sostitutiva che si rompe frequentemente impone un costo nascosto. Un pacchetto stabile con istruzioni chiare per il rollback trasformerebbe l'ottimizzazione in un'infrastruttura pratica.

La risposta di AMD è meno importante nel breve termine, ma il supporto ufficiale resta da monitorare. L'azienda controlla lo sviluppo di FSR e i percorsi Radeon supportati. Le scoperte della community possono evidenziare una domanda, ma non garantiscono che AMD supporterà questo processore derivato dal mining.

Per i proprietari di BC-250, il passo successivo sensato è una sperimentazione misurata. Verificate il file della release, conservate le librerie originali, confermate il watermark renderizzato e sottoponete a benchmark una scena ripetibile. Confrontate il comportamento visivo prima di decidere se l'overhead residuo valga la pena.

Per gli sviluppatori grafici, il progetto offre una lezione più ampia sulle assunzioni software. Un modello progettato attorno a hardware intero più recente può comportarsi male su un processore insolito, anche quando quel processore esegue le istruzioni richieste. Un lavoro mirato sugli shader può recuperare prestazioni che un percorso generico lascia inutilizzate.

Il risultato AMD BC-250 FSR 4 è quindi promettente per una ragione precisa. Trasforma un esperimento specializzato sui driver in un pacchetto portabile e riduce quasi della metà il carico di lavoro misurato. Non dimostra supporto universale né guadagni garantiti nel frame rate.

Le prove decisive dovrebbero arrivare dai giochi ordinari anziché da un altro dato isolato. RC9 migliora il frame pacing nelle scene impegnative preservando dettagli ricostruiti stabili? Risposte riproducibili a questa domanda determineranno se questa DLL diventerà una parte duratura del gaming su BC-250 o resterà un'impressionante dimostrazione tecnica.