[THREAD UFFICIALE] ATI Radeon X1800XT/XL

[T3d]

Originariamente inviato da yossarian

ottimizzazioni del genere, magari non sempre con incrementi di quella portata, nei prossimi mesi saranno abbastanza frequenti anche per altri titoli.
Non si deve dimenticare che i controller di R520 sono ottimizzabili via drivewr, anche in maniera mirata alla singola applicazione.

scusate se lo dico, ma questa è una cosa fantastica

[Eddie666]

Originariamente inviato da yossarian

ottimizzazioni del genere, magari non sempre con incrementi di quella portata, nei prossimi mesi saranno abbastanza frequenti anche per altri titoli.
Non si deve dimenticare che i controller di R520 sono ottimizzabili via drivewr, anche in maniera mirata alla singola applicazione.

quindi,correggimi se dico male,la' dove non arriveranno i programmatori di videogiochi,vincolati a non poter ottimizzare piu' di tanto i loro motori grafici in virtu' della gran omogeneita' di pc su cui dovranno girare,saranno invece gli sviluppatori di driver a poter effettuare ulteriori aggiustamenti "di fino' per le singole applicazioni 3d? probabilmente mi sono espresso malissimo .ma spero che tu abbia capito lo stesso il succo del discorso!
cmq se cosi' fosse sarebbe un ulteriore garanzia di longevita' della scheda stessa....
ciao

[yossarian]

a pensarci bene, secondo me l'R520 è il tuo chip ideale. Pensa alla possibilità di programmarlo via driver, ottimizzandolo per Linux e OpenGL

[shodan]

Originariamente inviato da yossarian

ottimizzazioni del genere, magari non sempre con incrementi di quella portata, nei prossimi mesi saranno abbastanza frequenti anche per altri titoli.
Non si deve dimenticare che i controller di R520 sono ottimizzabili via drivewr, anche in maniera mirata alla singola applicazione.

Ciao yossarian,
volevo farti una domanda in merito al grado di programmazione di questo controller di memoria rispetto a quelli crossbar classici (dal GF3 in poi se non vado errato).
I vecchi controller non erano affatto programmabili/ottimizzabili via driver (e quindi queste caratteristiche sarebbero prerogative di R520) oppure anche i controller precedenti avevano certe capacità di programmazione?

Ciao grazie.

[yossarian]

Originariamente inviato da Eddie666

quindi,correggimi se dico male,la' dove non arriveranno i programmatori di videogiochi,vincolati a non poter ottimizzare piu' di tanto i loro motori grafici in virtu' della gran omogeneita' di pc su cui dovranno girare,saranno invece gli sviluppatori di driver a poter effettuare ulteriori aggiustamenti "di fino' per le singole applicazioni 3d? probabilmente mi sono espresso malissimo .ma spero che tu abbia capito lo stesso il succo del discorso!
cmq se cosi' fosse sarebbe un ulteriore garanzia di longevita' della scheda stessa....
ciao

si; oddio, c'è sempre da tener presenti i limiti HW; ad esempio non posso pensare di programmare thread più lunghi di x istruzioni o un numero superiore di thread a parità di istruzioni (in entrambi i casi per mancanza di spazio nei registri interni). Però posso ottimizzare il flusso di dati e il tipo di elaborazione in base alle caratteristiche del motore grafico, in maniera molto più pesante di quanto non sia possibile con glin attuali chip. Oltre a poter lavorare sul riordino delle istruzioni, cosa già possibile adesso, sarà anche possibile cambiare la priorità di esecuzione delle istruzioni stesse, in modo tale da impedire che alcune elaborazioni facciano da collo di bottiglia alle prestazioni complessive.

[yossarian]

Originariamente inviato da shodan

Ciao yossarian,
volevo farti una domanda in merito al grado di programmazione di questo controller di memoria rispetto a quelli crossbar classici (dal GF3 in poi se non vado errato).
I vecchi controller non erano affatto programmabili/ottimizzabili via driver (e quindi queste caratteristiche sarebbero prerogative di R520) oppure anche i controller precedenti avevano certe capacità di programmazione?

Ciao grazie.

in R520 non è programmabile il solo controller della memoria (anzi, questa è una caratteristica secondaria); il controller programmabile è il dispatch processor, ossia quello principale. Comunque i normali controller di un'architettura crossbar non sono programmabili, se non al più basso livello (non attraverso i drivers)

[Eddie666]

Originariamente inviato da yossarian

si; oddio, c'è sempre da tener presenti i limiti HW; ad esempio non posso pensare di programmare thread più lunghi di x istruzioni o un numero superiore di thread a parità di istruzioni (in entrambi i casi per mancanza di spazio nei registri interni). Però posso ottimizzare il flusso di dati e il tipo di elaborazione in base alle caratteristiche del motore grafico, in maniera molto più pesante di quanto non sia possibile con glin attuali chip. Oltre a poter lavorare sul riordino delle istruzioni, cosa già possibile adesso, sarà anche possibile cambiare la priorità di esecuzione delle istruzioni stesse, in modo tale da impedire che alcune elaborazioni facciano da collo di bottiglia alle prestazioni complessive.

ok,piu' o meno ho capito:ottimizzazioni nei limiti della capacita' hardware della scheda stessa.....beh,un'ottima cosa direi.....mi piace l'ottimizzazione!
denghiu

[shodan]

Originariamente inviato da yossarian

in R520 non è programmabile il solo controller della memoria (anzi, questa è una caratteristica secondaria); il controller programmabile è il dispatch processor, ossia quello principale.

Come pensavo...

Comunque i normali controller di un'architettura crossbar non sono programmabili, se non al più basso livello (non attraverso i drivers)

Mmm... ricordo che all'epoca dei Detonator XP molti dissero che le GF3 beneficiarono di un bel balzo di prestazioni grazie a ottimizzazioni del memory controller di NV20. Quindi sostanzialmente questa motivazione è errata, in quanto il suo controller di memoria era programmabile solo tramite modifiche hardware e non software... oppure forse con questa frase si voleva/poteva intendere qualcos'altro (che però mi sfugge... ).

Ciao.

[yossarian]

Originariamente inviato da shodan

Come pensavo...

Mmm... ricordo che all'epoca dei Detonator XP molti dissero che le GF3 beneficiarono di un bel balzo di prestazioni grazie a ottimizzazioni del memory controller di NV20. Quindi sostanzialmente questa motivazione è errata, in quanto il suo controller di memoria era programmabile solo tramite modifiche hardware e non software... oppure forse con questa frase si voleva/poteva intendere qualcos'altro (che però mi sfugge... ).

Ciao.

non lo ricordo, però, molto probabilmente, era relativa allo sfruttamento di un'architettura di tipo crossbar rispetto ad una a canale unico tradizionale. NV20 è stato il chip con cui si è introdotta l'architettura crossbar che, rispetto a quella a canale unico, costituiva un notevole passo avanti in fatto di velocità di accesso alla ram.

[shodan]

Originariamente inviato da yossarian

non lo ricordo, però, molto probabilmente, era relativa allo sfruttamento di un'architettura di tipo crossbar rispetto ad una a canale unico tradizionale. NV20 è stato il chip con cui si è introdotta l'architettura crossbar che, rispetto a quella a canale unico, costituiva un notevole passo avanti in fatto di velocità di accesso alla ram.

Quindi gli incrementi sono stati avuti non perchè si è riprogrammato il memory controller, ma perchè i driver hanno adeguato il numero / l'ordine degli accessi alla RAM in modo da rendere il carico ottimale per un controller di tipo crossbar.
Spero di aver capito bene...

Ciao.

[JENA PLISSKEN]

Originariamente inviato da shodan

Quindi gli incrementi sono stati avuti non perchè si è riprogrammato il memory controller, ma perchè i driver hanno adeguato il numero / l'ordine degli accessi alla RAM in modo da rendere il carico ottimale per un controller di tipo crossbar.
Spero di aver capito bene...

Ciao.

erano i mitici detonator 23.11 ...me li ricordo...eccome

[ale30]

Ma è vero che le x1800 sono compatibili solo con Win XP?

[shodan]

Originariamente inviato da JENA PLISSKEN

erano i mitici detonator 23.11 ...me li ricordo...eccome

Io pure... assieme al Via Gart 4.10B, mi garantirono un salto da 2700 a 3000 punti nel 3dmark2001 (con cpu celeron 1000@1250 e geforce 256 DDR).
Che bei tempi...

[andreamarra]

Originariamente inviato da Psiche

Pare che con i prossimi Catalyst 5.11 (primo set di driver ufficiali che supporterà le X1000 ) Ati intrtodurra una funzionel che, con filtri attivi, aumenterà le prestazioni di un buon 35% in Doom3:




http://www.hexus.net/content/item.php?item=3668

molto interessante !

sarebbe bello che adesso, a ogni release mensile, si riuscisse a inserire in base ai giochi dei fix che, una volta partito il gioco, indicano alla scheda dei percorsi semplificati o scorciatoie per renderizzare in minor tempo una scena.

Pare che lo faranno, a quanto ho capito.

Se non sbaglio, correggimi yossy , basterebbe indicare al controller che in presenza di un tale gioco che sfrutta molto un determinato tipo di calcolo, delle priorità o altro per snellire le operazioni. In modo da avere dei vantaggi prestazionali soddisfacenti.

corretto ?

[andreamarra]

Originariamente inviato da T3d

pazzesco!
ma quando usciranno?

che domande... tra un mese !


si spera con la XT...

[JENA PLISSKEN]

Originariamente inviato da shodan

Io pure... assieme al Via Gart 4.10B, mi garantirono un salto da 2700 a 3000 punti nel 3dmark2001 (con cpu celeron 1000@1250 e geforce 256 DDR).
Che bei tempi...

stra...asd...il via gart...me ne ero quasi dimenticato....ringrazio cmq NV x aver inventato l' Nforce

[andreamarra]

Originariamente inviato da Vifani

Confermo quel fix per Doom 3. Ho ricevuto anche io un programmino per abilitarlo da subito.

ciao, ma lo avete utilizzato nei vostri bench con DooM3 questo fix?

[JENA PLISSKEN]

Originariamente inviato da andreamarra

molto interessante !

sarebbe bello che adesso, a ogni release mensile, si riuscisse a inserire in base ai giochi dei fix che, una volta partito il gioco, indicano alla scheda dei percorsi semplificati o scorciatoie per renderizzare in minor tempo una scena.

Pare che lo faranno, a quanto ho capito.

Se non sbaglio, correggimi yossy , basterebbe indicare al controller che in presenza di un tale gioco che sfrutta molto un determinato tipo di calcolo, delle priorità o altro per snellire le operazioni. In modo da avere dei vantaggi prestazionali soddisfacenti.

corretto ?

Così pare...sperando senza orribili ottimizzazioni...tipo la mitica storia di QUAK al posto di Quake

[andreamarra]

Originariamente inviato da T3d

ma si può sapere se sia una ottimizzazione che non va ad intaccare la qualità dell'immagine? nel senso, non c'è il pericolo di qualcosa di poco "corretto"? speriamo di no eh

non credo proprio che si tratterà di intaccare la qualità video (e a qualcuno neanche importerebbe, in fondo se non è importante l'aniso con tutte le angolazioni... ), quanto di dare al controller probabilmente delle priorità o dei "suggerimenti" in modo da evitare calcoli ridondanti e inutili o robe del genere.

in modo da avere in meno tempo più potenza di calcolo disponibile.

Ovviamente ogni release mensile potrà apportare miglioramenti al controller per i vari giochi.

da verificare se verrà fatta sta cosa per i titoli più importanti o quelli in cui ci sono defaillance, e se il vantaggio prestazionale si attesterà su valori sensibili e non minimi.

[andreamarra]

Originariamente inviato da JENA PLISSKEN

Così pare...sperando senza orribili ottimizzazioni...tipo la mitica storia di QUAK al posto di Quake

LOL... Quak...

mi ricordo le prime volte che seguivo il forum delle risate a leggere chi sio scannava con frasi del tipo "scusa, ma il draghetto dov'è ??" " ma tu pensa a quak va..."





in ogni caso non dovrebbero essere ottimizzazioni volte a peggiorare la qualità grafica, quanto un modo per dare delle "dritte" alla scheda video in modo da gestire al meglio un determinato tipo di ombra (ad esempio) o un determinato tipo di effetto.

Qua ci vorrebbe yossarian e fek per fare esempi, magari sto scrivendo puttanate