[THREAD UFFICIALE] Aspettando R700

Originariamente inviato da michelgaetano

bastardone

[gianni1879]

Originariamente inviato da @ndrey

Ma le mem della Qimonda 40x sono da 0.5ns/4.0Gbps e 50x sono da 0.4ns/5.0Gbps?!





0.4ns = 2.5Ggz x2
0.5ns = 2.0Ghz x2
Quelli delle Samsung sono da 0.5ns K4G52324FG-HC05 2000Mhz ..

PS. io aspetto quelli da 0.4

con tutta quella banda passante cambierebbe ben poco

se poi uno ha preferenze personali è un altro discorso

[-noxius-]

Originariamente inviato da michelgaetano

La HD4870 ne ha 2 da 6 pin.

MAGNIFICOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO !!!!

Credevo fossero 6+8 , non sai che piacere sapere questo !! Mi sono appena preso un 250 W per CF ed ha solo 2 connettori da 6 pin !!!

[Brightblade]

Di qua invece devo chiedere un'altra info. Se decidessi di prendere una 4870, secondo voi, il dissi della scheda video farebbe a pugni con la ventola del chipset della mia scheda madre? (che sarebbe questa)



Me lo chiedo perche' stamattina, smontando la 7900GT, ho guardato un po' quanto la coda della scheda arrivava a sfiorarlo, e pur essendo abbastanza piccola in proporzione alle schede odierne , ci andava molto vicino (soprattutto i componenti sul fondo della scheda). Che dite, col dissi doppio slot della 4870 rischio? In tal caso mi sa che potrei ripiegare su una variante della 4850 con dissi "custom" che raffredda magari non quanto il dual slot della 4870 ma meglio del dissino che sembra avere il modello base della 4850.

edit. Azz, non avevo visto che era stato aperto anche il thread della 4870 .. sorry.

[goldorak]

Originariamente inviato da michelgaetano

La HD4870 ne ha 2 da 6 pin.

E possibile che con il die shrink a 40nm per l'anno prossimo si passi ad un solo connettore a 6 pin sulla 4870 ?
La scheda mi tenta parecchio, ma non digerisco proprio i due connettori, anche perche' ho parecchi altre cose dentro al pc (4 hard disk, 3 ventole da 12cm, scheda raid hardware, 1 dvd-rom, 1 masterizzatore cd-rom, quadcore a 65nm, 4 GB di ram etc..) e non vorrei che l'ali soffrisse troppo (corsair HX 620 W).

Originariamente inviato da -noxius-

MAGNIFICOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO !!!!

Credevo fossero 6+8 , non sai che piacere sapere questo !! Mi sono appena preso un 250 W per CF ed ha solo 2 connettori da 6 pin !!!

graaaande

allora la prendi appena esce??

..beh non vedo l'ora di vedere qualche tuo bench con questa scheda super !!!

[-noxius-]

Originariamente inviato da Mister Tarpone

graaaande

allora la prendi appena esce??

..beh non vedo l'ora di vedere qualche tuo bench con questa scheda super !!!

Penso che ripiegherò sulla 1gb , alla fine al massimo ne metterò un'altra in CF dato che 550+250 = millemila watt .. e senza mettere sotto torchio l'ali principale .. (bisogna vedere quanto reggerà questo piccolo 250w ...)

ma devo vedere ..

[Benia]

Originariamente inviato da <^MORFEO^>

Sulle slide ufficiali AMD per un crossfire di due 4870, si parla di almeno un ali da 600W di importante qualità che abbia anche 4 connettori pci-e...

Azz!

Originariamente inviato da Benia

Azz!

e beh... un crossfire di queste belve consuma parecchio ... che ti aspettavi??

[Benia]

530/540 watt, visto che le 3870 consumano molto meno

[The_SaN]

Originariamente inviato da Benia

530/540 watt, visto che le 3870 consumano molto meno

Ma se c'é scritto 600W non vuol dire che se l' ali é da 550W non funziona...
Devi vedere quanti ampere ha sulla +12V

[yossarian]

Originariamente inviato da Mercuri0

Ma perché, multi-gpu on die (che ancora non ho capito cosa voglia dire) dal punto di vista delle dimensioni non è peggio rispetto a uno "monolitico"?
Ti servono tutti i transistor per tutti i due "core", che quindi hanno parti ridondanti rispetto a un'architettura "monolitica". Le GPU sono già abbastanza modulari di suo, non c'è bisogno di ricorrere a soluzioni di questo tipo. Non diminuirebbe neanche i costi di progetto, se bisogna progettare controller in cascata specifici.

la ridondanza è relativa, in quanto hai core di dimensioni ridotte e quindi linee di controlle e trasmissione di dimensioni ridotte. Il fatto di dover replicare alcune strutture introduce indubbiamente una ridondanza, ma dal punto di vista economico, una volta progettato un core è sufficiente replicare lo stesso n volte. A livello progettuale i costi aumentano proporzionalmente alla complessità del core e, nel caso di die shrink, core più complessi danno più problemi.

Originariamente inviato da Mercuri0

Per GPU "monolitica" di solito si è inteso riferendosi alle dimensioni del chip, mica alla sua architettura (che resta modulare anche se il chip è grande come un lenzuolo).

assolutamente no; è riferito alle architetture di trasmissione e controllo, alla presenza di uno o più scheduler "principali"; in un chip di tipo monolitico si ha uno scheduler che gestisce tutti i thread a livello più alto e decide come e dove allocare dati e risorse all'interno di tutto il chip. Le dimensioni non c'entrano nulla; tanto che tu stesso hai affermato che una cpu di tipo dual o quad ha un'area maggiore rispetto ad un monoprocessore; eppure non si può definire "architettura monolitica"

Originariamente inviato da Mercuri0

La necessità delle CPU multi-core non viene da un problema di area, ma da un problema di potenza! (= frequenza di clock). Anzi, la soluzione multi-core serve proprio per poter fare chip a frequenza minore a costo di usare area maggiore, parallelizzando le operazioni (e a costo di dover richiedere nuovi paradigmi di programmazione - come il Cell). Non è un discorso di antieconomicità, ma di impossibilità tecnologica nel poter progredire sulla strada delle frequenze.

per quale motivo; cosa mi impedisce di progettare un monoprocessore ad elevato parallelismo? Otterrei lo stesso risultato di un dual o di un quad e non dovrei salire in frequenza; è solo una questione di numero e di tipologia delle pipeline. Il cell è un discorso a parte, in quanto è un'architettura composta da un'unità centrale e 8 unità di calcolo vettoriali, gestite da un ring bus; non si tratta di un multicore in cui i singoli core sono indipendenti e con un rapporto paritario. Nel cell, ad esempio, è il ppe ad inizializzare i dma per i spe e l'arbiter del ring bus a gestirne gli accessi in memoria e i trasferimenti di dati tra unità di calcolo. La strada delle frequenze è obbligatoria solo se si sceglie una strada, come quella intrapresa da intel con i northwood prima e i prescott dopo, che porta a pipeline lunghe, con un elevato numero di stadi, il che comporta tempi molto lunghi di permanenza dei dati all'interno della pipeline, innumerevoli cicli di clock persi in caso di salti condizionali sbagliati, molti più problemi in caso di propagazione di "bolle" all'interno della pipeline. Questo comporta il cercare di avere stadi sempre più frazionati per velocizzare la singola elaborazione e, quindi, frequenze sempre più alte.

Originariamente inviato da Mercuri0

Cosa intendi per "Un unico core con la struttura di due core"?

è riferito al discorso precedente sulle strutture di controllo e trasmissione dati: posso creare all'interno di un chip monolitico un'architettura con più arbiter, uno per ogni blocco che simulerebbe il funzionamento di un core. A questo punto, però, si perde il senso di struttura monolitica e non vi sarebbe una convenienza dal punto di vista economico (stavolta dal punto di vista realizzativo e non progettuale).

Originariamente inviato da Mercuri0

Forse stiamo andando un pò OT, però - a parte la mia visione differente di hardware/software per cui non è scontato dire dove nelle operazioni del PPE cominci l'hardware e finisca il software -, magari può dare uno spunto di riflessione il fatto che nello Spursengine di Toshiba il PPE l'abbiano tolto, o che un boss di AMD commentando Roadrunner, dicesse che il problema del Cell è la PPE che fa da collo di bottiglia. Ovviamente il tipo voleva tirare acqua al mulino del GPGPU, e le GPU non hanno PPE.
Anche Larrabee probabilmente avrà un arbitro complesso come il PPE.

Evidentemente quando il Cell viene usato come coprocessere, risulta più conveniente far fare il lavoro del PPE alla CPU del sistema. Per me questo vuol dire solo "spostare il PPE fuori dal chip", ma magari per te equivale a dire fare in software del lavoro che prima si faceva in hardware

la cpu del sistema è in grado di inizializzare un dma e può sostituire in tutto e per tutto il ppe che, dal punto di vosta computazionale non è certo un fulmine, però come unità centrale è piuttosto funzionale. I spe non hanno memoria interna di tipo cached e quindi non sono in grado di accedere ad indirizzi di memoria di sistema predeterminati senza che qualcuno gli indichi la strada. Le soluzioni possibili sono due: un HW dedicato, oppure si deve lasciare il compito al programmatore (con tutte le difficoltà che questo comporta). Finora si è sempre fatto ricorso ad HW dedicato (ppe o cpu esterna che dir si voglia). Ovvio che da parte di AMD (ma anche di nVidia) si cerchi di tirare acqua al proprio mulino e si insista sul discorso gpgpu (anche Mark Harris, se non ricordo male, non espresse commenti favorevoli sul cell).

Originariamente inviato da Mercuri0

Il driver è critico per il funzionamento del chip comunque: se serve conoscere alla perfezione l'architettura del chip, i programmatori del chip devono farlo. Possono anche essere gli stessi progettisti dell'hardware a programmare le parti del driver che servono, eh

infatti, gli arbiter interni a cpu o gpu sono programmati a basso livello da chi conosce alla perfezione l'architettura del chip. La programmazione degli arbiter riguarda i criteri di arbitraggio ossia i criteri con cui si sceglie a quali thread dare la priorità, o quali richieste inoltrare prima o come distribuire la circolazione dei dati all'interno del chip e tra chip e risorse esterne o,ancora, come gestire i salti condizionali, tanto per fare alcuni esempi. A questo tipo di programmazione, si aggiunge un'altra forma di ottimizzazione ad lato livello, che può avvenire via driver. Ti faccio un esempio: quando usci la serie di gpu basata su R5x0, il motore grafico di doom3 appariva poco digeribile per le gpu di casa ati (anche perchè l'engine grafico era stato progettato tenendo a mente le caratteristiche di quelle nVidia). E' bastato ottimizzare via driver alcune funzionalità dell'arbiter che gestiva il ring bus per veder andare, con quake 4 (che usa lo stesso engine grafico), R580 meglio di G7x. I dispositivi HW permettono, evidentemente, anche elevata compatibilità e non vanno visti come qualcosa di statico.

Originariamente inviato da Mercuri0

Il discorso della scelta di quali parti fare in hardware o software non è un discorso di "criticità" ma un trade-off tra prestazioni e flessibilità. Ormai nella progettazione microelettronica si tendono a vedere le due cose come "integrate". Ci sono addirittura strumenti EDA molto di alto livello che consentono di fare un progettazione integrata hardware/software per poter simulare e scegliere già a livello esplorativo quali parti implementare in hardware e quali in software. Alcuni per esempio (LISA) permettono di simulare un chip e parallelamente generano un compilatore per il software in modo da poter scegliere quali istruzioni dell'architettura conviene implementare in hardware e quali in software.

le due cose sono integrate e non da oggi. L'HW ha necessità del SW per poter funzionare e il SW ha bisogno di HW su cui girare. Quale sia la percentuale di lavoro da far fare all'HW e quale al SW dipende dall'idea che si ha su come il dispositivo debba funzionare. Anche nel campo delle gpu abbiamo due esempi di differente rapporto HW/SW. Sulla serie G80/GT200, ma anche su R500, gran parte della gestione dei thread è affidata all'HW che non solo si occupa del bilanciamneto dei carichi di lavoro ma anche dell'ottenimento della massima parallelizzazione possibile, In R600 e RV6x0, invece, l'HW si occupa del bilanciamento dei carichi di lavoro ma l'ottenimento della massima parallelizzazione è affidata al SW. Il vantaggio della soluzione nVidia o ATi (con R500) è che il chip è in grado di avere un'efficienza elevata in pressochè tutte le condizioni di impiego, senza alcun intervento dall'esterno. Il vantaggio della soluzione adottata su R6x0, invece, è costituito dall'avere a disposizione una maggior potenza di calcolo a patto che si riesca ad ottimizzare il lavoro del chip (cosa evidentemente più complessa); questo eprchè l'architettura vliw permette di avere un numero notevolmente inferiore di registri e di sprecare meno cicli di clock per operazioni diverse dalla semplice esecuzione di calcoli (in pratica meno registri e meno unità e linee di controllo e di trasmissione, quindi più transistoir da poter dedicare alle unità di calcolo).

Originariamente inviato da Mercuri0

Scusami la digressione, ma credo sia stata utile per esporre il mio punto di vista (molto più "sfumato" sul rapporto hardware/software), altrimenti era difficile andare avanti nella discussione.

sicuramente è stata utile. In realtà il tuo punto di vista non è che sia più sfumato, né il mio può considerarsi "radicale". HW e SW sono strettamente compenetrati (e non può essere altrimenti). Il fatto è che, a volte, si operano delle scelte dettate dall'idea che si ha sul funzionamento di un determinato dispositivo, che sembrano privilegiare l'uno o l'altro.

Originariamente inviato da Mercuri0

Se un architettura prevedesse un hardware di controllo per il multi-GPU "totalmente compatibile" coi giochi, questo hardware potrebbe essere simulato via driver con il solo prezzo delle prestazioni (che può essere irrilevante o può diventare critico), ma non della "compatibilità". Dal lato della "compatibilità" il software è in vantaggio sull'hardware.

ti rispondo con una domanda: perchè simulare o emulare qualcosa che posso avere? Non per il discorso compatibilità (come ti ho detto precedentemente, non devi vedere un dispositivo di controllo come un qualcosa di statico o di rigido, ma di estremamente flessibile). Le prestazioni possono essere un fattore di scelta determinante e l'HW mi garantisce prestazioni migliori. Allora perchè scegliere un'emulatore?
La risposta te l'anticipo io: per due possibili motivi: ragioni economiche (un circuito di trasmissione e controllo su un'architettura complessa è sempre complesso da implementare); per ragioni di spazio (preferisco demandare al SW alcune operazioni per lasciare spazio ad HW che mi faccia altro.

[yossarian]

Originariamente inviato da Immortal

i 900mhz sono da moltiplicare per 4. Leoneazzurro aveva spiegato che le gddr5 non sono normali ddr ma qdr
Quindi la banda effettiva sarà doppia rispetto a quella indicata!

lo so come funzionano le gdd5 (è il programma che si vede che non lo sa)

In realtà, nelle gddr5 il clock interno è 16 volte quello esterno; in pratica, con le ddr2 si prendeve la frequenza della ram e si moltiplicava per 2, con le gddr5 la moltiplichi per 16 (e ovviamente la frequenza non è di 900 MHz); ipotesi: gddr5 da 3600 MHz di frequenza di trasferimento dati, lavorano a 225 MHz di frequenza di core

[Bhairava]

yossarian avrei una domanda da porti.
Un utente del forum ha testato le prestazioni della 4850 in presenza di aa, sul gioco Crysis.

Originariamente inviato da Tenebra

Ok, ecco i risultati, per molti versi sbalorditivi.
Ho messo Performance nei Catalyst, anisotropico "secondo l'applicazione" (cioè zero) e antialiasing idem.
Ricordo la mia configurazione: 4 giga di DDR2, Abit IP 35 Pro, Core Duo 8400 @ 3,6 giga (400x9)

Settaggio dal bench: tutto su HIGH

1280x1024 no aa no af: 46,265
1280x1024 aa2x no af 34,795
1280x1024 aa4x no af 33,715
1280x1024 aa8x no af 34,87
1280x1024 aa16x no af 34,855

1600x1200 aa8x no af 25,28
1600x1200 aa16x no af 25,28

Conclusioni sommarie: l'antialiasing a questa scheda gli fa una pippa, evidentemente. La differenza tra il metterlo e non metterlo c'è, ma tra le varie gradazioni non vedo sbalzi...

So che non puoi rivelare ancora l'architettura della gpu, ma puoi dirci se questi test sono possibili? La 4850 riesce ad essere così efficiente con aa16x? O, più probabilmente, i driver ancora immaturi non applicano un aa superiore a 4x?

io dico che non si attivano ne l'aa8x e ne il 16x... perchè anche se la scheda è prestante con i filtri, un MINIMO di impatto di prestazioni dovrebbe cmq avercelo..


però sentiamo cosa dice yossarian

[me3850]

3Dmark06, Crysis benchmarks of 4870 kills 9800GX2 too

System
* Intel Core 2 Extreme QX9650 @ 3.00GHz
* ASUS P5E3 Deluxe
* 2×1GB OCZ DDR3 1333MHz 9-9-9-26
* Western Digital 250GB 16MB SATA2 7200RPM
* 1GB GeForce 9800 GX2 - 600/1500/2000mhz
* 512MB ATI HD 4870 - 800/3400mhz

[_morghan_1968]

Originariamente inviato da me3850

3Dmark06, Crysis benchmarks of 4870 kills 9800GX2 too

System
* Intel Core 2 Extreme QX9650 @ 3.00GHz
* ASUS P5E3 Deluxe
* 2×1GB OCZ DDR3 1333MHz 9-9-9-26
* Western Digital 250GB 16MB SATA2 7200RPM
* 1GB GeForce 9800 GX2 - 600/1500/2000mhz
* 512MB ATI HD 4870 - 800/3400mhz

FONTE ???

ma sti bench non erano old e fake?? mi sembra che eran già stati postati una 50ina di pagine fa...

[yossarian]

Originariamente inviato da Bhairava

yossarian avrei una domanda da porti.
Un utente del forum ha testato le prestazioni della 4850 in presenza di aa, sul gioco Crysis.



So che non puoi rivelare ancora l'architettura della gpu, ma puoi dirci se questi test sono possibili? La 4850 riesce ad essere così efficiente con aa16x? O, più probabilmente, i driver ancora immaturi non applicano un aa superiore a 4x?

la gestione dell'AA è decisamente migliorata rispetto a quella di RV6x0; però quei risultati non mi sembrano verosimili. Tieni conto che i driver sono, a dir poco, immaturi e la gestione dell'AA e dei filtri in generale è una delle cose che vanno ancora messe a punto

[Errik89]

Originariamente inviato da yossarian

la gestione dell'AA è decisamente migliorata rispetto a quella di RV6x0; però quei risultati non mi sembrano verosimili. Tieni conto che i driver sono, a dir poco, immaturi e la gestione dell'AA e dei filtri in generale è una delle cose che vanno ancora messe a punto

secondo me hai perfettamente ragione, i driver secondo me scalano fino all'8x se non addirittura solo fino al 4x.