[THREAD UFFICIALE] Aspettando R700

[HackaB321]

Originariamente inviato da yossarian

Vero, le rese produttive caleranno di sicuro, ma c'è da tener conto della maggior semplicità di progettazione di un'architettura multicore rispetto ad una monolitica. Ovviamente anche il numero di core non può essere illimitato (a causa delle difficoltà di trovare un bus capace di farli dialogare senza introdurre latenze apprezzabili rispetto ad un unico core). Diciamo che le strade percorribili sono due: più chip sulla stessa scheda o nello stesso package (scelta economica sia per la progettazione che per la realizzazione); più chip sullo stesso die (scelta economica per la progettazione, meno per la realizzazione, con il vantaggio di poter ottimizzare le interconnesioni tra chip e la gestione dei carichi di lavoro più facilmente)

Più chip sullo stesso die secondo te potrebbe facilitare anche la scrittura dei driver?

E' realistica e conveniente un'ipotesi in cui non siano i driver (tramite l'AFR o altro) a ripartire il carico ma sia invece un dispositivo hardware a ripartire il carico tra i vari core (come avviene nelle gpu single-core attualmente con il dispatch processor che "smista" il lavoro tra i vari cluster)?

[LCol84]

Originariamente inviato da HackaB321

Più chip sullo stesso die secondo te potrebbe facilitare anche la scrittura dei driver?

E' realistica e conveniente un'ipotesi in cui non siano i driver (tramite l'AFR o altro) a ripartire il carico ma sia invece un dispositivo hardware a ripartire il carico tra i vari core (come avviene nelle gpu single-core attualmente con il dispatch processor che "smista" il lavoro tra i vari cluster)?

Ma non e quello che gia fa il chip PLX della x2?

[Mercuri0]

Originariamente inviato da LCol84

Ma non e quello che gia fa il chip PLX della x2?

Credo che il chip PLX serva solo al processore (o al driver se preferisci) a "vedere" ciascuna delle due GPU montate sullo stesso slot pci-express.

Erroneamente la gente pensa che quel chip serva per far comunicare tra loro le due GPU, o a ripartire non so ché.

In realtà quel chip è solo una "presa multipla" per slot pci express.

[LCol84]

Originariamente inviato da Mercuri0

Credo che il chip PLX serva solo al processore (o al driver se preferisci) a "vedere" ciascuna delle due GPU montate sullo stesso slot pci-express.

Erroneamente la gente pensa che quel chip serva per far comunicare tra loro le due GPU, o a ripartire non so ché.

In realtà quel chip è solo una "presa multipla" per slot pci express.

Chiarissimo

[yossarian]

Originariamente inviato da HackaB321

Più chip sullo stesso die secondo te potrebbe facilitare anche la scrittura dei driver?

E' realistica e conveniente un'ipotesi in cui non siano i driver (tramite l'AFR o altro) a ripartire il carico ma sia invece un dispositivo hardware a ripartire il carico tra i vari core (come avviene nelle gpu single-core attualmente con il dispatch processor che "smista" il lavoro tra i vari cluster)?

a ripartire i carichi di lavoro deve essere un dispositivo HW, possibilmente programmabile a basso livello. In un'architettura ibrida in parte di tipo vliw (come R6x0), è affidato al compilatore l'ottenimento del massimo parallelismo (questo è il motivo principale della non elevata efficienza di R6x0 e della sua elevata complessità di ottimizzazione) ma non il bilanciamento dei carichi di lavoro tra i gruppi di unità di calcolo. Discorso analogo vale per architetture multicore: deve esserci un arbiter "fisico" che si occupa di gestire il traffico di dati e richieste di accesso agli stessi da parte dei vari core, rispettando determinate priorità relative alle tipologie di calcoli o di dati richiesti. A svolgere questo compito può essere anche uno dei core di cui è composto il processore (che in quel caso ha integrate le funzionalità di arbiter)

[Marck]

Originariamente inviato da Errik89

le temp in effetti sono alte, ne abbiamo già discusso sul thread ufficiale e siamo giunti alla conclusione che c'è qualcosa che non va nei driver che non supportano ancora il powerplay...

Non capisco perchè si paragonano schede con dissipatori diversi....la 4850 monta un dissy che occupa un solo slot..mentre le altre 2 sono doppio slot..tanto vale allora mettere anche schede a liquido..se si vogliono fare paragoni bisogna mettere il dissy della 9800gtx sulla 4850 oppure fare il contrario..mettere il dissy della 4850 sulla 9800gtx..

edit: sbagliato grafico...va be lo lascio..può tornare utile a qualcuno

[michelgaetano]

Originariamente inviato da Marck

Non capisco perchè si paragonano schede con dissipatori diversi....la 4850 monta un dissy che occupa un solo slot..mentre le altre 2 sono doppio slot..tanto vale allora mettere anche schede a liquido..se si vogliono fare paragoni bisogna mettere il dissy della 9800gtx sulla 4850 oppure fare il contrario..mettere il dissy della 4850 sulla 9800gtx..

Non penso sia giusto così...parliamo di dissi stock, che sono forniti con la scheda ^^"

Certo sarebbe più gisuto metterle entrambe a confronto con dissi dual, ma uscirà, è solo questione di tempo

[gianni1879]

Originariamente inviato da Bhairava

Per vedere il funzionamento del Powerplay apri il file profile.xml di di Catalyst, ci dovrebbe essere un gruppo "Overdrive 5" in cui sono descritti gli State.
Come ho già ripetuto varie volte, non credo che siano i driver a causare alte temperature, ma la scarsa rotazione della ventola.

in full di sicuro se la ventola gira piano ovvio che scaldi parecchio (la ventola si controlla da bios), ma si discuteva dello stato idle, dove sembra che i voltaggi non scendano, dovrebbe essere una prerogativa dei driver no?

era successo una cosa molto simile con R600 che dopo qualche release di driver ci si è accorti che in idle scaldava molto meno

[Free Gordon]

Originariamente inviato da yossarian

proporre la stessa architettura, con lo stesso processo produttivo e le stesse frequenze ma un nome diverso non ha molto senso

Ti riferisci MICA per caso a 8800GTS e 9800GTX?


Una domanda spassionata (se puoi rispondere ):
secondo te avrà più senso la 4870 con 1GB o quella con 512MB?
La versione con 1GB, potrebbe avere latenze maggiori nell'accesso alla ram e per cui un pò di performance in meno, a parità di ram consumata?
Oppure no?

Grazie

[LCol84]

Raga ma una ipotetica 4850 con stessa gpu e con le ddr5 dovrebbe consumare meno rispetto a quella con ddr3 no?

[michelgaetano]

Originariamente inviato da LCol84

Raga ma una ipotetica 4850 con stessa gpu e con le ddr5 dovrebbe consumare meno rispetto a quella con ddr3 no?

quanto una 4870 downclockata, un pelo di meno per le gddr 5

[yossarian]

Originariamente inviato da Free Gordon

Ti riferisci MICA per caso a 8800GTS e 9800GTX?


Una domanda spassionata (se puoi rispondere ):
secondo te avrà più senso la 4870 con 1GB o quella con 512MB?
La versione con 1GB, potrebbe avere latenze maggiori nell'accesso alla ram e per cui un pò di performance in meno, a parità di ram consumata?
Oppure no?

Grazie

quando un controller è preposto a gestire più chip di ram, le latenze sono sempre leggermente superiori; per questo la soluzione dei 4 controller è migliore di quella a controller unico con, magari, un bus a 512 bit

[Free Gordon]

Originariamente inviato da yossarian

quando un controller è preposto a gestire più chip di ram, le latenze sono sempre leggermente superiori; per questo la soluzione dei 4 controller è migliore di quella a controller unico con, magari, un bus a 512 bit

Per cui mi stai dicendo che, con i 4MC di Rv770, il divario di prestazioni tra lo sku 512 e quello 1GB, a parità di ram consumata, dovrebbe ridursi MOLTO?

[yossarian]

Originariamente inviato da Free Gordon

Per cui mi stai dicendo che, con i 4MC di Rv770, il divario di prestazioni tra lo sku 512 e quello 1GB, a parità di ram consumata, dovrebbe ridursi MOLTO?

diciamo che la differenza tra le latenze è molto inferiore a quella che si avrebbe con un unico controller

[Mercuri0]

Originariamente inviato da michelgaetano

Non penso sia giusto così...parliamo di dissi stock, che sono forniti con la scheda ^^"

Certo sarebbe più gisuto metterle entrambe a confronto con dissi dual, ma uscirà, è solo questione di tempo

La caciara è che si sta facendo confusione coi grafici, e il lettore "disattendo" può confondere temperature (cioè dissipatore e velocità della ventola) con consumi (quanto scalda)

Originariamente inviato da LCol84

Raga ma una ipotetica 4850 con stessa gpu e con le ddr5 dovrebbe consumare meno rispetto a quella con ddr3 no?

Non ci saranno 4850 con GDDR5. Al massimo si può vedere come va una 4870 downcloccata.

I consumi in full della 4850 sono comunque in linea con le attese. Sui grafici non si vedono bene, perché i grafici mostrano i consumi dell'intero sistema in full, e quindi i contributi dovuti alla sola scheda grafica si "appiattiscono".

In idle, se è vero che il voltaggio ancora non viene regolato, ci sono margini di miglioramento via driver.

Il discorso delle temperature dipende invece dal dissipatore. Per ora non sappiamo se le alte temperature sono una scelta (il chip le tollera) o un errore (errore di velocità delle ventole).

Può darsi che quelle in idle si abbasseranno quando verrà regolato il voltaggio.

[HackaB321]

Originariamente inviato da yossarian

a ripartire i carichi di lavoro deve essere un dispositivo HW, possibilmente programmabile a basso livello. In un'architettura ibrida in parte di tipo vliw (come R6x0), è affidato al compilatore l'ottenimento del massimo parallelismo (questo è il motivo principale della non elevata efficienza di R6x0 e della sua elevata complessità di ottimizzazione) ma non il bilanciamento dei carichi di lavoro tra i gruppi di unità di calcolo. Discorso analogo vale per architetture multicore: deve esserci un arbiter "fisico" che si occupa di gestire il traffico di dati e richieste di accesso agli stessi da parte dei vari core, rispettando determinate priorità relative alle tipologie di calcoli o di dati richiesti. A svolgere questo compito può essere anche uno dei core di cui è composto il processore (che in quel caso ha integrate le funzionalità di arbiter)

Però attualmente nel multigpu di tipo crossfire o sli non è così: non esiste un dispositivo che ripartisca il lavoro tra le gpu, sono i driver che a livello di frame (e non di thread come farebbe un dispatch processor) ripartiscono il carico tra le varie gpu. Questo comporta inevitabili ottimizzazioni gioco per gioco per ottenere un'equa ripartizione, visto che la complessità di ogni frame varia in base al gioco e in base alla scena.
A quanto ho capito ,se si passasse ad un modello multicore integrato in un die questo modello andrebbe abbandonato e si dovrebbe passare ad una ripartizione via hardware. Si avrebbe quindi un dispatch processor che ripartisce i thread tra i vari core e, internamente ad ognuno di questi, la ripartizione avverrebbe come nelle gpu single core attuali con i vari arbeiter e sequencer che inoltrano i gruppi di thread ai vari cluster.
E' corretto?

[Mercuri0]

Originariamente inviato da Free Gordon

Per cui mi stai dicendo che, con i 4MC di Rv770, il divario di prestazioni tra lo sku 512 e quello 1GB, a parità di ram consumata, dovrebbe ridursi MOLTO?

Originariamente inviato da yossarian

diciamo che la differenza tra le latenze è molto inferiore a quella che si avrebbe con un unico controller

In questo discorso la modalità clamshell delle GDDR5 ci azzecca qualcosa??

[yossarian]

Originariamente inviato da HackaB321

Però attualmente nel multigpu di tipo crossfire o sli non è così: non esiste un dispositivo che ripartisca il lavoro tra le gpu, sono i driver che a livello di frame (e non di thread come farebbe un dispatch processor) ripartiscono il carico tra le varie gpu. Questo comporta inevitabili ottimizzazioni gioco per gioco per ottenere un'equa ripartizione, visto che la complessità di ogni frame varia in base al gioco e in base alla scena.
A quanto ho capito ,se si passasse ad un modello multicore integrato in un die questo modello andrebbe abbandonato e si dovrebbe passare ad una ripartizione via hardware. Si avrebbe quindi un dispatch processor che ripartisce i thread tra i vari core e, internamente ad ognuno di questi, la ripartizione avverrebbe come nelle gpu single core attuali con i vari arbeiter e sequencer che inoltrano i gruppi di thread ai vari cluster.
E' corretto?

si, e ovviamente anche questi arbiter possono essere programmati e, quindi, ottimizzati. In questo caso, l'ottimizzazione, più che gioco per gioco, andrebbe fatta in base alla tipologia di rendering che il motore grafico di quel gioco supporta (anche se non si può escluderer un'ottimizzazione sul tipo dell'attuale). Il vantaggio di avere un controller HW è che non si deve aspettare la release di driver ottimizzata per veder andare bene quel particolare gioco; i driver, semmai, possono servire per effetture una sorta di lavoro di rifinitura

[HackaB321]

Originariamente inviato da yossarian

si, e ovviamente anche questi arbiter possono essere programmati e, quindi, ottimizzati. In questo caso, l'ottimizzazione, più che gioco per gioco, andrebbe fatta in base alla tipologia di rendering che il motore grafico di quel gioco supporta (anche se non si può escluderer un'ottimizzazione sul tipo dell'attuale). Il vantaggio di avere un controller HW è che non si deve aspettare la release di driver ottimizzata per veder andare bene quel particolare gioco; i driver, semmai, possono servire per effetture una sorta di lavoro di rifinitura

Sarebbe un vantaggio non da poco. A quel punto un'ottimizzazione driver per una scheda multi core non sarebbe molto più complessa di quella per una scheda single core. Possibilità di vedere tutto questo già con R700?

[yossarian]

Originariamente inviato da Mercuri0

In questo discorso la modalità clamshell delle GDDR5 ci azzecca qualcosa??

si, nel senso che sicuramente beneficia della migliore gestione degli accessi alla ram di sistema in particolare e a risorse esterne in generale (tra cui può essre annoverata anche una seconda gpu) da parte delle unità di calcolo interne di ciascuna gpu