Link alla notizia: https://www.hwupgrade.it/news/skvideo/una-scheda-dual-vega-da-amd-ma-non-e-per-i-gamers_76559.html

Il modello Radeon Pro V340 è destinato all'ambito professionale, abbinando due GPU della famiglia Vega su singola scheda

Click sul link per visualizzare la notizia.

La scheda nell'immagine non ha manco la ventola di raffreddamento e sembra così simile alle immagini con cui presentarono la radeon instinct mi25 che probabilmente è la stessa immagine con incollato sopra la fascia blu e la scritta "radeon pro v340"
O è solo un'immagine di presentazione o è una scheda da rack con raffreddamento passivo.

Però la mi25 non è doppia e questo non gioca a favore della teoria per cui sia una dual vega.

Qualcuno su reddit analizzando i codici diceva che era una dual, ma l'immagine sarà messa lì tanto per
Molto probabile che sia la dual, evidentemente con if o mcm in questo tipo di applicazioni la memoria si somma...

Usare il raddoppio della quantità di memoria per cercare di capire se è una single o dual non è corretto, dato che da un po' sono stati fatti i nuovi die HBM2 con densità doppia che usa anche nvidia nelle sue V100.

Molto probabile che sia la dual, evidentemente con if o mcm in questo tipo di applicazioni la memoria si somma...
Eh no. l'IF collega chip sullo stesso package, dubito che 2 Vega + 8 chip HBM2 stiano in un package unico.
Esternamente la comunicazione avviene come con il Crossfire tramite PCIe. La somma della memoria funziona tale e quale, cioè con le stesse limitazioni della configurazione Crossfire. Fossero sullo stesso die, la condivisione avverrebbe allo stesso identico modo solo con banda maggiore.

Come con le DX12 dove c'era chi spergiurava avrebbero sommato magicamente i pool di memoria delle GPU in SLI/XF tramite magie SW, anche in questo caso non ci sono miracoli.
Solo limitazioni dovuti alla tecnologia, seppur se tramite condivisione su IF molto più vicini all'ideale modello di memoria doppia con doppia banda totale.

Se sommano due vega fe sono 4 chip di hbm2 non 8
Sicuramente non è vega 20 che per ora si è vista solo nella instinct e passerà ancora qualche mese...

Ecco appunto, penso che sarebbe anacronistico usare il chip plx per connettere le due gpu sullo stesso pcb...poi boh...tanto per questi calcoli vega è una bestia senza se e senza ma

Se sommano due vega fe sono 4 chip di hbm2 non 8
Sicuramente non è vega 20 che per ora si è vista solo nella instinct e passerà ancora qualche mese...
Comunque 2 Vega + 4 chip non ci stanno su un interposer < 2000mm^2

Veramente Infinity Fabric collega anche tra socket diversi, che poi possa comunque portare latenze per cui non è come averle sullo stesso package può darsi.
Ma Infinity Fabric è pensato proprio per connettere tutto.

Sì be', peccato che IF è un protocollo che esternamente è implementato su normali linee PCIe, quindi con le stesse limitazioni di banda e latenze che hai con un normalissimo CF e che quindi non ha le stesse caratteristiche di quando è "on die".

Si ma se fosse una dual non avrebbe pcie in mezzo.

E tramite cosa sarebbero collegati i due package?

IF è implementato sullo stesso HW di PCIe, ma è PtP e fa comunque 100GB/s...
per quello che deve far equesta scheda, anche solo IF implementato come ora è più che sufficiente.

Comunque 2 Vega + 4 chip non ci stanno su un interposer < 2000mm^2



Sì be', peccato che IF è un protocollo che esternamente è implementato su normali linee PCIe, quindi con le stesse limitazioni di banda e latenze che hai con un normalissimo CF e che quindi non ha le stesse caratteristiche di quando è "on die".

1 non si sa quanti canali saranno in comunicazione i due die.
2 due gpunon potranno mai comportarsi come un due monolitico a prescindere di quanto sia veloce il collegamento...il sistema continuerà comunque a gestire 2gpu e pianificare i task di conseguenza, a prescindere da un eventuale accesso di tipo UMA, non implementabile per ovvie ragioni.
3 avrà semplicemente latenze più alte (in vero assai meno molto importante per le GPU), ma il protocollo è pienamente usufruibile, come dimostrabile soluzioni dual socket di AMD

IF è implementato sullo stesso HW di PCIe, ma è PtP e fa comunque 100GB/s...
per quello che deve far equesta scheda, anche solo IF implementato come ora è più che sufficiente.
Il canale IF su PCIe (IFIS) è di 40GB/s bidirezionale, non 100.
E non è solo questione di banda, ma anche di latenze.

1 non si sa quanti canali saranno in comunicazione i due die.
No, ma non cambia il tempo di latenza.

2 due gpunon potranno mai comportarsi come un due monolitico a prescindere di quanto sia veloce il collegamento...il sistema continuerà comunque a gestire 2gpu e pianificare i task di conseguenza, a prescindere da un eventuale accesso di tipo UMA, non implementabile per ovvie ragioni.
3 avrà semplicemente latenze più alte (in vero assai meno molto importante per le GPU), ma il protocollo è pienamente usufruibile, come dimostrabile soluzioni dual socket di AMD

Cioè, quanto ho detto io, che le due partizioni di memoria non sono viste come una anche se con l'IF on chip le latenze diminuiscono (su PCIe sono le stesse della configurazione SLI/XF).
Mica ho detto che il sistema non funziona. Anche con lo SLI puoi accedere alla memoria dell'altra GPU, se sei pronto ad aspettare qualche milione di cicli di clock per avere la tua word.

Non è a me che devi insegnare come funziona una doppia GPU che sia MCM o dual socket. Dovresti spiegarlo a quelli che credono che con l'MC, così come fu con le miracolose DX12, tutta una serie di limitazioni fisiche spariscano per miracolo.

Riporto la frase da cui è cominciato tutto:
Molto probabile che sia la dual, evidentemente con if o mcm in questo tipo di applicazioni la memoria si somma...

No, ma non cambia il tempo di latenza.
iniziamo da qui...i protocolli sono diversi ergo hanno un overhead diverso. Pensa alla riduzione clamorosa delle latenze avvenuta con l'introduzione della terza generazione del protocollo PCI express.


Cioè, quanto ho detto io, che le due partizioni di memoria non sono viste come una anche se con l'IF on chip le latenze diminuiscono (su PCIe sono le stesse della configurazione SLI/XF).
guarda che in VEGA la ram di lavoro è la ram di sistema....le HBM2 sono "solo" delle enormi cache dedicate....


Mica ho detto che il sistema non funziona. Anche con lo SLI puoi accedere alla memoria dell'altra GPU, se sei pronto ad aspettare qualche milione di cicli di clock per avere la tua word.
aspetta. La comunicazione tra le cache serve per gestire la coerenza e non certo a prelevare dati da una LCC di un altro processore, e già il solo traffico di snoop richieda un generosissimo quantitativo di banda passante. Le cache sono dedicate, mi sono perso qualcosa?

Nello SLI le GPU dovevano comunque caricare sulla memoria grafica tutti i dati della scena 3D. Oggi questo limite con VEGA è venuto meno, ed è sufficiente che i dati siano contenuti nella RAM sistema (o qualora non bastasse nella memoria virtuale :O )

No gamers no party :O

iniziamo da qui...i protocolli sono diversi ergo hanno un overhead diverso. Pensa alla riduzione clamorosa delle latenze avvenuta con l'introduzione della terza generazione del protocollo PCI express.
La latenza minima è definita dallo strato fisico che su PCIe è relativa alla frequenza minore rispetto a quella possibile on chip.
Da cui puoi usare tutti i protocolli che vuoi, ma se devi accedere ad una word che sta dall'altra parte di un bus PCIe hai una latenza enorme, che insieme ala banda limitata, ti porta ad ottenere il tuo byte con migliaia di cicli di ritardo.
Come detto puoi, ma non è conveniente.


guarda che in VEGA la ram di lavoro è la ram di sistema....le HBM2 sono "solo" delle enormi cache dedicate....
Quella è la modalità con cui si mappa la memoria interna, ma non cambia una sola virgola di quali sono i tempi e le latenze per accedere alle varia partizioni di memoria.
Se accede alla memoria nella HBM cui è collegata ne sfrutta tutti i vantaggi di latenza ridotta e grandissima banda, se accede alla memoria di sistema avviene quello che avviene su tutte le altre GPU, ovvero aspetta secoli prima di avere il dato. Che sia di sistema o dell'altra partizione di memoria di una GPU.


aspetta. La comunicazione tra le cache serve per gestire la coerenza e non certo a prelevare dati da una LCC di un altro processore, e già il solo traffico di snoop richieda un generosissimo quantitativo di banda passante. Le cache sono dedicate, mi sono perso qualcosa?
Sì, che io non ho parlato di alcuna cache e di nessuna coerenza tra le due. Non è quello di cui parlavo.


Nello SLI le GPU dovevano comunque caricare sulla memoria grafica tutti i dati della scena 3D. Oggi questo limite con VEGA è venuto meno, ed è sufficiente che i dati siano contenuti nella RAM sistema (o qualora non bastasse nella memoria virtuale :O )
Assolutamente falso.
Lo SLI/XF non impone che le due partizioni di memoria contengano gli stessi dati per operare.
E' l'astrazione delle DX9/10/11 che lo impongono perché in questo modo si eliminano tutti i problemi che devono essere affrontati con le DX12 che non impone la limitazione ma ti devi smazzare a mano tutte le problematiche relative ad avere dati diversi in partizioni separate con tempi di accesso secolari in caso di necessita di prelevare un dato della memoria dell'altra GPU
Ecco perché i giochi DX12 non hanno accelerazione multi GPU ed ecco perché sia nvidia che AMD ormai non la supportano più.

Non c'entra nulla Vega e la sua modalità di mapparsi la memoria internamente. Non supera alcuna limitazione fisica che è presente per collegare 2 GPU diverse con 2 partizioni di memoria separate. E come detto, neanche l'IF risolve il problema, pur tamponandolo meglio.

Non so se hai visto che popò di roba che ha realizzato nvidia per connettere le sue GPU sui server HPC. Mica che Vega può farne a meno perché si mappa la memoria di sistema nello stesso spazio di quella locale. La riduzione dei problemi legati all'accesso remoto permangono e serve realizzare bus con capacità enormi e latenze bassissime per limitare i danni. Da qui il multiplex da 300 e oltre GB/s.

Accedere a 2 memorie separate come fosse un pool unico non è solo fare in modo che una GPU veda quella in un'altra partizione, che è una cosa che esiste da sempre (la GPU ha sempre potuto vedere ed accedere alla memoria di sistema, per esempio). Bisogna fare in modo che l'accesso non abbia delle ripercussioni sui tempi di recupero dei dati e che questo non porti a problemi di starving delle pipeline per accessi continui.
Tutti quelli che gridavano al miracolo DX12, due pool separati visti come uno, e bla bla bla, semplicemente hanno scordato questo particolare (o proprio non sapevano di cosa stavano parlando).
Solo allora puoi parlare di "somma delle RAM". Viceversa quando si ha un accesso svantaggioso (e qui si parla di molto svantaggioso) che rende impraticabile l'uso di memoria non locale, non ha alcun senso parlare di "somma delle RAM".
L'accesso alla memoria è uno dei punti critici delle future soluzioni MCM (che già hanno la possibilità di non usare PCIe, quindi molto meglio), tanto che infatti nessuno per ora ha una soluzione pronta alla cosa seppure una GPU MCM costerebbe meno di una monolitica con le stesse risorse.

Da valutare quanto meno è il costo, però, perché è sicuro che alcune cose andranno aggiunte e dell'overhead sarà introdotto.
Per cui se faccio una GPU con 2 die che costa sulla carta la metà di una monolitica, ma poi mi serve un interposer, un bus ad alta frequenza aggiunto (compreso il suo controller nei die) e lavorare con un memoria segmentata a cui accedere è uno svantaggio e mi tocca pure riscrivere le applicazioni ad hoc o fare magheggi con i driver (neanche non ne avessero già abbastanza da fare con le applicazioni di oggi) per ottenere 1,5x le prestazioni, mi sa che allora conviene, finché il PP lo permette, investire in quel 50% in più di silicio per un monolitico e continuare come si è sempre fatto finora.

La scheda nell'immagine non ha manco la ventola di raffreddamento e sembra così simile alle immagini con cui presentarono la radeon instinct mi25 che probabilmente è la stessa immagine con incollato sopra la fascia blu e la scritta "radeon pro v340"
O è solo un'immagine di presentazione o è una scheda da rack con raffreddamento passivo.

Però la mi25 non è doppia e questo non gioca a favore della teoria per cui sia una dual vega.

Io sulla slide leggo "OIL & GAS" è possibile che si riferisca al tipo di raffreddamento.

Io sulla slide leggo "OIL & GAS" è possibile che si riferisca al tipo di raffreddamento.

Si riferisce alla destinazione d'uso di queste schede, ovvero la simulazione e la ricerca nel mercato petrolifero e derivati.

Si riferisce alla destinazione d'uso di queste schede, ovvero la simulazione e la ricerca nel mercato petrolifero e derivati.

LOL, se è così, da ignorante immaginavo già un bagno in olio minerale o radiatore di raffreddamento a gas:sofico:

La latenza minima è definita dallo strato fisico che su PCIe è relativa alla frequenza minore rispetto a quella possibile on chip.
Da cui puoi usare tutti i protocolli che vuoi, ma se devi accedere ad una word che sta dall'altra parte di un bus PCIe hai una latenza enorme, che insieme ala banda limitata, ti porta ad ottenere il tuo byte con migliaia di cicli di ritardo.
Come detto puoi, ma non è conveniente.

Non diciamo castronerie.. è vero che la latenza aumenta ma non tanto da rendere non conveniente a prescindere (anche perchè da qualche parte la GPU deve prelevare i dati contenuti nella sua RAM)....dopotutto i 2 die di threadripper nel 50% dei accede ad una porzione di memoria gestita da un altro die. E la gestione NUMA non porta grandissimi benefici neppure in applicazioni dove la latenza è fondamentale.

Quella è la modalità con cui si mappa la memoria interna, ma non cambia una sola virgola di quali sono i tempi e le latenze per accedere alle varia partizioni di memoria.
Se accede alla memoria nella HBM cui è collegata ne sfrutta tutti i vantaggi di latenza ridotta e grandissima banda, se accede alla memoria di sistema avviene quello che avviene su tutte le altre GPU, ovvero aspetta secoli prima di avere il dato. Che sia di sistema o dell'altra partizione di memoria di una GPU.
Non ci capiamo, anche in threadripper le latenze diventano assurde (circa 200ns, mica poco considerando che stiamo parlando di una CPU) ma grazie al generoso quantitativo di cache L3, queste vengono mascherate, e nel 90% degli applicativi addirittura resi impercettibili le differenze....

fatto eclatante è stato il test interno di AMD in cui ha confrontato un ipotetico VEGA con soli 2GB di ram HBM2 e HBCC attivo e la stessa soluzione con 4GB e HBCC disattivato, con la prima in grado di generare il 50% di fps medi e il 100% più sui minimi....

il tuo discorso vale solo per le GPU in generale, tranne VEGA che presenta una vera innovazione in tal senso.
ricapitolando le latenze non cambiano in senso assoluto, ma quello che cambia è la frequenza all'accesso al componente più lento...sicuramente ridotta con un sistema di memoria che prevede un elevatissimo quantitativo di cache memory...


Tutti quelli che gridavano al miracolo DX12, due pool separati visti come uno, e bla bla bla, semplicemente hanno scordato questo particolare (o proprio non sapevano di cosa stavano parlando).

non capisco di cosa parli...in DX12 il multigpu è esplicito le due GPU vengono effettivamente gestite come se fosse 2 componenti separati, non solo lato driver/SO, ma anche lato applicativo, tanto che sarebbe possibile anche fa lavorare 2gpu di 2 marche differenti...il problema sta nella gestione del carico che rende difficoltosa e non conveniente l'uso di 2 gpu di potenza di elaborazione assai differente.


Solo allora puoi parlare di "somma delle RAM". Viceversa quando si ha un accesso svantaggioso (e qui si parla di molto svantaggioso) che rende impraticabile l'uso di memoria non locale, non ha alcun senso parlare di "somma delle RAM".
innanzitutto pensare al calcolo eterogeneo senza che i diversi componenti possano accedere con una certa frequenza ad una porzione di ram comune pare assurdo.
poi c'è anche un fattore di costo.....32GB di RAM video possono essere anche pochi.....e una configurazione di pari costo con 8GBHBM+ 128GB, per esempio, rendere molto di più.....

inoltre ti faccio notare che anche in threadripper, ma anche in ryzen non è che le cache L3 si sommino....


L'accesso alla memoria è uno dei punti critici delle future soluzioni MCM (che già hanno la possibilità di non usare PCIe, quindi molto meglio), tanto che infatti nessuno per ora ha una soluzione pronta alla cosa seppure una GPU MCM costerebbe meno di una monolitica con le stesse risorse.
Le GPU risentono molto meno per loro natura dei tempi di accesso.
se lo fanno per le CPU a maggior ragione possono farlo per le GPU.
ma ci sono vari fattori da considerare:
1. GPU di grosse dimensioni ha più di 60 unità elementari...ovvero offrono una certa ridondanza di base.
2. le GPU sono saldate direttamente sul pcb.
3. i problemi di latenza sono assai meno sentiti rispetto alle CPU.

Non vedo nessuna ragione per la quale una CPU vada bene su MCM e una GPU no.


Per cui se faccio una GPU con 2 die che costa sulla carta la metà di una monolitica, ma poi mi serve un interposer, un bus ad alta frequenza aggiunto (compreso il suo controller nei die) e lavorare con un memoria segmentata a cui accedere è uno svantaggio e mi tocca pure riscrivere le applicazioni ad hoc o fare magheggi con i driver (neanche non ne avessero già abbastanza da fare con le applicazioni di oggi) per ottenere 1,5x le prestazioni, mi sa che allora conviene, finché il PP lo permette, investire in quel 50% in più di silicio per un monolitico e continuare come si è sempre fatto finora.
aspetta, non mischiamo tutto....2 unità di elaborazioni rimangono pur sempre 2 unità di elaborazione....che vengono gestite in maniera indipendente (almeno dal SO), questo a prescindere dal collo di bottiglia delle memorie.
lo scaling non perfetto e i problemi di sincronismo nelle soluzioni multigpu sono dovuti a questo e non a problemi relativi alla memoria.