AMD Big Navi batte GeForce RTX 3080 nel 3DMark

23 Ottobre 2020 243

Dopo le notizie e trapelate su specifiche tecniche e possibili nomenclature delle Radeon RX 6000, oggi si parla di benchmark e di prestazioni che, se confermate, faranno sicuramente la gioia dei fan AMD e in generale di tutti gli appassionati che sono in attesa di aggiornare la propria scheda grafica.

Secondo un post pubblicato dal profilo twitter del noto tool di capturing CapFrameX, la GPU AMD "Big Navi" (si presume quindi la variante Navi 21 XTX) sarebbe in grado battere la GeForce RTX 3080 di NVIDIA (Recensione) nel benchmark 3DMark Fire Strike Ultra.

Nel tweet in questione non vengono riportati screenshot ma solo i punteggi che, come anticipato, vedono la nuova scheda AMD battere l'antagonista con uno scarto di circa l'8,5%, ossia 11500 vs 10600 punti. Ribadendo che si tratta di risultati ancora da confermare, a distanza di pochi giorni dal lancio è probabile che questo test sia stato condivisio da qualche partner AMD che, ovviamente, ha già in mano i primi esemplari della scheda, così come i pochi e fortunati tester.

Sempre da twitter arriva poi quella che sembra a tutti gli effetti la prima immagine del PCB della Radeon RX 6800 XT, scheda che secondo le attuali informazioni dovrebbe utilizzare la GPU Navi 21 XT da 4608 Stream Processor, affiancata da 16GB di VRAM GDDR6.


Come potete facilmente notare, il PCB è privo degli 8 moduli GDDR6, utilizza un doppio connettore PCI-E 8pin e un vistoso sistema di dissipatori passivi sui VRM, caratteristica quest'ultima che lascia intuire come quello in foto sia in realtà un esemplare pre-produzione di una versione custom di un partner AIB AMD. Visto che il modello di punta della serie, Radeon RX 6900 XT, dovrebbe essere almeno inizialmente una prerogativa AMD, è facile dedurre che siamo di fronte a una Radeon RX 6800 XT, confermando tra le altre cose che questo modello sarà dotato di 16GB di memoria.

A distanza di cinque giorni dal lancio, l'attesa per le Radeon RX 6000 continua a salire e, a differenza di quanto ipotizzato qualche mese fa, AMD potrebbe realmente tentare il colpaccio su NVIDIA, dopo aver messo alle strette Intel nel mercato processori con i Ryzen 5000 annunciati l'8 di ottobre.


243

Commenti

Regolamento Commentando dichiaro di aver letto il regolamento e di essere a conoscenza delle informazioni e norme che regolano le discussioni sul sito. Clicca per info.
Caricamento in corso. Per commentare attendere...
lucusta

doppio account?
tu mi chiami e poi m'insulti?
non funziona così la civiltà....

B!G Ph4Rm4

Ma perchè non è che uno ci gioca e basta con la GPU, puoi farci photoshop, puoi farci altre due mila cose oramai. C'è una marea di gente che non vuole spendere 3-4-5-6k per una Quadro e si compra la RTX, per dire.

Detto questo, spero che ribannino te e il tuo account originale lucusta anche da questo sito.
Che la vostra infestazione anche qui sia il più breve possibile? Ti hanno bannato definitivamente albertino alias lucusta, su Tom's, visto che siete venuti qua?

B!G Ph4Rm4

Ahahahah, ecco che hai tirato fuori il doppio account. Ma che problemi psicologici avete a farvi i doppi account? Che tristezza

Albertino

non è una soluzione Open; è una soluzione da API: DirectML.

sei pregato di fare meno propaganda.

lucusta

dimmi ragazzo, qual è il tuo problema?
vuoi che ti spieghi io in parole più semplici quello che già altri ti hanno ampiamente illustrato?

leggo spesso nominato il mio nome su queste pagine, di solito dai soliti elementi di poco conto che girano su tomsHW.
su tomshw non ti leggo spesso.
se hai qualche problema nel capire le questioni basta che chiedi e, gentilmente, ti sarà risposto.

Albertino

il punto è che non lo capisci tu, amico mio.

B!G Ph4Rm4

Incredibile, chi l'avrebbe mai detto. Il punto è che non si capisce quello che vuoi dire sopra

Albertino

secondo me ancora non hai compreso il punto essenziale del discorso:
senza benchmark di terze parti sono solo chiacchere.

B!G Ph4Rm4

Secondo me stai facendo una confusione pazzesca o non ti riesci a far capire (o sarà colpa mia, boh). 32 thread per warp o 64 non vogliono dire in alcun modo 64 OP. Vogliono dire appunto 32 o 64 thread che partono ed eseguono un kernel. Può essere lungo quanto ti pare, può esserci il codice che ti pare. Tutti i thread all'interno di un warp eseguono la stessa istruzione, sempre, quindi l'esecuzione asincrona, se ti riferisci a questo, non c'entra nulla. Quella va vista a livello di grid (o l'equivalente per le AMD), non di certo a livello di warp o di singoli thread.
Stesso discorso per gli FP16 che non vedo cosa c'entrino.

Anzi, continuando a leggere credo che con asynchronous computing intendi quello che intendo io, e quindi vale quello che ho scritto sopra. A meno che nel caso delle DX12 si parli di altro (non credo).
Se è la stessa cosa che intendo io, l'esecuzione asincrona altro non è che un modo per evitare che esecuzioni indipendenti vengano bloccate dalle altre prima di loro. Sostanzialmente permette ai vari thread della CPU di lanciare kernel in maniera appunto asincrona e non aspettare l'esecuzione di altri kernel lanciati da altri thread. Fine. Tutto ciò avviene a livello di grid, ovvero quanti thread vengono lanciati totalmente per eseguire quel kernel, ed è un discorso totalmente indipendente da come sono disegnati i warp. Proprio non c'entra nulla.

Albertino

Asincronous computing probabilmente predilige warp corti, a 32 stadi; molti giochi usano FP16, in cui si fanno mezze traslate di piani; ci sono decine di casi in cui, nei giochi, puoi usare una schedulazione meno profonda per migliorare l'esecuzione generale dei vari thread nella macchina, non solo nella GPU.
la condizione di evitare branching ed usare una "metrica" a 64 step deriva principalmente da 2 fattori:
il primo è che traslare una coordinata di un vettore da uno spazio 3D ad uno 2D 8ed è quello che fanno in continuazione le GPU), ci vuole una matrice 3x3 e questa la risolvi in 64 OPs;
la seconda è perchè la maggior parte dei motori grafici (soprattutto quelli che hanno una licenza free use) prende ad esempio le architetture nvidia e se prendi una come quella di Maxwell, praticamente poteva operare solo in quel modo.
nessuno ti dice che continuerà in questo modo (ed infatti non si opera più in quel modo se non in UE4).
AMD ha operato per anni con warp 32 doppio, ossia un doppio passaggi su scheduler per arrivare ai fatidici 32 stadi di calcolo, ma questo comportava un "ricaricamento" della schedulazione e quindi latenze ed impegno superiore della macchina.

è da Polaris che usa anche un warp a 64 stadi.
oggi ha solo equiparato l'HW alla logica che viene usata nei driver, ma solo per sopperire alle sue "mancanze" verso codice pensato in modo vecchio.
già con le DX12 si è passati ad altro modo di utilizzare la GPU e la sua schedulazione e prossimamente, anche per l'aggiunta di DXR, il vantaggio di usare una concatenazione così lunga di un processo semplicemente svanirà con il passaggio nel fare i giochi, in cui si passa ad altri obbiettivi: non si può più salire di frequenza sul singolo core, quindi o si demanda il lavoro anche sugli altri core, o si rimane limitati dalla stessa potenza delle CPU in single core;
diventa anche inutile aggiungere ulteriore lavoro grafico in quanto è sfruttabile solo su alcune tipologie di giochi, non su tutti, quindi diventano inutile anche nuove tecnologie che frenano troppo le prestazioni a causa della CPU... inventarsi poi stratagemmi per semplificare i compiti alla CPU non serve a molto...

quindi consiglio di guardare prima i risultati e poi rifletterci sopra.... ma prima facciamoli almeno uscire.

B!G Ph4Rm4
perché dici che non avviene.
se ci pensi bene, in un albero BVH hai più lock che continuazioni di thread...

Non so come funzionano le implementazioni dell'algoritmo, quindi se hai un profiling dell'esecuzione se ne può discutere. E da quel che leggo, è una sottocategoria di alcune applicazioni di computer grafica, non CGI in generale.

comunque non ti dicono che vengono ottenuti ESCLUSIVAMENTE in quei casi, ma che è stato pensato per sanare PRINCIPALMENTE quella situazione... diamo peso alle parole.

E io ti dico che ci sono svariati casi in cui non esistono dipendenze. Ovvero ci sono molti algoritmi dove fortunatamente non hai branching affatto, in altri ce ne può essere molto. Anche se a dire il vero un buon programmatore dovrebbe trovare il modo di eliminare il branching nella maggior parte delle situazioni.
Quindi rimane valido quello che è scritto sopra.

Albertino

perché dici che non avviene.
se ci pensi bene, in un albero BVH hai più lock che continuazioni di thread...
comunque non ti dicono che vengono ottenuti ESCLUSIVAMENTE in quei casi, ma che è stato pensato per sanare PRINCIPALMENTE quella situazione... diamo peso alle parole.

B!G Ph4Rm4

Si ma ti dice anche il perchè vengono ottenuti. Vengono ottenuti in quei casi in cui una parte significativa dei thread sarebbe in lock perchè deve aspettare gli altri thread all'interno di un warp.
Cosa che non avviene per la computer grafica, ergo videogiochi, ergo FSU.
Ergo non c'entra con la questione sopra.

Albertino

i benefici di IPC li hanno ottenuti soprattutto su Wave64, quindi con warp 64.

Albertino

Figure 3 below illustrates how the new dual compute unit exploits instruction-level parallelism within a simple example shader to execute on a SIMD with half the latency in wave32 mode and a 44% reduction in latency for wave64 mode compared to the previous generation GCN SIMD.

IPC.
come puoi leggere si è tagliato il 30% della latenza anche su Wave64, quindi con un warp a 64, più adatto alle trasformate di coordinate tipiche della grafica 3D.

per quanto riguarda il "riferimento" e solo marketing.
AMD sta ricalcando in tutto e per tutto il marketing che ha fatto nvidia sulle sue Ampere per dimostrare una presunta superiorità.
se vedi seguono passo passo la strada segnata dal marketing nvidia...
lo scopo di AMD è, probabilmente, di far notare al pubblico che questi leak non solo altro che una diretta campagna di marketing, a sua volta usata da nvidia per "condizionare" il pubblico.
una volta che la gente si sarà resa conto che i leak non sono altro che pubblicità, farà la dovuta attenzione a quello che scrivono le testate e gli daranno il giusto peso, ossia "è solo pubblicità" ed in quanto tale non ti dirà mai la vera verità.

PS:
anche i benchmark sintetici sono un sistema inventato per fare solo marketing... di per se non servono a nulla.

B!G Ph4Rm4

Guarda che l'IPC è direttamente tirato in ballo nella questione.
Se io ho un metà dei thread che devono aspettare gli altri per finire l'esecuzione e rilasciarli, sto perdendo (pochi, tanti, una marea) cicli di clock a non far nulla. Loro dicono "in certi casi, con 64 thread per warp, lo spreco è enorme, quindi permettiamo di usare anche 32 thread in modo che se lo spreco c'è, sia minore e limitato".

si è visto sia sui benchmark sintetici che sui giochi rispetto alla sua precedente architettura.

Non ha connessione logica con quello che è la computer grafica, come viene implementata e quello che dice AMD nel whitepaper. AMD nel whitepaper scrive lei stessa che in task grafici, cito "existing graphics-focused wave64" l'esecuzione di warp a 64 thread è più indicata.
Quindi la maggior efficienza nell'uso di warp di 32 thread non sembra toccare l'ambito grafico.
FSU, ecc sono benchmark grafici, ergo il discorso che hai fatto sulla dimensione dei warp non c'entra. Idem nei giochi veri e propri.

Albertino

si parla di IPC non propriamente di tecnica warp.
AMD è riuscita, con l'agiunta del secondo scheduling, a limare cicli di esecuzione sulle varie OPs di un 30% buono e questo, di riflesso, si è visto sia sui benchmark sintetici che sui giochi rispetto alla sua precedente architettura.

un netto aumento di IPC che ha compensato l'erronea credenza che "i TF AMD non sono uguali ai TF Nvidia", ma a causa di altri fattori dovuti ad una errata considerazione di cosa fanno le singole unità di calcolo.
che poi questa tecnologia si riflette anche su codice GPGPU generalista è normale...

PS:
si riflette su GPGPU generalista perché è comunque codice generico, ma un'architettura come Vega deve essere usata con codice specialistico, per come è fatta l'architettura.
il doppio scheduler ha un peso sia sui consumi che sulla dimensione del chip e in ambito prettamente HPC è più conveniente far consumare la potenza a delle pipeline in più, che possono offrire più potenza computazionale, che moduli accessori;
basta che programmi per come dev'essere usata l'architettura.
anche la grande caches di Vega è del tutto inutile nei giochi, ma molto utile in ambito HPC...

come ti scrivevo prima si deve vedere come è implementata la caches a livello HW per riuscire a capire se un tipo di codice ne ha o meno giovamento (se l'architettura risponde meglio); anche Vega

ha una bella caches, ma non è stata mai sfruttata in ambito videoludico, perchè probabilmente la sfrutta come una L3 e non come una L2 (essenzialmente dipende dal bus di comunicazione con le singole unità, se diretto o unificato).

B!G Ph4Rm4

Ripeto, come tra l'altro scrive anche AMD nel whitepaper, non esiste nessuna dimensione di warp "migliore in assoluto e punto". Dipende dall'algoritmo che viene eseguito e da come è stato pensato. Come loro scrivono, giustamente immagino, lasciare la possibilità di usare un warp di 32 thread può portare dei benefici in tutti quei task complessi dove la probabilità di avere il branching è alta o addirittura diventa inevitabile, ergo, se il fenomeno è pronunciato, il degrado prestazionale sarebbe assolutamente sostanziale.
Loro affermano comunque che non è questo il caso della grafica (e a ben vedere, da quel poco che mi hanno spiegato amici che fanno videogiochi e sanno come funziona la computer grafica), dove un warp da 64 thread continua a rimanere la scelta migliore.

Ergo, continuo a non capire cosa c'entri tutto ciò con il mio discorso iniziale, dove parlavo di grafica e prestazioni in game.

Per il resto, sono convinto che una spiegazione ci sia e non ho neanche io voglia di approfondire troppo, ritengo tuttavia strano che si prenda questo benchmark come riferimento, visto che sembra favorire le schede AMD.
Un'altra prova di tutto ciò è che sono stati leakati i punteggi della stessa scheda dell'articolo (verosimilmente la 6800XT) in TS e TSE, che ho confrontato con i punteggi in game e sembrano molto più realistici, e mostrano come invece la 3080 stia sopra in entrambi i test.
Com'è che in TS e TSE la 3080 sembra stia sopra alla 6800XT, mentre in FSU, un benchmark che sembra avvantaggiare le AMD, sta sotto? Visto che, appunto, le 5700XT non sono affatto così vicine alle 3080 in game.
E' questa la questione che ho posto.

Albertino

la fonte te l'ho aggiunta sul post sopra.

il warp scheduling influisce direttamente sull'efficienza della pipeline.
parliamo sempre di TF teorici, ma in effetti questa è la misura di operazioni molto semplici che eventualmente riescono ad essere eseguite una per ogni singolo clock del chip... non è mai così.
le operazioni che mediamente si usano sono più complesse e servono più cicli per riuscire ad essere completate.
meno cicli impieghi per operazione, più l'IPC aumenta.
il problema è che l'uso delle varie OPs variano mediamente sia per lo scopo che per l'abitudine dello sviluppatore ad usare una o l'altra (e del compilatore nell'approfittare di particolari workarround sulle specifiche architetture, dall'ottimizzazione che hanno)...
è quindi aleatorio parlare di TF teorici, soprattutto quando poi non si considerano fattori incisivi come quello che ti ho menzionato sopra.
il confronto che fa AMD sulle due diverse architetture (Vega e Navi) lo fa in relazione allo stesso gruppo di OPs, quindi si parla specificatamente di IPC di pipeline e l'IPC è direttamente correlato alle prestazioni (qui hanno tagliato un sacco di latenze).

non ti contestavo nessuna questione prestazionale; ti facevo semplicemente osservare che confrontavi 2 GPU (non architetture, ma implementazioni) nettamente diverse sia in modo di calcolare che in prestazioni offerte su un codice che è tra l'altro ancora più particolare (in quanto non riflette essenzialmente le esigenze di calcolo di un comune gioco... non ha INT sufficienti).
puoi grossolanamente confrontare schede con prestazioni molto simili, ma non schede così nettamente distanti in quanto a rapporto prestazionale... entrano in gioco troppe ulteriori questioni che possono deviare la linearità diei valori che il benchmark ti mostra.
potrei studiare più attentamente questo benchmark per dirti quanto è la sua curva di deviazione dalla linearità in rapporto alle potenze grafiche (e della CPU), ma non credo che ne valga il tempo speso...

comunque basta che guardi la prova di una Turing più lenta, come la 2060, fatta dalla stessa testata
hothardware. com/reviews/nvidia-geforce-rtx-2060-review?page=3

come vedi non esiste linearità: secondo i dati della 2060 la 2080 Ti dovrebbe superare i 9250 punti nel graphics score.

B!G Ph4Rm4

Ti faccio notare che il link al whitepaper dice esattamente quello che ho scritto sotto:

The RDNA architecture is natively designed for a new narrower wavefront with 32 work-items,
intuitively called wave32, that is optimized for efficient compute. Wave32 offers several
critical advantages for compute and complements the existing graphics-focused wave64

mode.
One of the defining features of modern compute workloads is complex control flow: loops,
function calls, and other branches are essential for more sophisticated algorithms
. However,
when a branch forces portions of a wavefront to diverge and execute different instructions, the
overall efficiency suffers since each instruction will execute a partial wavefront and disable the
other portions. The new narrower wave32 mode improves efficiency for more complex compute
workloads by reducing the cost of control flow and divergence.

1) l'esecuzione di 32 thread alla volta è utile nel computing, quindi non in grafica o videogiochi
2) c'è scritto chiaramente che la wave64 è migliore ed ottimizzata proprio per l'esecuzione di codice di "grafica", quindi videogiochi
3) quando sotto ho scritto: "ad esempio una metà dei thread finisce prima dell'altra metà" mi riferivo proprio all'ultima parte che ho messo in grassetto. Se il tuo algoritmo definisce condizioni, ad esempio "se x > n fai questo, altrimenti fai quest'altro", e assumento che metà dei tuoi dati soddisfano la condizione, e assumendo che se la condizione è True l'esecuzione che segue sia più veloce rispetto a quando è false, ti ritroverai, mediamente, con metà dei thread in un warp che hanno finito e aspettano gli altri che devono concludere, avendo sostanzialmente un'inefficienza nell'esecuzione. Quello che in modo più tecnico nel paper chiamano branching.

Ma appunto, come scrivono loro, si parla di scenari che si ritrovano per la maggior parte in compiti di GPGPU, non di grafica o videogiochi.

Ergo, continua a non tornare cosa c'entri tutto ciò con i punteggi di firestrike o dei videogame

Albertino

il link l'ho già messo nel post (di solito sono uso nel citare le fonti);

comunque era la review di hothardware della 3080.

Albertino

mediamente è del 30%, ma non andrei a guardare il 4K... non ci sono oggi giochi così pesanti da non limare un po' di prestazioni a questa scheda a causa dei bottleneck della CPU, anche a 4K.

se in un benchmark hai il framerate che scende da una media di 100 a brevi tratti in cui sei a 60 a causa della CPU, lo avrai con ogni scheda che supera 60 e cambierà solo se cambi CPU.
quindi una scheda che nella maggior parte delle situazioni esprime 120fps avrà una media molto più intaccata da quei brevi tratti a 60fps dovuti alla CPU di una che fa solo 100fps.
dipende essenzialmente se è la GPU o la CPU a limitare il framerate (e lo vedi essenzialmente cambiando GPU o CPU sull'analisi del gioco ed osservando il plot del frametime; i picchi dovuti alla GPU viaggiano con la varietà delle potenze espresse dalla GPU, quelli dovuti alla CPU per quelle delle CPU... ecco perchè ritengo che le analisi prestazionali che fanno molti siti di tecnologia sono decisamente carenti).

un'altra cosa:
i benchmark integrati nei giochi sono, solitamente, più pesanti e condizionati da quanto poi si ha nel normale gameplay.
nascono, in effetti, per tarare il proprio sistema alle peggiori condizioni che si potrebbero incontrare nel gioco e ma non riflettono la richiesta media del gioco, ma solo quella più esigente.

B!G Ph4Rm4
su firestrike si usano OPs di piccola entità dove il warp scheduling ha un rendimento netto molto più elevato, ma questo va oltre la tua osservazione:

Mi serve la fonte per questo, e per la quantità di codice INT di cui parli, altrimenti parliamo di aria fritta.

dove il warp scheduling ha un rendimento netto molto più elevato

Che senso ha questa frase? Il warp scheduling è semplicemente il modo in cui viene decisa l'esecuzione dei thread, sulle NVIDIA per dire un warp gestisce 32 thread, su RDNA 32 o 64. Non è una cosa introdotta su RDNA, è un concetto fondamentale che esiste da sempre. Semplicemente il warp è l'unità fondamentale (più piccola) di raggruppamento di thread per l'esecuzione, nient'altro.

E sinceramente non si capisce come metti in relazione il cambio di dimensione dei warp con le prestazioni. Non esiste una dimensione giusta ed una sbagliata in senso assoluto. A meno che per qualche strano motivo il tuo algoritmo non sfrutta pienamente tutti i thread di un warp (ad esempio una metà dei thread finisce prima dell'altra metà), non si può dire "ora puoi anche farli da 32 quindi è meglio per quello".

Per il resto, guarda che non hai capito il mio commento. Io non mi sto lamentando delle prestazioni della 5700 XT, io sto dicendo che, visto che la 5700 XT fa 7000 punti, la 3080 dovrebbe farne 14000 in quel test, ma ne fa solo 11000, visto che in game la 5700 XT fa 47 fps e la 3080 ne fa 93, in 4K.

Dal momento che la memoria c'entra ben poco, perchè anche come potenza bruta (in tflops, ma non solo), la 3080 verosimilmente disintegra la 5700XT in ogni test reale di computazione (deep learning, per dire, anche se non di bench che ho cercato non ci sono), ripeto, com'è possibile che il distacco sia così basso in 4K su quel test, visto che in game è invece enorme, e visto che come potenza bruta il distacco, forse, è ancora maggiore?

Albertino

ho aggiunto al post un altro dettaglio: il wave32...
su firestrike si usano OPs di piccola entità dove il warp scheduling ha un rendimento netto molto più elevato, ma questo va oltre la tua osservazione:
in 4K la 5700 XT perde sempre qualche frame, limitata dalla banda della RAM; lo puoi vedere in tutti i giochi confrontando la 5700 XT con una Turing.
i 448GB/s per quella architettura sono limitativi, più di quanto non lo fossero sulle precedenti.
AMD ha sempre sofferto del fatto che utilizza una disposizione della VRAM unificata, ossia tutta la VRAM della scheda è disponibile alla singola unità, congestionando il bus dati (sulle architetture Nvidia hai uno o due chip direttamente sfruttati da un singolo GPC; i vari SKU inferiori derivati da un chip possono modificare questa disposizione, ma a scapito delle prestazioni pure, come avveniva sulla 970).
andare a guardare i 4K su una 5700 XT non è quindi indicativo, perché hai le VRAM che fanno bottleneck e perché non è una schedda pensata per quell'ambito.
d'altra parte non è pratico andare a valutare le prestazioni di una 3080 in 1440p o 1080p, perché è quasi sempre in bottleneck della CPU...
l'infinity caches che si presume abbiano messo in Big Navi sicuramente aiuterà la gestione dei dati in circolo nella GPU, sposando sia i vantaggi di una VRAM unificata, sia quelli di una connessione diretta della RAM per singolo gruppo di unità di calcolo, perché hai sempre la VRAM unificata, ma la caches che comunica con tutte le unità non replicando nemmeno i dati...

ma finché non hai i numeri non puoi dire quanto giovi questo in firestrike o in un gioco normale.

i due interventi sono per far comprendere agli appassionati che l'architettura è stata profondamente cambiata (anche solo per l'inserimento della caches) e che quindi non ci sono più riferimenti attendibili.
riferimenti che, tra l'altro, vertevano su errate interpretazioni delle architetture.

servono i test... prima è inutile parlarne.
in pratica non si può dire se il raffronto che si fa tra i (presunti) valori del benchmark firestrike e i normali giochi sarà come prima, se peggio o meglio, perchè semplicemente è troppo complicato riuscire a prevedere cosa comporti l'inserimento di una grande porzione di caches (e non sappiamo nemmeno come è collegata alle VRAM e alle unità di elaborazione).

PS:
non si può mettere a confronto nemmeno con le APU delle console, perchè quelle non sono realmente RDNA2, in quanto usano gli stessi miglioramenti delle pipeline, ma non hanno l'infinity caches (in una APU sarebbe stato troppo oneroso... sarebbe diventato un chip da 400-420mm2 con al'linterno transistors che dovevano girare a 3.6ghz... è pretendere troppo per un chip oltremodo mainstream), che è essenzialmente il punto su cui verte l'intera speculazione sulle prestazioni di Big Navi.

B!G Ph4Rm4

Continuano a non tornare i conti, perchè se per questo bench fosse così il distacco tra 2080 e 5700 XT dovrebbe essere "falsato" rispetto a quello in game, ma quello tra la 3080 e la 5700 XT dovrebbe essere giusto, visto che su ampere hanno permesso di calcolare FP32 con le unità "miste".
Invece non viene rispettato perchè la 5700XT fa qualcosa come 7000 punti (non lontano da una 2080 Ti, che invece in game è moooolto lontana) e la 3080 ne fa 11000 circa, mentre come fps, in 4k, ne fa il doppio di una 5700 XT.
Se fosse come dici tu il punteggio della 2080 Ti sarebbe quasi "giusto", mentre la 3080 dovrebbe fare qualcosa come 14000 punti, cosa che non fa, mai.

Tra l'altro mi manderesti il link dove hai preso queste info sui benchmark, lucusta, dovrebbe essere questo il tuo vero nick, giusto?

Albertino

il test favoriva le AMD per il loro tipo di architettura: le AMD possono calcolare FP ed INT sul medesimo SP, come oggi Ampere può fare sulla metà dei suoi cudacore.
questo test ha ben pochi INT da calcolare.

questa tua osservazione riprende il solito meme che "i TF di AMD non sono i TF di Nvidia", ma la questione è sempre stata nel fatto che Nvidia ha sempre usato pipeline distinte per fare FP e altre per fare INT, fino ad arrivare alla condizione, con Turing, di avere mezza architettura con FP e mezza con INT.

quindi la prestazione delle diverse architettura dipende esclusivamente dal tipo di calcoli e dalla frazione percentuale che devono fare su un gioco.

su firestrike fanno più FP32 che INT32, quindi risulta che una AMD e Amprere hanno più prestazioni di una Turing di egual misura, ma perché la percentuale media di INT nel codice è inferiore a quella di un gioco normale, quindi useranno più unità miste per fare FP32.

è quindi il riferimento che prendi che è sbagliato: "l'unica cosa che si può dire con relativa certezza è che sembra favorisca AMD".
la realtà è che l'unica cosa che si può dire con relativa certezza è che (questo benchmark) sembra favorisca le architettura che hanno pipeline che computano indifferentemente su più basi, che hanno una flessibilità d'uso, quindi quelle AMD, ma anche Ampere.

ti puoi fare i calcoli per quanti INT usa firestrike, basta che fai la proporzione tra Ampere e Turing, normalizzando i punteggi per frequenza e per numero di cudacore in FP32: circa il 20%, contro il 30% che di solito si usa nei giochi...
è per questo che AMD (ed oggi anche Ampere) performa meglio delle passate generazioni nvidia di circa il 10% rispetto a quanto poi si riscontra sui giochi.

B!G Ph4Rm4

Io ho scritto che la 3080 è il 30-40% meglio della 2080 Ti a seconda dei giochi IN GAME, non in quel bench

Albertino

a 4K se li facevi con un celeron cambiava quasi nulla.

Albertino

Joined Oct 16, 2020

masterblack91

Mi scusi,ma io ho giudicato i suoi genitori? Poi,giudicare qualcuno da una frase è estemamente sbagliato e riduttivo.
Io potrei dire:"ma che educazione le hanno dato i suoi genitori che,non ha rispetto e giudica altre persone?".
Vuole essere educato? Non giudichi gli altri da una frase.
Io non la conosco e lei non conosce me,io NON posso giudicarla ne dire nulla al riguardo e non lo faccia nemmeno lei con me :)

TecR6

Tra 250W e 350W non te ne accorgi nemmeno a fine mese in bolletta.

Volpe

e borderlands. tutto il resto (per fare l’italiota qualunquista) nvidia ha il suo vantaggio. soprattutto nei titoli vecchi di decine di anni (2000/2005)

Lupo Alberto
Luxto

vediamo la stabilità e performance in game , dove spesso finisce sempre che AMD fa schermate nere a non finire, i benchmark lasciano il tempo che trovano. DLSS e Ray Tracing, Nvidia è avanti. almeno che non faccia il doppio dei frame, può restare sullo scaffale per me.

458 speciale

sbagliato: i leak provengono da igor's lab, che a sua volta li ha avuti da partner AIB di AMD che montano sia nvidia che AMD nelle loro piattaforme di prova, che sono le stesse per ambo le gpu...ergo l'hanno provata a parita di processore, qualunque esso sia

Farmer Armer

io spero consumino meno watt la bolletta ne risente XD a parte gli scherzi spero ci sia una buna battaglia cosi passo ad amd anche nelle schede video sono passato da intel ad AMD e sono sodisfatto.

Lupo Alberto

Che facciamo? Tiriamo fuori Fermi?

Emiliano Frangella

Vero
Ma hanno fatto vedere anche test di soli Frame

Emiliano Frangella

Ho avute tutte, sia amd che Nvidia. Sinceramente una rx5700xt a 450 da una pista ad una 2060 super dello stesso prezzo . ..
Esempio.

Poi dipende da gioco a gioco.

10-13 frame hai un po' esagerato.

Alessandro

Io vorrei che tu smettessi di fare propaganda, ma non sempre si può avere ciò che si desidera

Alessandro

Si vedrà..

Alessandro

Le 3080 son testate con cpu Intel, le nuove radeon con zen 3 che è molto meglio, nel 3dmark il cpu score influisce tantissimo.. Pensaci.

Frazzngarth

ma le hanno già presentate e il benchmark è una roba ufficiale...?

marco polo

Ma cosa? Amd boy... È dalla 480 che sento dire ste boyate... P.s. Radeon 7

Lupo Alberto

Rispetto ad Ampere, al momento, sembra andare il 20% meno.

Al momento.

Junior Lo

Rispetto ad ampere intendo,staremo a vedere,spero vada bene almeno meglio per le nostre tasche

Lupo Alberto

L'unico modo che ha Nvidia per salvare il salvabile è mettere il GA-102 nella serie 3070, rimettendoci un sacco di soldi.

Lupo Alberto

Meglio di Turing.
Ma aspetta l'upscaling.
Ricorda che oltretutto AMD va molto meglio in gioco che in benchmark.

Lupo Alberto

Lo è.

Lupo Alberto

600€.

Recensione NVIDIA GeForce RTX 4070 Ti: consuma poco e vola nel gaming a 1440P

Recensione Gigabyte GeForce RTX 4080 AERO OC: Potente e imponente

Recensione Intel Core i5-13600K: Core i7 sei tu? Test con DDR4 e DDR5

Recensione AMD Ryzen 9 7950X e Ryzen 7 7700X: ecco i nostri test con ECO MODE