[Thread Ufficiale] Aspettando le nuove VGA AMD Radeon™

[DakmorNoland]

Originariamente inviato da Il nabbo di turno

La questione è, confronta la 280 con la 285 lato features:
-Niente nuovo mc
-Niente vsr
-Niente crossfire bridge
-Niente diminuzione dei consumi
-Niente trueaudio
-A parità di clock, la 285 va come la 280x nonostante le minori cu
E come se non bastasse sembra che la 285 vada ancora più forte con gli omega driver rispetto a tahiti.

Sono cose che contano, e sinceramente averle in gpu da 100 euro farebbe comodo .

Ma se la 280 va come la 285 e costa la metà... Poi vabbè la 280 consuma decisamente di più... Però al prezzo della 285 ti prendi la 280x. La 285 non ha senso di esistere per me.

[Il nabbo di turno]

Originariamente inviato da DakmorNoland

Ma se la 280 va come la 285 e costa la metà... Poi vabbè la 280 consuma decisamente di più... Però al prezzo della 285 ti prendi la 280x. La 285 non ha senso di esistere per me.

Non proprio:
http://www.bitsandchips.it/hardware/...-slim?start=12

[FroZen]

Ma infatti gcn 1 (tahiti) scompare, rimarra solo dal 1.2 in su....le 380 saranno delle 290 riviste....e tonga scendera sulla fascia medio bassa....sulla fascia bassa non mi esprimo, non mi interessa...

[Il nabbo di turno]

Originariamente inviato da FroZen

Ma infatti gcn 1 (tahiti) scompare, rimarra solo dal 1.2 in su....le 380 saranno delle 290 riviste....e tonga scendera sulla fascia medio bassa....sulla fascia bassa non mi esprimo, non mi interessa...

Io sarei contento se ALMENO sulla fascia bassa(360/360x), mi porti cgn 1.2 o 1.3, ormai è troppo restare con cgn 1 o 1.1.

[FroZen]

Mmmm le 37x saranno tonga imho e saranno delle belle schede equilibrate....le 36x possono anche scomparire con le nuove apu....un full tonga rischia di andare poco meno di una 290, troppo vicina... A meno che le tengano a 2/3gb x limitarle....

[Il nabbo di turno]

Originariamente inviato da FroZen

Mmmm le 37x saranno tonga imho e saranno delle belle schede equilibrate....le 36x possono anche scomparire con le nuove apu....un full tonga rischia di andare poco meno di una 290, troppo vicina... A meno che le tengano a 2/3gb x limitarle....

Finchè le apu non mi ricevono delle memorie veloci(e neanche le ddr4 lo sono), imho sopra i 70 euro tutte le schede video hanno un senso di esistere.
Full tonga potrebbe andare un 10-15% in più rispetto alla 280x, troppo poco per stare vicino alla 290.

[nasone32]

qualcuno ha per caso letto se le stacked hbm sono (quanto?) piu alte delle gddr? intendo proprio la dimensione fisica
e ci dobbiamo quindi aspettare che gpu e memorie stiano su un "interposer" rialzato rispetto al pcb?

giusto per farmi un'idea di come potrebbe essere fisicamente la scheda.

[nasone32]

tipo

[The Witcher]

ma di queste schede di nuovo cosa c'è? nulla, praticamente (a parte una).

Sono delle specie di rebrand, giusto?

[Il nabbo di turno]

Originariamente inviato da The Witcher

ma di queste schede di nuovo cosa c'è? nulla, praticamente (a parte una).

Sono delle specie di rebrand, giusto?

In teoria le uniche schede che conosciamo già saranno la 290(x) e la 285, per il resto dovrebbero essere schede nuove.

[okorop]

Originariamente inviato da Il nabbo di turno

In teoria le uniche schede che conosciamo già saranno la 290(x) e la 285, per il resto dovrebbero essere schede nuove.

quoto sebbene le "vecchie" saranno sicuramente riviste con clock piu' spinti e con revisioni di chip migliori che garantiranno consumi e performance migliuori

[maurilio968]

Vorrei esprimervi un dubbio sulla possibilità di indirizzare tutta la ram di uno sli/crossfire in modo che risulti condivisa ovvero "sommata" ( il "memory stacking" di cui si legge negli articoli) a differenza di quanto avviene ora (con directx 11) e tutto questo semplicemente passando a nuove api (directx 12 e/o mantle)

Questa possibilità esiste realmente anche per le attuali vga (per esempio cross di amd 280-290x oppure sli di gtx 970-980) ?
E anche per le future vga, basta davvero una nuova api (mantle o directx 12 che sia) e nuovi driver per consentire la cosa?

Io purtroppo penso proprio di no e vi illustro perchè.

Se faccio uno SLI/cross posso usare due tecniche per accelerare il rendering dei frame:

AFR (Alternate frame rendering - directx 11):

Con l'AFR ipotizziamo che tra un frame e il successivo non vi siano particolari differenze che implicano diversi tempi di calcolo:le GPU renderizzino ciascuna un frame.
E' più rozzo ma più efficiente.Però con AFR non c'è un effetto di memory stacking: ogni GPU ha la sua partizione di RAM dedicata indipendente dall'altra e ogni dato da elaborare è copiato nella ram di ciascuna delle 2, quindi tutto (geometria, texture, shader ecc) è duplicato.
Svantaggio: di 8GB disponibili (4+4 perchè su 2 bus separati) solo 4 sono realmente quelli che il software del gioco può sfruttare.
Vantaggio: ogni GPU ha pieno accesso alla prorpia RAM e ogni GPU elabora metà dei dati necessari: ne deriva che la banda totale disponibile è doppia, come lo sono gli shader, le TMU e le ROP.


SFR (Split frame rendering - directx 12 o mantle):

Non si fa una linea sì e una no (avrei problemi con i filtri, tipo l'AA), ma splittando l'immagine in 2 (o più parti a seconda del numero di GPU disponibili).

Bene allora usiamo SFR con le nuove directx 12 o con mantle.Tutto ok con le attuali vga? Ora questo io non creto!

Con l'attuale architettura SLI/CrossFire La RAM è divisa in 2 e ogni parte è collegata esclusivamente al bus di una GPU.
Se una GPU vuole accedere al bus dell'altra deve passare per il PCI-Express con una banda ridotta.

Per fare in modo che le GPU accedano ad una RAM comune secondo me serve un hardware dedicato che supporti la cosa, cioè un sistema di comunicazione tra GPU che sia almeno paragonabile alla velocità dell'attuale controller RAM dedicato delle GPU.
Perciò servirebbe un bus (con una strategia di accesso) ovvero un controller a bordo che serva entrambe le GPU.

Perchè ? Vedo di spiegarmi.

Ammettiamo di dividere l'immagine da renderizzare in due parti (SFR); ok si riduce il carico sulla singola scheda però:

1- la scena (da cui le due parti dell'immagine provengono) e tutti i dati ad essa relativa come fanno ad essere ricalcolati in tempo ? Cioè come stabilire quali texture e geometrie stanno solo in una parte dell'immagine e quali solo in quell'altra ?
2- se e quando queste dovranno essere a disposizione (perché la scena si sta spostando) come si fa a includerle e anticipare il loro caricamento (onde evitare il blocco del rendering in attesa dell'aggiornamento) ?

Attualmente anche solo la rimozione delle superfici nascoste richiede un algoritmo che nelle GPU è implementato in hardware dedicato.
Qui dovremmo avere qualcosa che calcola in maniera esatta quali risorse vanno in una parte dell'immagine e quali in un'altra e fornire in tempo quelle che occorrono rimuovendo quelle che non sono più necessarie appena ciò si rende necessario.

Esempio: il giocatore effettua un salto e la texture che prima era visibile solo nella parte inferiore ora è usata anche nella parte superiore dell'immagine.
Se non ce l'ho in memoria devo caricarla: se devo passare dal pci express sono dolori.


Obiezione: faccio un buffer comune implementato da qualche parte via driver.
Ma così la banda non sarebbe diciamo la metà (o quanto) di una singola gpu ?
Infatti se almeno una parte della memoria video fosse condivisa tra tutte le GPU le texture ed i file necessari per la renderizzazione del frame che sono in comune potrebbero stare nella zona diciamo "shared". Per eseguire l'accesso, tuttavia, servirebbe un meccanismo di mutua esclusione tra le GPU (una variabile shared può essere letta da un solo processo alla volta, attraverso l'impelementazione di una coda) il che provoca latenze e delay.

E comunque per fare quanto descritto nei punti 1- e 2- occorre una potenza di calcolo assai superiore alle attuali schede:

Infatti un grosso problema di SFR è che non tutte le parti hanno la stessa complessità, e quindi è difficile ottimizzare il rendering.
Una GPU a cui è stata data una parte semplice dell'immagine dovrà aspettare che un'altra finisca il suo lavoro più complesso prima che si possa mettere tutto insieme e fare un buffer unico (comunque esso sia implementato). Il tempo d'attesa di quella (o quelle) GPU è tempo morto, che in post analisi si poteva evitare dando un parte più grande di rendering alla prima GPU e togliendola alla seconda. Ma lo sai dopo, non prima.
A volerlo fare in maniera dinamica non mi pare possibile solo via GPGPU, occorrerebbe una CPU a cui vanno inviati tutti i dati o una specie di "GPU master" in Hardware.

In entrembi i casi (nuovo bus e/o nuovo controller per non passare dal pci-e oppure nuova "gpu master") mi sembra indispensabile un nuovo hardware.
(e infatti i test "entusiasmanti" con nuove directx 12 le fanno su NUOVE schede video ancora da presentare al pubblico http://www.tomshw.it/cont/news/direc...u/62583/1.html )

Le attuali gpu mi sembrano comunque tagliate fuori.
Per le future mi pare occorra ben di più che un semplice cambio di api.

[magnusll]

Per lo "sdoppiamento" della VRAM su configurazioni multi-gpu con DX12/Mantle di parla di SFR.

I dettagli ovviamente non li conosco. Tieni pero' presente che sebbene le tue obiezioni abbiano un senso, le GPU moderne sono pensate esplicitamente per il parallelismo massivo. Non tutte le operazioni possono essere eseguite in parallelo, ma molte si. E anche la gestione della memoria non e' "monolitica" (basti pensare ai vari tipi di cache presenti nelle GPU stesse per ottenere latenze piu' basse possibile sui dati a maggior frequenza di accesso).

E' ipotizzabile che dando agli sviluppatori la possibilita' di allocazione di specifici segmenti di memoria, gli stessi possano scrivere engine grafici che inviano i dati "globali" ad entrambe le GPU e quelli necessari solo alle operazioni "locali" alla specifica GPU che esegue le elaborazioni per quel segmento del frame. Non ci sarebbe un raddoppio secco (una parte della VRAM andrebbe "sprecata" per i dati "globali" ripetuti) ma un miglioramento netto comunque si.


[EDIT] Un esempio pratico e' Civ: Beyond Earth, che ha implementato lo SFR per le schede AMD tramite Mantle. c'e' un interessante articolo a questo link:

SFR in CIV: Beyond Earth

L' articolo si focalizza sui miglioramenti dal punto di vista del microstuttering ma si puo' estrapolare come utilizzando la stessa tecnica si puo' "riciclare" parte della VRAM invece di dover mandare le stesse strutture di memoria a tutte le GPU.

[nasone32]

una volta ati in crossfire supportava il super tiling

nessun microstuttering e una divisione dei compiti migliore dello split frame.

Questa possibilità esiste realmente anche per le attuali vga (per esempio cross di amd 280-290x oppure sli di gtx 970-980) ?
E anche per le future vga, basta davvero una nuova api (mantle o directx 12 che sia) e nuovi driver per consentire la cosa?

nessuno pretende di fare uno stacking vero e proprio della memoria. sarebbe impossibile, bisognerebbe collegare ogni gpu alla memoria della compagna con lo stesso bus, che è fisicamente impossibile, visto che una 390x dovrebbe avere 4096 bit (non oso immaginare il connettore che si dovrebbe usare...).
E poi, non stiamo cercando di staccarci da questi benedetti connettori?

si tratta ovviamente di uno stacking virtuale.
se ogni gpu renderizza una parte della scena, e si fa in modo che abbia bisogno di avere meno dati possibili dalla sua compagna (e *questo* è reso possibile da mantle/dx12) allora anche i requisiti di memoria si abbassano per ogni scheda, visto che non è più necessario avere una copia di tutto su ogni scheda.

in realtà già ora la comunicazione tra le schede non è così intensa come credi.
tra una scheda e l'altra vengono copiate sopratutto risorse persistenti che non è necessario ricalcolare ogni frame (tipo le shadow map?) e ovviamente dati di sincronia e composizione della successione dei frame.

se ora si riesce a caricare nella memoria di ogni scheda solo quello che le serve, per calcolare la parte di frame necessaria, virtualmente abbiamo più memoria a disposizione.
chiaramente questo non funziona in AFR perchè se ogni scheda deve renderizzare tutto il frame le servono tutti i dati...

quindi, mantle e dx12 permetteranno di allocare meglio il compito di ogni scheda, lavorando a basso livello, e da qui lo stacking virtuale della memoria.

[sgrinfia]

Caso GeForce GTX 970, una class action contro Nvidia e Gigabyte
Nvidia e Gigabyte sono state denunciate negli Stati Uniti per pubblicità ingannevole e pratiche commerciali scorrette, illegali e ingannevoli. La causa, che mira a trasformarsi in class action, riguarda la GTX 970, l'uso che fa dei 4 GB di memoria grafica e la modifica di alcune specifiche dopo mesi dall'arrivo sul mercato.
Nvidia, insieme al partner Gigabyte Technology, è stata denunciata per pubblicità ingannevole, scorrette, illegali e ingannevoli. Al centro della vicenda la GeForce GTX 970, una scheda video recentemente al centro delle polemiche per l'uso "particolare" di 4 GB di memoria (qui la spiegazione), ma soprattutto per un cambio di specifiche che ha riguardato il numero di ROPs e la quantità di cache L2.

Nvidia logo

La denuncia (qui il testo) è stata depositata da Andrew Ostrowski, per conto di sé stesso e altri che sono nella sua stessa posizione. La class action, depositata presso una corte californiana, richiede che si tenga un processo con giuria e la restituzione dei profitti ottenuti con le presunte pratiche illecite, i danni ingiuntivi e tutto ciò che è consentito dalla legge della California.

"Gli imputati hanno condotto un'azione volta a indurre in errore il consumatore circa le caratteristiche, le qualità e i vantaggi della GTX 970 affermando che la scheda fornisce 4 GB di memoria effettivi, 64 ROPs e 2048 KB di cache L2, quando in realtà non lo fa", si legge nel testo della denuncia. "Il marketing legato alla GTX 970 portato avanti dagli imputati era inteso e ha creato la percezione tra i consumatori che il prodotto era, di fatto, in grado di conformarsi con le specifiche come pubblicizzato".

Gigabyte GTX 970 4GB Windforce 3X
Gigabyte GTX 970 4GB Windforce 3X € 351,44Acquista+
Nvidia ha finora spiegato che la scheda funziona come da progetto, almeno per quanto concerne l'uso dei 4 GB di memoria. Di questa quantità di memoria solo 3,5 GB sono ad accesso prioritario e rapido, mentre la restante parte è più lenta e vi si accede solo in determinati casi e momenti. Questo è da ricondursi alla "modifica" del chip GM204, castrato (1664 CUDA core) rispetto alla sua massima espressione (che riscontriamo nella GTX 980 con 2048 CUDA core).

La scheda si comporta bene nei test, vi sono però dei casi - come il gaming in 4K con dettagli alti, ma anche in QHD con alcuni titoli - in cui gli appassionati hanno rilevato prestazioni non sempre uniformi (stuttering). Ed è proprio da questo comportamento che la vicenda è montata, sfociando in gennaio con le dichiarazioni di Nvidia. Per quanto riguarda le specifiche tecniche, l'azienda ha ammesso di aver comunicato male le informazioni alla stampa: la GPU ha solo 56 ROPs e una cache L2 di 1792 KB.

[francisco9751]

si ma cosa centra qua?

Inviato dal mio LG-D802 utilizzando Tapatalk

[sgrinfia]

Originariamente inviato da francisco9751

si ma cosa centra qua?

Inviato dal mio LG-D802 utilizzando Tapatalk

Be, pura informazione

[nasone32]

Quindi da quello che leggo l'aspetto delle nuove 390 sarà di un chippone centrale con solo 4 chipponi di memoria attaccati. Ergo un solo waterblock centrale con base larga 4x4 cm puo raffreddare contemporaneamente gpu e memorie in un sol colpo.

Ergo, se la gpu della 390 sarà raffreddata a liquido lo saranno anche le memorie per forza.
Bello no? Memorie raffreddate a liquido.

[jotaro75]

Originariamente inviato da nasone32

Quindi da quello che leggo l'aspetto delle nuove 390 sarà di un chippone centrale con solo 4 chipponi di memoria attaccati. Ergo un solo waterblock centrale con base larga 4x4 cm puo raffreddare contemporaneamente gpu e memorie in un sol colpo.

Ergo, se la gpu della 390 sarà raffreddata a liquido lo saranno anche le memorie per forza.
Bello no? Memorie raffreddate a liquido.

ma sei sicuro? io da quel che ho letto e mi pare di aver capito solo il chip sarà raffreddato a liquido mentre il resto(e nel resto io includevo anche le memorie) verrà raffreddato ad aria, infatti si accenna sempre a un raffreddamento ibrido tipo r9 295x2

Io invece avrei un'altra domanda per tutti...voi avete già letto qualche info su eventuali misure della 390x?dite che ho qualche speranza che la reference non superi i 290mm?

[FroZen]

Imho non essendo monolitico ( implementazione 2.5d non 3d visti gli alti consumi delle gpu che rovinerebbero i chip ram) si avrà un die alla intel con la parte gpu e poco lontano le ram, il TUTTO raffreddato a liquido.... La ventola servira per i vrm .... Mi aspetto schede piu corte in virtu di questo fatto....