Link alla notizia: https://www.hwupgrade.it/news/skvideo/amd-fsr-alimentato-dall-intelligenza-artificiale-a-suggerirlo-e-il-cto-dell-azienda_124946.html

Intervenendo nel podcast No Priors, il CTO di AMD ha spiegato che la società sta testando l'introduzione dell'intelligenza artificiale in un ampio ventaglio di applicazioni, tra le quali ci sarebbe anche FSR.

Click sul link per visualizzare la notizia.

non so magari in futuro miglioreranno, ma al momento attuale questi frame generators io li trovo un disastro con gran parte dei giochi, tanto input lag, movimenti visuale fastidiosi, problemi all´hud, ghosting, fps su schermo raddoppiati che invece fanno andare il gioco peggio. Boh per me Dlss3 e Fsr 3 sono stati un fallimento, anche se vogliono dipingerli come il Mantra assoluto. Avevo invece apprezzato molto il Dlss 2, davvero ottimo e su quality mode non ti accorgevi della differenza rispetto al native. Queste versioni 3 a mio avviso sono puro marketing. Ripeto, spero che le migliorano in futuro, soprattutto l´input lag eccessivo

Le tecnologie di frame generation *NON* (presente la "negazione"? :D ) vanno usate a bassi FPS ma solo sopra i 50 e per puntare alla sincronizzazione con i monitor ad alti refresh rate.

*NON* servono a guadagnare performance.

Non vanno assolutamente usate insieme all'LFC (low frame compensation) dei monitor con VRR (per questo c'è il requisito di usarli sopra i 50 FPS dato che l'LFC lavora fino a 48-50 ipotizzando un monitor con refresh rate di 100 Hz), altrimenti la latenza di input QUADRUPLICA dato che LFC attua a sua volta un'interpolazione "base" replicando l'ultimo frame ricevuto dalla GPU

Per quanto riguarda la latenza di input su NVidia è necessario attivare Reflex per compensare e probabilmente anche AMD introdurrà qualcosa di simile (ma ormai il treno è andato).
Intel invece punta su un approccio di predizione e non di interpolazione, per cui quando presenterà la sua tecnologia analoga (a DLSS3 / FSR3) il problema dell'input lag non ci sarà (ovviamente ci saranno altri problemi)

il Dlss 2, davvero ottimo e su quality mode non ti accorgevi della differenza rispetto al native

Più o meno :asd:

non so magari in futuro miglioreranno, ma al momento attuale questi frame generators io li trovo un disastro con gran parte dei giochi, tanto input lag, movimenti visuale fastidiosi, problemi all´hud, ghosting, fps su schermo raddoppiati che invece fanno andare il gioco peggio. Boh per me Dlss3 e Fsr 3 sono stati un fallimento, anche se vogliono dipingerli come il Mantra assoluto. Avevo invece apprezzato molto il Dlss 2, davvero ottimo e su quality mode non ti accorgevi della differenza rispetto al native. Queste versioni 3 a mio avviso sono puro marketing. Ripeto, spero che le migliorano in futuro, soprattutto l´input lag eccessivo

Hai pienamente ragione. E' intrinseco nella tecnologia che è una cacata. Nell'interpolazione di due frame hai: o grosso input lag perché aspetti il frame successivo "vero" per creare quello interpolato tra questo e l'ultimo "vero" oppure lo crei in base ai precedenti e in questo caso è un frame inventato che però si differirà poco o tanto da quello che realmente dovrebbe essere renderizzato. Se ho l'immagine che mi scorre da sinistra a destra ma proprio in quel momento cambia direzione dei "vettori" dei pixel avrò un bell'artefatto.

La gente pur di giocare in 4k rinuncia all'immagine 'pixel perfect' con tutte queste tecnologie, sbavature, sfuma di lì, sfuma di là, artefatti... L'importante è non vedere i pixel!! Poco importa se definiscono meno di un 720p.

Un po' come per i sensori delle macchine fotografiche/cellulari, ora arrivano a 200 megapixel ma poi all'atto pratico definiscono meno di un Foveon da 12 megapixel di una Sigma.

Su queste cose per me stiamo andando indietro :rolleyes:

E' di fatto un ammissione che l'attuale approccio è inferiore a quello gestito tramite AI di tutti gli altri ( Intel, Nvidia e addirittura Microsoft fra poco )

Le tecnologie di frame generation *NON* (presente la "negazione"? :D ) vanno usate a bassi FPS ma solo sopra i 50 e per puntare alla sincronizzazione con i monitor ad alti refresh rate.

*NON* servono a guadagnare performance.

Non vanno assolutamente usate insieme all'LFC (low frame compensation) dei monitor con VRR (per questo c'è il requisito di usarli sopra i 50 FPS dato che l'LFC lavora fino a 48-50 ipotizzando un monitor con refresh rate di 100 Hz), altrimenti la latenza di input QUADRUPLICA dato che LFC attua a sua volta un'interpolazione "base" replicando l'ultimo frame ricevuto dalla GPU

Per quanto riguarda la latenza di input su NVidia è necessario attivare Reflex per compensare e probabilmente anche AMD introdurrà qualcosa di simile (ma ormai il treno è andato).
Intel invece punta su un approccio di predizione e non di interpolazione, per cui quando presenterà la sua tecnologia analoga (a DLSS3 / FSR3) il problema dell'input lag non ci sarà (ovviamente ci saranno altri problemi)

Veramente il mio monitor 165hz con LFRC lavora anche fino a 10 fps... non che serva a qualcosa ma resta sincronizzato.
Quindi non serve a nulla frame generator per sincronizzare i monitor con adaptive sync.

La latenza con LFRC non aumenta visto che appena arriva un nuovo frame viene riprodotto.
Anzi è proprio il frame generator che aumenta la latenza.

AMD per la latenza ha Anti-Lag da diverso tempo.

Imho i frame generator servono a poco o nulla comunque, soprattutto se si ha un monitor con alto refresh compatibile con LFRC.




Comunque la notizia non parlava di frame generator ma di upscaler :)

Mi rifaccio al discorso di Huang quando lanciò le serie 2000,ci vorranno 10 anni o più per avere un vero ray tracing.
In effetti quello che vediamo su schermo è un ray tracing parziale o totale però su una scena semplice ,senza troppi poligoni,questo lo hanno detto diversi programmatori di diverse software house.
I frame generator servono solo a nascondere il problema,non c'è abbastanza potenza per applicare il ray tracing a tutto schermo in modo nativo con risoluzioni 2k 2k+ ,4k e 4k+,ci si sta a malapena dentro al 1080,sempre che la scena non sia troppo complicata e i frame da generare non siano troppi.
Secondo me AMD dovrebbe collaborare con Intel e lavorare assieme sulle xess

Veramente il mio monitor 165hz con LFRC lavora anche fino a 10 fps... non che serva a qualcosa ma resta sincronizzato.
Quindi non serve a nulla frame generator per sincronizzare i monitor con adaptive sync.
Mi sa che non hai capito quello che ho scritto o non hai per niente chiaro come funziona tutta la faccenda.

Ho detto che a bassi FPS è controproducente usare una tecnologia che "raddoppia" da 20 a 40 gli FPS perchè a 20 FPS
1) scatta GIA' l'LFC del monitor che porta automaticamente il refresh rate al doppio degli FPS (funziona così l'LFC) e quindi hai GIA' da questo la sensazione di fluidità a monitor
2) lo fa ma introducendo una latenza di input (di input, non di frame, sono 2 cose diverse) che si somma a quella dell'LFC del monitor


La latenza con LFRC non aumenta visto che appena arriva un nuovo frame viene riprodotto.
Anzi è proprio il frame generator che aumenta la latenza.
Vedi sopra, sto parlando della latenza di INPUT (il ritardo del tuo click rispetto al risultato che ti aspetteresti a monitor, non il ritardo dovuto alla creazione di un frame da parte di CPU+GPU)
Se il monitor mette 2 frame uguali (funziona così LFC) devi aspettare il doppio dei frame per vedere il risultato dei tuoi click o dei tuoi movimenti (oltre al tempo necessario per accedere al buffer *NEL MONITOR* ma trascuriamolo pure)
Questo appunto senza contare quella introdotta dalla FG.


AMD per la latenza ha Anti-Lag da diverso tempo.
Anti-lag esattamente come ULL di Nvidia non fa altro che lasciare un unico frame nella render queue della GPU, sta cosa si poteva forzare già 20 anni fa :asd:
Tanto che l'Unreal Engine ha da allora l'opzione relativa nei file di configurazione......21 ANNI FA.
https://i.postimg.cc/fWgwZFn4/Senza-titolo.jpg (https://postimg.cc/K4BXD08Q)
L'unica soluzione sensata è Reflex che però necessita una implementazione diretta nel motore per come funziona (mette dei semafori alla pipeline di rendering)


Imho i frame generator servono a poco o nulla comunque, soprattutto se si ha un monitor con alto refresh compatibile con LFRC.
La frame generation serve APPOSTA per sfruttare i monitor ad alto refresh rate nella parte ALTA dei valori a cui altrimenti non arriveresti e come ho detto va assolutamente evitata sotto i 50 FPS perchè l'LFC scatta tipicamente sotto i 48 Hz (quindi sotto i 50 hai la latenza di input dovuta a LFC che si somma alla latenza di input dovuta alla FG)

Intel invece punta su un approccio di predizione e non di interpolazione, per cui quando presenterà la sua tecnologia analoga (a DLSS3 / FSR3) il problema dell'input lag non ci sarà (ovviamente ci saranno altri problemi)
Intel copierà gli altri, come ha fatto fino ad oggi, perchè FG di nvidia e di AMD sono già predittivi; non avresti quell'input lag, altrimenti.

difficile perdere un teno che non è mai partito.

Nell'interpolazione di due frame hai: o grosso input lag perché aspetti il frame successivo "vero" per creare quello interpolato tra questo e l'ultimo "vero" oppure lo crei in base ai precedenti e in questo caso è un frame inventato che però si differirà poco o tanto da quello che realmente dovrebbe essere renderizzato. Se ho l'immagine che mi scorre da sinistra a destra ma proprio in quel momento cambia direzione dei "vettori" dei pixel avrò un bell'artefatto.

funzionano come hai descritto nella seconda parte;
vengono predetti attraverso i vettori di movimento ed è per questo che devi usarli oltre un certo frame rate, o diversamente noterai il problema.
con 60 FPS nativi hai un frame ogni 16-17 ms, ma predici un frame che visualizzerai 8 ms dopo.
qualora risultasse sbagliato vedrai la solita schia di ghosting, ma sarà l'unico frame che subirà una errata predizione delle posizioni e dei movimenti 8piccoli movimenti in 8 ms).
lo noti sia su FG AMD che nvidia.

già se sei a 90 FPS, il frame time è di 11 ms e il "mezzo frame di 5.5 ms.
vedresi il frame sbagliato esclusivamente come una piccola sfocatura del personaggio in terza persona, ma se sei in prima persona il movimento d'insieme non ti consente di apprezzare bene questo difetto.

se usi FG a 30FPS noterai precisamente questo effetto.

E' di fatto un ammissione che l'attuale approccio è inferiore a quello gestito tramite AI di tutti gli altri ( Intel, Nvidia e addirittura Microsoft fra poco )

è di fatto una cattiva interpretazione di quanto detto nell'intervista.

Intel copierà gli altri, come ha fatto fino ad oggi, perchè FG di nvidia e di AMD sono già predittivi; non avresti quell'input lag, altrimenti.

difficile perdere un teno che non è mai partito.
Interpolazione -> input lag
Predizione -> no input lag ma errori di posizione / annullamento predizione (e qui c'è il ritardo)

Poi se vuoi spiegare a me come funzionano interpolatori e predittori su cui ho dato esami ed esami prego :asd:

vengono predetti attraverso i vettori di movimento
No :D

AMD stessa dice che è interpolazione

https://github.com/AzagraMac/FidelityFX-SDK-FSR3/blob/master/docs/techniques/super-resolution-interpolation.md

FSR3 is a container effect consisting of four components. For details on each component, please refer to the dedicated documentation page:

FfxFsr3Upscaler - please refer to the FSR2 temporal upscaler documentation for details
FfxOpticalFlow
FfxFrameinterpolation
Frame interpolation swapchain

Frame Pacing in FSR3
With frame generation enabled, frames can take wildly different amounts of time to render. The workload for interpolated frames can be much smaller than for application rendered frames ("real" frames). It is therefore important to properly pace presentation of frames to ensure a smooth experience. The goal here is to display each frame for an equal amount of time.

Presentation and pacing are done on two new threads separate from the main render loop.

A high-priority pacing thread keeps track of average frame time and calculates the target presentation time. It also waits for gpu work to finish to avoid long GPU-side waits after the CPU-side presentation call.

To prevent frame time spikes from impacting pacing too much, the moving average of the past seven frames is used to calculate a stable frame time.

A present thread dispatches frame composition work and first presents the interpolated frame, then waits until the target presentation time and presents the real frame.

The present interval is always set to 0 (queueing disabled) to avoid waits in the presentation backend. If supported, the allow-tearing-flag is set if and only if the interpolated frame rate exceeds the monitor's refresh rate.

If the application presents to the proxy swapchain using a non-zero present interval, tearing is always disabled. In these cases, the call to the presentation backend may block on some drivers, which prevents the frame rate from exceeding the monitor's refresh rate. On AMD Radeon graphics cards, users should enable Enhanced Sync in AMD Software to avoid this behavior.

The application should ensure that the rendered frame rate is as close as possible to, but ideally slightly below half the desired output frame rate.

It is recommended to use normal priority for any GPU queues created by the application to allow interpolation work to be scheduled with higher priority. In addition, developers should take care that command lists running concurrently with interpolation and composition are short (in terms of execution time) to allow presentation to be scheduled at a precise time.

E si chiamano vettori di spostamento ( https://www.andreaminini.org/fisica/cinematica/vettore-spostamento ), non movimento.

A conferma che parliamo di INTERPOLAZIONE e non PREDIZIONE (il fatto che si faccia la predizione del campo di spostamento non implica che si faccia la predizione dei frame......sono 2 cose diverse, si fa predizione del campo di spostamento per agevolare l'interpolazione in questo caso)

https://www.custompc.com/amd-fsr3-frame-generation-up-to-four-interpolated-frames-nvidia-dlss-3
https://www.techspot.com/article/2747-amd-fsr-3-tech/

https://www.techspot.com/articles-info/2747/images/2023-10-10-image-22.jpg

O qui

https://www.tomshw.it/hardware/intel-extrass-sfida-dlss-3-ed-fsr-3-con-una-tecnica-innovativa

ExtraSS si basa infatti sull’estrapolazione dei frame, anziché sulla loro interpolazione. I due metodi condividono delle somiglianze, ma l’approccio di Intel ha alcuni vantaggi che potrebbero rendere ExtraSS un concorrente agguerrito.

L’algoritmo di Intel pone le basi su XeSS, l’upscaler sviluppato da Intel. Sfruttando l’estrapolazione dei frame è possibile generare un frame usandone solo uno come base, non due come accade con l’interpolazione, riducendo di molto la latenza. Tuttavia questo metodo necessità anche di un input a risoluzione più alta, dal momento che, se l’immagine di partenza non è abbastanza dettagliata (e quindi non ha abbastanza informazioni), si andrebbero a creare glitch e artefatti grafici molto evidenti. Intel ha spiegato tutto nel dettaglio in questo white paper. -> https://dl.acm.org/doi/pdf/10.1145/3610548.3618224

Mi sa che non hai capito quello che ho scritto o non hai per niente chiaro come funziona tutta la faccenda.

Ho detto che a bassi FPS è controproducente usare una tecnologia che "raddoppia" da 20 a 40 gli FPS perchè a 20 FPS
1) scatta GIA' l'LFC del monitor che porta automaticamente il refresh rate al doppio degli FPS (funziona così l'LFC) e quindi hai GIA' da questo la sensazione di fluidità a monitor
2) lo fa ma introducendo una latenza di input (di input, non di frame, sono 2 cose diverse) che si somma a quella dell'LFC del monitor


Ho interpretato male perchè hai scritto che LFRC lavora fino a 48-50 e parlavamo di fps, ma intendevi Hz.
In tal caso si è corretto, se la gpu produce per esempio 15 fps il monitor lavora a 45hz e ripropone lo stesso frame per 3 volte.

Quindi poi ho interpretato praticamente al contrario tutto il resto :stordita:


Vedi sopra, sto parlando della latenza di INPUT (il ritardo del tuo click rispetto al risultato che ti aspetteresti a monitor, non il ritardo dovuto alla creazione di un frame da parte di CPU+GPU)
Se il monitor mette 2 frame uguali (funziona così LFC) devi aspettare il doppio dei frame per vedere il risultato dei tuoi click o dei tuoi movimenti (oltre al tempo necessario per accedere al buffer *NEL MONITOR* ma trascuriamolo pure)
Questo appunto senza contare quella introdotta dalla FG.


Sempre escludendo FG, non credo che LFRC introduca molto ritardo.
È vero che propone due o più frame uguali ma il frametime è comunque variabile.
Parliamo di 50hz per esempio che equivarrebbero a 20ms di frametime ma una volta che il nuovo frame è pronto per essere visualizzato il monitor può sostituire il frame precedente con quello nuovo nel minor frametime possibile (7ms per un 144hz).
Quindi la latenza o almeno la latenza introdotta dal tempo di refresh del monitor dovrebbe essere sempre la minore possibile.
Quindi di fatto non serve FG per lavorare con il minor frametime possibile.


Anti-lag esattamente come ULL di Nvidia non fa altro che lasciare un unico frame nella render queue della GPU, sta cosa si poteva forzare già 20 anni fa :asd:
Tanto che l'Unreal Engine ha da allora l'opzione relativa nei file di configurazione......21 ANNI FA.
https://i.postimg.cc/fWgwZFn4/Senza-titolo.jpg (https://postimg.cc/K4BXD08Q)
L'unica soluzione sensata è Reflex che però necessita una implementazione diretta nel motore per come funziona (mette dei semafori alla pipeline di rendering)


Un sacco di cose si potevano fare prima, anche l'upscale si poteva fare prima forza da driver l'upscale da gpu e non da monitor.
Tutto sta nel come e quanto facilmente vengono fatte.

Un sacco di cose si potevano fare prima, anche l'upscale si poteva fare prima forza da driver l'upscale da gpu e non da monitor.
Tutto sta nel come e quanto facilmente vengono fatte.
Quell'opzione è disponibile su GPU Nvidia dal 2007 (e nell'Unreal Engine dal 2003, dovrei controllare per Raven Shield nel 2002, fu il primo gioco importante ad usare UE 2.x :D ), semplicemente aveva un altro nome prima che gli venisse dato quello comprensibile (aveva il nome tecnico del "numero di frame" nella coda di rendering), cosa che è stata fatta qualche anno fa, nient'altro (a parte considerarlo un aspetto importante causa E-sport diffusosi a macchia d'olio grazie ai servizi di streaming) :asd: :asd: :asd:

La vera rivoluzione fu Reflex, soprattutto considerando che è supportata da Maxwell in poi (quando appunto cambiarono i nomi nel pannello di controllo).....che è il motivo per cui uso il passato remoto (2015, anche qui sono già 9 anni ormai)

Se vi interessa l'ultima versione di RTSS (Rivatuner Statistics Server di Unwinder) "inietta" i marker reflex nella pipeline in modo artificiale......senza che il motore ci sia costruito intorno.

Qui documentata nel 2011, ma se non ricordo male comparve ai tempi delle GeForce 8xxx (o forse pure prima)

https://forums.anandtech.com/threads/maximum-pre-rendered-frames-nvidia.2175155/

pardon, 2004 :asd:

https://forums.guru3d.com/threads/what-is-max-frames-to-render-ahead.84220/