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

[IlPresidente]

è una domanda che mi faccio circa da 1 anno... Non so perché le AMD per ottenere pari prestazioni han bisogno di un 60% di TFLOPS in più.
è una limitazione hardware/di architettura? driver? ottimizzazione dei software? booooh

sarebbe una risposta (forse parziale) vedere come girano su software che usano la scheda per fare calcoli, forse

 

[Pasquale C.]

http://www.smartworld.it/informatica/teraflops-cosa-sono.html , in questo link c'è una spiegazione abbastanza semplice di cosa sono i TFlops . Dipende tanto dall'architettura e dalla progettazione della GPU stessa comunque , Nvidia è sempre andata molto meglio in campo Gaming e video, AMD invece come molti di voi si saranno accorti va meglio nel mining e nel calcolo puro , per una differenza di progettazione dell'Unità aritmetica logica "ALU" , è un discorso abbastanza complicato comunque :sisi: . In conclusione i TFLOPS sono "un'unità di misura" da prendere con le pinze , poichè è una misura molto indicativa e poco precisa sulle prestazioni finali della scheda stessa.

 

[dgcross]

http://www.smartworld.it/informatica/teraflops-cosa-sono.html , in questo link c'è una spiegazione abbastanza semplice di cosa sono i TFlops . Dipende tanto dall'architettura e dalla progettazione della GPU stessa comunque , Nvidia è sempre andata molto meglio in campo Gaming e video, AMD invece come molti di voi si saranno accorti va meglio nel mining e nel calcolo puro , per una differenza di progettazione dell'Unità aritmetica logica "ALU" , è un discorso abbastanza complicato comunque :sisi: . In conclusione i TFLOPS sono "un'unità di misura" da prendere con le pinze , poichè è una misura molto indicativa e poco precisa sulle prestazioni finali della scheda stessa.

Quindi la potenza è reale, ma in alcuni ambiti non riesce a esprimersi completamente?
Per fare un parallelismo: è come una macchina con un motore che genera tot cavalli, ma se poi trasmissione, sospensioni, aerodinamica, etc. non sono all'altezza può farsi bagnare il naso in pista da una con meno cavalli?

 

[Pasquale C.]

Quindi la potenza è reale, ma in alcuni ambiti non riesce a esprimersi completamente?
Per fare un parallelismo: è come una macchina con un motore che genera tot cavalli, ma se poi trasmissione, sospensioni, aerodinamica, etc. non sono all'altezza può farsi bagnare il naso in pista da una con meno cavalli?

No , diciamo che la potenza è reale ma sono proprio progettate in modo diverso , come dicevo prima è un discorso abbastanza complicato anch'io non ho le conoscenze necessarie per approfondirlo , sicuramente qui c'è qualcuno che ne sa molto più di me , in termini semplicistici sta tutto nella differenza di progettazione , Nvidia sviluppa per avere le migliori performance possibili in ambito gaming , mentre AMD è superiore nel calcolo puro quindi ha vantaggi abbastanza netti nei cosiddetti "workload" e nel mining appunto dove quello che conta è la potenza di calcolo , ecco perchè AMD vende molto più di Nvidia in questi settori ed in gaming Nvidia è quasi l'unica opzione..Ci sono tanti fattori da considerare come ad esempio le API , esempio Vulkan sfrutta molto l'architettura delle scheda AMD ecco perchè nei giochi che sfruttano quest'API abbiamo delle grandi performance da parte delle VGA di AMD.

 

[LAST88™]

La mia macchina ha 200 cavalli (teraflops, diciamo) e la tua ne ha 150.
Ma la tua per come é progettata (aerodinamica, impianto frenante, sospensioni, distribuzione del peso, etc) é piú veloce ed efficiente in curva e in un circuito tortuoso ricco di curve esasperate, come quello di Montecarlo, vince nonostante sia nettamente meno POTENTE.
I Teraflops quindi, analogamente ai cavalli sotto al cofano che caratterizzano il motore di un’auto, non sono necessariamente indice di prestazioni. Ci sono tanti altri fattori che incidono.

Personalmente l’ultima cosa che guardo in una scheda da gaming (anche in sede di acquisto) é il numerino che indica quanti TFlops ha.

 

[IlPresidente]

No , diciamo che la potenza è reale ma sono proprio progettate in modo diverso , come dicevo prima è un discorso abbastanza complicato anch'io non ho le conoscenze necessarie per approfondirlo , sicuramente qui c'è qualcuno che ne sa molto più di me , in termini semplicistici sta tutto nella differenza di progettazione , Nvidia sviluppa per avere le migliori performance possibili in ambito gaming , mentre AMD è superiore nel calcolo puro quindi ha vantaggi abbastanza netti nei cosiddetti "workload" e nel mining appunto dove quello che conta è la potenza di calcolo , ecco perchè AMD vende molto più di Nvidia in questi settori ed in gaming Nvidia è quasi l'unica opzione..Ci sono tanti fattori da considerare come ad esempio le API , esempio Vulkan sfrutta molto l'architettura delle scheda AMD ecco perchè nei giochi che sfruttano quest'API abbiamo delle grandi performance da parte delle VGA di AMD.

Però c'è da dire che Nvidia ormai è un colosso nel deep learning e anche in ambito scientifico vengono utilizzate in maniera massiccia queste schede.

Comunque se hai qualcosa di più tecnico passa pure, voglio provarci a capire qualcosa :)

Fra l'altro vorrei capire, al di là dei teraflops, l'architettura PUO' essere sfruttata a modo dai giochi ma non accade per limiti di progettazione oppure con dei buoni driver si fa tutto?
Parlando di driver ho letto che Raja Koduri ha affermato che "tutti si possono mettere a produrre schede grafiche, il vero problema è che pochissimi hanno le risorse per investire nei driver che è la parte più impegnativa anche dal punto di vista economico".

edit: cito
Utente reddit: How difficult is the process of developing drivers for a GPU architecture with so many differences from previous product designs?
Raja: Developing drivers for new architecture is one of the most complex and difficult engineering tasks for a GPU company...In fact this is one of the reasons why there are only so few GPU companies.

https://www.reddit.com/r/Amd/comments/6bklro/we_are_radeon_technologies_group_at_amd_and_were/

leggendo qui ho letto che Vega è un architettura completamente nuova rispetto a Polaris. Fino a polaris che sviluppo hanno seguito le schede grafiche AMD?
Mi sa molto di "ryzen" versione gpu :)



PS: davvero discorso interessante :)

 

[Pasquale C.]

Però c'è da dire che Nvidia ormai è un colosso nel deep learning e anche in ambito scientifico vengono utilizzate in maniera massiccia queste schede.

Comunque se hai qualcosa di più tecnico passa pure, voglio provarci a capire qualcosa :)

Fra l'altro vorrei capire, al di là dei teraflops, l'architettura PUO' essere sfruttata a modo dai giochi ma non accade per limiti di progettazione oppure con dei buoni driver si fa tutto?
Parlando di driver ho letto che Raja Koduri ha affermato che "tutti si possono mettere a produrre schede grafiche, il vero problema è che pochissimi hanno le risorse per investire nei driver che è la parte più impegnativa anche dal punto di vista economico".

edit: cito
Utente reddit: How difficult is the process of developing drivers for a GPU architecture with so many differences from previous product designs?
Raja: Developing drivers for new architecture is one of the most complex and difficult engineering tasks for a GPU company...In fact this is one of the reasons why there are only so few GPU companies.

https://www.reddit.com/r/Amd/comments/6bklro/we_are_radeon_technologies_group_at_amd_and_were/

leggendo qui ho letto che Vega è un architettura completamente nuova rispetto a Polaris. Fino a polaris che sviluppo hanno seguito le schede grafiche AMD?
Mi sa molto di "ryzen" versione gpu :)



PS: davvero discorso interessante :)

Ti sei risposto da solo lol , il mio riferimento nel mio commento era serie Geforce contro serie Radeon cioè fascia consumer destinata al gioco visto che in questo thread si sta parlando di questo , non ho menzionato di proposito schede professionali , Nvidia è un colosso nel deep learning ed in ambito scientifico con schede totalmente differenti dalla serie Geforce (Quadro/Tesla ecc..) , dicevo che ti sei risposto da solo nel senso che , se una Quadro come la GP100 ha 12TFlops in FP32 , perchè non va in gaming come una 1080Ti?:rolleyes: Come vedi i TFLOPS non c'entrano nulla , è tutta questione di progettazione , ovviamente i Drivers sono fondamentali , parlando in modo molto semplicistico ti rimando al commento di LAST88 :) .

 

[IlPresidente]

Ti sei risposto da solo lol , il mio riferimento nel mio commento era serie Geforce contro serie Radeon cioè fascia consumer destinata al gioco visto che in questo thread si sta parlando di questo , non ho menzionato di proposito schede professionali , Nvidia è un colosso nel deep learning ed in ambito scientifico con schede totalmente differenti dalla serie Geforce (Quadro/Tesla ecc..) , dicevo che ti sei risposto da solo nel senso che , se una Quadro come la GP100 ha 12TFlops in FP32 , perchè non va in gaming come una 1080Ti?:rolleyes: Come vedi i TFLOPS non c'entrano nulla , è tutta questione di progettazione , ovviamente i Drivers sono fondamentali , parlando in modo molto semplicistico ti rimando al commento di LAST88 :) .

quindi praticamente AMD vende alla fascia consumer un prodotto che in realtà è a scopo professionale? Non ho capito :asd:

 

[lucusta]

Quindi la potenza è reale, ma in alcuni ambiti non riesce a esprimersi completamente?
Per fare un parallelismo: è come una macchina con un motore che genera tot cavalli, ma se poi trasmissione, sospensioni, aerodinamica, etc. non sono all'altezza può farsi bagnare il naso in pista da una con meno cavalli?

se torni indiero alle prime 50 pagine di questo thread o di quello su polaris è stato accennato.

in sintesi la questione è che sia AMD che nvidia non usano le API, ma le interpretano tramite driver sulle loro architetture.
l'arichitettura AMD puo' eseguire molti calcoli piccoli, mentre quella Nvidia puo' sviluppare calcoli grandi ma in numero limitato.
se usi il modo di operare di AMD devi, per forza di cose, usare molte unità per sviluppare i calcoli necessari, ma ad ogni passaggio di unità perdi cicli di computo a causa di cicli si spostamento.
meno sposti i dati, piu' le unità hanno il tempo di calcolare i risultati.
Nvidia incece ha affrontato la cosa con unità in cui la richiesta entra ed esce il risultato, senza dover mai spostare i dati e saltare da unità ad unità.

ad oggi, con le API che si usavano, la frammentazione dei dati era ridotta (DX11 vanno con massimo 4 thread principali, 8 se si usano le DX11.3 delle console).
DX 12 e vulkan (emanazione diretta di manlte) hanno invece una granulometria piu' fine dei dati.
spezzettano di piu' la catena delle operazioni, quindi unità piu' piccole hanno la possibilità di produrre per intero il dato, mentre unità piu' grandi sarebbero sottoutilizzate.
calcolo asincrono, insomma.
con la vecchia architetura sotto hawaii almeno il 33% del tempo era dedicato allo spostamento dati e non al calcolo (e quando sposti... esegui comunque un'operazione, e scaldi di conseguenza).
in DX12, con maxwell, nvidia è impossibilitata a spezzettare le sue operazioni, dovendo eseguire il calcolo su una unità molto grande, ma sfruttata per metà, e dovendo poi estrarre il dato dall'unità saltando tuti gli stadi non necessari (flushing dell apipeline) che comporta quindi spostamento e perdita di cili operazionali dedicati al calcolo puro.
su Polaris AMD ha cercato di trovare il modo di aggregare piu' unità, di per se sempre separate, ma in cui l'uscita da una unità di calcolo era già l'entrata dell'altra, eliminando operazioni di spostamento (cluster a 16 SP), ed infatti in DX11 le cose son migliorate parecchio.
dall'altro versante nvidia, con pascal, ha optato per dividere a metà le sue unità di calcolo, in modo da non dover sottoutilizzarle su codice piu' frammentato.
con Vega e Volta entrambe si troveranno a gestire unità di calcolo degnamente variabili a seconda del codice usato, con Vega che puo' evitare le operazioni si spostamento ancora meglio di polaris, recuperando il gap in DX11, e Volta che invece, se lo fanno realmente come V100 con i tensor core (ma decisamente piu' piccoli, perchè un tensor core V100 è per calcoli FP128, ossia potrebbe sviluppare 2x doppia precisione, cosa del tutto inutile sul gaming), a questo punto capace di frammentare maggiormente le sue unità e quindi recuperare in DX12 e AC/ACE.

per dirla in breve AMD sono già 5 anni che punta ad un codice altamente parallelizzato, ma per questo ha dovuto trascurare il modo di sviluppo dei giochi che da 5 anni a questa parte veniva operato, dovendo usare i driver come "traduttore in tempo reale".
a mano a mano il codice si è sempre piu' spostato verso una parallelizzazione maggiore (dx9 con 1 o 2 thread, dx 10 con 2, dx11 con 4, ed ora dx12... ma solo le DX12 t3 sono quelle che permettono ben oltre 4 thread).
nvidia invece ha sempre puntato su un'architettura adatta al tipo di parallelizzazione che si usava nel periodo, facendo diventare "vecchie" le sue vecchie architetture ad ogni generazione, perchè poco adatte al nuovo tipo di parallelizzazione dei giochi (incappava, in pratica, nella stessa problematica di AMD: dover sommare piu' unità e perdere tempo ha farlo, e non sempre a sviluppato driver per 2 successivi salti... le schede pensate per le DX9 non sono adatte alle DX11 sia per l'HW, ma soprattutto per il driver, che ha elevati costi per fare questo).

ecco perchè ancora c'e' gente con una 7000 e invece le 6xx d'invidia non sono piu' efficienti nemmeno in dx11, ma una 7000 è comunque inadeguata oggi per le DX12, o meglio, le unità utilizzate per le top oggi sono ad appannaggio della serie base di AMD, e tanto possono dare.


AGGIUNGO:
al meglio dell'espressione delle DX12 e DX11 di per se non cambia nulla per il gioco.
se fai 100fps usando le DX11 ne puoi produrre al massimo 100 con le DX12.
è il rendimento di calcolo che conta.
DX12 comportano comunque piu' lavoro per l'HW e soprattutto per la CPU, ma è anche una questione di che tipo di HW hai.
se usi un quad core al massimo puoi allocare 4 thread intensivi, sennò vanno in concorrenza sulle risorse HW della CPU; fai il gioco in DX11 e usi 4 thread, ma per ottenere prestazioni superiori devi aumentare per forza il clock della CPU.
in DX12 invece puoi usare almeno 8 thread, quindi su un octacore puoi sfruttare tutte le risorse HW che ha, ma a questo punto, anche se il lavoro aumenta perchè devi gestire piu' thread (ti sforzi sia nel separare, ma anche nel riaccorpare i calcoli), alla fine hai comunque il doppio dei core, e puoi permetterti di andare poco piu' della metà della frequenza del quadcore...

il punto essenziale è questo: la potenza di una 1080 Ti è arrivata a saturare un quadcore a 5ghz se il suo lavoro è leggero (FHD); se scendi a risoluzioni inferiori non ottieni piu' frame perchè la CPU non ce la fà.
usando un octacore a 3Ghz invece puoi ancora incrementare (solo se il gioco sfrutta realmente 8 thread).
prendiamo un esempio: un gioco che scala bene in SLI, ma per cui un 7700K a 5Ghz già è al limite in FHD con una sola 1080 Ti; usi 2x 1080 Ti non ottieni incrementi prestazionali... le GPU se la spassano e la CPU stà tirata al collo.
il problema è che domani avrai GPU singole con la potenza di uno SLI di 1080 Ti, ma cercare di spingere un 7700K o suo successore oltre i 5Ghz diventa impraticabile.
ecco perchè si deve passare a DX12... usi un ocracore a 3.5ghz, che vale come un quad a 7ghz per il quale il lavoro di separazione ed unione ti fà spendere il 10% in piu' di risorse, ma hai sempre la potenza computazionale di un quadcore a 6.3ghz, e sei a posto.

purtroppo pero' non sappiamo come và Vega, non sappiamo chi è Volta, non conosciamo i nuovi motori grafici, e tutto diventa molto confuso nel prevedere cosa succederà..

 

[IlPresidente]

se torni indiero alle prime 50 pagine di questo thread o di quello su polaris è stato accennato.

in sintesi la questione è che sia AMD che nvidia non usano le API, ma le interpretano tramite driver sulle loro architetture.
l'arichitettura AMD puo' eseguire molti calcoli piccoli, mentre quella Nvidia puo' sviluppare calcoli grandi ma in numero limitato.
se usi il modo di operare di AMD devi, per forza di cose, usare molte unità per sviluppare i calcoli necessari, ma ad ogni passaggio di unità perdi cicli di computo a causa di cicli si spostamento.
meno sposti i dati, piu' le unità hanno il tempo di calcolare i risultati.
Nvidia incece ha affrontato la cosa con unità in cui la richiesta entra ed esce il risultato, senza dover mai spostare i dati e saltare da unità ad unità.

ad oggi, con le API che si usavano, la frammentazione dei dati era ridotta (DX11 vanno con massimo 4 thread principali, 8 se si usano le DX11.3 delle console).
DX 12 e vulkan (emanazione diretta di manlte) hanno invece una granulometria piu' fine dei dati.
spezzettano di piu' la catena delle operazioni, quindi unità piu' piccole hanno la possibilità di produrre per intero il dato, mentre unità piu' grandi sarebbero sottoutilizzate.
calcolo asincrono, insomma.
con la vecchia architetura sotto hawaii almeno il 33% del tempo era dedicato allo spostamento dati e non al calcolo (e quando sposti... esegui comunque un'operazione, e scaldi di conseguenza).
in DX12, con maxwell, nvidia è impossibilitata a spezzettare le sue operazioni, dovendo eseguire il calcolo su una unità molto grande, ma sfruttata per metà, e dovendo poi estrarre il dato dall'unità saltando tuti gli stadi non necessari (flushing dell apipeline) che comporta quindi spostamento e perdita di cili operazionali dedicati al calcolo puro.
su Polaris AMD ha cercato di trovare il modo di aggregare piu' unità, di per se sempre separate, ma in cui l'uscita da una unità di calcolo era già l'entrata dell'altra, eliminando operazioni di spostamento (cluster a 16 SP), ed infatti in DX11 le cose son migliorate parecchio.
dall'altro versante nvidia, con pascal, ha optato per dividere a metà le sue unità di calcolo, in modo da non dover sottoutilizzarle su codice piu' frammentato.
con Vega e Volta entrambe si troveranno a gestire unità di calcolo degnamente variabili a seconda del codice usato, con Vega che puo' evitare le operazioni si spostamento ancora meglio di polaris, recuperando il gap in DX11, e Volta che invece, se lo fanno realmente come V100 con i tensor core (ma decisamente piu' piccoli, perchè un tensor core V100 è per calcoli FP128, ossia potrebbe sviluppare 2x doppia precisione, cosa del tutto inutile sul gaming), a questo punto capace di frammentare maggiormente le sue unità e quindi recuperare in DX12 e AC/ACE.

per dirla in breve AMD sono già 5 anni che punta ad un codice altamente parallelizzato, ma per questo ha dovuto trascurare il modo di sviluppo dei giochi che da 5 anni a questa parte veniva operato, dovendo usare i driver come "traduttore in tempo reale".
a mano a mano il codice si è sempre piu' spostato verso una parallelizzazione maggiore (dx9 con 1 o 2 thread, dx 10 con 2, dx11 con 4, ed ora dx12... ma solo le DX12 t3 sono quelle che permettono ben oltre 4 thread).
nvidia invece ha sempre puntato su un'architettura adatta al tipo di parallelizzazione che si usava nel periodo, facendo diventare "vecchie" le sue vecchie architetture ad ogni generazione, perchè poco adatte al nuovo tipo di parallelizzazione dei giochi (incappava, in pratica, nella stessa problematica di AMD: dover sommare piu' unità e perdere tempo ha farlo, e non sempre a sviluppato driver per 2 successivi salti... le schede pensate per le DX9 non sono adatte alle DX11 sia per l'HW, ma soprattutto per il driver, che ha elevati costi per fare questo).

ecco perchè ancora c'e' gente con una 7000 e invece le 6xx d'invidia non sono piu' efficienti nemmeno in dx11, ma una 7000 è comunque inadeguata oggi per le DX12, o meglio, le unità utilizzate per le top oggi sono ad appannaggio della serie base di AMD, e tanto possono dare.


AGGIUNGO:
al meglio dell'espressione delle DX12 e DX11 di per se non cambia nulla per il gioco.
se fai 100fps usando le DX11 ne puoi produrre al massimo 100 con le DX12.
è il rendimento di calcolo che conta.
DX12 comportano comunque piu' lavoro per l'HW e soprattutto per la CPU, ma è anche una questione di che tipo di HW hai.
se usi un quad core al massimo puoi allocare 4 thread intensivi, sennò canno in concorrenza sulle risorse HW della CPU; fai il gioco in DX11 e usi 4 thread, ma per ottenere prestazioni superiori devi aumentare per forza il clock della CPU.
in DX12 invece puoi usare almeno 8 thread, quindi su un octacore puoi sfruttare tutte le risorse HW che ha, ma a questo punto, anche se il lavoro aumenta perchè devi gestire piu' thread (ti sforzi sia nel separare, ma anche nel riaccorpare i calcoli), alla fine hai comunque il doppio dei core, e puoi permetterti di andare poco piu' della metà della frequenza del quadcore...

il punto essenziale è questo: la potenza di una 1080 Ti è arrivata a saturare un quadcore a 5ghz se il suo lavoro è leggero (FHD); se scendi a risoluzioni inferiori non ottieni piu' frame perchè la CPU non ce la fà.
usando un octacore a 3Ghz invece puoi ancora incrementare (solo se il gioco sfrutta realmente 8 thread).
prendiamo un esempio: un gioco che scala bene in SLI, ma per cui un 7700K a 5Ghz già è al limite in FHD con una sola 1080 Ti; usi 2x 1080 Ti non ottieni incrementi prestazionali... le GPU se la spassano e la CPU stà tirata al collo.
il problema è che domani avrai GPU singole con la potenza di uno SLI di 1080 Ti, ma cercare di spingere un 7700K o suo successore oltre i 5Ghz diventa impraticabile.
ecco perchè si deve passare a DX12... usi un ocracore a 3.5ghz, che vale come un quad a 7ghz per il quale il lavoro di separazione ed unione ti fà spendere il 10% in piu' di risorse, ma hai sempre la potenza computazionale di un quadcore a 6.3ghz, e sei a posto.

purtroppo pero' non sappiamo come và Vega, non sappiamo chi è Volta, non conosciamo i nuovi motori grafici, e tutto diventa molto confuso nel prevedere cosa succederà..

Davvero molto molto molto informativo, grazie mille, ho apprezzato tantissimo il poema e se ne scrivessi altri li leggerei volentieri :D

mi hai chiarito un sacco di cose :)

 

[lucusta]

leggendo qui ho letto che Vega è un architettura completamente nuova rispetto a Polaris. Fino a polaris che sviluppo hanno seguito le schede grafiche AMD?
Mi sa molto di "ryzen" versione gpu :)

PS: davvero discorso interessante :)

Vega dovrebbe avere, secondo le mie personali interpretazioni, una disposizione a 4 vie rispetto alle 2 di Polaris, che è praticamente il discorso di ryzen e Intel da SB, che sono passati da una doppia via a 2 vie (che è diverso, perchè un 2 vie è comunque un doppio 2 vie).

hai il raddoppio delle pipeline di calcolo (oltre il vecchio modo di replicare alcune unità di calcolo della stessa pipeline).

Volta, invece, sembra essere un vector processor, adatto alla metrica matriciale (praticamente ogni calcolo lo puoi ridurre a matrice).
quello che ha fatto vedere nvidia nel V100 è pero' enormemente grande per il settore gaming, non per il quantitativo di unità, ma per la singola unità.
un tensor core V100 processa a 128FP, e prima che la maggiorparte dei giochi passerano a FP64 potremmo avere nipoti belli grandi, te lo assicuro.
la cosa buona di un tensor core è pero' che lo puoi dividere, quindi un solo tensor core puo' diventare 16 (errata, avevo scritto solo 4) unità distinte da FP32.
il problema qui è un'altro: nvidia non vuole sprecare le sue architetture PRO per il gaming perchè comportano spreco di risorse (caches, buffer, e tante altre cose che non servono per il gaming ma occupano spazio vitale e costoso sul silicio) e perchè non vuole svalutare le soluzioni PRO, che fanno guadagnare parecchio.

quindi, ad oggi, non è facile dare un volto a Volta nel settore gaming, perchè se usano i tensor core, anche limitati a FP32, lo devono inibire via software per non farlo usare professionalmente con le basi inferiori a FP32.

di contro, se vuole usare AC ed ACE, deve dare la possibilità di frammentare la matrice di calcolo in sottomatrici piu' piccole (quindi aprire a FP16 e INT8, ampiamente sfruttato in deeplearning).... si vedrà come risolve la questione.

per quanto riguarda i driver: qualsiasi calcolo lo puoi ridurre ad una matrice, ma... non è come bere un bicchier d'acqua....

EDIT:
aggiungo qui la questione per cui AMD fà schede per cui i chip possono essere usati sia in ambito gaming che PRO e nvidia usa due differenti tipi di disegno:
AMD non ha una penetrazione di mercato che possa garantire la creazione di chip distinti; ne usa uno e lo differenzia solo per i driver, in questo modo ha la possibilità di ottenere economia di scala caricando parte del costo dei chip PRO su quelli gaming, ma addossando a questi appunto questa parte di costo in piu' dovuta a piu' silicio, ma anche, visto che si tratta di piu' transistors, anche piu' assorbimento e calore;
Nvidia invece ha la possibilità di dividere le linee ed ottenere comunque economia di scala su entrambe le line di prodotto... ha i numeri, insomma.
questo le consente di fare elevati margini operativi (perchè non sembra che costino poco), ma anche di spenderli in R&D e nella creazione di nuove architetture puntuali sul codice in quel momento sviluppato.

 

[IlPresidente]

Vega dovrebbe avere, secondo le mie personali interpretazioni, una disposizione a 4 vie rispetto alle 2 di Polaris, che è praticamente il discorso di ryzen e Intel da SB, che sono passati da una doppia via a 2 vie (che è diverso, perchè un 2 vie è comunque un doppio 2 vie).

hai il raddoppio delle pipeline di calcolo (oltre il vecchio modo di replicare alcune unità di calcolo della stessa pipeline).

Volta, invece, sembra essere un vector processor, adatto alla metrica matriciale (praticamente ogni calcolo lo puoi ridurre a matrice).
quello che ha fatto vedere nvidia nel V100 è pero' enormemente grande per il settore gaming, non per il quantitativo di unità, ma per la singola unità.
un tensor core V100 processa a 128FP, e prima che la maggiorparte dei giochi passerano a FP64 potremmo avere nipoti belli grandi, te lo assicuro.
la cosa buona di un tensor core è pero' che lo puoi dividere, quindi un solo tensor core puo' diventare 4 unità distinte da FP32.
il problema qui è un'altro: nvidia non vuole sprecare le sue architetture PRO per il gaming perchè comportano spreco di risorse (caches, buffer, e tante altre cose che non servono per il gaming ma occupano spazio vitale e costoso sul silicio) e perchè non vuole svalutare le soluzioni PRO, che fanno guadagnare parecchio.

quindi, ad oggi, non è facile dare un volto a Volta nel settore gaming, perchè se usano i tensor core, anche limitati a FP32, lo devono inibire via software per non farlo usare professionalmente con le basi inferiori a FP32.

di contro, se vuole usare AC ed ACE, deve dare la possibilità di frammentare la matrice di calcolo in sottomatrici piu' piccole (quindi aprire a FP16 e INT8, ampiamente sfruttato in deeplearning).... si vedrà come risolve la questione.

che sarebbero AC e ACE?

ps:curiosità, ingegnere elettronico? :)

 

[lucusta]

no, chimico; informatica ed elettronica sono solo passatempo.

AC ACE è la prerogativa di un tipo di andamento di calcolo con l'uso di un coprocessore matematico.
devi guardare l'insieme CPU+GPU come un direttore (CPU) ed un esecutore (GPU).
la CPU pero' opera comunque dei calcoli, ma per l'impostazione generalista che ha, li esegue in modo molto piu' lento.
risulta quindi che in un computo finito (prendiamo l'esempio della creazione di un frame video), la CPU si trova a dover dare alla GPU le ccordinate da calcolare, ma allo stesso tempo la GPU le esegue rapidamente e ne chiede altre.
la GPU, se sproporzionatamente potente rispetto alla CPU, starebbe sempre ad aspettarla.
questo succede su calcoli sequenziali.
nel calcolo asincrono invece tu operi su piu' fronti (piu' parti del frame allo stesso momento), e pur avendo delle sequenze appunto sequenziali, le unità sia della CPU che della GPU, dopo aver eseguito il proprio compito, possono essere messe a disposizione di un'altro calcolo, eliminando i tempi di attesa.
inutile farlo se hai una pipeline per la CPU ed una per la GPU, ma molto utile se ne hai tante per la CPU e tantissime per la GPU.
in piu' puoi dividere ulteriormente i singoli calcoli in parti piu' piccole, aumentando quindi la frammentazione, e sfruttando meglio l'HW.
AC è la sigla per asynchronous compute, ACE per Asynchronous Compute Engine.
frammentare il calcolo permette di far partire un sub calcolo (una sottomatrice) quando ancora non hai tutti gli elementi della matrice, e continuare a calcolare gli altri mentre la sottomatrice viene calcolata; quando hai calcolato ulteriori elementi tali da produrre una nuova sottomatrice, la mandi in esecuzione ad un'altr aunità libera...

in pratica i giochi 3D sono l'esasperato calcolo di coordinate 3D per poi essere riportate in un immagine bidimensionale... se si tratta di fisica devi solo applicare la legge giusta per lo spostamento, quindi una nuova matrice, in finale.
le GPU sono in pratica degli operatori algebrici altamente specializzati nella risoluzione di matrici... ora pero', se ti andiamo a guardare come si calcola un logaritmo usando una matrice, capisci qual'e' il vero ruolo dei driver.
il programmatore imposta il calcolo di un logaritmo nel software, lui deve risolverlo matricialmente... di modi ce ne sono parecchi, il driver efficiente usa quello piu' rapido.
il difficile viene quando ci sono aggregazioni di operazioni superiori (somma di logaritmi, logaritmo per potenze... funzioni insomma), perchè ci sono metodi piu' veloci di esecuzione rispetto al calcolo delle singole operazione in modo distinto e all'esecuzione finale di queste... con una passata potresti riuscire a calcolare tre operandi in una volta.... e questo diventa difficile.
gran parte dei tools nvidia sono dedicati proprio ad algoritmi per l'esecuzione diretta di multioperandi.
anche AMD ha creato algoritmi per questo, ma non credo che ne abbia fatto una suitte di costruzione...li citava nella presentazione di vega instinct.
http://www.gamersnexus.net/news-pc/2821-amd-vega-rapid-packed-math-demonstration
ancora non ne sò nulla, però...

 

[JulianGroove]

se torni indiero alle prime 50 pagine di questo thread o di quello su polaris è stato accennato.

in sintesi la questione è che sia AMD che nvidia non usano le API, ma le interpretano tramite driver sulle loro architetture.
l'arichitettura AMD puo' eseguire molti calcoli piccoli, mentre quella Nvidia puo' sviluppare calcoli grandi ma in numero limitato.
se usi il modo di operare di AMD devi, per forza di cose, usare molte unità per sviluppare i calcoli necessari, ma ad ogni passaggio di unità perdi cicli di computo a causa di cicli si spostamento.
meno sposti i dati, piu' le unità hanno il tempo di calcolare i risultati.
Nvidia incece ha affrontato la cosa con unità in cui la richiesta entra ed esce il risultato, senza dover mai spostare i dati e saltare da unità ad unità.

ad oggi, con le API che si usavano, la frammentazione dei dati era ridotta (DX11 vanno con massimo 4 thread principali, 8 se si usano le DX11.3 delle console).
DX 12 e vulkan (emanazione diretta di manlte) hanno invece una granulometria piu' fine dei dati.
spezzettano di piu' la catena delle operazioni, quindi unità piu' piccole hanno la possibilità di produrre per intero il dato, mentre unità piu' grandi sarebbero sottoutilizzate.
calcolo asincrono, insomma.
con la vecchia architetura sotto hawaii almeno il 33% del tempo era dedicato allo spostamento dati e non al calcolo (e quando sposti... esegui comunque un'operazione, e scaldi di conseguenza).
in DX12, con maxwell, nvidia è impossibilitata a spezzettare le sue operazioni, dovendo eseguire il calcolo su una unità molto grande, ma sfruttata per metà, e dovendo poi estrarre il dato dall'unità saltando tuti gli stadi non necessari (flushing dell apipeline) che comporta quindi spostamento e perdita di cili operazionali dedicati al calcolo puro.
su Polaris AMD ha cercato di trovare il modo di aggregare piu' unità, di per se sempre separate, ma in cui l'uscita da una unità di calcolo era già l'entrata dell'altra, eliminando operazioni di spostamento (cluster a 16 SP), ed infatti in DX11 le cose son migliorate parecchio.
dall'altro versante nvidia, con pascal, ha optato per dividere a metà le sue unità di calcolo, in modo da non dover sottoutilizzarle su codice piu' frammentato.
con Vega e Volta entrambe si troveranno a gestire unità di calcolo degnamente variabili a seconda del codice usato, con Vega che puo' evitare le operazioni si spostamento ancora meglio di polaris, recuperando il gap in DX11, e Volta che invece, se lo fanno realmente come V100 con i tensor core (ma decisamente piu' piccoli, perchè un tensor core V100 è per calcoli FP128, ossia potrebbe sviluppare 2x doppia precisione, cosa del tutto inutile sul gaming), a questo punto capace di frammentare maggiormente le sue unità e quindi recuperare in DX12 e AC/ACE.

per dirla in breve AMD sono già 5 anni che punta ad un codice altamente parallelizzato, ma per questo ha dovuto trascurare il modo di sviluppo dei giochi che da 5 anni a questa parte veniva operato, dovendo usare i driver come "traduttore in tempo reale".
a mano a mano il codice si è sempre piu' spostato verso una parallelizzazione maggiore (dx9 con 1 o 2 thread, dx 10 con 2, dx11 con 4, ed ora dx12... ma solo le DX12 t3 sono quelle che permettono ben oltre 4 thread).
nvidia invece ha sempre puntato su un'architettura adatta al tipo di parallelizzazione che si usava nel periodo, facendo diventare "vecchie" le sue vecchie architetture ad ogni generazione, perchè poco adatte al nuovo tipo di parallelizzazione dei giochi (incappava, in pratica, nella stessa problematica di AMD: dover sommare piu' unità e perdere tempo ha farlo, e non sempre a sviluppato driver per 2 successivi salti... le schede pensate per le DX9 non sono adatte alle DX11 sia per l'HW, ma soprattutto per il driver, che ha elevati costi per fare questo).

ecco perchè ancora c'e' gente con una 7000 e invece le 6xx d'invidia non sono piu' efficienti nemmeno in dx11, ma una 7000 è comunque inadeguata oggi per le DX12, o meglio, le unità utilizzate per le top oggi sono ad appannaggio della serie base di AMD, e tanto possono dare.


AGGIUNGO:
al meglio dell'espressione delle DX12 e DX11 di per se non cambia nulla per il gioco.
se fai 100fps usando le DX11 ne puoi produrre al massimo 100 con le DX12.
è il rendimento di calcolo che conta.
DX12 comportano comunque piu' lavoro per l'HW e soprattutto per la CPU, ma è anche una questione di che tipo di HW hai.
se usi un quad core al massimo puoi allocare 4 thread intensivi, sennò vanno in concorrenza sulle risorse HW della CPU; fai il gioco in DX11 e usi 4 thread, ma per ottenere prestazioni superiori devi aumentare per forza il clock della CPU.
in DX12 invece puoi usare almeno 8 thread, quindi su un octacore puoi sfruttare tutte le risorse HW che ha, ma a questo punto, anche se il lavoro aumenta perchè devi gestire piu' thread (ti sforzi sia nel separare, ma anche nel riaccorpare i calcoli), alla fine hai comunque il doppio dei core, e puoi permetterti di andare poco piu' della metà della frequenza del quadcore...

il punto essenziale è questo: la potenza di una 1080 Ti è arrivata a saturare un quadcore a 5ghz se il suo lavoro è leggero (FHD); se scendi a risoluzioni inferiori non ottieni piu' frame perchè la CPU non ce la fà.
usando un octacore a 3Ghz invece puoi ancora incrementare (solo se il gioco sfrutta realmente 8 thread).
prendiamo un esempio: un gioco che scala bene in SLI, ma per cui un 7700K a 5Ghz già è al limite in FHD con una sola 1080 Ti; usi 2x 1080 Ti non ottieni incrementi prestazionali... le GPU se la spassano e la CPU stà tirata al collo.
il problema è che domani avrai GPU singole con la potenza di uno SLI di 1080 Ti, ma cercare di spingere un 7700K o suo successore oltre i 5Ghz diventa impraticabile.
ecco perchè si deve passare a DX12... usi un ocracore a 3.5ghz, che vale come un quad a 7ghz per il quale il lavoro di separazione ed unione ti fà spendere il 10% in piu' di risorse, ma hai sempre la potenza computazionale di un quadcore a 6.3ghz, e sei a posto.

purtroppo pero' non sappiamo come và Vega, non sappiamo chi è Volta, non conosciamo i nuovi motori grafici, e tutto diventa molto confuso nel prevedere cosa succederà..

Vega dovrebbe avere, secondo le mie personali interpretazioni, una disposizione a 4 vie rispetto alle 2 di Polaris, che è praticamente il discorso di ryzen e Intel da SB, che sono passati da una doppia via a 2 vie (che è diverso, perchè un 2 vie è comunque un doppio 2 vie).

hai il raddoppio delle pipeline di calcolo (oltre il vecchio modo di replicare alcune unità di calcolo della stessa pipeline).

Volta, invece, sembra essere un vector processor, adatto alla metrica matriciale (praticamente ogni calcolo lo puoi ridurre a matrice).
quello che ha fatto vedere nvidia nel V100 è pero' enormemente grande per il settore gaming, non per il quantitativo di unità, ma per la singola unità.
un tensor core V100 processa a 128FP, e prima che la maggiorparte dei giochi passerano a FP64 potremmo avere nipoti belli grandi, te lo assicuro.
la cosa buona di un tensor core è pero' che lo puoi dividere, quindi un solo tensor core puo' diventare 16 (errata, avevo scritto solo 4) unità distinte da FP32.
il problema qui è un'altro: nvidia non vuole sprecare le sue architetture PRO per il gaming perchè comportano spreco di risorse (caches, buffer, e tante altre cose che non servono per il gaming ma occupano spazio vitale e costoso sul silicio) e perchè non vuole svalutare le soluzioni PRO, che fanno guadagnare parecchio.

quindi, ad oggi, non è facile dare un volto a Volta nel settore gaming, perchè se usano i tensor core, anche limitati a FP32, lo devono inibire via software per non farlo usare professionalmente con le basi inferiori a FP32.

di contro, se vuole usare AC ed ACE, deve dare la possibilità di frammentare la matrice di calcolo in sottomatrici piu' piccole (quindi aprire a FP16 e INT8, ampiamente sfruttato in deeplearning).... si vedrà come risolve la questione.

per quanto riguarda i driver: qualsiasi calcolo lo puoi ridurre ad una matrice, ma... non è come bere un bicchier d'acqua....

EDIT:
aggiungo qui la questione per cui AMD fà schede per cui i chip possono essere usati sia in ambito gaming che PRO e nvidia usa due differenti tipi di disegno:
AMD non ha una penetrazione di mercato che possa garantire la creazione di chip distinti; ne usa uno e lo differenzia solo per i driver, in questo modo ha la possibilità di ottenere economia di scala caricando parte del costo dei chip PRO su quelli gaming, ma addossando a questi appunto questa parte di costo in piu' dovuta a piu' silicio, ma anche, visto che si tratta di piu' transistors, anche piu' assorbimento e calore;
Nvidia invece ha la possibilità di dividere le linee ed ottenere comunque economia di scala su entrambe le line di prodotto... ha i numeri, insomma.
questo le consente di fare elevati margini operativi (perchè non sembra che costino poco), ma anche di spenderli in R&D e nella creazione di nuove architetture puntuali sul codice in quel momento sviluppato.

no, chimico; informatica ed elettronica sono solo passatempo.

AC ACE è la prerogativa di un tipo di andamento di calcolo con l'uso di un coprocessore matematico.
devi guardare l'insieme CPU+GPU come un direttore (CPU) ed un esecutore (GPU).
la CPU pero' opera comunque dei calcoli, ma per l'impostazione generalista che ha, li esegue in modo molto piu' lento.
risulta quindi che in un computo finito (prendiamo l'esempio della creazione di un frame video), la CPU si trova a dover dare alla GPU le ccordinate da calcolare, ma allo stesso tempo la GPU le esegue rapidamente e ne chiede altre.
la GPU, se sproporzionatamente potente rispetto alla CPU, starebbe sempre ad aspettarla.
questo succede su calcoli sequenziali.
nel calcolo asincrono invece tu operi su piu' fronti (piu' parti del frame allo stesso momento), e pur avendo delle sequenze appunto sequenziali, le unità sia della CPU che della GPU, dopo aver eseguito il proprio compito, possono essere messe a disposizione di un'altro calcolo, eliminando i tempi di attesa.
inutile farlo se hai una pipeline per la CPU ed una per la GPU, ma molto utile se ne hai tante per la CPU e tantissime per la GPU.
in piu' puoi dividere ulteriormente i singoli calcoli in parti piu' piccole, aumentando quindi la frammentazione, e sfruttando meglio l'HW.
AC è la sigla per asynchronous compute, ACE per Asynchronous Compute Engine.
frammentare il calcolo permette di far partire un sub calcolo (una sottomatrice) quando ancora non hai tutti gli elementi della matrice, e continuare a calcolare gli altri mentre la sottomatrice viene calcolata; quando hai calcolato ulteriori elementi tali da produrre una nuova sottomatrice, la mandi in esecuzione ad un'altr aunità libera...

in pratica i giochi 3D sono l'esasperato calcolo di coordinate 3D per poi essere riportate in un immagine bidimensionale... se si tratta di fisica devi solo applicare la legge giusta per lo spostamento, quindi una nuova matrice, in finale.
le GPU sono in pratica degli operatori algebrici altamente specializzati nella risoluzione di matrici... ora pero', se ti andiamo a guardare come si calcola un logaritmo usando una matrice, capisci qual'e' il vero ruolo dei driver.
il programmatore imposta il calcolo di un logaritmo nel software, lui deve risolverlo matricialmente... di modi ce ne sono parecchi, il driver efficiente usa quello piu' rapido.
il difficile viene quando ci sono aggregazioni di operazioni superiori (somma di logaritmi, logaritmo per potenze... funzioni insomma), perchè ci sono metodi piu' veloci di esecuzione rispetto al calcolo delle singole operazione in modo distinto e all'esecuzione finale di queste... con una passata potresti riuscire a calcolare tre operandi in una volta.... e questo diventa difficile.
gran parte dei tools nvidia sono dedicati proprio ad algoritmi per l'esecuzione diretta di multioperandi.
anche AMD ha creato algoritmi per questo, ma non credo che ne abbia fatto una suitte di costruzione...li citava nella presentazione di vega instinct.
http://www.gamersnexus.net/news-pc/2821-amd-vega-rapid-packed-math-demonstration
ancora non ne sò nulla, però...

Madre
Di
Dio
Mettete sotto spoiler e fatene una guida
Santo
Subito

 

[IlPresidente]

Madre
Di
Dio
Mettete sotto spoiler e fatene una guida
Santo
Subito

quotone, è un peccato se queste cose vadano perse e dovrebbero rimanere affisse in un thread magari apposito.

venire a conoscenza di cose del genere sono fatti che ampliano molto le proprie conoscenze ed è un motivo per cui vale la pena stare in questo forum, grazie ancora @lucusta