Nrg
Utente Èlite
- Messaggi
- 3,732
- Reazioni
- 1,172
- Punteggio
- 133
Nel frattempo l'ho messo apposto ;)
Pubblicità
UFFICIALE AMD RX Vega 56 e 64 - La risposta ai GP104
- Autore discussione SuperGiachi
- Data d'inizio
Pubblicità
Nel frattempo l'ho messo apposto ;)
Patapu
Utente Attivo
- Messaggi
- 598
- Reazioni
- 53
- Punteggio
- 41
Ammetto xo che pensavo andasse bene in ogni modo...credevo di poter mettere due tubi sullo stesso lato
U
Utente cancellato 304870
Ospite
https://www.tomshw.it/radeon-rx-vega-56-arrivo-versione-pulse-sapphire-91290
ma non facevano prima a metterci un waterblock e venderla come nano?
Se un giorno arriverà in un negozio ad un prezzo normale la prendo e faccio subito la modifica!
ma non facevano prima a metterci un waterblock e venderla come nano?
Se un giorno arriverà in un negozio ad un prezzo normale la prendo e faccio subito la modifica!
dgcross
Utente Attivo
- Messaggi
- 1,281
- Reazioni
- 343
- Punteggio
- 77
è quello a cui punterei anche io... non fosse che causa machine learning probabilmente passerò ai verdi. Mi chiedo come mai AMD abbandoni così questo settore.
Che poi, da ignorante quale sono, non è che il numero elevato di tflops sarebbe un bel vantaggio per queste applicazioni?
Che poi, da ignorante quale sono, non è che il numero elevato di tflops sarebbe un bel vantaggio per queste applicazioni?
techfede
Utente Attivo
- Messaggi
- 1,081
- Reazioni
- 229
- Punteggio
- 62
Per quello che ho capito io, il problema in quell'ambito è l'ecosistema.
Nvidia con cuda avrà speso un sacco, ma ha ottenuto un ecosistema che funziona ed è stato adottato da tutti.
Credo che alcune cose si possano programmare anche in openGL, o comunque usando dei framework fatti apposta per non appoggiarsi a cuda (vedi ROCM, che non sono sicuro di cosa sia ma sembra una specie di "traduttore), però, come detto, non sono molto esperto e non vorrei dire cavolate.
dgcross
Utente Attivo
- Messaggi
- 1,281
- Reazioni
- 343
- Punteggio
- 77
da quel che ho capito io sì, è possibile usare AMD, ma bisogna prendere vie traverse. E visto che per me il ML sarebbe un mezzo per fare altri lavori e non fine a se stesso, non ho troppa voglia di mettermi a pacioccare col poco tempo che ho. Certo se AMD se ne uscisse con l'equivalente di CUDA non ci penserei 2 volte a rimanere in casa rossa. Però non ho mai letto da nessuna parte di simili progetti
Avevo già l'acquolina per per le Sapphire Pulse :(
Avevo già l'acquolina per per le Sapphire Pulse :(
techfede
Utente Attivo
- Messaggi
- 1,081
- Reazioni
- 229
- Punteggio
- 62
Come dissipatore la pulse sembra carina, ma temo non sia così efficiente con le temperature.
IlPresidente
Utente Èlite
- Messaggi
- 2,653
- Reazioni
- 886
- Punteggio
- 72
@dgcross dai un'occhiata qua: https://rocm.github.io/dl.html qui invece c'è pure tensorflow
io non ho fatto in tempo a provare perchè poi ho venduto la Vega (e ritornato a nvidia che è chiaramente superiore, più accessibile e più supportato), però qualcuno (chiaramente su linux - ubuntu) l'ha fatto andare, aprii pure un topic su reddit che ha avuto un buon afflusso
io non ho fatto in tempo a provare perchè poi ho venduto la Vega (e ritornato a nvidia che è chiaramente superiore, più accessibile e più supportato), però qualcuno (chiaramente su linux - ubuntu) l'ha fatto andare, aprii pure un topic su reddit che ha avuto un buon afflusso
dgcross
Utente Attivo
- Messaggi
- 1,281
- Reazioni
- 343
- Punteggio
- 77
Beh, chiaramente la liquiderei :) mi interessa per il PCB corto
Sì avevo letto di ROCm, però confesso che mi ci sono perso completamente :)
Nrg
Utente Èlite
- Messaggi
- 3,732
- Reazioni
- 1,172
- Punteggio
- 133
Ma infatti in altri wb delle vga non indicava nessun verso,infatti non mi sono nemmeno preoccupato
Poi ho dato un occhio al manuale,e c'era il verso,infatti ho gudagnato abbastanza sulle temp vga
solitamente il verso è in da sotto e out da sopra, ma solo per prevenire la formazione di bolle d'aria ed evitare che rimagano nel WB.
in effetti è sufficiente che solo l'out vada in alto, per facilitare la fuoriuscita di eventuali bolle d'aria (poi sarà il flusso che le guida).
Nrg
Utente Èlite
- Messaggi
- 3,732
- Reazioni
- 1,172
- Punteggio
- 133
Veramente il manuale ek consiglia IN nella parte sinistra,preferibilmente sopra,e l'OUT nella parte bassa,preferibilmente nella parte destra
Comunque basta rispettare la sinistra e destra,poi l'In/Out è ininfluente
In(parte sinistra)
Out(parte destra)
per quanto riguarda ROCm VS CUDA, il primo paga per la gioventù...
la questione è solo quante macro ti mettono a disposizione, sennò te le devi costruire.
CUDA ne ha molte di più, ma poi il compilatore fa tutto a modo suo, nel senso che deciderà lui dove mandare ad eseguire il codice, indifferentemente dall'HW che hai.
molto codice CUDA viene eseguito su CPU non su GPU (dipende da molteplici fattori e dalle macro che usi.. basta una macro per far scattare il tutto su CPU invece che GPU).
esattamente la stessa cosa può avvenire con ROCm, pero', essendo il supporto HW piu' limitato ed essendoci meno macro già editate, di solito incappi in meno problemi di questo genere.
per spiegarmi:
andare a fare il debug di CUDA cercando di sfruttare al massimo la GPU richiede molto piu' sacrificio, pur essendoci molte piu' possibilità, perchè devi andare a riconoscere l'istruzione o la macro che t'impedisce de facto di usare l'HW che tu desideri usare.
su ROCm te lo fai li per lì, in C, quindi in effetti conosci bene il software che hai creato in ogni sua parte e trovi il bandolo della matassa in modo piu' diretto...
logicamente CUDA offre rutine già preconfezionati per molte cose, che annoverano istruzioni e macro ottimizzate per specifici HW (di solito pero' sono a pagamento).
la questione è solo quante macro ti mettono a disposizione, sennò te le devi costruire.
CUDA ne ha molte di più, ma poi il compilatore fa tutto a modo suo, nel senso che deciderà lui dove mandare ad eseguire il codice, indifferentemente dall'HW che hai.
molto codice CUDA viene eseguito su CPU non su GPU (dipende da molteplici fattori e dalle macro che usi.. basta una macro per far scattare il tutto su CPU invece che GPU).
esattamente la stessa cosa può avvenire con ROCm, pero', essendo il supporto HW piu' limitato ed essendoci meno macro già editate, di solito incappi in meno problemi di questo genere.
per spiegarmi:
andare a fare il debug di CUDA cercando di sfruttare al massimo la GPU richiede molto piu' sacrificio, pur essendoci molte piu' possibilità, perchè devi andare a riconoscere l'istruzione o la macro che t'impedisce de facto di usare l'HW che tu desideri usare.
su ROCm te lo fai li per lì, in C, quindi in effetti conosci bene il software che hai creato in ogni sua parte e trovi il bandolo della matassa in modo piu' diretto...
logicamente CUDA offre rutine già preconfezionati per molte cose, che annoverano istruzioni e macro ottimizzate per specifici HW (di solito pero' sono a pagamento).
allora non saprei che dirti...
di solito gli impianti si operano con questa filosofia: l'aria sale e si devono evitare percorsi contro corrente.
U
Utente cancellato 244728
Ospite
Lo consiglia anche per le nVidia ;)
Sta scritto solo nel manuale, ma anche per la mia GTX1080 ek consiglia ingresso lato "core" e uscita lato "vrm" :)
Dipende da come il costruttore del wubbo ha progettato i canali in corrispondenza della gpu
EKWB li ha fatti con percorso di distribuzione del liquido centrale (addirittura su alcuni, come quello della vega, ha messo anche un jetplate):
Altri usano un più classico "pettine" a flusso diretto che rende indifferente il verso di percorrenza del fluido:
Pubblicità