di  -  venerdì 1 aprile 2016

Eccoci alla quarta e ultima parte (qui la prima, qui la seconda, qui la terza) di una lunga e dettagliata retrospettiva riguardante gli ultimi quattro anni di competizione fra nVidia e AMD. Anni che hanno visto avvicendarsi architetture diversissime, uniti però da un sottile fil rouge, il processo produttivo a 28nm. Ecco a voi la sostanziosa parte conclusiva del contributo, il cui autore, assiduo frequentatore di AD, si fa conoscere col nickname omerico “nessuno”.  Speriamo di tornare presto su questi schermi con nuovi contributi fermo restando che, come sempre, piuttosto che proporre riempitivi rimarremo silenti. Se ritenete tuttavia di avere qualcosa di interessante da proporre, non esitate a scriverci attraverso questo link.

Nuovi test 4K
Con l’arrivo della GTX980Ti e della Fury X, il gaming a 4K su singola scheda diventa possibile. Nonostante qualche compromesso sull’uso degli effetti e filtri più impegnativi, è possibile raggiungere il minimo dei 30FPS a questa risoluzione (che ricordiamo, necessita di calcolare 4 volte il numero dei pixel necessari per il Full HD).
I test a 4K dei giochi diventano quindi test ordinari, mentre prima erano solo test riservati alle sole configurazioni multi GPU e singole prove delle possibilità delle schede mono GPU in 4K.
La nuova scheda di AMD ha creato parecchia attesa, visto i bench non ufficiali che circolavano e che la vedevano con prestazioni leggermente superiori alla Titan X. I test condotti dai vari siti di tecnologia però raccontano una storia diversa. I numeri che la Fury X riesce a macinare non sono superiori a quelli della GTX980Ti. In alcuni test a 4K è leggermente sopra, in altri è leggermente sotto, portando le schede ad essere in media equivalenti. La sorpresa viene dai test effettuati a risoluzioni inferiori: qui la Fury X accusa più divario con la 980Ti man mano che la risoluzione scende, tanto che in Full HD la nuova scheda di AMD è quasi alla pari con la soluzione di fascia inferiore, la 390X (che monta un Hawaii leggermente overcloccato di fabbrica rispetto alla vecchia 290X).

Nonostante l’uso delle più sofisticate tecnologie a disposizione e l’uso di raffreddamento a liquido la scheda non ottiene in nessun campo dei valori migliori di quello che ha presentato la concorrenza giusto qualche mese prima, né in prestazioni né in efficienza (calcolata come prestazioni rispetto ai W consumati). La scheda è quanto di meglio AMD abbia realizzato con GCN (ultima versione 1.2 dell’architettura con HBM, la cui adozione aumenta lo spazio interno alla GPU poiché il nuovo memory controller è molto più piccolo), ma è evidente che non basta. Da notare che il confronto è fatto con le versioni base delle due schede, ma la GTX980Ti è una scheda che è facilmente overcloccabile a valori ben più alti di quelli di fabbrica, mentre la Fury X si è dimostrata incapace di raggiungere valori di overclock sostenuti nonostante il raffreddamento a liquido. Il divario quindi aumenta se si considerano le 980Ti custom o per qualunque utente in grado di spostare lo slider del clock.

La delusione è grande. Dopo l’hype generato da AMD che prima della presentazione la descriveva come una rivoluzione per il gaming a cui nessun altra soluzione sarebbe potuta arrivare, la realtà è ben diversa. La mossa di nVidia di aver piazzato la 980Ti ad un prezzo non eccessivo (anche se non economico) è un mattone che pesa sui margini di AMD. Fiji ha un costo di produzione che è certamente superiore a quello del GM200 visto l’uso della HBM e dell’interposer e nVidia con il prezzo della 980Ti limita il margine di guadagno (o minima perdita) che AMD può realizzare. Ad aggravare la cosa si aggiunge l’uso del raffreddamento a liquido All-In-One (AIO) che AMD mette di default sulla scheda che aumentando i costi di produzione riduce ulteriormente il margine.

Non c’è altro da aggiungere alla diatriba. nVidia, sia che fosse consapevole del valore della sua 980Ti o avesse messo un prezzo per tentare di renderla appetibile nonostante i numeri superiori circolanti dei test della Fury X vs Titan X, ha messo AMD in grave difficoltà con la sua ultima creazione. Il prezzo massimo dunque “schiaccia” il tetto cui AMD può ardire con la sua top, e obbliga a mettere la versione Fury (senza X), la versione con chip castrato, leggermente downcloccato e senza raffreddamento a liquido ad un prezzo inferiore che a sua volta va a interferire con la fascia inferiore, quella coperta dalla 390X. Inevitabile che il prezzo di quest’ultima cali ancora e a catena tutte le altre.

La nuova line up delle due case costruttrici è così (quasi) definita e i prezzi ridotti di AMD le permettono delle vendite che finalmente arrestano quello che fino a quel momento era un salasso di utenza e quindi perdita di market share. Non c’è però molto da gioire in casa AMD, dato che i risultati finanziari non sono certo brillanti con numeri di vendita così ridotti e margini molto bassi.
La line up dei prodotti viene conclusa a Dicembre 2015 quando AMD presenta (finalmente) una versione di Tonga quasi totalmente sbloccata che viene montata sulla scheda 380X, prima non presente in listino. Il perché Tonga completo non sia stato presentato prima rimane un mistero (forse dovuto a qualche accordo di esclusiva con Apple), ma ancora più misteriose rimangono le affermazioni di AMD che dicono che Tonga ha in verità un bus di memoria di 384bit che però non verrà mai sbloccato totalmente per questioni legate al mercato. Evidentemente qualcosa con la progettazione rispetto alla situazione di mercato è andato storto con questa GPU che ha avuto sfortunate vicende.

Per concludere una piccola precisazione riguardo al valore delle prestazioni delle schede grafiche.
Le prestazioni assolute, calcolate come la capacità di generare frame per secondo nei vari test, sono solo una parte della valutazione che bisogna condurre per valutare la bontà o meno di una soluzione in tutti i suoi aspetti. Le GPU infatti sono dispositivi che fanno uso di computazione altamente parallela che scala quasi linearmente con la quantità di unità di elaborazione messe a disposizione. Quindi in teoria un valore qualsiasi di performance è ottenibile incrementando il numero di queste unità. I fattori limitanti sono principalmente due: la dimensione del die (area di silicio usata) che influisce in maniera diretta sul costo del chip e i consumi massimi – limitati dai parametri del bus PCI-e, dalla fisica e dal buon senso.
Dati questi paletti da rispettare (con i consumi che rappresentano un limite più flessibile, producendo un costo che è a carico dell’utente) la potenza assoluta di una GPU è dunque determinata dall’efficienza della sua architettura tramite il doppio rapporto tra prestazioni su consumi e prestazioni su area di silicio necessaria.

La valutazione che si può fare alla fine del ciclo del processo produttivo a 28nm è che l’architettura GCN di AMD perde nettamente su entrambi i fronti con quelle realizzate da nVidia (sia Kepler che Maxwell). A parità di prestazioni nVidia ha un chip più piccolo e meno energivoro di quanto non possa fare AMD. E il divario già presente con Kepler è aumentato ulteriormente con Maxwell, dove nVidia ha realizzato qualcosa che andava oltre le aspettative (e delle previsioni stesse di AMD, molto probabilmente).

Tenendo conto di questi fattori, il fatto che AMD competa in prestazioni assolute con una soluzione di nVidia non va giudicata esclusivamente sui frame generati, ma anche sulle risorse necessarie per ottenere quei numeri. Essendo sistemi che scalano linearmente, come abbiamo detto, escludendo le schede top limitate dai massimi consumi, le prestazioni degli altri chip della concorrenza possono essere raggiunte usando soluzioni più grandi ed energivore. Ed è proprio quello che AMD è stata costretta a fare per tutti questi 4 anni con GCN. Escludendo il confronto tra Hawaii e GK110, dove quest’ultimo era in difetto nel rapporto prestazioni/area (ma non prestazioni/consumi) dovendo nVidia includere le unità di calcolo a 64 bit necessarie per realizzare le versioni professionali Quadro e Tesla – AMD non è mai riuscita a presentare una scheda con le stesse prestazioni della relativa soluzione nVidia con consumi e silicio usato inferiori (come invece faceva con la vecchia architettura Terascale). Si può quindi azzardare che AMD abbia potuto competere in termini di prestazioni assolute usando chip destinati alle fasce superiori ma declassati. Il declassamento comporta la riduzione dei prezzi relativi a quelle soluzioni e quindi ai margini di guadagno, che sono proprio quelli che sono mancati alla divisione grafica di AMD alla fine di tutti i trimestri a partire da Gennaio 2012.

A rafforzare questa idea è il fatto che nVidia abbia creato schede considerate di fascia alta usando GPU di precedente generazione, che andavano a concorrere con la fascia top di AMD. A partire dal GK104 vs Tahiti – con l’inedita accoppiata Gx104 su scheda x80 ovvero il GM204 sulla 980, quando prima era G200 sulla GTX280, GF100 sulla GTX480, GF110 sulla GTX580 – è comprensibile che le versioni enthusiast siano state destinate a versioni “over the top”, che hanno a loro volta lasciato spazio ad una nuova serie prosumer, le Titan; e che le soluzioni enthusiast da gaming abbiano trovato posto in schede con la nuova denominazione x80Ti.

Per vedere le differenti risorse messe in gioco per ottenere prestazioni simili basta dare uno sguardo a quello che sono le GTX960 vs la R9-380. La differenza tra dimensioni, bus e consumi delle due GPU (sebbene c’è da dire che la soluzione AMD ottenga prestazioni leggermente superiori, ma non certo della proporzione delle risorse messe in gioco) esemplifica il quadro competitivo definitosinegli ultimi 4 anni. I numeri grezzi di confronto sono questi. La GTX960 monta il GM206 che è un chip che è esattamente la metà del GM204, ovvero ha 1024 shader, 64 TMU, 32 ROP e un bus di 128bit il tutto all’interno di una superficie di 227mm^2 con TDP di 120W. La R9-380 monta Tonga castrato il cui numeri sono 1792 shader, 112 TMU e 32 ROP e un bus da 256bit racchiusi in un’area di 359mm^2 e dal TDP di 190W. Le differenze di area e consumi sono di oltre il 60%. Tenendo conto delle differenze di prestazioni (circa il 10% a favore di Tonga) è facile vedere che AMD ha una efficienza che è circa il 25-30% inferiore alle soluzioni nVidia. Il GM206 è una GPU che con i suoi 128bit di bus nelle precedenti generazioni era destinata alla serie x50 e inferiore, mentre la GPU di AMD con il bus da 256bit era una GPU che avrebbe dovuto competere con il GM204, le cui prestazioni sono invece notevolmente lontane da quelle ottenibili da Tonga.

Per tutti questi 4 anni AMD è stata messa sotto pressione dalle soluzioni nVidia che hanno ribaltato la situazione che vi era prima dell’introduzione di GCN. I dati di vendita sono impietosi e sicuramente più penalizzanti di quanto le soluzioni di questo produttore non meritino. Ma è evidente che le difficoltà sono state tante e AMD ha dovuto difendersi come meglio ha potuto limitando i danni il più possibile. nVidia dal canto suo ha avuto gioco facile e il fatto che tutte le sue schede siano sempre state vendute ai prezzi di lancio è la cosa più rappresentativa che indica quanto poco affanno ha avuto dalla strategia e dalle soluzioni della concorrenza.

È di questi giorni la presentazione di qualche slide di AMD relativa alla sua nuova architettura destinata al nuovo processo produttivo a 16nm o 14nm, a seconda della fabbrica che andrà ad usare (rispettivamente TMSC o GlobalFoundry). Anche questa è una novità per AMD, azienda sempre molto parca di indiscrezioni e dettagli, finanche sulle architetture appena lanciate. Di certo il periodo non è fra i migliori per tenere secretate informazioni che possono riportare interesse verso il proprio lavoro e possibilmente qualche investitore in più.
Le premesse che si sono potute vedere (non molte in verità) sono promettenti, così come il test di efficienza mostrato. La speranza è che le novità che verranno introdotte siano sufficienti a colmare il divario con la nuova architettura Pascal (che parte dalla già ottima architettura Maxwell) che nVidia per ora tiene segreta. Entrambe si apprestano a utilizzare le nuove HBM di seconda generazione, che abbattono molti dei limiti della prima versione, sulle proprie schede enthusiast/professionali. Probabilmente non quest’anno, visto che le HBM v2 non sono ancora in produzione.
Si spera comunque che con il nuovo processo produttivo il gap di efficienza fra le soluzioni delle due case si comprima, a vantaggio della competizione sulla tecnologia e sul prezzo. Diversamente si tornerebbe a un mercato in cui un concorrente prevale nettamente e per questo può mantenere i prezzi di lancio dei propri prodotti indefinitamente.

Con questo si conclude il riassunto della lotta per la conquista del mercato delle schede video discrete di questi ultimi 4 anni. La storia è basata sui fatti cronologici successi e sui numeri delle specifiche e dei test che sono apparsi in rete in questo arco di tempo. La speranza è di non aver commesso clamorosi errori: nel caso sono gradite le segnalazioni.

26 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Cesare Di Mauro
     scrive: 

    Grazie per questa splendida serie di articoli. Spero che ne aggiungerai un altro quando AMD e nVidia presenteranno le nuove soluzioni a 16/14nm.

  • # 2
    Xeus32
     scrive: 

    Ho letto l’articolo e lo ho trovato molto interessante e posso dire di essere molto d’accordo almeno per quanto riguarda l’aspetto generale.

    La mia perplessità a riguardo è principalmente dovuta al fatto che non si è minimamente menzionato il contesto dello sviluppo AMD.
    In quanto, a mio modesto avviso è da citare che con l’arrivo di Nvidia Maxwell si è invertito un trend dove Nvidia era caposaldo delle prestazioni in GPU Computing.
    Ora il competitor è in grado di sorpassare le prestazioni in vari bechmark OPENCL e sappiamo bene che tali prestazioni sono indirizzate verso i datacenter dove ci sono maggiori margini, tuttavia mi pare di capire che AMD non sia stata in grado capitalizzare.

    Al contempo, tutte le soluzioni AMD hanno delle feature che verranno implementate nel prossimo Pascal, come ad esempio “lo spazio di indirizzamento condiviso con la CPU”. Questo ha comportato l’implementazione di un bus a 64bit che, da quanto ne so, è una peculiarità AMD.
    Tale funzione è stata chiave di volta per lo sviluppo dei processori per le nuove console (ps4, xbox one e nintendo nx) e fondamentale per il progetto di computazione eterogeneo portato avanti da anni da AMD.

    Effettivamente sembra che il progetto sia stato sviluppato più incentrato sulla potenza computazionale che sulle performance 3d, infatti se si guarda bene Nvidia ha scelto di castrare le prestazioni fp64 sulle sue soluzioni gaming mentre AMD le ha lasciate più o meno invariate. (http://www.geeks3d.com/20140305/amd-radeon-and-nvidia-geforce-fp32-fp64-gflops-table-computing/)
    Questa scelta è comprensibile perchè in gaming non servono le fp64 ed è quindi migliore la strategia di nvidia.

  • # 3
    Nessuno
     scrive: 

    Mmmm.. ci sono cose che non mi convincono nel tuo discorso.

    Il passaggio da Kepler e Maxwell non ha diminuito le capacità di computazione. Anzi. Maxwell è molto più veloce nel GPGPU di Kepler. Se guardi i grafici del calcolo F@H vedi come le barrette rispetto a Kepler sono aumentate notevolmente.
    Quella che è sparita è la capacità di calcolo in doppia precisione (64bit Floating Point).
    L’idea che la capacità GPGPU sia legata alle capacità DP (FP64) è qualcosa che è difficile da estirpare (un po’ come i megapixel delle fotocamere), ma la realtà è che sono due cose slegate tra loro.
    Le capacità FP64 sono utili sono in ambiti molto ristretti e la loro mancanza non inficia minimamente sulle capacità generali di una achitettura di eseguire in maniera più che efficiente il calcolo FP32, che è di gran lunga più usato in tutti gli ambiti (pure nei data center).
    Quindi non c’è alcuna corrispondena tra il fatto che AMD vada più veloce nei test OpenCL, dove è sempre andata meglio di nvidia che su quello standard non punta e ottimizza, con l’uscita di Maxwell.

    Maxwell viceversa ha trovato posto in schede di calcolo solo FP32 molto efficienti, giusto per sottolineare che il GPGPU non è il suo problema e che è un netto miglioramento rispetto a Kepler.

    Il fatto che AMD metta capacità FP64 nelle architetture da gioco deriva dalla sua architettura: diversamente da nvdia che inserisce unità DP apposite a fianco di quelle FP32 in misura variabile a seconda del target della GPU, AMD raggruppa le stesse unità FP32 per ottenere unità FP64. Il metodo di nvidia ha lo svantaggio di usare molto spazio quando vuole costruire una GPU che sia DP64 capable per davvero (deve mettere unità FP32 + FP64).
    La soluzione di AMD, a parità di capacità DP, usa meno spazio (usa le stesse unità di calcolo) ma di contro avrà un minimo spazio sprecato (circuiteria che combiana le unità) comunque anche sulla soluzioni che del FP64 non se ne fanno nulla.
    Comunque, sebbene nvidia abbia deciso di non mettere alcuna unità DP nel GM200, anche AMD è andata a tagliare alla grande le sue capacità DP man mano che realizzava le revisioni di GCN: è partita da 1/4 con Tahiti (GCN 1.0) ed è finita con 1/16 con Fiji (proprio la CPU di punta, GCN 1.2). Entrambe quindi messe alle strette dal PP che non ha migliorato per diversi anni hanno deciso di sacrificare le capacità FP64.

    AMD non ha una soluzione efficiente di memoria condivisa con le schede discrete. La sua soluzione è uguale a quella che usa nvidia, cioè simulare il fatto che le memorie di sistema e della scheda siano sullo stesso bus e usando il lento PCI express bus per spostare i dati da una parte all’altra secondo il bisogno.
    Per il programmatore la cosa è trasparente, ma in termnini di efficienza reale siamo davvero al minimo possibile.
    AMD ha una soluzione di memoria condivisa efficiente nei suoi SoC, dove ha il controllo completo dei bus e dei memory controller di CPU e GPU e quindi la possibilità di usare un bus che non sia 20 volte più lento della banda che la GPU può godere quando accede alla sua memoria locale.
    Per ovviare al problema della condivisione di memoria su scheda discreta, nvidia ha realizzato l’nvlink che è una soluzione proprietaria molto più veloce del PCI express che permette di accedere alla memoria remota (PC->GPU o GPU->PC) in maniera più veloce. Questo diminuisce il problema delle memorie su bus differenti (diversamente che in un SoC) ma non lo elimina del tutto (almeno finché la velocità del bus di comunicazione e la latenzanon diventino più che comparabili con la banda e la latenza tra GPU e la sua VRAM).
    Ovviamente l’nvlink è una soluzine proprietaria costosa e quindi non troverà spazio nel mercato consumer per collegare la GPU discreta alla CPU. Nessun produttore di schede madri farà infuriare Intel inserendo tale opzione. Se mai si avrà una scheda gaming con il GP100 (le cui specifiche sono state rese note proprio ieri) l’unica possibilità di vedere l’nvlink all’opera a casa propria è come collegamento SLI tra due (o più) schede.

    La capacità di nvidia in questi 4 anni è stata quella di aver fatto fruttare i precedenti 4 anni di sviluppo su architetture GPGPU centriche che AMD non aveva fatto, capitalizzando solo nel breve periodo con la possibilità di arrivare vicino alle piastrelle nvidia GPGU capable con GPU più piccole (ma inefficienti nel GPGPU). Dopo il G200, nvidia ha capito che esistono 2 mercati con esigenze diverse da mungere in maniera diversa: il mercato dei viddeogiocatori a cui le capacità GPGPU non interessano e quelle dei datacenter/server HPC e studi di analisi e progettazione che non si spaventano davanti a soluzioni più che costose se integrano quello che a loro serve per guadagnare di più in meno tempo.
    Ecco perché ha 2 linee separate ed effetivamente 2 architetture, una per le GPU da gioco da cui avere buoni margini di guadagno risparmiando sul silicio che a questi non serve e l’altra per il mercato professionale dove il silicio in più è comunque pagato molto bene.
    AMD non ha abbracciato questa filosofia, pensando che presentarsi con grandi numeri di prestazioni (inutili) di calcolo su carta che la nuova architettura GCN offre avrebbe attirato utenza. Questi grandi numeri costano in termini di silicio (e a quanto pare anche di consumi) e questo non è quello che interessa a chi vuole semplicemente più FPS. Il risultato è minor margine di guadagno per AMD e una minore considerazione da parte dell’utenza per i consumi eccessivi (sulle schede low end il divario è davvero grande, a tal punto che i portatili, dove i consumi contano, con schede discrete AMD su architettura GCN si possono contare sulle dita di una mano).

    Non credo di aver trascurato alcun aspetto dello sviluppo di AMD. Semplicemente questo sviluppo è andato in direzione sbagliata rispetto alle richieste del mercato consumer, e questo non ha premiato certamente una architettura come GCN, con un sacco di difetti ma anche qualche pregio. Pregi che AMD non ha saputo sfruttare nel campo professionale, per motivi a me sinceramente sconosciuti. Ma di schede che facciano concorrenza alle Quadro ne sono uscite poche e senza particolari prestazioni, e nel campo GPGPU puro (mercato delle Tesla di nvidia per intenderci), non ha mai realizzato nulla di nulla.
    Quindi non capisco questa cosa di aver voluto sviluppare una architettura ibrida con la possibilità di avere grandi capacità di calcolo con minimo silicio e non sfruttarla in campo professionale ma con molta meno efficienza (sia in termini di prestazioni/mmq che di prestazioni/W) nel mercato consumer.
    Speriamo che per la prossima generazione la strategia cambi.

  • # 4
    TheZik
     scrive: 

    @ nessuno

    Devo dire che questo tuo ultimo commento lo si potrebbe definire come una parte 4.5 Lungo articolato ma non ancora della lunghezza giusta per diventare la parte 5
    Ti ringrazio del tempo che hai “perso” per queste dettagliate e bene fatte spiegazioni

  • # 5
    Cesare Di Mauro
     scrive: 

    http://www.top500.org/project/linpack/

    “In particular, the operation count for the algorithm must be 2/3 n^3 + O(n^2) double precision floating point operations. This excludes the use of a fast matrix multiply algorithm like “Strassen’s Method” or algorithms which compute a solution in a precision lower than full precision (64 bit floating point arithmetic)”

  • # 6
    Nessuno
     scrive: 

    Eerrrmmm…. e quindi?

  • # 7
    Cesare Di Mauro
     scrive: 

    Quindi l’uso della doppia precisione in “codice GPGPU” non è certo raro.

  • # 8
    makrov
     scrive: 

    in generale preferisco l’approccio AMD che evita di creare chip volutamente castrati per massimizzare un singolo ambito (gaming in questo caso)
    il problema di AMD è principalmente di driver, e ovviamente di marcheting (in ambito gpu almeno, in quello cpu, dove è costretta ancora ad usare 28nm contro intel che è gia uscita con i 14nm, che alcuni dicono essere un po tarocchi, è ovviamente anche tecnologico, io vorrei sapere cosa si sono bevuti per utilizzare lo stesso approccio netbrust con una pipeline lunga e sprecona invece di fare un die shrink a 28nm dei core k10 con la fpu condivisa a moduli come bulldozer)
    se AMD riesce a comportarsi meglio della concorrenza in VR forse riesce ad avere quel ritorno d’immagine per rimanere a galla, al momento il comportarsi leggermente meglio in 4k non ha giovato granchè, e na maggior parte dei player su pc ambiscono a montare una gtx970 anche sapendo del bus ram azzoppato verso l’ultimo 1/2 GB che destabilizza tutto oltre il 1080p (anche se effettivamente andare oltre 1080p 60hz al momento è un puro esercizio di stile, con VR sarà fondamentale raddoppiare sia risoluzione sia refresh rate)
    infine AMD sta facendo un gran bel lavoro driver su linux per rendere omogenea l’installazione sia dei driver proprietari sia di quelli opensource.
    Zen e le future APU saranno il vero campo di test di AMD, se toppa anche questa volta nn so che fine possa fare!

  • # 9
    Nessuno
     scrive: 

    @Cesare di Mauro

    Hai linkato un test usato per i misurare le capacità di calcolo di server HPC. Dove i 64 bit hanno un senso e un mercato dove AMD non c’è.
    Quindi non risponde alla domanda del perché AMD ha voluto inserire le capacità 64bit su GPU destinate al mondo consumer (dove non servono a nulla se non per benchmark e 2 programmi di calcolo distribuito in croce, sempre usati come benchmark).

  • # 10
    Cesare Di Mauro
     scrive: 

    E’ un mercato in cui AMD ha deciso di non entrare, pur essendo particolarmente remunerativo. nVidia è presente nella TOP500 con diverse soluzioni basate sulle sue GPU, e non credo che lo faccia per beneficenza o per farsi pubblicità.

    Non so se lo consideri facente parte del mondo consumer, ma ci sono anche GPU per ambiti professionali, e dove supportare float a 64-bit è importante per questioni di precisione che fp a 32 bit non può garantire.

  • # 11
    Nessuno
     scrive: 

    Ancora sei andato per la tangente.
    Che non risponde alla domanda.

    nvidia si è costruita un mercato della computazione tramite GPU dove vive e prospera e ci fa gli investimenti necessari, compreso quindi dover mettere le unità FP64 nelle GPU destinate a questo mercato. E questo non mi sembra richiedere alcuna spiegazione o faccia sorgere alcun quesito particolare.

    Ma se AMD non vuole entrare nel mondo degli HPC o comunque della computazione non necessariamente su server, che diamine ha aggiunto il supporto alla FP64 a fare nelle sue GPU? Per quelle 4 schede che vende nel mondo workstation secondo te è giustificabile lo spreco di silicio e W nel mercato consumer dove vende il 99% delle sue schede (e anche per tali scelte è rimasta indietro)?

    Infine, tutto il tuo ragionamento è smentito proprio dal fatto che con l’andare del tempo è partita con una capacità FP64 pari a 1/4 di quella FP32 e poi è caduta a 1/16 con Fiji (il cippone con HBM che le costa tantissimo). Il chip più veloce di AMD a fare conti a 64bit rimane Tahiti, nonostante 2 revisioni della architetture e sopratutto il fatto che siano stati creati 2 chip (molto) più grandi di questo e una revisione (la cui gestione richiederebbe un altro bell’articolo sulle stranezze delle strategie seguite in quel di Sunnyvale) di praticamente pari dimensioni.

    La domanda è quale tipo di strategia ha voluto perseguire AMD in questa generazione, vista che è è chiaramente partita con un certa prospettiva (1/4 FP32) su un chip relativamente piccolo per finire con un’altra (1/16 FP32) su un chippone dal costo insostenibile per il mercato consumer.

    Sarebbe da fare un bell’articolo sul’analisi di queste scelte ed evoluzioni. Tipo pensava che Tahiti sarebbe stato il suo chippone che avrebbe tenuto a bada tutto e tutti e quindi dotato di tutto quanto necessario per il mercato sia consumer che professionale mentre poi si è vista superare da un chipetto della concorrenza? I tempi dilatatissimi di rilascio di Tahiti, Hawaii e Fiji potrebbero far pensare che questi due ultimi chip siano stati creati ad hoc al di fuori di una roadmap prestabilita con aggiustamenti fatti per correggere il tiro a cui erano indirizzati.

    Oppure AMD era partita con l’idea di realizzare chippetti per il mercato HPC e (qui urge seria interrogazione) ha deciso che i chipponi seguenti non sarebbero stati adeguati al compito?

    E’ partita con l’idea di poter sfondare nel mondo professionale grazie ai numeri sulla carta che ha pubblicizzato per tanto tempo (pure sulle scatole delle schede da gioco) e poi il sogno si è infranto quando ha visto i numeri di calcolo (e consumi) del GK110?

    Quello che mi sembra ovvio è che c’è stato un cambio di strategia subito dopo la presentazione della prima versione di GCN. Mi chiedo, da appassionato, quindi quale fosse la strategia che volevano perseguire e cosa ha fatto loro cambiare idea. E quanto la rincorsa alla prima strategia abbia fatto del male alla efficienza/qualità e quindi alla vendita di tutta la generazione dei 28nm.
    E quindi quale strategia vorrà riproporre per la nuova architettura, cioè se ancora avrà numeri in FP64 da capogiro anche sul chippetto di fascia medio-alta, se adotterà la strategia di nvidia di 2 architetture diverse per mercati diversi o se abbandonerà in toto la corsa ai numeroni sulla carta che poi le costano in termini di silicio e W rispetto alla concorrenza che vende con margini più alti un quantitativo maggiore di schede.

    In tutto questo, il tuo link al benchamrk, che già conoscevo, non dà alcuna risposta, così come il commento successivo, davvero troppo debole per spiegare investimenti di svariati centinaia di milioni di dollari.

  • # 12
    Alessio Di Domizio (Autore del post)
     scrive: 

    Che belli i flame ad alto contenuto tecnologico :-)

  • # 13
    Benjamin Sisko
     scrive: 

    E si… mi ricordano i flame del meglio z80, no 6502, o di Amiga meglio di Atari ST :-)

  • # 14
    Nessuno
     scrive: 

    Più che flame ho mille domande senza risposta.

    Venire qui con un link fuori contesto, senza spiegazione, per fare quello che risolve tutto “alla fonzie” mi sembra un po’ fuori luogo.
    Altro che vecchi flame. A quel tempo c’era poco da discutere: meglio il 6502 e l’Amiga :D

  • # 15
    Alessio Di Domizio (Autore del post)
     scrive: 

    @ Nessuno
    Qui su AD siamo fra amici ormai e Cesare, oltre ad essere “socio fondatore”, in fatto di tecnologia è abbondantemente gallonato :-)
    Le opinioni che esprime sono frutto di riflessione e mi pare – purtroppo non sono qualificato per entrare nel merito – che siamo ancora in ambito di opinabile (parlo delle strategie architetturali di AMD/nVidia, non dei dati che hai portato a sostegno delle tesi nel tuo articolo). Non parlerei quindi di atteggiamento “alla fonzie” ma di una sana divergenza.
    Sono certo che appena Cesare troverà il tempo stenderà uno dei suoi proverbiali “lenzuolini” esponendo in dettaglio tutti gli argomenti che lo hanno portato a trarre le sue conclusioni.
    Personalmente ho già in caldo i pop corn ;-)

  • # 16
    Cesare Di Mauro
     scrive: 

    Per fortuna che mi conosci bene Alessio. Sono stato via per la recente PyCon7 a Firenze, per cui ho potuto rispondere soltanto adesso, ma spero di non deluderti. :-P

    Ancora sei andato per la tangente.

    Vedremo se è così, oppure ti sei costruito un film tutto tuo su una storia inesistente.

    Che non risponde alla domanda.

    Quale? Non mi sembra di averne poste, mi pare, mai sei liberissimo di quotarmi e farmele vedere.

    nvidia si è costruita un mercato della computazione tramite GPU dove vive e prospera e ci fa gli investimenti necessari, compreso quindi dover mettere le unità FP64 nelle GPU destinate a questo mercato. E questo non mi sembra richiedere alcuna spiegazione o faccia sorgere alcun quesito particolare.

    Benissimo, nulla da dire su questo.

    Ma se AMD non vuole entrare nel mondo degli HPC o comunque della computazione non necessariamente su server, che diamine ha aggiunto il supporto alla FP64 a fare nelle sue GPU?

    Non lo so e non chiederlo a me, che peraltro lavoro per la sua concorrente (ma in ambito CPU).

    Magari aveva in progetto di entrarci, e non c’è riuscita nonostante gli sforzi.

    Per quelle 4 schede che vende nel mondo workstation secondo te è giustificabile lo spreco di silicio e W nel mercato consumer dove vende il 99% delle sue schede (e anche per tali scelte è rimasta indietro)?

    No, ma vedi sopra.

    Infine, tutto il tuo ragionamento

    Quale? Perché, a quanto pare, ne sai più tu su me che me medesimo. Cos’avrei detto? E, soprattutto, cos’è che avrei elaborato?

    è smentito proprio dal fatto che con l’andare del tempo è partita con una capacità FP64 pari a 1/4 di quella FP32 e poi è caduta a 1/16 con Fiji (il cippone con HBM che le costa tantissimo).

    Premesso quanto sopra (dunque vorrei capire cos’è che sarebbe stato smentito. Giusto per essere chiari almeno una volta), una mossa del genere potrebbe essere dettata dal fatto che il costo dell’implementazione degli FP64 si sia rivelato troppo elevato rispetto a quanto effettivamente sia riuscita a raccogliere AMD in termini di mercato.

    Ma, in ogni caso, non è cosa che m’interessi o sulla quale mi fossi espresso in precedenza, commenti alla mano (ovviamente felice di essere smentito).

    Il chip più veloce di AMD a fare conti a 64bit rimane Tahiti, nonostante 2 revisioni della architetture e sopratutto il fatto che siano stati creati 2 chip (molto) più grandi di questo e una revisione (la cui gestione richiederebbe un altro bell’articolo sulle stranezze delle strategie seguite in quel di Sunnyvale) di praticamente pari dimensioni.

    Bene. OK. Non c’è problema. Ne prendo atto. Anche perché non mi sembra di aver mai detto nulla sull’argomento.

    La domanda è quale tipo di strategia ha voluto perseguire AMD in questa generazione, vista che è è chiaramente partita con un certa prospettiva (1/4 FP32) su un chip relativamente piccolo per finire con un’altra (1/16 FP32) su un chippone dal costo insostenibile per il mercato consumer.

    Una risposta ho provato ad abbozzartela sopra. In ogni caso è una domanda che dovresti porre ad AMD, e non a me, visto che non ci lavoro né tanto meno mi sono espresso in merito.

    Sarebbe da fare un bell’articolo sul’analisi di queste scelte ed evoluzioni.

    Ottimo. Sarebbe un’interessante nonché utile integrazione.

    Tipo pensava che Tahiti sarebbe stato il suo chippone che avrebbe tenuto a bada tutto e tutti e quindi dotato di tutto quanto necessario per il mercato sia consumer che professionale mentre poi si è vista superare da un chipetto della concorrenza? I tempi dilatatissimi di rilascio di Tahiti, Hawaii e Fiji potrebbero far pensare che questi due ultimi chip siano stati creati ad hoc al di fuori di una roadmap prestabilita con aggiustamenti fatti per correggere il tiro a cui erano indirizzati.

    Il problema forse è dovuto al fatto che la concorrenza ha rilasciato un chippetto piccolo in ambito consumer, mentre per la fascia professionale ha utilizzato chip di dimensioni maggiori per gli FP64.

    Rimane una mia ipotesi, sia chiaro.

    Oppure AMD era partita con l’idea di realizzare chippetti per il mercato HPC e (qui urge seria interrogazione) ha deciso che i chipponi seguenti non sarebbero stati adeguati al compito?

    Già. E’ l’unica cosa sensata. Solo che non è riuscita a fare bene in nessuno dei due mercati.

    E’ partita con l’idea di poter sfondare nel mondo professionale grazie ai numeri sulla carta che ha pubblicizzato per tanto tempo (pure sulle scatole delle schede da gioco) e poi il sogno si è infranto quando ha visto i numeri di calcolo (e consumi) del GK110?

    Ma non solo quello: bisognerebbe chiedersi come si faccia a entrare in un mercato proponendo soltanto una soluzione hardware, e senza adeguati strumenti software. Ogni riferimento a CUDA non è puramente casuale…

    Quello che mi sembra ovvio è che c’è stato un cambio di strategia subito dopo la presentazione della prima versione di GCN. Mi chiedo, da appassionato, quindi quale fosse la strategia che volevano perseguire e cosa ha fatto loro cambiare idea. E quanto la rincorsa alla prima strategia abbia fatto del male alla efficienza/qualità e quindi alla vendita di tutta la generazione dei 28nm.

    Premesso che non ti posso rispondere io, come ho già detto, penso siano evidenti le ricadute negative che ha avuto su tutto, ma soprattutto in ambito consumer, che delle potenzialità in ambito GPGPU se n’è sostanzialmente fregato.

    E quindi quale strategia vorrà riproporre per la nuova architettura, cioè se ancora avrà numeri in FP64 da capogiro anche sul chippetto di fascia medio-alta, se adotterà la strategia di nvidia di 2 architetture diverse per mercati diversi o se abbandonerà in toto la corsa ai numeroni sulla carta che poi le costano in termini di silicio e W rispetto alla concorrenza che vende con margini più alti un quantitativo maggiore di schede.

    Mi spiace, ma non ti posso rispondere. Personalmente penso sia molto più sensato avere due architetture ottimizzate per i rispettivi mercati, visto che sono abbastanza diversi.

    Certo, c’è il non trascurabile problema che bisogna investirci un bel po’ di soldi, e questo non solo per l’hardware, ma anche per il software.

    In tutto questo, il tuo link al benchamrk, che già conoscevo, non dà alcuna risposta, così come il commento successivo, davvero troppo debole per spiegare investimenti di svariati centinaia di milioni di dollari.

    Non avevano certo questa pretesa, se non quello di riportare soltanto due fatti: che i 64-bit sono utilizzati in ambito GPGPU, e non sono affatto rari.

    Anzi, per volerla dire tutta, lo sono anche in ambito consumer, sebbene in misura minore. Ad esempio le WPF di Microsoft utilizzano proprio i double per rappresentare le coordinate, e Javascript fa lo stesso per l’unico tipo numerico che mette a disposizione. Dunque l’accelerazione del rendering della UI e di pagine web può trarre beneficio da GPU in grado lavorare agevolmente anche sugli FP64.

    Più che flame ho mille domande senza risposta.

    Che rimarranno tali, visto che io domande non ne ho certe poste. Basti leggere i precedenti commenti per notare l’assenza di ?, come pure di frasi che lascino pensare alla formulazione di domande.

    Venire qui con un link fuori contesto

    Fuori contesto? Non avevi scritto appositamente di FP64 e di GPGPU? Non è che me lo sia sognato io, eh! Come non mi sono sognato neppure il fatto che ne hai minimizzato l’utilizzo.

    C’è bisogno che ti quoti, o hai abbastanza onestà intellettuale da andare a vedere il tuo commento e verificarlo di persona?

    senza spiegazione

    Passi per il primo commento, che effettivamente non era di facile interpretazione, ma già il secondo, pur essendo costituito da una sola frase, era piuttosto schietto e non lasciava alcun dubbio sull’ambito della (sotto)discussione.

    per fare quello che risolve tutto “alla fonzie” mi sembra un po’ fuori luogo.

    E cos’avrei risolto, di grazia? Quale problematica avrei tirato fuori? Su cosa avrei pontificato? E perché mai sarebbe fuori luogo?

    Adesso le domande te le faccio io, e sono piuttosto mirate e ben inquadrate.

    Hai preteso delle spiegazioni su domande inesistenti: abbi la cortesia di fornire delle risposte a degli elementi concreti che TU STESSO mi hai appioppato.

    Altro che vecchi flame. A quel tempo c’era poco da discutere: meglio il 6502 e l’Amiga :D

    Ma anche no: bisogna sempre vedere di cosa si parla. E te lo dice uno che ha avuto home basati su 6510 come pure un paio di Amiga. Ma che non nasconde i difetti e le mancanze di entrambi.

    Per il resto capisco benissimo che come autore ti sia sentito preso in causa dai miei commenti. L’articolo è il tuo, e cerchi di difenderlo, come pure di difendere le tue affermazioni. Ho lavorato per diversi anni su AD, per cui so come ci si sente.

    Ma la prossima volta prima di partire in quarta ordendo una sceneggiatura kafkiana nei confronti di un tuo lettore, ti consiglio quanto meno di domandargli qualche informazione per capire se effettivamente ci fa, o invece hai peccato troppo di mania di persecuzione.

    Il tutto senza nulla togliere agli articoli che hai scritto, inclusi i commenti, che ho particolarmente apprezzato per l’alto contenuto tecnico.

  • # 17
    Luca
     scrive: 

    Articolo molto interessante.
    Ormai ho perso di vista il modo gamer soprattutto a causa di vari impegni, ma ricordo l’importanza dei driver altre alla bontà del progetto hardware.
    Sarebbe interessante un confronto tra AMD e NVIDIA anche su tale fronte.

  • # 18
    Nessuno
     scrive: 

    @CdM
    Mi sa che ci siamo fraintesi.
    Sono io che ho posto il dubbio sul perché delle unità FP64 nell’architettura consumer di AMD:
    [quote]Quindi non capisco questa cosa di aver voluto sviluppare una architettura ibrida con la possibilità di avere grandi capacità di calcolo con minimo silicio e non sfruttarla in campo professionale ma con molta meno efficienza (sia in termini di prestazioni/mmq che di prestazioni/W) nel mercato consumer.[/quote]
    Non ho sollevato alcun dubbio sull’utilità della computazione a 64bit nel mercato in cui queste hanno effettivamente un senso.
    [quote]Quindi l’uso della doppia precisione in “codice GPGPU” non è certo raro.[/quote]
    Nessuno ha detto che è raro sui server HPC.
    Al contrario ho sollevato la perplessità di proporre grandi capacità di calcolo FP64 nel mercato consumer. Dubito che Java e WPF siano accelerati tramite GPU per fare conti ultra parallelizzati sulle coordinate. Tant’è che nessun bench di qualsiasi programma consumer risulta penalizzato dall’assenza di grandi quantità di unità FP64 dedicate.

    Io non ho fatto domande a te personalmente, per cui non è che devi giustificare di non avere risposte (che credo abbiano solo le alte sfere di AMD) né tanto meno ho affermato che tu ne avessi fatte. Ho visto nelle 2 risposte sintetiche solo un modo di liquidare il discorso in maniera veloce (ma ripeto, erano fuori contesto, dato che non rispondevano a nessuno dei dubbi sollevati).
    Colpa mia se ho interpretato male le tue intenzioni.

    Per quanto riguarda la validità dell’articolo, non pretendo che sia oro colato e molte di quello che ho “interpretato” dalla sequenza di fatti potrebbe essere errato. La sua validità può essere smentita solo da una interpretazione diversa delle cause ed effetti degli eventi che sia più credibile (o con maggiori fatti a sostegno) di quanto abbia fatto io.
    Invito tutti a fare delle riflessioni sui fatti storici (incontestabili) e di creare una propria teoria di causa-effetto da proporre come alternativa. Ne potrebbe venire una discussione interessante dove molte cose cambiano rispetto a quanto io ho affermato e una serie di teorie che spieghino le cose in un contesto più dettagliato. Sono sicuro che molte cose mi sono sfuggite e altre possono essere spiegate meglio.

    Peace and Love

  • # 19
    Nessuno
     scrive: 

    Mi sa che ho sbagliato il tag x i quote… sorry
    test
    test

  • # 20
    Cesare Di Mauro
     scrive: 

    Mi fa piacere che siamo riusciti a chiarirci.

    Riguardo all’uso dei double in ambito consumer, WPF è pesantemente basata sui double e supporta nativamente l’accelerazione hardware (su GPU), come puoi vedere in questi link:
    https://msdn.microsoft.com/en-us/library/aa480177.aspx
    https://msdn.microsoft.com/en-us/library/mt149842.aspx
    http://blogs.microsoft.co.il/janiv/2009/06/07/hardware-acceleration-in-wpf/

    E’ anche interessante notare che supporta scRGB come spazio colore:https://en.wikipedia.org/wiki/ScRGB
    e utilizzando 16-bit per ogni componente, in caso di elaborazioni complesse sui colori un float può starci stretto.

    Riguardo a Javascript (non Java), come dicevo il tipo numerico disponibile e predefinito è il double. Nelle ultime versioni sono stati introdotti altri tipi numerici in cui è possibile specificare in maniera precisa la dimensione (e il tipo stesso: quindi interi o in virgola mobile). Però sono poco usati ancora e in genere si continua a usare il tipo numerico standard. Per cui il double domina ovunque.

    Infine tengo a precisare che i miei precedenti commenti volevano soltanto ribadire un paio di fatti.

    P.S. I tag in WordPress non sono come quelli dei forum, ma seguono una sintassi simile a HTML/XML (quindi niente parentesi quadre, ma devi usare minore e maggiore per racchiuderli). Inoltre hanno anche nomi un po’ diversi. In particolare per il quote utilizzare blockquote, tutto in minuscolo.

  • # 21
    MOHSIN
     scrive: 

    ho visitato

  • # 22
    Cipollino84
     scrive: 

    Complimenti per l’articolo.
    Da una parte l’ho trovato molto dettagliato e ben fatto… Ma auspico ci sia una quinta parte, perché il discorso è incompleto…. non riesco a trovare nessun riferimento alle DX12 e Vulkan e di come l’architettura GCN, che reputi evidentemente disastrosa, sia diventata di colpo, in ogni sua versione, decisamente competitiva.

    Prendiamo per esempio nella la fascia media le ultime 2 arrivate, la GTX1060 e la RX480:
    La 1060 è una scheda discreta, non mi convince il bus a 192bit accoppiato a 48 Rop’s, effettivamente in una configurazione del genere del back-end implica che lavorino “bene” solo 32 Rop’s, mentre le altre 16 siano di supporto (Se non inutilizzate). Teoricamente la scheda ha un output di 48 pixel ma ne può disegnare fisicamente “solo” 32….Non riesco proprio a capire perché nVidia “tagli” in questo modo i chip per la fascia media… Anche la 970 aveva le stesse limitazioni date da un taglio non proprio ottimale… Per il resto sembra buona….Ora come ora, avrà sicuramente buoni numeri dalla sua parte, anche superiori alla RX480….. Ma immaginati tra un anno quando quasi tutti i giochi saranno in Dx12/Vulkan….. La situazione si ribalterebbe a favore della 480…. E non di poco.
    La cosa che non mi convince affatto invece è proprio l’architettura Pascal….. Comunque… in DX12 e Vulkan AMD ha un architettura decisamente più efficace….. L’esperienza che ha accumulato AMD nel creare Mantle le ha permesso di creare un architettura (GCN) che si adattasse perfettamente alle caratteristiche di queste nuove API.
    Effettivamente, dopo aver “sofferto” le Dx11, AMD doveva assolutamente creare un architettura di base che si adattasse bene da subito alle nuove librerie…. Infatti, se ci si pensa, la base architetturale di diverse generazioni di GPU rimane sempre la stessa.
    Prendiamo come esempio nVidia: tutte le architetture nVidia degli ultimi anni si basano ancora sull’architettura Fermi: Kepler, Maxwell e Pascal sono solo step evolutivi della stessa architettura. Personalmente credo che Pascal sia l’ultimo step evolutivo di questa architettura, infatti è evidente quanto essa “soffra” con le nuove API, ed è innegabile l’impegno di nVidia nel “mettere una pezza” tramite driver…. In effetti credevo che con Pascal avrebbero implementato ottimamente l’Async compute, visto che in Maxwell era solo abbozzato (2 pipeline asincrone, di cui una a bassa priorità, utilizzata soprattutto come supporto alla prima , mentre GCN ha 8 motori della stessa dimensione), invece nella realtà Pascal ha gli stessi problemi e limitazioni di Maxwell, questo mi fa credere che l’utilizzo dei motori asincroni sia di difficile implementazione in questo tipo di architettura base, che risale, nella sua versione iniziale, al 2010 e che quindi è intrinsecamente nata con in testa le Dx11.
    AMD d’altro canto ha rinnovato la sua architettura passando da Vliw a GCN, da uno scheduler “software” leggero ad uno hardware e complesso, creando la sua architettura basandola su Mantle, che a sua volta somiglia alle Dx12 e Vulkan (Sacrificando evidentemente le prestazioni in Dx11) e quindi non ci si deve stupire se con l’avvento delle nuove librerie le Arch. AMD danno numeri estremamente maggiori sia nei giochi aggiornati alle nuove librerie rispetto alle vecchie, sia rispetto all’architettura della concorrenza, che cerca di sopperire alle mancanze tramite software… Infatti i bench dei giochi Dx12/Vulkan fanno guadagnare alle Arch.AMD numeri estremamente maggiori rispetto alle Arch.nVidia, che se va bene guadagnano il 5% di prestazioni a fronte di un buon 35/40% di TUTTE le versioni di GCN.

    Il mio vuol esser un intervento assolutamente superpartes, con la sola intenzione di stimolare al ragionamento ed al confronto…. Nondimeno la mia attuale Vga è una Gtx770.

  • # 23
    Luca
     scrive: 

    Magnifica raccolta di articoli, non solo interessanti ma anche fruibili e ben scritti.

    Spero vivamente un una nuova infornata in merito alle nuove architetture a 14 e 16 nanometri, all’uso degli schedulatori di shader asincroni e all’introduzione delle API Vulkan.

    Se poi Cesare Di Mauro ti facesse da revisore penso che uscirebbe un articolo da pubblicare su tutte le testate di calibro e da incorniciare in tutte le case di noi appassionati :D

    Grazie e complimenti!

  • # 24
    Luca
     scrive: 

    @Cesare Di Mauro

    Solo un paio di questioni:

    In merito allo spazio colore scRGB a 48bit non capisco come il calcola in DP possa servire, le operazioni, come tu sicuramente sai molto meglio di me, vengono effettuate per componente e non per vettore, avrei pensato quindi piu’ all’uso degli half-float, che non ai double.

    In merito a javascript, sebbene tu non abbia detto nulla di sbagliato non penso che un’eventuale accelerazione via GPU richieda strettamente la presenza di FP64, anzi mi aspetto che nella stragrande maggioranza dei casi si preferira’ la velocita’ superiore dei float alla precisione dei double, in un linguaggio che non fa della precisione matematica il suo punto di forza.

    Penso che la questione veramente discriminante tra mercato consumer e pro nel campo delle GPGPU non sia tanto l’ampiezza dei campi floating point quanto l’affidabilita’ del dato prodotto, che spesso nelle schede consumer ( e in particolare in uscita dai ROP ) puo’ essere degradata per favorire la velocita’ di esecuzione del calcolo, almeno a quanto ne so io.

  • # 25
    Nicolo1968
     scrive: 

    Con la nuova gamma nvidia e amd si potrà ancora meglio usare il 4k e anche la realtà virtuale, fate un articolo che parli di questo sarebbe anch esso interessante

  • # 26
    Cesare Di Mauro
     scrive: 

    @Luca: scRGB a 48 bit utilizza 16 bit per componente colore. Un FP32 ha una mantissa di 23 bit, per cui rimangono soltanto 7 bit di precisione per l’elaborazione, che possono non essere sufficienti se si fanno calcoli complessi. Specialmente con la “moda” di rappresentare i numeri come valori in virgola mobile da 0 a 1.0, senza FP con buona precisione a disposizione è facile che si perdano già alcuni valori.
    Per ovvie ragioni l’uso di FP16 è impensabile, perché è impossibile anche soltanto mantenere i valori immodificati (tranne ovviamente per un ristretto sottoinsieme).

    Riguardo Javascript, il problema è che, come dicevo prima, l’unico tipo numerico a disposizione (a parte i nuovi che sono stati introdotti) è il double, per cui una macchina virtuale che sia conforme allo standard del linguaggio deve usare FP64 per i calcoli, a meno di operazioni di tracciamento dei valori che vengono effettuate dai compilatori JIT (senza di questi accorgimenti le prestazioni dell’esecuzione di codice Javascript crollerebbe).
    Ma se per valori “presumibilmente interi” questi giochetti sono possibili, nel momento in cui utilizzi valori con la virgola non puoi sapere a priori quanta precisione userai, a meno di complicare enormemente il JITer. Questo perché tracciare l’intervallo di un valore intero è banale, mentre per uno in virgola mobile devi eseguire operazioni molto più complesse per capire se un certo numero può essere memorizzato come FP32 senza perdere precisione.

    Infine sull’utilizzo di GPGPU in ambito consumer, è chiaro che mi aspetto come minimo che sia affidabile, ossia che non produca risultati che si discostino (se non entro una certa misura) da quelli di una CPU. Riguardo alla precisione da utilizzare, ovviamente dipende dal tipo di dati manipolati: per buona parte gli FP32 potranno bastare, ma per altri servono necessariamente gli FP64 (o gli INT64, a seconda dei casi).

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.