|
|
|
|
Strumenti |
20-02-2015, 16:02 | #10081 | |
Senior Member
Iscritto dal: Apr 2004
Messaggi: 10840
|
Quote:
__________________
Asus X470 Prime, AMD Ryzen 2700, 32GB Corsair DDR4 3000, RTX 3070 Ti, Samsung 970 Evo Plus 2TB, EVGA G2 750W, CM HAF X, Samsung TV QN95 55" + AOC G2590PX |
|
20-02-2015, 16:07 | #10082 | |
Bannato
Iscritto dal: Aug 2013
Messaggi: 4811
|
Quote:
http://www.bitsandchips.it/hardware/...-slim?start=12 |
|
20-02-2015, 16:15 | #10083 |
Bannato
Iscritto dal: Aug 2001
Città: Bergamooo...
Messaggi: 20089
|
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...
|
20-02-2015, 16:18 | #10084 |
Bannato
Iscritto dal: Aug 2013
Messaggi: 4811
|
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.
|
20-02-2015, 16:23 | #10085 |
Bannato
Iscritto dal: Aug 2001
Città: Bergamooo...
Messaggi: 20089
|
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....
|
20-02-2015, 16:27 | #10086 | |
Bannato
Iscritto dal: Aug 2013
Messaggi: 4811
|
Quote:
Full tonga potrebbe andare un 10-15% in più rispetto alla 280x, troppo poco per stare vicino alla 290. |
|
20-02-2015, 19:17 | #10087 |
Member
Iscritto dal: Feb 2007
Messaggi: 114
|
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. |
20-02-2015, 19:27 | #10088 |
Member
Iscritto dal: Feb 2007
Messaggi: 114
|
tipo
|
20-02-2015, 19:29 | #10089 |
Bannato
Iscritto dal: Nov 2013
Città: Windows 10 Pro 64bit,i5 3570k 3.4GHZ,MB Asrock Z77 Extreme6 RAM32GB DDR3 1600 Corsair (8x4) Sapphire AMD 480 8GB,HD 3TB Seagate Barracuda,ALI Corsair T 650w, Monitor Dell U2414H FULL HD
Messaggi: 4163
|
ma di queste schede di nuovo cosa c'è? nulla, praticamente (a parte una).
Sono delle specie di rebrand, giusto? |
20-02-2015, 19:46 | #10090 |
Bannato
Iscritto dal: Aug 2013
Messaggi: 4811
|
|
20-02-2015, 21:03 | #10091 |
Senior Member
Iscritto dal: Jan 2007
Messaggi: 24976
|
quoto sebbene le "vecchie" saranno sicuramente riviste con clock piu' spinti e con revisioni di chip migliori che garantiranno consumi e performance migliuori
|
20-02-2015, 21:32 | #10092 |
Senior Member
Iscritto dal: Feb 2006
Messaggi: 1654
|
SLI con directx 12 e/o mantle: ram stacking su attuali e future vga
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.
__________________
ogni minuto muore un imbecille e ne nascono due. Ultima modifica di maurilio968 : 20-02-2015 alle 21:44. |
20-02-2015, 23:32 | #10093 |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 851
|
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. Ultima modifica di magnusll : 20-02-2015 alle 23:57. |
21-02-2015, 06:42 | #10094 | |
Member
Iscritto dal: Feb 2007
Messaggi: 114
|
una volta ati in crossfire supportava il super tiling
nessun microstuttering e una divisione dei compiti migliore dello split frame. Quote:
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. Ultima modifica di nasone32 : 21-02-2015 alle 06:50. |
|
21-02-2015, 07:01 | #10095 |
Senior Member
Iscritto dal: Jan 2013
Messaggi: 4225
|
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. |
21-02-2015, 08:14 | #10096 |
Senior Member
Iscritto dal: Sep 2011
Città: milano
Messaggi: 8490
|
si ma cosa centra qua?
Inviato dal mio LG-D802 utilizzando Tapatalk |
21-02-2015, 13:41 | #10097 |
Senior Member
Iscritto dal: Jan 2013
Messaggi: 4225
|
|
22-02-2015, 14:51 | #10098 |
Member
Iscritto dal: Feb 2007
Messaggi: 114
|
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. |
23-02-2015, 16:25 | #10099 | |
Senior Member
Iscritto dal: Jan 2013
Città: Lecco
Messaggi: 2494
|
Quote:
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?
__________________
PC:Zalman z9Plus/i5 3450/ASRock B75M Pro3/LiqMax II 120/xfx proseries 550w/RAM 8GB/Samsung EVO128GB/1TB WD Blue/2x500GB/PNY 1060 6GB/CM Storm TriggerZ/Logitech G302/Benq 2450HM BattleTag:Stecor#2429 Steam:Jotaro75 UPlay:Lars_Ulu PS:jotaro75 Trattative:Leonidas, gluvocio,Cazzabubbola,free rider |
|
23-02-2015, 16:38 | #10100 |
Bannato
Iscritto dal: Aug 2001
Città: Bergamooo...
Messaggi: 20089
|
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....
|
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 08:09.