UFFICIALE AMD RX Vega 56 e 64 - La risposta ai GP104

Pubblicità
Io se una dual Vega ottimizzata con infinite fabric quindi uno scaling dall' 80% minimo a salire andasse anche un 10% piú di una top volta io lo farei l.acquisto però questo è sognare ad occhi aperti. A me fotte sega del marchio acquisto quella che va di più

Inviato da MotoG3 tramite App ufficiale di Tom\\\'s Hardware Italia Forum

mha... tempo fà si parlava di una tecnologia che avrebbe permesso di far vedere al sistema piu' cluster come uno soltanto (tutto via software... come se avessi una GPU virtuale e usassi due risorse reali distinte), ma implicava un buon processo di astrazione e, soprattutto, una bella banda passante, oltre che un i "soliti accessori" (buffer da paura).
qui:
https://www.google.it/patents/EP3060979A1?cl=en&dq=inassignee:"Advanced+Micro+Devices"
hai l'estratto di astrazione di un brevetto per la compressione dei dati sul bus di comunicazione tra CPU e tra GPU.
contando che infinite fabric tra due CPU (e anche tra le GPU), indicato nei paper come 4-XGMI (4 dovrebbe essere l'estensione del link e la sigla dovrebbe indicare eXternal Global Memory Interconnect), puo' avere una bidirezionalità da 100GB/s, con una buona compressione e la replica di alcuni set di memoria su entrambe le schede, passando solo le istruzioni base, la limitazione maggiore che un CF possa avere credo sia parecchio ridimensionata...

purtroppo nulla c'e' dato di sapere di piu' ad oggi...

io credo che questa tecnologia sia pero' piu' adatta a mGPU DX12, nel momento in cui non vengono operati un frame a GPU, ma che un frame sia diviso per quante GPU si usino...
credo che questi "messaggi" siano dovuti piu' che altro alla distribuzione di carico.
faccio un esempio per spiegarmi meglio:
ho un frame da 3840x2160 x 3 schede (abbondiamo).
lo divido non i tre spezzoni da 1280x2160x3, ma in 3 da, diciamo 1600x2160 pixel. mi trovo nella condizione per cui la prima scheda calcola la prima frazione di 1600 (in larghezza), la seconda scheda dal pixel 1120 al pixel 2720, l'ultima da 2240 a 3840, quindi parte della prima sezione e parte dell'ultima sezione sono in parte coperte da quella di mezzo, per cui si accavallano per una striscia di 480 pixel.
le schede lavorano, ma se la scheda 1 ha carico elevato per i suoi 1120 suoi esclusivi pixel, mentre quella che si occupa della sezione di mezzo è piu' scarica, non processera la striscia da 240 pixel (metà dell'accavallamento), ma sarà la scheda 2 a farlo... e cosi' per quanto riguarda la terza.
in questo modo hai la proprietà di poter variare dinamicamente il carico delle CPU senza doverle caricare di memoria inutile...
quella condivisa sarà solo relativa ai 480 pixel di accavallamento delle due strisce...

ora, per gestire la dinamica, devi comunque dare nozione alle schede interessate... un bel trafico.

in piu' si potrebbe optare direttamente per il travaso di calcolo, per cui un graphics engine puo' comandare graphics processor dell'altra scheda, ma solo per la parte per cui si accavallano, quindi con un carico decisamente inferiore rispetto a quello che dovrebbe fare per l'intero frame...

purtroppo mGPU è a carico degli sviluppatori, ed in ultimo ai motori grafici, quindi... io son ignorante sulle dinamiche logiche dei motori in uso oggi, figurarsi su quelli che non ci sono e no si possono ricavare esempi...
 
Amd non fallirà mai solo impiega le forze in fasce diverse basta pensare quante rx5
mha... tempo fà si parlava di una tecnologia che avrebbe permesso di far vedere al sistema piu' cluster come uno soltanto (tutto via software... come se avessi una GPU virtuale e usassi due risorse reali distinte), ma implicava un buon processo di astrazione e, soprattutto, una bella banda passante, oltre che un i "soliti accessori" (buffer da paura).
qui:
https://www.google.it/patents/EP3060979A1?cl=en&dq=inassignee:"Advanced+Micro+Devices"
hai l'estratto di astrazione di un brevetto per la compressione dei dati sul bus di comunicazione tra CPU e tra GPU.
contando che infinite fabric tra due CPU (e anche tra le GPU), indicato nei paper come 4-XGMI (4 dovrebbe essere l'estensione del link e la sigla dovrebbe indicare eXternal Global Memory Interconnect), puo' avere una bidirezionalità da 100GB/s, con una buona compressione e la replica di alcuni set di memoria su entrambe le schede, passando solo le istruzioni base, la limitazione maggiore che un CF possa avere credo sia parecchio ridimensionata...

purtroppo nulla c'e' dato di sapere di piu' ad oggi...

io credo che questa tecnologia sia pero' piu' adatta a mGPU DX12, nel momento in cui non vengono operati un frame a GPU, ma che un frame sia diviso per quante GPU si usino...
credo che questi "messaggi" siano dovuti piu' che altro alla distribuzione di carico.
faccio un esempio per spiegarmi meglio:
ho un frame da 3840x2160 x 3 schede (abbondiamo).
lo divido non i tre spezzoni da 1280x2160x3, ma in 3 da, diciamo 1600x2160 pixel. mi trovo nella condizione per cui la prima scheda calcola la prima frazione di 1600 (in larghezza), la seconda scheda dal pixel 1120 al pixel 2720, l'ultima da 2240 a 3840, quindi parte della prima sezione e parte dell'ultima sezione sono in parte coperte da quella di mezzo, per cui si accavallano per una striscia di 480 pixel.
le schede lavorano, ma se la scheda 1 ha carico elevato per i suoi 1120 suoi esclusivi pixel, mentre quella che si occupa della sezione di mezzo è piu' scarica, non processera la striscia da 240 pixel (metà dell'accavallamento), ma sarà la scheda 2 a farlo... e cosi' per quanto riguarda la terza.
in questo modo hai la proprietà di poter variare dinamicamente il carico delle CPU senza doverle caricare di memoria inutile...
quella condivisa sarà solo relativa ai 480 pixel di accavallamento delle due strisce...

ora, per gestire la dinamica, devi comunque dare nozione alle schede interessate... un bel trafico.

in piu' si potrebbe optare direttamente per il travaso di calcolo, per cui un graphics engine puo' comandare graphics processor dell'altra scheda, ma solo per la parte per cui si accavallano, quindi con un carico decisamente inferiore rispetto a quello che dovrebbe fare per l'intero frame...

purtroppo mGPU è a carico degli sviluppatori, ed in ultimo ai motori grafici, quindi... io son ignorante sulle dinamiche logiche dei motori in uso oggi, figurarsi su quelli che non ci sono e no si possono ricavare esempi...

Quindi in parole povere dipendendo parecchio dalla banda passante cosa ne pensi di questa tecnologia applicata a vega ? ci può stare non scali alla perfezione vi che le hbm2 non brillano di certo per le memorie veloci, alla fine la banda c'è però è fortemente limitata dalle latenze alte. Però alla fine non si sa se uscirà un dual gpu quindi è inutile fasciarsi la testa, mi interessa in campo cpu e pure qui trova il limite delle memorie di ryzen, chissà come faranno combaciare tutto sono parecchio interessato visto che è una tecnologia nuova
 
Amd non fallirà mai solo impiega le forze in fasce diverse basta pensare quante rx5


Quindi in parole povere dipendendo parecchio dalla banda passante cosa ne pensi di questa tecnologia applicata a vega ? ci può stare non scali alla perfezione vi che le hbm2 non brillano di certo per le memorie veloci, alla fine la banda c'è però è fortemente limitata dalle latenze alte. Però alla fine non si sa se uscirà un dual gpu quindi è inutile fasciarsi la testa, mi interessa in campo cpu e pure qui trova il limite delle memorie di ryzen, chissà come faranno combaciare tutto sono parecchio interessato visto che è una tecnologia nuova
La modularità la vedremo con Navi, ancora mancano un paio di anni
 
Amd non fallirà mai solo impiega le forze in fasce diverse basta pensare quante rx5


Quindi in parole povere dipendendo parecchio dalla banda passante cosa ne pensi di questa tecnologia applicata a vega ?
da che ho memoria ogni chip, alla fine, ha sempre sofferto per la banda passante di qualche bus o memoria (e cache).
più ce n'è, meglio è.

videocardz ha fatto filotto d'informazioni.

die size circa 490mm^2, ma comunque sotto i 500;
2 versioni, da 4096 e da 3584 (da 8 e da 16 GB sotto i mac pro).
sembra che non escano con le memorie hynix (o comunque quei chip che mostrano non sembra siano hynix).
c'e' anche l'intera lineup delle 500 PRO, ma non cambia granchè con le 400, solo una via di mezzo 575 con le CU della 580 e le frequenze della 570, piu' le 560 e 550..
 
da che ho memoria ogni chip, alla fine, ha sempre sofferto per la banda passante di qualche bus o memoria (e cache).
più ce n'è, meglio è.

videocardz ha fatto filotto d'informazioni.

die size circa 490mm^2, ma comunque sotto i 500;
2 versioni, da 4096 e da 3584 (da 8 e da 16 GB sotto i mac pro).
sembra che non escano con le memorie hynix (o comunque quei chip che mostrano non sembra siano hynix).
c'e' anche l'intera lineup delle 500 PRO, ma non cambia granchè con le 400, solo una via di mezzo 575 con le CU della 580 e le frequenze della 570, piu' le 560 e 550..
Una 560 "Pro" che differenze ha con una 560 attuale?
 
Beh dai la 480 alla fine si e' rivelata una bella scheda mainstream, il fatto che fosse praticamente il die shrink di tonga fa sempre pensare che non avessero i mezzi per una architettura nuova
No, aspetta, non proprio il die-shrink, non esageriamo.
Scherzare Sì ma così No.
Queste sono le vere Polaris, non le 400, IMHO.
 
Come ragionamento non lo trovo così sbagliato, alla fine parlando seriamente solo in Italia quanti hanno pc che superano le 2000 euro e quanti dai 1000 in giù ? se dovessi fare un discorso di guadagno preferirei puntare alla fascia dove la gente acquista di più però di fatto amd non ha rilasciato nemmeno vga di fascia media anzi ha lanciato un penoso refresh con consumi abnormi per le performance prodotte
Va bene solo se ti riferisci alle 580.
 
da che ho memoria ogni chip, alla fine, ha sempre sofferto per la banda passante di qualche bus o memoria (e cache).
più ce n'è, meglio è.

videocardz ha fatto filotto d'informazioni.

die size circa 490mm^2, ma comunque sotto i 500;
2 versioni, da 4096 e da 3584 (da 8 e da 16 GB sotto i mac pro).
sembra che non escano con le memorie hynix (o comunque quei chip che mostrano non sembra siano hynix).
c'e' anche l'intera lineup delle 500 PRO, ma non cambia granchè con le 400, solo una via di mezzo 575 con le CU della 580 e le frequenze della 570, piu' le 560 e 550..
Poco meno di 500, le ipotesi erano corrette quindi.
Aggiungo un altro dato:

Apple sul sito dedicato all' imac pro, descrive Vega (11tflops) come tre volte più veloce della m395x, quindi poco sopra la 1080.
Se consideriamo che Vega gaming andrà quasi sicuramente sui 1600mhz, saliamo @12.5/13tflops senza contare il possibile oc della GPU stessa
 
Pubblicità
Pubblicità
Indietro
Top