View Full Version : Nvidia si è impantanata?
Riguardo a drivers....non rilascia più una versione ufficiale da quanto?Due mesi?
Va bene che non ho problemi con nessun gioco,però avere una relase al mese che mi faccia guadagnare qualche frames nei giochi
e aggiunga qualche novità come ai vecchi tempi non mi farebbe schifo.
Mi ricordo che Nvidia stessa annunciò che avrebbe allentato i ritmi
nel mercato delle sk grafiche 3d,forse si riferiva proprio a questo.
Credo però che semplicemente il sistema dei drivers unificati (inventato da lei se non sbaglio) si stia rivelando un'arma a doppio taglio e che far andare daccordo una Vanta quanto una Nv 40 si stia rivelando alla lunga difficile....se poi ci mettiamo in mezzo anche l'architettura FX che ha bisogno di parecchi accorgimenti nei drivers per non crollare prestazionalmente nei giochi,abbiamo il quadro completo.
Magari mi sbaglio,però un pò mi sono stufato di fare da betatester.
Voglio dei drivers nuovi e prestazionali!:mad:
Alberto Falchi
02-11-2004, 16:42
Oddio... gli aggiornamenti dovrebbero essere fatti quando serve. Se non ne fanno in continuazione, i casi sono due: prodotto "abbandonato" o driver abbastanza maturi. E mi sembra che non ci si possa lamentare degli ultimi ForceWare... insomma... meglio così che updatare ogni mese, non credi?
Pape
TheDarkAngel
02-11-2004, 16:48
basta che eliminasse le fx dai driver... tanto peggio di così non fanno :asd:
Originariamente inviato da GMCPape
Oddio... gli aggiornamenti dovrebbero essere fatti quando serve. Se non ne fanno in continuazione, i casi sono due: prodotto "abbandonato" o driver abbastanza maturi. E mi sembra che non ci si possa lamentare degli ultimi ForceWare... insomma... meglio così che updatare ogni mese, non credi?
Pape
No,non del tutto....ho detto che non ho nessun problema,però guadagnare qualcosa in prestazioni non fa mai male,Nvidia ci ha abituato ad avere relase mensili che ogni volta guadagnano qualcosina,il suo fiore all'occhiello.
Non dimenticare poi che c'è Nv40 che può solo gioviarne da dei drivers aggiornati e migliorati,non credo che come architettura abbia già dato tutto,sarebbe la prima volta che accade in così poco tempo che dei drivers sfruttano tutto il potenziale di un'architettura così nuova.
Alberto Falchi
02-11-2004, 16:55
Originariamente inviato da R@nda
No,non del tutto....ho detto che non ho nessun problema,però guadagnare qualcosa in prestazioni non fa mai male,Nvidia ci ha abituato ad avere relase mensili che ogni volta guadagnano qualcosina,il suo fiore all'occhiello.
Non dimenticare poi che c'è Nv40 che può solo gioviarne da dei drivers aggiornati e migliorati,non credo che come architettura abbia già dato tutto,sarebbe la prima volta che accade in così poco tempo che dei drivers sfruttano tutto il potenziale di un'architettura così nuova.
Beh, trovami un titolo che ha problemi di fluidità su NV40 ^_^. Alla fine, se devono migliorare solo per far lavorare il reparto marketing.. tanto vale che non facciano le release, IMHO
Pape
Originariamente inviato da GMCPape
Beh, trovami un titolo che ha problemi di fluidità su NV40 ^_^. Alla fine, se devono migliorare solo per far lavorare il reparto marketing.. tanto vale che non facciano le release, IMHO
Pape
ATi ha tutt'altra idea, e io la condivido pienamente
bYeZ!
Alberto Falchi
02-11-2004, 17:20
Originariamente inviato da ATi7500
ATi ha tutt'altra idea, e io la condivido pienamente
Beh... potrei anche dire che ATI deve esercitarsi ancora a lungo, prima di essere all'altezza di nVidia per quanto riguarda i driver (nel campo del 3D, per lo meno) :-P
Pape
Originariamente inviato da GMCPape
Beh... potrei anche dire che ATI deve esercitarsi ancora a lungo, prima di essere all'altezza di nVidia per quanto riguarda i driver (nel campo del 3D, per lo meno) :-P
Pape
Ciao:)
ATi non dovrebbe esercitarsi più per l'OpenGL?;)
Secondo me le release mensili di drivers sono inutili,perché da quello che ho potuto constatare apportano poche migliorie prestazionali nei giochi.............IMHO,dovrebbero essere rilasciati meno frequentemente così da dare tempo di inserire + cose.:)
Alberto Falchi
02-11-2004, 17:33
Originariamente inviato da DNA_RNA
Ciao:)
ATi non dovrebbe esercitarsi più per l'OpenGL?;)
Secondo me le release mensili di drivers sono inutili,perché da quello che ho potuto constatare apportano poche migliorie prestazionali nei giochi.............IMHO,dovrebbero essere rilasciati meno frequentemente così da dare tempo di inserire + cose.:)
Secondo me devono essere rilasciati quando servono. C'è un bug con un titolo? OK, fatene di nuovi. Aumentate le prestazioni in XXX di 1 FPS quando giocate a 1152x876 con AA6X e AF 16X? tenete le modifiche e implementatele quando ci saranno cose pià interessanti da aggiungere ^_^
Pape
Originariamente inviato da GMCPape
Secondo me devono essere rilasciati quando servono. C'è un bug con un titolo? OK, fatene di nuovi. Aumentate le prestazioni in XXX di 1 FPS quando giocate a 1152x876 con AA6X e AF 16X? tenete le modifiche e implementatele quando ci saranno cose pià interessanti da aggiungere ^_^
Pape
Ti do pienamente ragione.:)
Ultimamente sembra di assistere ad una concorrenza spietata anche in campo dei drivers tra Nvidia e ATI.
Non so se sei d'accordo con questo.
Nonostante tutto,mi sembra che Nvidia sia leggermente svantaggiata dall'archittetura nuova, dato che qualche scatto improvviso dovuta ai drivers ancora imperfetti si nota.
Alberto Falchi
02-11-2004, 17:41
Originariamente inviato da DNA_RNA
Ti do pienamente ragione.:)
Ultimamente sembra di assistere ad una concorrenza spietata anche in campo dei drivers tra Nvidia e ATI.
Non so se sei d'accordo con questo.
Si, assolutamente. Del resto i driver sono davvero fondamentali per spremere al meglio l'architettura, e gli utenti lo sanno (quelli sgamati, per lo meno). E, considerando che entrambe le architetture sono molto buone, un software che permette di gestire le GPU in maniera veloce ed efficiente, oltre che spingendo al limite la scheda, è positivissimo. E, nonostante qualche problema di ATI nei driver, devo ammettere di aver apprezzato parecchio AI: una funziona che permette con un click di migliorare le prestazioni diminuendo solo marginalmente la qualità dell'immagine.
Nonostante tutto,mi sembra che Nvidia sia leggermente svantaggiata dall'archittetura nuova, dato che qualche scatto improvviso dovuta ai drivers ancora imperfetti si nota.
Mah... non ho notato particolari problemi con le 6800 nei giochi. Anzi...
Pape
Dark Schneider
02-11-2004, 17:44
In effetti dal punto di vista del rilascio drivers è peggiorata.
Mi ricordo ad aprile i 56.xx...poi a fine luglio i 61.77.....adesso sono passati altri 3 mesi ed ancora non si vede manco un drivers ufficiale nuovo.
Oddio non è che alla fine è vitale, però quando avevo la 4200 anche gli ufficiali uscivano con maggior frequenza ricordo. :(
Alla fin fine posso anche installare drivers ogni 3-4 mesi per la mia 6800 GT. Poco mi frega. Tanto non danno mai problemi con giochi e applicazioni.
Però è anche vero che mi sembra proprio brutto vedere che ci son prodotti come la 6600 e la 6200 che NON sono supportati ufficialmente. Ed il bello che fino a Luglio non era supportata la 6800 ufficialmente...e stava sui negozi da almeno un mese e mezzo prima. Io ho comprato a Giugno la 6800 GT..ed il supporto ufficiale è arrivato solo il 27 luglio.
Però devo ammettere una cosa: quando sono passato dai drivers beta ai drivers ufficiali 61.77 ho ottenuto un Boost di prestazioni assurdo..sopratutto nei giochi che utilizzavano gli shader(FC decollato..e già mi andava bene con i drivers precedenti..ma con i 61.77 un vero decollo). :)
Quindi spero che quando rilasceranno avrò un altro boost di questo genere. :)
Originariamente inviato da GMCPape
Si, assolutamente. Del resto i driver sono davvero fondamentali per spremere al meglio l'architettura, e gli utenti lo sanno (quelli sgamati, per lo meno). E, considerando che entrambe le architetture sono molto buone, un software che permette di gestire le GPU in maniera veloce ed efficiente, oltre che spingendo al limite la scheda, è positivissimo. E, nonostante qualche problema di ATI nei driver, devo ammettere di aver apprezzato parecchio AI: una funziona che permette con un click di migliorare le prestazioni diminuendo solo marginalmente la qualità dell'immagine.
Però secondo me questa guerra ha portato ad una release di drivers da tutte e due le parti con pochissimi cambiamenti effettivi...........questo,IMHO,serve solo per alimentare l'hype.
Mah... non ho notato particolari problemi con le 6800 nei giochi. Anzi...
Pape
Non dico che rallenti perché so che è un mostro:D ,però ho visto che ha dei piccoli scatti improvvisi dovuti a dei drivers non ancora ottimizzati per la sua archittetura.
Non so se li hai notati anche tu.
Originariamente inviato da GMCPape
E, nonostante qualche problema di ATI nei driver, devo ammettere di aver apprezzato parecchio AI: una funziona che permette con un click di migliorare le prestazioni diminuendo solo marginalmente la qualità dell'immagine.
Pape
A cosa ti riferisci in particolare?
Non sarai mica una di quelli che consigliano Nvidia perché i dirver Ati danno problemi?:rolleyes:
Originariamente inviato da MaBru
A cosa ti riferisci in particolare?
Non sarai mica una di quelli che consigliano Nvidia perché i dirver Ati danno problemi?:rolleyes:
Guarda che i driver ATI conservano ancora qualche piccola problema di compatibilità con certi giochi, come ho potuto osservare personalmente.Poi c'è tutta la questione OpenGL................;)
Originariamente inviato da DNA_RNA
Guarda che i driver ATI conservano ancora qualche piccola problema di compatibilità con certi giochi, come ho potuto osservare personalmente.Poi c'è tutta la questione OpenGL................;)
Nel Direct3D Ati è avanti rispetto ad nvidia. In OpenGl il contrario.
Originariamente inviato da MaBru
Nel Direct3D Ati è avanti rispetto ad nvidia. In OpenGl il contrario.
Nel Direct3d sono sostanzialmente uguali, con un leggero vantaggio di ATI ad alte risoluzioni con filtri attivati.
Sempre in Direct3d, i pixel shader di Nvidia sono nettamente superiori a qulli di ATI.
Per quanto riguarda l'OpenGL, il vantaggio è di Nvidia.
Originariamente inviato da DNA_RNA
Nel Direct3d sono sostanzialmente uguali, con un vantaggio di ATI ad alte risoluzioni con filtri attivati.
Sempre in Direct3d, i pixel shader di Nvidia sono nettamente superiori a quelli di ATI.
Per quanto riguarda l'OpenGL, il vantaggio è di Nvidia.
Originariamente inviato da DNA_RNA
Nel Direct3d sono sostanzialmente uguali, con un leggero vantaggio di ATI ad alte risoluzioni con filtri attivati.
Sempre in Direct3d, i pixel shader di Nvidia sono nettamente superiori a qulli di ATI.
Per quanto riguarda l'OpenGL, il vantaggio è di Nvidia.
sbagli sui pixel shader. nv ha una versione più avanzata (3.0) che sarà sfruttata più avanti, però come prestazioni sui 2.0 ATi conserva ancora un leggero margine.
sullì'open gl c'è ancora da attendere dato che stanno riscrivendo il driver da zero a quanto ne so.
Originariamente inviato da rera
sbagli sui pixel shader. nv ha una versione più avanzata (3.0) che sarà sfruttata più avanti, però come prestazioni sui 2.0 ATi conserva ancora un leggero margine.
sullì'open gl c'è ancora da attendere dato che stanno riscrivendo il driver da zero a quanto ne so.
No, ho ragione.:)
Nvdia è superiore nei PS 1.1,1.4, e 2.0 con la serie 6800.
http://www.beyond3d.com/reviews/ati/r420_x800/index.php?p=16
http://www.beyond3d.com/reviews/leadtek/6800/index.php?p=6
Come puoi vedere, Nvidia conserva il suo vantaggio, laddove prima ce l'aveva ATI.:)
Per quanto riguarda l'OGL, secondo me ATI l'ha sottovalutato troppo, e spero che adesso si dia da fare.
Originariamente inviato da DNA_RNA
Sempre in Direct3d, i pixel shader di Nvidia sono nettamente superiori a qulli di ATI.
Ma stai parlando di hardware o di software?
Originariamente inviato da MaBru
Ma stai parlando di hardware o di software?
Tutti e due, dato che il vantaggio c'è da tutte e due le parti.:)
Originariamente inviato da DNA_RNA
Tutti e due, dato che il vantaggio c'è da tutte e due le parti.:)
si, hai guardato il 3dmark2003, gli altri li hai bellamente saltati. Dai un occhio, poi dicci cosa ne pensi.
ad esempio guarda qui
http://www.hardware.fr/articles/513/page2.html
poi adesso stop ot, non è qui che si parla di quale scheda va più forte.
tornando in topic, anche io preferirei avere un supporto ufficiale più frequente, quando avevo la fx i driver uscivano più spesso (forse proprio per le problematiche dell'architettura che lo richiedevano), forse ora ha rallentato troppo nel dare driver whql. Ati dal canto suo produce driver a iosa, correggendo pochi bug quando ce ne sarebbero altri da togliere.
:)
Originariamente inviato da R@nda
Riguardo a drivers....non rilascia più una versione ufficiale da quanto?Due mesi?
Va bene che non ho problemi con nessun gioco,però avere una relase al mese che mi faccia guadagnare qualche frames nei giochi
e aggiunga qualche novità come ai vecchi tempi non mi farebbe schifo.
Mi ricordo che Nvidia stessa annunciò che avrebbe allentato i ritmi
nel mercato delle sk grafiche 3d,forse si riferiva proprio a questo.
Credo però che semplicemente il sistema dei drivers unificati (inventato da lei se non sbaglio) si stia rivelando un'arma a doppio taglio e che far andare daccordo una Vanta quanto una Nv 40 si stia rivelando alla lunga difficile....se poi ci mettiamo in mezzo anche l'architettura FX che ha bisogno di parecchi accorgimenti nei drivers per non crollare prestazionalmente nei giochi,abbiamo il quadro completo.
Magari mi sbaglio,però un pò mi sono stufato di fare da betatester.
Voglio dei drivers nuovi e prestazionali!:mad:
io non vedo il motivo di lamentarsi, i driver ci sono anche se non sono su nvidia.com, ma sono su nzone.com e sono ufficiali per le 6800 series e datati 19 ottobre li ho installati provati e vanno perfettamente
;)
Originariamente inviato da pon 87
io non vedo il motivo di lamentarsi, i driver ci sono anche se non sono su nvidia.com, ma sono su nzone.com e sono ufficiali per le 6800 series e datati 19 ottobre li ho installati provati e vanno perfettamente
;)
E grazie,ci sono mille versioni beta,ufficiali,non ufficiali,whql,al pomodoro e in salsa rosa ver 0.3.
Però sul sito Nvidia,di driver finali e ufficiali non c'è nulla.
Ma non vi stufate a testare driver?
Oh non è che sia una piaga sociale,problemi non ne ho nei giochi,mai avuti....è che ero abituato in un certo modo con Nvidia e adesso invece non è più così.
Sulla bontà dei driver Nvidia proprio non si discute!:)
diciamo che fino adesso ne ho testati 3 di driver per la 6800 i 61.36 beta, poi tutto contento avevo messo i 61.77 whql e adesso che volevo driver nuovi ho messo i 66.81.
Che si facciano attendere un po' troppo è verissimo, però come aveva spiegato un dirigente nvidia, non fanno uscire mensilmente driver come ati con poche "innovazioni" nel senso con la correzzione di qualche bug, ma aumenti prestazionali praticamente inesistenti, nvidia si fa aspettare perchè crea dei driver ogni volta "nuovi".
secondo me il problema vero è che neanche nvidia sa più cosa fare !!! ha così tante release per le mani che non sa quale sviluppare per prima !!
solo in ottobre sono usciti in ordine di rilascio:
i 66.72 whql
i 66.81 (nzone)
i 61.82 whql
i primi omega nvidia v1.6177 (questi non sono colpa di nvidia :D )
i 66.81 whql (nzone)
i 66.72 ottimizzati da msi (neanche questi :D )
i 70.41
i 66.74 whql
i 70.40
i 66.77 whql
i 70.41 quadro
:mc: :mc: :mc:
è come creare un soft in versione 1.0
aggiornarlo subito e fare uscire la v2.0
e quindi continuare lo sviluppo dalla versione 1 !!!:D
Alberto Falchi
03-11-2004, 08:34
Originariamente inviato da DNA_RNA
Però secondo me questa guerra ha portato ad una release di drivers da tutte e due le parti con pochissimi cambiamenti effettivi...........questo,IMHO,serve solo per alimentare l'hype.
In certi casi si, ma spesso serve a riparare a certi errori o leggerezze. Prendi le ottimizzazioni tipo brilinear attivate di default su ATI solo per vincere nei bench. O certe strane ottimizzazioni specifiche di nVidia scoperte su vecchie release... quando vengono scoperte, bisogna correre ai ripari.
Non dico che rallenti perché so che è un mostro:D ,però ho visto che ha dei piccoli scatti improvvisi dovuti a dei drivers non ancora ottimizzati per la sua archittetura.
Non so se li hai notati anche tu.
No, sinceramente. Non è che hai qualche problema col vsync o simili?
Pape
Alberto Falchi
03-11-2004, 08:36
Originariamente inviato da MaBru
A cosa ti riferisci in particolare?
Non sarai mica una di quelli che consigliano Nvidia perché i dirver Ati danno problemi?:rolleyes:
I driver ATI non sono all'altezza di quelli nVidia, come stabilità e compatibilità, IMHO. RImangono sempre alcuni problemini con alcuni giochi, e l'OGL è gestito penosamente da ATI.
Pape
Originariamente inviato da GMCPape
I driver ATI non sono all'altezza di quelli nVidia, come stabilità e compatibilità, IMHO. RImangono sempre alcuni problemini con alcuni giochi, e l'OGL è gestito penosamente da ATI.
Pape
Condivido appieno l'arretratezza dei driver Ati in OpenGl.
Questo è un motivo per cui ,in ambito professionale,Ati non è molto adatta.
Per quanto riguarda la tecnica del Brilinear,adottata da Ati,tecnica che si interpone tra Bilinear e Trilinear,quest'ultima utilizzata da Nvidia,non le consente di operare allo stesso livello di Nvidia.
Non so se questa arretratezza dipenda esclusivamente dall'architettura di R420,che non presenta innovazioni tecniche rispetto ai progetti precedenti R3xx,o dovuto a cause che non conosco.
Alberto Falchi
03-11-2004, 09:03
Originariamente inviato da Spytek
Condivido appieno l'arretratezza dei driver Ati in OpenGl.
Questo è un motivo per cui ,in ambito professionale,Ati non è molto adatta.
Per quanto riguarda la tecnica del Brilinear,adottata da Ati,tecnica che si interpone tra Bilinear e Trilinear,quest'ultima utilizzata da Nvidia,non le consente di operare allo stesso livello di Nvidia.
NOn è adottata da ATI o nVidia: il brilinear è un'ottimizzazione per aumentare la velocità nel filtraggio delle texture. ATI può (e disattivando AI lo fa) usare vero trilinear. Ma, per come la vedo, esclusi i benchmark, AI andrebbe abilitato,. visto il boost preastazionale e il basso degrado della quailtà.
Non so se questa arretratezza dipenda esclusivamente dall'architettura di R420,che non presenta innovazioni tecniche rispetto ai progetti precedenti R3xx,o dovuto a cause che non conosco.
Mah... più che di arretratezza, direi minore esperienza. Guarda di contro la qualità dei driver 2D di ATI, che le rendono ottime per gli HTPC. ATI è storicamente eccezionale in questo campo.. nVidia di contro ha sempre puntato solo sul 3D. Col tempo, spero si appianeranno le differenze.
Pape
Originariamente inviato da GMCPape
NOn è adottata da ATI o nVidia: il brilinear è un'ottimizzazione per aumentare la velocità nel filtraggio delle texture. ATI può (e disattivando AI lo fa) usare vero trilinear. Ma, per come la vedo, esclusi i benchmark, AI andrebbe abilitato,. visto il boost preastazionale e il basso degrado della quailtà.
Mah... più che di arretratezza, direi minore esperienza. Guarda di contro la qualità dei driver 2D di ATI, che le rendono ottime per gli HTPC. ATI è storicamente eccezionale in questo campo.. nVidia di contro ha sempre puntato solo sul 3D. Col tempo, spero si appianeranno le differenze.
Pape
Fin troppo esaustivo con le spiegazioni,Pape:)
Quindi il Trilinear Filtering è utilizzato in tutti gli effeti da Ati, attraverso la disattivazione dell Ai,e non solo Nvidia.
Pertanto possiamo affermare che Ati è più prestante con i filtri,rispetto a quelli di Nvdia?Infatti dalle recensioni che vedo,soprattutto nelle comparazioni dei modelli di punta Ati Vs Nvidia,inizialmente partite senza filtri attivati,noto un certo vantaggio di Nvidia in certi giochi,ma al momento dell'attivazioni dei filtri,Ati riesce a recuperare lo svantaggio iniziale.
Concordi con me questo ribaltamento di posizione? ;)
Originariamente inviato da GMCPape
I driver ATI non sono all'altezza di quelli nVidia, come stabilità e compatibilità, IMHO. RImangono sempre alcuni problemini con alcuni giochi, e l'OGL è gestito penosamente da ATI.
Pape
Rimangono sempre alcuni problemini con alcuni giochi. Io amo la precisione, ci traduci alcuni problemini e alcuni giochi con l'effetiva lista dei problemini e dei giochi relativi? :)
Perchè è qualche tempo che possiedo una 9700 Pro e di "alcuni problemini" in "alcuni giochi" non ne ho mai avuti :)
Originariamente inviato da DjLode
Rimangono sempre alcuni problemini con alcuni giochi. Io amo la precisione, ci traduci alcuni problemini e alcuni giochi con l'effetiva lista dei problemini e dei giochi relativi? :)
Perchè è qualche tempo che possiedo una 9700 Pro e di "alcuni problemini" in "alcuni giochi" non ne ho mai avuti :)
Era quello che intendevo io.
In quasi tre anni di ati (dopo due di nvidia vorrei sottolineare) l'unico problema che ho avuto sono state le ombre in Thief 3....:rolleyes:
IMHO
I Catalyst sono un passo avanti ai ForceWare :)
Poi l'uscita mensile certificata a cui segue sempre la stratosferica Omega... applausi a scena aperta ;)
Originariamente inviato da GMCPape
I driver ATI non sono all'altezza di quelli nVidia, come stabilità e compatibilità, IMHO. RImangono sempre alcuni problemini con alcuni giochi, e l'OGL è gestito penosamente da ATI.
Pape
Scusa ma qst è una gran stupidata, parli per luoghi comuni ...
I Catalyst sono un passo avanti ai ForceWare
Si andiamo da un estremo all'altro adesso....
In TOCA Race Driver i Catalyst applicano male l'AA
In Prince Of Persia non applicano l'AA e danno problemi con l'acqua.
Problemi anche in Sacred applicando i filtri.
Ho avuto la 9800pro fino a un mese fà e mi ricordo tutte le "bestemmie" per questi giochi.
Alberto Falchi
03-11-2004, 10:49
Originariamente inviato da Maury
Scusa ma qst è una gran stupidata, parli per luoghi comuni ...
http://www.ati.com/support/issuetype/games.html
Il primo esempio che mi è venuto in mente. poi ci aggiungo le performance relativamente lente nei giochi basati sul motore degli ISI, l'acqua di POP e qualche altro. Aggiungici il casino che fa l'installer su certe configurazioni (ho smadonnato non poco per installare una ATI su un PC del laboratorio... senza poi capire il perché di tanto delirio)
Niente di eclatante, sia chiaro, ma indubbiamente la compatibilità con le schede nVidia è migliore.. sarà anche merito del TWIMTBP, che quantomeno è garanzia di compatibilità.
Pape
Quindi tutti problemi, rob-roy, relativi ai filtri. Non ti fa pensare che la colpa sia l'implementazione dei filtri o il motore del gioco in questione che ha problemi con l'AA delle Ati e non un problema di driver? Perchè Prince of Persia è uscito da tempo e se il problema fosse risolvibile, lo avrebbero fatto. Per me i problemi sono quelli che non ti fanno andare un gioco. I filtri se danno problemi, li disabilito :)
Riguardo alla lista, il primo problema si riferisce ai Catalyst 3.5. Non lo prendo neanche in nota.
Secondo problema : " To correct this issue, download and install CATALYST™ 02.4 or higher." Quindi il problema non esiste più e non la prendiamo neanche in nota.
Terzo problema " To correct this issue, obtain and install Windows XP display driver version 6.13.10.6025 or higher." E non lo prendiamo neanche in nota.
Quarto problema "To correct this issue, download and install the display driver and control panel version, CATALYST 3.0 or higher" (catalyst 3.0 faccio notare e ribadisco) non lo prediamo neanche in nota.
Quinto problema "This issue can affect all display adapters and is not specific to ATI. Both Windows XP and Windows 2000 have a limitation in performing a complete enumeration of all the different modes and refresh rates for full screen. This issue and workaround for it is documented by Microsoft." E non lo prediamo neanche in nota.
Yawn al quinto problema, cinque soluzioni, problemi vecchi come il cucco... mi sono rotto di continuare. Abbiamo una lista più aggiornata/sensata per dimostrare le opinioni (che tali rimangono e quindi limitiamoci nell'uso di "indubbiamente" perchè dei dubbi ancora ne abbiamo tanti) o tali opinioni sono attualmente dimostrabili con un imho e non con delle prove certe?
Prove?
Oh bhe,a me risulta postando spessissimo nella sezione giochi che i problemi con i suddetti nel 90% dei casi li abbiano i possessori Ati.
Il fatto che tu dici che siano risolvibili o meno conta poco,il punto è che io installo i driver Nvidia e non devo pensare a nient'altro,ok?
Non così per Ati...dove,se un gioco ha qualche problema gli utenti
cominciano a postare probabili soluzioni:
Hai provato a ad aggiornare i driver
Sai con la versione xxx ho risolto
Disabilita questo
Prova togliere quest'altro
Scarica la patch
Che poi alla fine il gioco funziona senza problemi ok...ma queste cose con Nvidia succedono raramente.
O vuoi dire di no?
Se neghi semplicemente leggi poco la sezione giochi.
E non mi interessa se ad avere i problemi sono gli "utonti" perchè
è giusto che tutti possano giocare senza problemi,o quantomeno avendone il meno possibile per via dei driver.
Alberto Falchi
03-11-2004, 11:53
Originariamente inviato da R@nda
E non mi interessa se ad avere i problemi sono gli "utonti" perchè
è giusto che tutti possano giocare senza problemi,o quantomeno avendone il meno possibile per via dei driver.
E questo è il punto fondamentale. La maggior parte degli utenti, mette i driver che trova nella scatola. E, oggettivamente, quelli di nVidia, anche anziani come release, risentono meno dei problemi di compatibilità. A mio avviso, ATI dovrebbe puntare maggiormente al supporto degli sviluppatori: guarda la lista dei giochi Get in the Game e quella TWIMTBP. Sarà marketing.. ma funziona... e serve anche quello a un'azienda.
Pape
Originariamente inviato da rob-roy
In TOCA Race Driver i Catalyst applicano male l'AA
In Prince Of Persia non applicano l'AA e danno problemi con l'acqua.
Problemi anche in Sacred applicando i filtri.
Potrebbe essere un problema del gioco in sé, non del driver.
Originariamente inviato da GMCPape
E questo è il punto fondamentale. La maggior parte degli utenti, mette i driver che trova nella scatola. E, oggettivamente, quelli di nVidia, anche anziani come release, risentono meno dei problemi di compatibilità. A mio avviso, ATI dovrebbe puntare maggiormente al supporto degli sviluppatori: guarda la lista dei giochi Get in the Game e quella TWIMTBP. Sarà marketing.. ma funziona... e serve anche quello a un'azienda.
Pape
Scusa Alberto ma non riesco più a seguirti. Prima dici che è colpa degli ingegneri Ati che sono meno "sgamati" di quelli Nv, poi dici che il programma TWIMTBP, anche se è solo marketing, assicura maggiore compatibilità. Allora è colpa degli sviluppatori...
Originariamente inviato da R@nda
Il fatto che tu dici che siano risolvibili o meno conta poco,il punto è che io installo i driver Nvidia e non devo pensare a nient'altro,ok?
Scusa ma se il problema è risolvibile, allora non è un problema. Le release di driver servono a correggere i problemi. Installi i driver Nvidia e non devi pensare ad altro? In che favola? Altrimenti perchè dovrebbero fare delle release nuove? Scusami ma francamente da che mondo e mondo gli aggiornamenti servono per risolvere i problemi, e se un problema viene risolto vuol dire che non è più un problema.
Non così per Ati...dove,se un gioco ha qualche problema gli utenti
cominciano a postare probabili soluzioni:
Hai provato a ad aggiornare i driver
Sai con la versione xxx ho risolto
Disabilita questo
Prova togliere quest'altro
Scarica la patch
Mi fai qualche esempio? Perchè, ribadisco per i meno attenti, a me sta cosa non è mai successa :asd:
Che poi alla fine il gioco funziona senza problemi ok...ma queste cose con Nvidia succedono raramente.
O vuoi dire di no?
Allora se alla fine il gioco funziona senza problemi, i problemi con i giochi non ci sono. O vuoi dire di no? :asd:
E' logica: A ha problemi. A funziona senza problemi. Come fai a dire che A ha dei problemi?
Se neghi semplicemente leggi poco la sezione giochi.
Mi basta quello che leggo in giro in altre sezioni :)
E non mi interessa se ad avere i problemi sono gli "utonti" perchè
è giusto che tutti possano giocare senza problemi,o quantomeno avendone il meno possibile per via dei driver.
Già, ma se poi vuoi giocare a Doom3 con i catalyst del '29 non dare la colpa ai driver :asd:
Se c'è una cosa in cui NON credo sono i problemi a random, se un gioco ha problemi con un driver lo deve dare a tutti, non è possibile che su 100 persone, 90 giocano senza problami e 10 hanno rogne.
Il driver va o non va.
ATI ha preso la bella abitudine di mettere pezze al posto degli stessi team di programmazione, il tuo gioco ha un guaio ? Tu non hai voglia di sbatterci la testa (chissà perchè ..... ) ? OK ci penso io.
Se ATI dopo un tot di release non riesce a sistemare il prob vuol dire che lo stesso è insito nell'engine e con i driver non ci combini nulla, a qst punto i coder dovrebbero tirarsi su le maniche e buttare qualche minuti della loro vita.
X GMCPape
Hai smadonnato a installare un'ATI su un Pc vuoi dare la colpa alla Società Canadese ? Dalla a te che è meglio ;) Le tue difficoltà non fanno testo ...
Ma ci fate o ci siete?:confused:
A me sembra di scrivere cose così semplici da capire e che sono sotto gli occhi di tutti....
Alberto Falchi
03-11-2004, 13:16
Originariamente inviato da MaBru
Scusa Alberto ma non riesco più a seguirti. Prima dici che è colpa degli ingegneri Ati che sono meno "sgamati" di quelli Nv, poi dici che il programma TWIMTBP, anche se è solo marketing, assicura maggiore compatibilità. Allora è colpa degli sviluppatori...
Gli ingegneri ATI, sia per l'OpenGL sia per alcuni (piccoli, ora come ora) problemi, non sono all'altezza di quelli nVidia, secondo me. Poi può anche trattarsi di una questione di architettura della GPU, più che di bravura dei software engineer, ma il fatto è che mentre non sento la necessità di aggiornare spesso i driver nVidia, mi capita spesso di doverlo fare con quelli ATI.
Oltre a questo, ritengo che il programma TWIMTBP contribuisca non poco alla compatibilità: se un gioco si vuole fregiare di tale logo, deve per forza funzionare senza problemi su tutta la gamma di acceleratori nVidia supportati. Di contro, i programmatori si interessano in maniera relativa delle vecchie schede ATI, non avendo "obblighi".
Ciò che mi fa pensare che gli ingegneri di nVidia siano più sgamati, è il fatto che riescano a ottenere boost di prestazioni notevoli con nuove release dei driver, cosa che difficilmente avviene con ATI, dove l'AI fa guadagnare sì parecchi punti percentuali, ma solo abbassando la qualità di alcuni filtraggi.
Sia chiaro che tutto questo non vuo dire "ATI fa dei driver penosi", tutt'altro. Semplicemente, per come la vedo io, sul lato software prediligo nVidia. E te lo dice uno che attualmente sta usando una X800 XT PE ;-)
Pape
Originariamente inviato da R@nda
Ma ci fate o ci siete?:confused:
A me sembra di scrivere cose così semplici da capire e che sono sotto gli occhi di tutti....
Sotto i tuoi di occhi, perchè il mondo è grande sai e non tutti hanno i problemi che lamenti, 3 utenti in un forum non fanno un sentenza.
Io sono favorevole alla scelta di nVidia. Ho Ati e non mi dispiacerebbero release più corpose, mi fa girare le OO reinstallare driver ogni mese e non scorgere nessun cambiamento. Considerato poi che ho molte partizioni e lo dovrei fare ad ognuna (mai fatto).
Riguardo i driver negli ultimi anni Ati è migliorata molto ma complessivamente ancora un pelo sotto nvidia. Però un grosso vantaggio di Ati si ha dalla versione 4.4 dei catalyst ossia il temporal AA, altro che quintrix o quello che era.
Alberto Falchi
03-11-2004, 13:19
Originariamente inviato da DjLode
Scusa ma se il problema è risolvibile, allora non è un problema. Le release di driver servono a correggere i problemi. Installi i driver Nvidia e non devi pensare ad altro? In che favola? Altrimenti perchè dovrebbero fare delle release nuove? Scusami ma francamente da che mondo e mondo gli aggiornamenti servono per risolvere i problemi, e se un problema viene risolto vuol dire che non è più un problema.
Si, risolvibili, e quindi un plauso ad ATI che si impegna per migliorarsi costantemente. Ma il problema è che non tutti sanno cosa sia un driver, ne hanno connessioni veloci per scaricarsi i 2o e passa mega dei Catalyst. Le soluzioni nVidia, tipicamente, funzionano bene (dal punto di vista della compatibilità) out of the box. ATI solo con questa generazione ci sta riuscendo.
Già, ma se poi vuoi giocare a Doom3 con i catalyst del '29 non dare la colpa ai driver :asd:
Sai com'è... su tutti quelli che hanno comprato doom III, molti hanno ancora i driver della confezione. Si, saranno niubbi, ma non puoi pretendere di alfabetizzare il pubblico che vuole solo farsi una partita ^_^
Pape
Cmq Dj,io ti ho riportato la lista dei problemi che ho avuto con la mia ex 9800pro,non intendevo dare un giudizio negativo su ATI..;)
Poi non ho la competenza per capire se il problema è dato dal driver o dal motore del gioco.
Però il problema di PoP con le ATI è presente.....possibile che i programmatori non se ne siano accorti??
Originariamente inviato da Maury
Sotto i tuoi di occhi, perchè il mondo è grande sai e non tutti hanno i problemi che lamenti, 3 utenti in un forum non fanno un sentenza.
Ma io non ho assolutamente problemi...mai avuti con nessuna sk video,perchè sò cosa installare,so cosa ci vuole per far funzionare decentemente una sk video,perchè sono skillato,quello che vuoi insomma...ma mica sono tutti così.
3....bhuahahaha 3 utenti.
Ma dai Maury la sezione giochi la segui anche tu,vedi anche tu cosa succede.
Ma pare che pur di difendere la vostra idea siete capaci di negare ogni cosa.
Perchè io che ho una sk video Nvida sbatto su i driver e Doom3 funziona alla grande a prescindere dalla relase?
Perchè se faccio las tessa cosa con Ati saltano fuori problemi?
Questo è solo un esempio...ce ne sono mille altri.
Ma perchè negare?
Non vi capisco proprio.
Alberto Falchi
03-11-2004, 13:22
Originariamente inviato da Maury
Hai smadonnato a installare un'ATI su un Pc vuoi dare la colpa alla Società Canadese ? Dalla a te che è meglio ;) Le tue difficoltà non fanno testo ...
è risaputo che l'installer di ATI ha problemi con particolari configurazioni, e per risolvere il problema infatti mi sono rifatto alle loro FAQ. Calcolando che si trattava di una macchina ghostata di fresco, nuda e cruda, quindi senza nulla che potesse fare potenziale conflitto software (e aggiungendo che ho una certa esperienza con questo lavoro), non posso certo imputare la colpa altri che ad ATI, che è ancora acerba sotto questo profilo. Per farti un esempio: i Forceware li scrivo senza problemi sopra quelli vecchi. Fallo coi Catalyst, e dimmi se non rischi che ne succedano di ogni.
Pape
Originariamente inviato da GMCPape
Gli ingegneri ATI, sia per l'OpenGL sia per alcuni (piccoli, ora come ora) problemi, non sono all'altezza di quelli nVidia, secondo me. Poi può anche trattarsi di una questione di architettura della GPU, più che di bravura dei software engineer, ma il fatto è che mentre non sento la necessità di aggiornare spesso i driver nVidia, mi capita spesso di doverlo fare con quelli ATI.
Oltre a questo, ritengo che il programma TWIMTBP contribuisca non poco alla compatibilità: se un gioco si vuole fregiare di tale logo, deve per forza funzionare senza problemi su tutta la gamma di acceleratori nVidia supportati. Di contro, i programmatori si interessano in maniera relativa delle vecchie schede ATI, non avendo "obblighi".
Ciò che mi fa pensare che gli ingegneri di nVidia siano più sgamati, è il fatto che riescano a ottenere boost di prestazioni notevoli con nuove release dei driver, cosa che difficilmente avviene con ATI, dove l'AI fa guadagnare sì parecchi punti percentuali, ma solo abbassando la qualità di alcuni filtraggi.
Sia chiaro che tutto questo non vuo dire "ATI fa dei driver penosi", tutt'altro. Semplicemente, per come la vedo io, sul lato software prediligo nVidia. E te lo dice uno che attualmente sta usando una X800 XT PE ;-)
Pape
Ciao:)
Ti do ragione per quanto riguarda i capricci che fanno i driver di Nvidia.Io fino a poco tempo fa avevo una 9800 pro, andava benissimo come prestazioni, ma rispetto alla Nvidia che avevo una volta, ho notato più problemi di incompatibilità in giochi come Deus Ex 2,POP,Toca, Thief 3,NOLF 2.
Secondo me questo è in parte attribuibile alla minore esperienza di ATI nel programmare driver pienamente efficienti nel 3d dato che è da relativamente poco che si è messa a livello di Nvidia, e in parte al marketing Nvidia che almeno spinge una buona parte degli sviluppatori ad assicurarsi che i loro giochi funzionino al meglio su di Nvidia.;)
Originariamente inviato da GMCPape
Gli ingegneri ATI, sia per l'OpenGL sia per alcuni (piccoli, ora come ora) problemi, non sono all'altezza di quelli nVidia, secondo me. Poi può anche trattarsi di una questione di architettura della GPU, più che di bravura dei software engineer, ma il fatto è che mentre non sento la necessità di aggiornare spesso i driver nVidia, mi capita spesso di doverlo fare con quelli ATI.
Oltre a questo, ritengo che il programma TWIMTBP contribuisca non poco alla compatibilità: se un gioco si vuole fregiare di tale logo, deve per forza funzionare senza problemi su tutta la gamma di acceleratori nVidia supportati. Di contro, i programmatori si interessano in maniera relativa delle vecchie schede ATI, non avendo "obblighi".
Ciò che mi fa pensare che gli ingegneri di nVidia siano più sgamati, è il fatto che riescano a ottenere boost di prestazioni notevoli con nuove release dei driver, cosa che difficilmente avviene con ATI, dove l'AI fa guadagnare sì parecchi punti percentuali, ma solo abbassando la qualità di alcuni filtraggi.
Sia chiaro che tutto questo non vuo dire "ATI fa dei driver penosi", tutt'altro. Semplicemente, per come la vedo io, sul lato software prediligo nVidia. E te lo dice uno che attualmente sta usando una X800 XT PE ;-)
Pape
Scusa ma se c'è una società che sta facendo u casino della Madonna con i driver è proprio nVidia, sta sfornando tonnellate di beta senza senso, leggendo nei forum trovo sempre più spesso appellativi del tipo: Che schifo questo nuovo driver etc ... ATI te ne fa uno al mese e ti dice cosa ha corretto e cosa c'è da correggere. Del resto l'ultimo driver nVidia certificato a quando risale ?
La storia dell'OpenGL non regge, OpenGl vuol dire 2 giochi, non c'è motivo di riscrivere un driver per un'API che ha e avrà sempre meno spazio, si lavora sul gioco e basta, come fatto con Doom 3, che a dirla tutta si avvale delle caratteristiche della serie 6800 ed affini.
Il progresso dei Catalyst è innegabile, si può dire lo stesso dei Force ? Gli aumenti dei force come pensi che vengano ottenuti ?
nVidia non ha coder più sgamati, paga le case per plasmare gli engine sulle loro architetture/driver ... è diverso.
Originariamente inviato da GMCPape
i Forceware li scrivo senza problemi sopra quelli vecchi. Fallo coi Catalyst, e dimmi se non rischi che ne succedano di ogni.
Pape
E vero questo: l'ho sperimentato anch'io.
:)
Scusa ma se c'è una società che sta facendo u casino della Madonna con i driver è proprio nVidia, sta sfornando tonnellate di beta senza senso, leggendo nei forum trovo sempre più spesso appellativi del tipo: Che schifo questo nuovo driver etc ... ATI te ne fa uno al mese e ti dice cosa ha corretto e cosa c'è da correggere. Del resto l'ultimo driver nVidia certificato a quando risale ?
Ti pare che non lo so?
Ho aperto il post apposta per lamentarmi di sta cosa!:D
Alberto Falchi
03-11-2004, 13:27
Originariamente inviato da DNA_RNA
Secondo me questo è in parte attribuibile alla minore esperienza di ATI nel programmare driver pienamente efficienti nel 3d dato che è da relativamente poco che si è messa a livello di Nvidia, e in parte al marketing Nvidia che almeno spinge una buona parte degli sviluppatori ad assicurarsi che i loro giochi funzionino al meglio su di Nvidia.;)
Esattamente. NOn dimentichiamo che, senza nulla togliere all'ottimo lavoro di ATI in questi anni (il primo Radeon era eccezionale come scheda... ma i driver... dio mio che schifo), bisogna riconoscere che nVidia ha tra le sue fila alcuni dei migliori ingegneri del 3D esistenti. Si parla di gente che ha lavorato in silicon graphic, ma soprattutto di persone che hanno creato 3dfx. ATI sta migliorando, è innegabile, ma ancora deve fare qualcosa per battere la rivale. Ti faccio l'esempio del flop di NV3X: nonostante i problemi insiti in quell'architettura, i giochi funzionavano. Lenti, ma senza proboemi di compatibilità. E, in quei casi, le nuove release dei forceware riuscivano a dare ottimi boost prestazionali senza ricorrere (se non in rari casi) a ottimizzazioni "sporche"
Pape
Originariamente inviato da R@nda
Ma io non ho assolutamente problemi...mai avuti con nessuna sk video,perchè sò cosa installare,so cosa ci vuole per far funzionare decentemente una sk video,perchè sono skillato,quello che vuoi insomma...ma mica sono tutti così.
3....bhuahahaha 3 utenti.
Ma dai Maury la sezione giochi la segui anche tu,vedi anche tu cosa succede.
Ma pare che pur di difendere la vostra idea siete capaci di negare ogni cosa.
Perchè io che ho una sk video Nvida sbatto su i driver e Doom3 funziona alla grande a prescindere dalla relase?
Perchè se faccio las tessa cosa con Ati saltano fuori problemi?
Questo è solo un esempio...ce ne sono mille altri.
Ma perchè negare?
Non vi capisco proprio.
4 allora ? Di certo non uso una sezione apposita di un forum, dove gente posta "di proposito e dopo ricerche" domande per fare una stima.
Doom 3 non nominiamolo, è culo e camicia con nVidia ...
Originariamente inviato da rob-roy
Cmq Dj,io ti ho riportato la lista dei problemi che ho avuto con la mia ex 9800pro,non intendevo dare un giudizio negativo su ATI..;)
Nessun problema, ma come ti ho fatto notare, i filtri non è che siano tutto sto gran problema :)
Poi non ho la competenza per capire se il problema è dato dal driver o dal motore del gioco.
Basta che guardi, se c'è scritto nel readme del gioco (e se non ricordo male in PoP c'è) è un problema del gioco, altrimenti verrebbe risolto con i driver.
Però il problema di PoP con le ATI è presente.....possibile che i programmatori non se ne siano accorti??
Sì, se ne sono accorti... ma quelli di PoP non hanno voluto mettere una pezza. Purtroppo non c'è altro da dire.
Originariamente inviato da GMCPape
è risaputo che l'installer di ATI ha problemi con particolari configurazioni, e per risolvere il problema infatti mi sono rifatto alle loro FAQ. Calcolando che si trattava di una macchina ghostata di fresco, nuda e cruda, quindi senza nulla che potesse fare potenziale conflitto software (e aggiungendo che ho una certa esperienza con questo lavoro), non posso certo imputare la colpa altri che ad ATI, che è ancora acerba sotto questo profilo. Per farti un esempio: i Forceware li scrivo senza problemi sopra quelli vecchi. Fallo coi Catalyst, e dimmi se non rischi che ne succedano di ogni.
Pape
E' risaputo da chi ? Caso mai rientri nella possibilità che ci sia qualcosa che da conflitto, poi dai ...da utente "sgamanto" mi fai l'installazione manuale no ? :rolleyes:
Originariamente inviato da GMCPape
Esattamente. NOn dimentichiamo che, senza nulla togliere all'ottimo lavoro di ATI in questi anni (il primo Radeon era eccezionale come scheda... ma i driver... dio mio che schifo), bisogna riconoscere che nVidia ha tra le sue fila alcuni dei migliori ingegneri del 3D esistenti. Si parla di gente che ha lavorato in silicon graphic, ma soprattutto di persone che hanno creato 3dfx. ATI sta migliorando, è innegabile, ma ancora deve fare qualcosa per battere la rivale. Ti faccio l'esempio del flop di NV3X: nonostante i problemi insiti in quell'architettura, i giochi funzionavano. Lenti, ma senza proboemi di compatibilità. E, in quei casi, le nuove release dei forceware riuscivano a dare ottimi boost prestazionali senza ricorrere (se non in rari casi) a ottimizzazioni "sporche"
Pape
IMHO, ATI è riuscito a programmare dei driver decenti solo dopo aver acquistato ArtX che le ha dato gente capace di realizzare un progetto ottimo con dei drivers adatti.
L'unica cosa che mi lascia perplesso è l'OGL, che sembra voler trascurare, e molti piccoli bug in certi giochi, vecchi e non, che non vengono mai aggiustati nelle release nuove.:mad:
Ok...lasciamo perdere Doom3.
FarCry?
Che su tantissime Ati striangola il mare?Risolvibile certo,smanetta di qua,prova un altra relase...ecc...
Vedo che ancora non afferrate il punto della questione,vi soffermate solo sul fatto che si sta criticando i driver Ati(guai eh?).
Alberto Falchi
03-11-2004, 13:34
Originariamente inviato da Maury
Scusa ma se c'è una società che sta facendo u casino della Madonna con i driver è proprio nVidia, sta sfornando tonnellate di beta senza senso, leggendo nei forum trovo sempre più spesso appellativi del tipo: Che schifo questo nuovo driver etc ... ATI te ne fa uno al mese e ti dice cosa ha corretto e cosa c'è da correggere. Del resto l'ultimo driver nVidia certificato a quando risale ?
L'hai detto tu: BETA. Non so te, ma su una macchina da lavoro non ci metterei i driver beta. Io sul PC di casa uso da tempo i 61.77, e non riscontro problema alcuno. I driver beta mi rifiuto di usarli anche solo per i test delle schede video (esclusi casi particolarissimi, come quando mi trovo a testare degli engineering sample)
La storia dell'OpenGL non regge, OpenGl vuol dire 2 giochi, non c'è motivo di riscrivere un driver per un'API che ha e avrà sempre meno spazio, si lavora sul gioco e basta, come fatto con Doom 3, che a dirla tutta si avvale delle caratteristiche della serie 6800 ed affini.
Due giochi? Se mi metto a elencare i titoli col motore di Q3 non finisco più.
nVidia non ha coder più sgamati, paga le case per plasmare gli engine sulle loro architetture/driver ... è diverso.
Bah, se dobbiamo fare i bambini con queste sparate, tanto vale troncare il discorso. Senza contare che la generazione precedente era dominata da ATI, come prestazioni: li pagavano loro?
Pape
Ah, che sindrome da beta tester che vedo :D :D
NESSUNO VI OBBLIGA AD INSTALLARE L'ULTIMA RELEASE ALPHA-BETA di un qualunque pacchetto driver, Catalyst o ForceWare che sia!
La pubblicità non obbliga nessuno a comprare, al massimo siete voi che vi lasciate suggestionare! :D
P.S.: Io il test delle release beta lo faccio dal 2001 (dai detonator 6.xx), ma è solo perchè VOGLIO farlo io, per curiosità, so benissimo che non c'è bisogno di tirarsi matti :)
Bye ;)
Originariamente inviato da R@nda
Ok...lasciamo perdere Doom3.
FarCry?
Che su tantissime Ati striangola il mare?Risolvibile certo,smanetta di qua,prova un altra relase...ecc...
Vedo che ancora non afferrate il punto della questione,vi soffermate solo sul fatto che si sta criticando i driver Ati(guai eh?).
Far Cry ?
Scusa ma parli del mio gioco preferito, gioco che mi sparo da mesi, non l'ho manco patchato (!!!) ... ho cambaito tutte le release dei catalyst e dire che va liscio come l'olio è un offesa alla sua perfezione ;)
Caso mai sn le nVidia ad aver sputato sangue con qst titolo, artefatti ovunqua, banding, frame rate bassi, etc
Thunder82
03-11-2004, 13:36
Sinceramente quando avevo la 8500 (presa appena uscita a dicembre 2001) i driver erano uno schifo. Non funzionava quasi nulla se non con PESANTI tweak tramite programmi esterni (rage3d e altri). Dalla disperazione presi una Ti4200 appena uscì e mi pareva di aver trovato il nirvana... a dicembre dell'anno scorso ho voluto dare una seconda possibilità ad ATi, sperando che i suoi driver fossero migliorati... ebbene, non ho notato NESSUNA differenza di compatibilità o di stabilità passando dalla ti4200 alla 9600xt.... mi sono stupito anche io, ripensando a quanti problemi aveva la 8500 solamente 2 anni prima, alla ATi hanno fatto un lavoro mastodontico. E anche con questa ati TUTTI i giochi mi vanno senza problemi, anche quelli vecchi, e senza nessun tweak. Installi e via. Esattamente come per nVidia.
Originariamente inviato da R@nda
Ok...lasciamo perdere Doom3.
FarCry?
Che su tantissime Ati striangola il mare?Risolvibile certo,smanetta di qua,prova un altra relase...ecc...
Vedo che ancora non afferrate il punto della questione,vi soffermate solo sul fatto che si sta criticando i driver Ati(guai eh?).
Ciao:)
Il problema di cui parli me lo faceva la mia ex-9800 pro, ho dovuta smanettare tre ore per riuscire a fare qualcosa per risolverlo.
E' innegabile che con Nvidia questi problemi,non gravi ma fastidiosi, siano quasi inesistenti.
Originariamente inviato da R@nda
Ok...lasciamo perdere Doom3.
Meglio va...
FarCry?
Che su tantissime Ati striangola il mare?Risolvibile certo,smanetta di qua,prova un altra relase...ecc...
Sulla mia 9700 non ha mai dato problemi di questo tipo, giocato all'epoca dell'uscita con i driver che c'erano.
Vedo che ancora non afferrate il punto della questione,vi soffermate solo sul fatto che si sta criticando i driver Ati(guai eh?).
Un conto è criticare con cose concrete, un conto è dire cose che non si possono dimostrare (tipo, su tantissime Ati stringola il mare. Perchè non su tutte? Se fosse un problema di driver non credi lo farebbe su tutte? Forse le suddette schede sono un pò tirate e il case è caldo? Ati credo implementerà dalla versione 5.0 la funziona raffredda case e sarà la prima casa al mondo a farlo :asd:).
Originariamente inviato da GMCPape
L'hai detto tu: BETA. Non so te, ma su una macchina da lavoro non ci metterei i driver beta. Io sul PC di casa uso da tempo i 61.77, e non riscontro problema alcuno. I driver beta mi rifiuto di usarli anche solo per i test delle schede video (esclusi casi particolarissimi, come quando mi trovo a testare degli engineering sample)
Due giochi? Se mi metto a elencare i titoli col motore di Q3 non finisco più.
Bah, se dobbiamo fare i bambini con queste sparate, tanto vale troncare il discorso. Senza contare che la generazione precedente era dominata da ATI, come prestazioni: li pagavano loro?
Pape
I driver nVidia rimangono beta da un secolo perchè hanno dei bug, o cmq qualcosa che non va, ecco perchè non vanno o peggio NON passano la certificazione.
E' inutile che mi nomini i titoli derivanti da Quake 3, cosa mi cambia tra 200 e 180 fps ? Nulla. Va bene così com'è.
Il logo nVidia e il suo caro programma è sulla schermata iniziale di 3/4 dei titoli in uscita o usciti a da poco, non c'è da fare i bambini c'è da prendere atto di un qualcosa che a tutti gli effetti succede.
Alberto Falchi
03-11-2004, 13:39
Originariamente inviato da Maury
E' risaputo da chi ? Caso mai rientri nella possibilità che ci sia qualcosa che da conflitto, poi dai ...da utente "sgamanto" mi fai l'installazione manuale no ? :rolleyes:
Fare l'installazione manuale? E perché? Dovrebbe funzionare e punto. Io posso forzarla, come ho fatto, ma la gente normale?
Cmq, è risaputo si: http://www.ati.com/support/issuetype/installation.html
Pape
Thunder82
03-11-2004, 13:41
Originariamente inviato da R@nda
Ok...lasciamo perdere Doom3.
FarCry?
Che su tantissime Ati striangola il mare?Risolvibile certo,smanetta di qua,prova un altra relase...ecc...
Vedo che ancora non afferrate il punto della questione,vi soffermate solo sul fatto che si sta criticando i driver Ati(guai eh?).
Non mi ha mai striangolato il mare in far cry, nè con la demo nè col gioco completo. Se ti riferisci al fatto dei triangoli sulle ombre con i driver che erano usciti prima ancora dell'uscita della demo, bastava settare l'aniso dal gioco invece che dal pannello di controllo... tutto qua.
Cmq Far Cry tanto per restare in tema non è un gioco felice per nVidia... pensiamo al banding sugli shader, alle prestazioni imbarazzanti, ecc...
Alberto Falchi
03-11-2004, 13:43
Originariamente inviato da Maury
I driver nVidia rimangono beta da un secolo perchè hanno dei bug, o cmq qualcosa che non va, ecco perchè non vanno o peggio NON passano la certificazione.
E perché non impazziscono a farne uscire di nuovi? Forse perché la gente si trova bene con quelli che ci sono? Possibile che a me vada tutto, anche con vecchie release dei driver? NOn mi sembra un brutto lavoro.
E' inutile che mi nomini i titoli derivanti da Quake 3, cosa mi cambia tra 200 e 180 fps ? Nulla. Va bene così com'è.
Beh, Doom III è un chiaro esempio dove un miglior supporto OGL non sarebbe male. Ah no scusa, Doom lo ha comprto nVidia, indipendemente da quanto dice carmack nei .plan e nonostante l'assenza di logo.
Il logo nVidia e il suo caro programma è sulla schermata iniziale di 3/4 dei titoli in uscita o usciti a da poco, non c'è da fare i bambini c'è da prendere atto di un qualcosa che a tutti gli effetti succede.
Bah.. un altro che non ha capito cosa voglia dire quel logo. Se credi un logo implichi mazzette, contento te.
Pape
Originariamente inviato da GMCPape
Fare l'installazione manuale? E perché? Dovrebbe funzionare e punto. Io posso forzarla, come ho fatto, ma la gente normale?
Cmq, è risaputo si: http://www.ati.com/support/issuetype/installation.html
Pape
Perchè tu pensi che tutto ciò che è informatica vada al primo colpo ? Nulla che ha a che fare con i bit avrà un % di successo del 100%, se è per questo io ho dei problemi con uno scanner combo HP, ma di certo non dico che è una rogna della macchina in oggetto! Può capitare, e il fatto che ATI lo faccia presente vuol dire solamente lasciar traccia di ogni problema, senza nasconderlo.
Mi dicii che hai smadonnato ... e io ti dico, non dovevi da utente "avanzato" risolvevi in 2 minuti. Non si parlava dell'utente normale, quello che per inciso non sa dove mettere una chiave storage usb... figurati una scheda video con relativo driver.
Originariamente inviato da GMCPape
E perché non impazziscono a farne uscire di nuovi? Forse perché la gente si trova bene con quelli che ci sono? Possibile che a me vada tutto, anche con vecchie release dei driver? NOn mi sembra un brutto lavoro.
Beh, Doom III è un chiaro esempio dove un miglior supporto OGL non sarebbe male. Ah no scusa, Doom lo ha comprto nVidia, indipendemente da quanto dice carmack nei .plan e nonostante l'assenza di logo.
Bah.. un altro che non ha capito cosa voglia dire quel logo. Se credi un logo implichi mazzette, contento te.
Pape
Doom 3 non è esempio di nulla, non dimostra nulla, dato che l'ENGINE USA le features delle nuove nVidia. A voglia a fare driver nuovi ...
Il logo nVidia è PUBBLICITA' e le case di software NON sono enti benefici, fatti i tuoi conti
Originariamente inviato da GMCPape
Due giochi? Se mi metto a elencare i titoli col motore di Q3 non finisco più.
Meglio ancora. Non più due giochi, ma uno solo. :asd:
Thunder82
03-11-2004, 13:51
Originariamente inviato da GMCPape
Beh, Doom III è un chiaro esempio dove un miglior supporto OGL non sarebbe male. Ah no scusa, Doom lo ha comprto nVidia, indipendemente da quanto dice carmack nei .plan e nonostante l'assenza di logo.
Indubbiamente D3 ERA meglio su nVidia, ma non perchè è openGL. I suoi shader per lo specular utilizzano texture invece di operazioni matematiche. Se questa era l'opzione migliore per R200 e per tutte le GF che hanno GROSSI problemi a gestire texture e matematiche insieme, per ATi era un handicap. Infatti con gli ultimi driver ATi ha sostituito quegli shader (catalyst A.I.) con operazioni matematiche equivalenti, ottenendo un boost di fps anche di oltre 10-15fps, arrivando praticamente ai livelli nVidia.
Inoltre è indubbio che a carmack piace di + nvidia. Altrimenti perchè ha implementato l'ultrashadow II di nv40 e invece non ha implementato il 3DC di ati che avrebbe QUADRUPLICATO la velocità di trasferimento delle textures e avrebbe reso disponibile la ultra quality già con una scheda da 128Mb invece di 512? ;)
Originariamente inviato da GMCPape
Beh, Doom III è un chiaro esempio dove un miglior supporto OGL non sarebbe male. Ah no scusa, Doom lo ha comprto nVidia, indipendemente da quanto dice carmack nei .plan e nonostante l'assenza di logo.
Lo stesso Carmack però ha anche detto che basterebbe variare anche leggermente il codice per mandare a putt@ne il vantaggio di nvidia.
Originariamente inviato da Thunder82
Indubbiamente D3 ERA meglio su nVidia, ma non perchè è openGL. I suoi shader per lo specular utilizzano texture invece di operazioni matematiche. Se questa era l'opzione migliore per R200 e per tutte le GF che hanno GROSSI problemi a gestire texture e matematiche insieme, per ATi era un handicap. Infatti con gli ultimi driver ATi ha sostituito quegli shader (catalyst A.I.) con operazioni matematiche equivalenti, ottenendo un boost di fps anche di oltre 10-15fps, arrivando praticamente ai livelli nVidia.
Inoltre è indubbio che a carmack piace di + nvidia. Altrimenti perchè ha implementato l'ultrashadow II di nv40 e invece non ha implementato il 3DC di ati che avrebbe QUADRUPLICATO la velocità di trasferimento delle textures? ;)
IMHO,Carmack si muove verso chi gli offre una maggiore possibilità di sbizzarirsi, ed evidentemente si vede che Nvidia gli ha dato questa possibilità.Infatti una volta ha dato che Doom 3 era x ATI:rolleyes: ,prima che uscisse la 5800 che deve averlo portato a vedere le cose in un altro modo.
Ma scusa, che ne sai che avrebbe QUADRUPLICATO le prestazioni il 3dc?
Ati non ha nessun problema a livello di driver...
Contenti?
Adesso ogni volta che vedrò un vostro post nella sezione giochi o problemi schede video che riguarda una sk Ati ve lo metto qui.
Così magari capite...
Le fette di slame sugli occhi...
AH..aggiungo,a me FarCry su una 9700 e su una 7500 ha striangolato di brutto,uno scempio,va bene ho aggiornato i Catalyst ed è andato a posto.
Rimane il fatto che su Nvidia 4200Ti,5900,Geforce3.....con relase vecchie senza toccare un tubo è andato via liscio senza toccare una vafa.
Ma continuiamo a rigirare la frittata,neghiamo sempre.
ma l'obiettività dove cavolo è finita...
yossarian
03-11-2004, 14:01
personalmente, ai drivers miracolosi non ci credo né ci ho mai creduto; inoltre, tanto per creare più confusione, ci sono test con SW pro in cui NV40 va decisamente meglio di R420 in D3D (3dsmax, ad esempio) e R420 doppia letteralmente le prestazioni di NV40 in OGL (CATi A, tanto per non far nomi), questo alla faccia del luogo comune sulla superiorità di NV in OGL e di ATi in D3D.
Sulla serie NV3x se ne sono viste (e purtroppo se ne vedono ancora) di tutti i colori (mi riferisco a drivers che darebbero boost portentosi). All'interno dei drivers (siano NV, ATi, Matrox o altro) esistono dei compilatori che rendono il SW più digeribile all'architettura su cui deve girare. Al di là di queste (lecite) ci sono state altre ottimizzaizoni illecite (clipping planes per i 3DMark, application detect - in passato lo ha fatto anche ATi con quak - e shader replacement per i giochi che utilizzano SM2.0 per NV3x) che avevano il solo scopo di far andare gpu che oggettivamente con questo tipo di shader sono un "chiodo", più o meno al livello della concorrenza. Dico illecite per un semplice motivo: anche se la sostituzione di uno shader2.0 con uno 1.1 in molti casi non crea problemi a livello di IQ (soprattutto per l'uso ridicolo che realmente si fa in molti SW di SM2.0, vedi Aquamark o TRAoD, per esempio, per non citare lo stesso 3DMark2003), dà risultati completamente sballati a livello di benchmark; di conseguenza, se devo valutare le prestazioni di una determinata architettura con un certo tipo di SW non avrò risultati attendibili.
Attualmente non c'è un solo SW che faccia uso di fp32 su NV3x; su NV35 si fa, in qualche caso moderato uso di fp16; NV30 gira esclusivamente con codice fx12. Questo vale, almeno, nei casi in cui le prestazioni siano allineate con quelle di R300. Diverso il discorso con SW DX8.1 con cui NV3x va, invece, molto bene senza ottimizzazioni.
Per completare il discorso, si può aggiungere che si può scrivere codice ottimizzato per una determinata architettura penalizzando in misura ridotta un'altra (è il caso di Doom3), oppure che ne metta in ginocchio una e favorisca l'altra (questo, per fortuna, non accade, anche perchè non avrebbe senso un gioco che gira solo su chip NV o su chip ATi), però non è possibile coprire con il SW le magagne importanti di ui tipo HW (lo si può fare solo barando).
Alberto Falchi
03-11-2004, 14:02
Originariamente inviato da Maury
Doom 3 non è esempio di nulla, non dimostra nulla, dato che l'ENGINE USA le features delle nuove nVidia. A voglia a fare driver nuovi ...
Carmack, in un'intervista a Beyond 3D, ha ammesso che Ultrashadow NON è attivata nei driver. E, anche se lo fosse, a sua detta non cambierebbe poi tanto. E carmack mi sembra non sia schierato né per l'una né per l'altra.
Il logo nVidia è PUBBLICITA' e le case di software NON sono enti benefici, fatti i tuoi conti
Il logo nVidia è pubblicità, certo, ma gli sviluppatori non sono pagati per metterlo. Sta a loro scegliere se partecipare al programma o meno. Per nVidia è fidelizzazione del cliente, per gli sviluppatori è un bene esporre sulle confezioni il logo dell'azienda che, ai tempi, aveva la gran parte del mercato delle GPU. Perché il nubbio, vedendo il logo sdella sua scheda, sapeva di non andare incontro a problemi vari. E perché allo sviluppatore fa comodo poter certificare il funizonamento.
Guarda che pubblicità non vuol dire "dare soldi a mazzo". Secondo te, le copertine delle riviste di VG sono dunque mazzette?
Pape
yossarian
03-11-2004, 14:05
Originariamente inviato da Maury
Doom 3 non è esempio di nulla, non dimostra nulla, dato che l'ENGINE USA le features delle nuove nVidia. A voglia a fare driver nuovi ...
anche di quelle vecchie (NV3x) se è per questo. Forse perchè, come dice Vifani, Doom3 non ha un'engine nato per lavorare in fp ed è stato adattato a farlo (e non lo ha certo fatto ispirandosi a R300 la cui resa migliore, a livello di numero di operazione per ciclo di clock, si ha quando si compiono operazioni di texture fetch e calcoli matematici in simultanea).
Thunder82
03-11-2004, 14:10
Originariamente inviato da DNA_RNA
IMHO,Carmack si muove verso chi gli offre una maggiore possibilità di sbizzarirsi, ed evidentemente si vede che Nvidia gli ha dato questa possibilità.Infatti una volta ha dato che Doom 3 era x ATI:rolleyes: ,prima che uscisse la 5800 che deve averlo portato a vedere le cose in un altro modo.
Ma scusa, che ne sai che avrebbe QUADRUPLICATO le prestazioni il 3dc?
Mi dici cosa intendi per "possibilità di sbizzarrirsi"?................ LOL!
E non ho detto che il 3DC avrebbe quadruplicato le prestazioni. Leggi meglio quello che scrivo. Ho detto che avrebbe quadruplicato la velocità di trasferimento delle textures, e se tu sapessi come funziona sapresti anche il perchè.
Originariamente inviato da Thunder82
Mi dici cosa intendi per "possibilità di sbizzarrirsi"?................ LOL!
E non ho detto che il 3DC avrebbe quadruplicato le prestazioni. Leggi meglio quello che scrivo. Ho detto che avrebbe quadruplicato la velocità di trasferimento delle textures, e se tu sapessi come funziona sapresti anche il perchè.
Prima cosa, che ne sai tu di quello che so io, perciò non venire a dirmi frasi come ''se tu sapessi.........''
Secondo cosa, ho sbagliato a leggere, tutto qui, e so benissimo come funziona il 3dc.
Per sbizzaririsi intendo dire che Nvidia, evidentemente, gli offerto delle features in più con cui poteva cimentarsi, ed inoltre Doom 3 è OpenGl e probabilmente la sua scelta è stata dettata dal fatto che Nvidia è + veloce in questo campo.
Ho letto
Alberto Falchi
03-11-2004, 14:31
Originariamente inviato da DNA_RNA
Per sbizzaririsi intendo dire che Nvidia, evidentemente, gli offerto delle features in più con cui poteva cimentarsi, ed inoltre Doom 3 è OpenGl e probabilmente la sua scelta è stata dettata dal fatto che Nvidia è + veloce in questo campo.
Perché "scelta"? Non può essere che Carmack ha fatto un motore come andava a lui (come fa di sempre) e, per il suo modo id programmare, l'architettura nVidia si è rivelata più adeguata? Sono certo che i programmatori non puntano a un'architettura sola quando sviluppano giochi: sarebbe folle e idiota. Loro fanno si che il gioco giri decentemente su tutte le schede, integrate comprese. Poi, ovviamente, a seconda dei compilatori HLSL o delle feature usate, un'architettura si trova avvantaggiata o meno. Ma non certo per scelte volute degli ingegneri del software.
Del resto HL2 è stato "comprato" da ATI (cosa che dovrebbe far inorridire tutti quelli che sputano sul logo TWIMTBP, ma stranamente... nessuno cita questo caso), eppure non mi sembra giri male con le schede nVidia, sebbene risulti leggermente meno performante.
Pape
Originariamente inviato da GMCPape
Perché "scelta"? Non può essere che Carmack ha fatto un motore come andava a lui (come fa di sempre) e, per il suo modo id programmare, l'architettura nVidia si è rivelata più adeguata? Sono certo che i programmatori non puntano a un'architettura sola quando sviluppano giochi: sarebbe folle e idiota. Loro fanno si che il gioco giri decentemente su tutte le schede, integrate comprese. Poi, ovviamente, a seconda dei compilatori HLSL o delle feature usate, un'architettura si trova avvantaggiata o meno. Ma non certo per scelte volute degli ingegneri del software.
Del resto HL2 è stato "comprato" da ATI (cosa che dovrebbe far inorridire tutti quelli che sputano sul logo TWIMTBP, ma stranamente... nessuno cita questo caso), eppure non mi sembra giri male con le schede nVidia, sebbene risulti leggermente meno performante.
Pape
Il vantaggio di NVidia è molto probabilmente dovuto al fatto che Doom 3 è programmato in OGL.Per ''scelta'' volevo dire che Carmack, dato che programma in OpenGl, si deve essere trovato meglio con Nvidia che offre un supporto hardware e software migliore di ATI x l'OGL, e quindi, programmandolo, è andato a vantaggi di Nvidia.
Poi è ovvio che si cerca di renderlo più fluide e funzionale possibile su tutte i tipi di schede, ma ci sarà sempre un'architettura avvantaggiata.
X quanto riguarda ATI e HL2, secondo me neanche si tratta di una ''scelta'' dettata dai soldi,dato che anche le Nvidia girano decentemente.
Alberto Falchi
03-11-2004, 14:50
Originariamente inviato da DNA_RNA
X quanto riguarda ATI e HL2, secondo me neanche si tratta di una ''scelta'' dettata dai soldi,dato che anche le Nvidia girano decentemente.
Ma infatti. Non credo che i soldi possano comprare tanto. Non stiamo costruendo un ponte, stiamo parlando di un prodotto che va venduto a un pubblico. E farsi comprare da una casa sarebbe davvero stolto. Certo, ATI ha pagato Valve non poco, ma più che per ottimizzarlo, per metterlo in bundle, cosa sicuramente molto più importante. Ovvio che, venendo regalato insieme a molte schede, Valve ha avuto un'occhio di riguardo per l'architettura della casa canadese, pur facendo girare alla grande il gioco anche su altre schede. A sentire alcuni qui dentro, nVidia è tanto stupida da pagare per un logo e, soprattutto, per avere anche punteggi inferiori nei bench di tali titoli
Pape
HL2 secondo me su Nvidia girerà non decentemente, ma di poco al di sotto di quanto farà con ATi, dato che la 6800 è un prodotto decisamente ben riuscito e sui driver Nv non ha bisogno di insegnamenti. Secondo me la politica del marchio su un gioco non paga mai (e in ogni caso a me se la mia scheda mi permette di giocarci non importa se c'è ati, nv, xgi, ecc.)
Originariamente inviato da GMCPape
Ma infatti. Non credo che i soldi possano comprare tanto. Non stiamo costruendo un ponte, stiamo parlando di un prodotto che va venduto a un pubblico. E farsi comprare da una casa sarebbe davvero stolto. Certo, ATI ha pagato Valve non poco, ma più che per ottimizzarlo, per metterlo in bundle, cosa sicuramente molto più importante. Ovvio che, venendo regalato insieme a molte schede, Valve ha avuto un'occhio di riguardo per l'architettura della casa canadese, pur facendo girare alla grande il gioco anche su altre schede. A sentire alcuni qui dentro, nVidia è tanto stupida da pagare per un logo e, soprattutto, per avere anche punteggi inferiori nei bench di tali titoli
Pape
Sono sostanzialmente d'accordo con te.:)
Il fatto che le vecchie 59xx girassero male con HL2 era dovuto ai PS pietosi di quella serie e non qualche accordo fatto per screditare Nvidia.
Adesso che il divario si è colmato, le prestazioni sono pressapoco identiche, con un leggero vantaggio x ATI.
IMHO,erano sempre i PS scarsi di Nvidia che hanno portato Valve a preferire ATI, e non qualche accordo commerciale.
A sentire certe gente,si va contro qualsiasi discorso che abbia un minimo di buon senso e di criterio;)
yossarian
03-11-2004, 16:07
Originariamente inviato da DNA_RNA
Prima cosa, che ne sai tu di quello che so io, perciò non venire a dirmi frasi come ''se tu sapessi.........''
Secondo cosa, ho sbagliato a leggere, tutto qui, e so benissimo come funziona il 3dc.
Per sbizzaririsi intendo dire che Nvidia, evidentemente, gli offerto delle features in più con cui poteva cimentarsi, ed inoltre Doom 3 è OpenGl e probabilmente la sua scelta è stata dettata dal fatto che Nvidia è + veloce in questo campo.
Ho letto
Carmack ha anche dichiarato che in ARB2 l'NV30 andava la metà dell'R300; a vedere i risultati della serie fx e a confrontarli con quelli della serie R3x0, si direbbe che o le fx non utilizzino ARB2 standard ma specifiche path (come per HL2), oppure che Doom non è programmato in OGL standard. Quindi, in questo caso, inputare i risultati con il gioco ID alla superiorità dei drivers NV in OGL non è corretto.
Originariamente inviato da yossarian
Carmack ha anche dichiarato che in ARB2 l'NV30 andava la metà dell'R300; a vedere i risultati della serie fx e a confrontarli con quelli della serie R3x0, si direbbe che o le fx non utilizzino ARB2 standard ma specifiche path (come per HL2), oppure che Doom non è programmato in OGL standard. Quindi, in questo caso, inputare i risultati con il gioco ID alla superiorità dei drivers NV in OGL non è corretto.
Questo x quanto riguarda NV30.............io mi riferivo ad NV40 e affini che sono indubbiamente i x performanti con Doom 3, grazie al vantaggio che conservano in OGL.
Il fatto che ci siano path specifiche mi sa tanto di accordo preventivato...;)
yossarian
03-11-2004, 18:41
Originariamente inviato da DNA_RNA
Questo x quanto riguarda NV30.............io mi riferivo ad NV40 e affini che sono indubbiamente i x performanti con Doom 3, grazie al vantaggio che conservano in OGL.
Il fatto che ci siano path specifiche mi sa tanto di accordo preventivato...;)
ma parte dell'architettura di NV30 è stata ripresa su NV40 (la dipendenza tra fpu e tmu come punto debole e la struttura delle rop's come punto di forza); quindi i vantaggi di cui gode NV3x a causa di determinate ottimizzazioni, sono gli stessi di cui gode NV40
Che poi i drivers OGL di NV siano più maturi (anche se alcuni SW pro, come CATI A) offrono indicazioni contrastanti e che l'NV40 abbia, nel complesso, un'architettura valida che ha veramente poco a che vedere con le magagne di NV3x, credo siano cose indiscutibili.
;)
Originariamente inviato da yossarian
ma parte dell'architettura di NV30 è stata ripresa su NV40 (la dipendenza tra fpu e tmu come punto debole e la struttura delle rop's come punto di forza); quindi i vantaggi di cui gode NV3x a causa di determinate ottimizzazioni, sono gli stessi di cui gode NV40
Che poi i drivers OGL di NV siano più maturi (anche se alcuni SW pro, come CATI A) offrono indicazioni contrastanti e che l'NV40 abbia, nel complesso, un'architettura valida che ha veramente poco a che vedere con le magagne di NV3x, credo siano cose indiscutibili.
;)
Allora mi stai dicendo che NV40 usa le stesse path specifiche del NV30, e quindi ATI avrebbe le stesse prestazioni se non fosse per questo?:wtf:
yossarian
03-11-2004, 19:41
Originariamente inviato da DNA_RNA
Allora mi stai dicendo che NV40 usa le stesse path specifiche del NV30, e quindi ATI avrebbe le stesse prestazioni se non fosse per questo?:wtf:
NV40 trae sicuramente vantaggio dall'utilizzo di texture dependent read (con notevole risparmio di operazioni matematiche e possibilità di utilizzo massiccio di fp16 senza perdita di qualità: uno dei punti deboli di NV40 è la dipendenza tra alu e tmu che ne riduce il potenziale complessivo di calcolo in presenza di texture ops e math ops in contemporanea) e dall'utilizzo massiccio di stencil ops (le rop's di NV40 sono identiche a quelle di NV3x).
Questi sono due fattori che, di contro, penalizzano R420, tanto che i catalyst, dai 4.9 in poi, sostituiscono in tutti i casi possibili le operazioni di dependent read con operazioni matematiche in cui il chip ATi eccelle).
Al di là di questo, sarebbe interessante vedere, a parità di condizioni, le prestazioni di entrambi i chip.
Queste, al di là di specifiche path, sono caratteristiche del motore di Doom3. Quindi non posso assolutamente credere a Carmack quando dice che ha programmato senza tener conto di una particolare architettura
Originariamente inviato da yossarian
NV40 trae sicuramente vantaggio dall'utilizzo di texture dependent read (con notevole risparmio di operazioni matematiche e possibilità di utilizzo massiccio di fp16 senza perdita di qualità: uno dei punti deboli di NV40 è la dipendenza tra alu e tmu che ne riduce il potenziale complessivo di calcolo in presenza di texture ops e math ops in contemporanea) e dall'utilizzo massiccio di stencil ops (le rop's di NV40 sono identiche a quelle di NV3x).
Questi sono due fattori che, di contro, penalizzano R420, tanto che i catalyst, dai 4.9 in poi, sostituiscono in tutti i casi possibili le operazioni di dependent read con operazioni matematiche in cui il chip ATi eccelle).
Al di là di questo, sarebbe interessante vedere, a parità di condizioni, le prestazioni di entrambi i chip.
Queste, al di là di specifiche path, sono caratteristiche del motore di Doom3. Quindi non posso assolutamente credere a Carmack quando dice che ha programmato senza tener conto di una particolare architettura
Neanch'io ci credo quando dice che non ha programmato con un'architettura specifica in mente.;)
Per parità di condizioni cosa intendi?
Ma secondo te si potrebbe sviluppare Doom 3 con le directX, mantenendo le stesse caratteristiche del motore?:)
yossarian
03-11-2004, 20:13
Originariamente inviato da DNA_RNA
Neanch'io ci credo quando dice che non ha programmato con un'architettura specifica in mente.;)
Per parità di condizioni cosa intendi?
Ma secondo te si potrebbe sviluppare Doom 3 con le directX, mantenendo le stesse caratteristiche del motore?:)
in realtà, parità di condizioni significa dare un colpo alla botte ed uno al cerchio. Le due architetture sono molto simili tra loro, ma hanno delle importanti differenze; l'R420 è più veloce con calcoli misti di tipo matematico e texture ops (avendo alu e tmu indipendenti); ad esempio una sequenza del tipo text/math/math, tanto per intenderci. L'NV40, invece, minimizza il problema della dipendenza suddetta in presenza di sole testure ops o di sole math ops (nel qual caso ha una capacità di calcolo, per ciclo di clock, almeno pari a quella dell'R420; ha la connessione tra rop's e pixel pipeline più efficiente di quella di R420 e trae vantaggio dalle stencil ops; R420 ha un clock maggiore (quindi più operazioni al secondo complessive), ha vsu più efficienti (tranne che con le fixed function) e gestisce meglio le operazioni di HSR e di compressione dati.
Armi pari può significare programmare tenendo conto di vantaggi e svantaggi di entrambe e cercare di bilanciare la cosa.
Doom si sarebbe sicuramente potuto programmare in D3D (anche perchè, da un po' di tempo, le OGL vanno a rimorchio delle prime nell'introdurre nuove feature, come ad esempio linguaggio ad alto livello, HLSL per DX e GLSL per opengl o gli shader programmabili).
Non necessariamente, il programmare in D3D avrebbe, però, favorito ATi; dipende sempre da come si struttura l'engine grafico
Alberto Falchi
03-11-2004, 20:25
Originariamente inviato da yossarian
Queste, al di là di specifiche path, sono caratteristiche del motore di Doom3. Quindi non posso assolutamente credere a Carmack quando dice che ha programmato senza tener conto di una particolare architettura
Quando si sviluppa un chip grafico, solitamente lo si fa in relazione ai desideri dei programmatori. Esattamente come nel caso delle librerie grafiche. Ergo: già dai tempo sia Ati sia nVidia sapevano dove Carmack voleva andare a parare e quali sarebbero state le problematiche del suo engine. NOn a caso, Creative ha ben penasto di patentare gli algoritmi (o meglio, le idee alla base) per l'implementazione delle ombre. Insomma: lui ha espresso le sue necessità, e ha seguito la sua strada. Poi l'architettura nVidia è risultata la più azzeccata per far girare il suo motore, ma non sono così convinto che questo sia accaduto perché Carmack ha plasmato l'engine attorno a NV30/40. Al massimo, mi sembra più plausibile una maggior collaborazione di nVidia e id rispetto a quanto abbia fatto ATI, ma con collaborazione intendo semplicemente il realizzare l'hardware puntando molto su tale engine.
ATi, è doveroso ammetterlo, non è mai stata troppo presente in queste questioni, e almeno all'inizio si è basata più sulle API che guardando al futuro, nel realizzare i suoi chip. COme dire: un'architettura molto ottimizzata pensando al presente, non certo facendo piani a lungo termine su come far evolvere il chip verso le future esigenze.
NOn a caso, X800 non è niente altro che un "hack" delle 9800, non certo un progetto nuovo. Per come la vedo io, ATI non si è voluta lanciare su titoli che sarebbero usciti in futuro, puntando più a quanto già presente.
In definitiva, in parte ti do ragione, Yossaran, ma più che carmack che ha cucito un motore attorno a un'architettura, direi che è l'architettura della GPU studiata per soddisfare le sue esigenze.
Pape
PS: Se non vado errato, Carmack aveva deciso di intraprendere una strada leggermente diversa (e meno efficiente) per la gestione delle ombre, per evitare beghe legali con Creative. Sembra poi che sia tornto sulla soluzione più prestante dopo che l'azienda gli ha concesso l'utilizzo gratuito di tali routine. Chissà.. magari la seconda strada avrebbe avvantaggiato l'architettura di R420...
yossarian
03-11-2004, 20:54
Originariamente inviato da GMCPape
Quando si sviluppa un chip grafico, solitamente lo si fa in relazione ai desideri dei programmatori. Esattamente come nel caso delle librerie grafiche. Ergo: già dai tempo sia Ati sia nVidia sapevano dove Carmack voleva andare a parare e quali sarebbero state le problematiche del suo engine. NOn a caso, Creative ha ben penasto di patentare gli algoritmi (o meglio, le idee alla base) per l'implementazione delle ombre. Insomma: lui ha espresso le sue necessità, e ha seguito la sua strada. Poi l'architettura nVidia è risultata la più azzeccata per far girare il suo motore, ma non sono così convinto che questo sia accaduto perché Carmack ha plasmato l'engine attorno a NV30/40. Al massimo, mi sembra più plausibile una maggior collaborazione di nVidia e id rispetto a quanto abbia fatto ATI, ma con collaborazione intendo semplicemente il realizzare l'hardware puntando molto su tale engine.
ATi, è doveroso ammetterlo, non è mai stata troppo presente in queste questioni, e almeno all'inizio si è basata più sulle API che guardando al futuro, nel realizzare i suoi chip. COme dire: un'architettura molto ottimizzata pensando al presente, non certo facendo piani a lungo termine su come far evolvere il chip verso le future esigenze.
NOn a caso, X800 non è niente altro che un "hack" delle 9800, non certo un progetto nuovo. Per come la vedo io, ATI non si è voluta lanciare su titoli che sarebbero usciti in futuro, puntando più a quanto già presente.
In definitiva, in parte ti do ragione, Yossaran, ma più che carmack che ha cucito un motore attorno a un'architettura, direi che è l'architettura della GPU studiata per soddisfare le sue esigenze.
Pape
PS: Se non vado errato, Carmack aveva deciso di intraprendere una strada leggermente diversa (e meno efficiente) per la gestione delle ombre, per evitare beghe legali con Creative. Sembra poi che sia tornto sulla soluzione più prestante dopo che l'azienda gli ha concesso l'utilizzo gratuito di tali routine. Chissà.. magari la seconda strada avrebbe avvantaggiato l'architettura di R420...
a dire la verità, quando si progetta un chip ci si basa su quelle che sono le APi di riferimento per quel chip; si dà il caso che la DX, essendo API proprietarie, sono fissate da MS con la collaborazione dei principali produttori di chip grafici (anche se l'ultima parola spetta sempre a zio Bill) e la OGL sono un open standard fissato da un consorzio presieduto da SGI (che le ha ideate) e a cui aderiscono 3DLabs, ATi, nVIDIA, e molti altri produttori di HW e qualche sviluppatore, tra cui Carmack. Le specifiche più recenti per le OGL sono fissate dall'ARB2 con l'aggiunta della possibilità di utilizzare un linguaggio ad alto livello (le OGL1.5 sono un ibrido nato perchè non si sono ancora definite le specifiche delle 2.0 a causa delle beghe interne). Carmack, nel progettare l'engine di Doom, se avesse voluto attenersi alle API standard, avrebbe dovuto utilizzare le specifiche ARB2 (ma le prestazioni della serie fx tendono a far escludere questa ipotesi, a meno che le fx non siano testate con path specifiche, tipo la path NV30 o la NV20).
L'ARB2 prevede l'utilizzo di texture dependent read, come le DX (dalle specifiche dello SM1.4 in poi), così come prevede l'utilizzo di calcoli in fp16 e fp32, nonchè fx12.
Ora, l'engine di Doom è un misto di ARB2 e istruzioni proprietarie di NV (che non fanno parte del codice standard) e le scelte di nVIDIA E di Carmack sono troppo coincidenti per essere credibili.
Secondo questa tesi,, nVIDIA, avrebbe progettato una serie di chip non in base alla standard imposto dalle api di riferimento, ma in base alle scelte di Carmack per il suo engine grafico. Ti assicuro che, progettare su queste basi, è un salto nel buio, qualcosa di veramente folle: non si può ideare un'architettura basandosi su un solo engine grafico che, per giunta, non rispetta neppure in pieno lo standard ma, spesso e volentieri, scantona; la mia idea è che Carmack abbia progettato sulla base dell'architettura di NV30 (NV40 ha delle differenze rispetto al chip precedente, anche se, in alcuni casi, gode di qualche beneficio, avendo conservato elementi in comune, pur avendo molto meno bisogno di aiuto rispetto al predecessore).
Perchè non ha utilizzato ARB2? Magari con la sola aggiunta delle stencil shadow?
Ripeto, la cosa non mi convince affatto (soprattutto alla luce di quanto da lui stesso affermato: "NV30 in ARB2 va la metà di R300)
Originariamente inviato da yossarian
a dire la verità, quando si progetta un chip ci si basa su quelle che sono le APi di riferimento per quel chip; si dà il caso che la DX, essendo API proprietarie, sono fissate da MS con la collaborazione dei principali produttori di chip grafici (anche se l'ultima parola spetta sempre a zio Bill) e la OGL sono un open standard fissato da un consorzio presieduto da SGI (che le ha ideate) e a cui aderiscono 3DLabs, ATi, nVIDIA, e molti altri produttori di HW e qualche sviluppatore, tra cui Carmack. Le specifiche più recenti per le OGL sono fissate dall'ARB2 con l'aggiunta della possibilità di utilizzare un linguaggio ad alto livello (le OGL1.5 sono un ibrido nato perchè non si sono ancora definite le specifiche delle 2.0 a causa delle beghe interne). Carmack, nel progettare l'engine di Doom, se avesse voluto attenersi alle API standard, avrebbe dovuto utilizzare le specifiche ARB2 (ma le prestazioni della serie fx tendono a far escludere questa ipotesi, a meno che le fx non siano testate con path specifiche, tipo la path NV30 o la NV20).
L'ARB2 prevede l'utilizzo di texture dependent read, come le DX (dalle specifiche dello SM1.4 in poi), così come prevede l'utilizzo di calcoli in fp16 e fp32, nonchè fx12.
Ora, l'engine di Doom è un misto di ARB2 e istruzioni proprietarie di NV (che non fanno parte del codice standard) e le scelte di nVIDIA E di Carmack sono troppo coincidenti per essere credibili.
Secondo questa tesi,, nVIDIA, avrebbe progettato una serie di chip non in base alla standard imposto dalle api di riferimento, ma in base alle scelte di Carmack per il suo engine grafico. Ti assicuro che, progettare su queste basi, è un salto nel buio, qualcosa di veramente folle: non si può ideare un'architettura basandosi su un solo engine grafico che, per giunta, non rispetta neppure in pieno lo standard ma, spesso e volentieri, scantona; la mia idea è che Carmack abbia progettato sulla base dell'architettura di NV30 (NV40 ha delle differenze rispetto al chip precedente, anche se, in alcuni casi, gode di qualche beneficio, avendo conservato elementi in comune, pur avendo molto meno bisogno di aiuto rispetto al predecessore).
Perchè non ha utilizzato ARB2? Magari con la sola aggiunta delle stencil shadow?
Ripeto, la cosa non mi convince affatto (soprattutto alla luce di quanto da lui stesso affermato: "NV30 in ARB2 va la metà di R300)
E poi si chiede ad ATI di migliorare il driver OpenGL... ma x favore ... :rolleyes:
Alberto Falchi
03-11-2004, 21:16
Originariamente inviato da yossarian
a dire la verità, quando si progetta un chip ci si basa su quelle che sono le APi di riferimento per quel chip; si dà il caso che la DX, essendo API proprietarie, sono fissate da MS con la collaborazione dei principali produttori di chip grafici (anche se l'ultima parola spetta sempre a zio Bill) e la OGL sono un open standard fissato da un consorzio presieduto da SGI (che le ha ideate) e a cui aderiscono 3DLabs, ATi, nVIDIA, e molti altri produttori di HW e qualche sviluppatore, tra cui Carmack.
Si, ma le api di riferimento come vengono scelte? Dai produttori, come indichi giustamente. Ma i produttori, a quanto mi è dato di sapere, si consultano eccome coi guru della programmazione per capire quali siano le loro reali necessità. Le API alla fine sono basate sulle principali esigenze di chi il 3D lo realizza. E esiste un Deus ex Machina che dal nulla decide quali siano le spec più importanti per uno sviluppatore di giochi innovatore, quale un Carmak o un Rein?
Le specifiche più recenti per le OGL sono fissate dall'ARB2 con l'aggiunta della possibilità di utilizzare un linguaggio ad alto livello (le OGL1.5 sono un ibrido nato perchè non si sono ancora definite le specifiche delle 2.0 a causa delle beghe interne). Carmack, nel progettare l'engine di Doom, se avesse voluto attenersi alle API standard, avrebbe dovuto utilizzare le specifiche ARB2 (ma le prestazioni della serie fx tendono a far escludere questa ipotesi, a meno che le fx non siano testate con path specifiche, tipo la path NV30 o la NV20).
L'ARB2 prevede l'utilizzo di texture dependent read, come le DX (dalle specifiche dello SM1.4 in poi), così come prevede l'utilizzo di calcoli in fp16 e fp32, nonchè fx12.
Ora, l'engine di Doom è un misto di ARB2 e istruzioni proprietarie di NV (che non fanno parte del codice standard) e le scelte di nVIDIA E di Carmack sono troppo coincidenti per essere credibili.
NOn che manchino path specifici per R420, del resto. Il fatto che path nVidia risultino più performanti, poi, non posso sapere da cosa dipenda, se dall'architettura migliore o da "pigrizia" di carmack nel voler ottimizzare anche per ATI.
Secondo questa tesi,, nVIDIA, avrebbe progettato una serie di chip non in base alla standard imposto dalle api di riferimento, ma in base alle scelte di Carmack per il suo engine grafico. Ti assicuro che, progettare su queste basi, è un salto nel buio, qualcosa di veramente folle: non si può ideare un'architettura basandosi su un solo engine grafico che, per giunta, non rispetta neppure in pieno lo standard ma, spesso e volentieri, scantona;
Le specifiche nVidia le rispetta, ma il progetto di NV30 e NV40 andava in questa direzione peculiare (perché non supportare FP24 con NV30 ma puntare tutto su FP16 e FP32? Sembra una pazzia, da come dici, eppure...). INsomma, pur rispettando gli standard, si è corso il rischio di accelerare quello che probabilmente sarebbe diventato l'engine di riferimento per anni a venire. Del resto, un rischio nemmeno troppo esagerato, considerando l'influenza di Carmack nel campo videoludico (e il numero di giochi sull'engine di Q3 usciti negli anni passati)
la mia idea è che Carmack abbia progettato sulla base dell'architettura di NV30 (NV40 ha delle differenze rispetto al chip precedente, anche se, in alcuni casi, gode di qualche beneficio, avendo conservato elementi in comune, pur avendo molto meno bisogno di aiuto rispetto al predecessore).
Perchè non ha utilizzato ARB2? Magari con la sola aggiunta delle stencil shadow?
Ripeto, la cosa non mi convince affatto (soprattutto alla luce di quanto da lui stesso affermato: "NV30 in ARB2 va la metà di R300)
NOn sono un programmatore, quindi non ho idea di cosa risponderti sotto questo profilo. Però, il fatto che Creative (che tra l'altro produceva schede nVidia) avesse patentato "le ombre", mi fa pensare che certe idee di Carmack erano presenti nel motore già da molto tempo.
Ovviamente, sono speculazioni di carattere logico, non certo tecnico ^_^
Pape
PS: Il fatto che nVidia punti molto sullo SM3, già da adesso, non è casuale. L'intero Unreal Engine 3 punta molto sull'utilizzo di complessi shader, che vanno oltre le limitazioni imposte dalla versione 2.0. Sembra un suicidio puntarci ora, ma considerando la collaborazione fra nVidia e Epic per lo sviluppo di NV50, appare una mossa mirata per puntare su un'architettura che faccia da apripista verso tali feature, che in futuro saranno sfruttate da quello che si presume sarà il più interessante engine di prossima generazione.
Thunder82
03-11-2004, 21:29
Originariamente inviato da GMCPape
PS: Se non vado errato, Carmack aveva deciso di intraprendere una strada leggermente diversa (e meno efficiente) per la gestione delle ombre, per evitare beghe legali con Creative. Sembra poi che sia tornto sulla soluzione più prestante dopo che l'azienda gli ha concesso l'utilizzo gratuito di tali routine. Chissà.. magari la seconda strada avrebbe avvantaggiato l'architettura di R420...
L'utilizzo di quegli algoritmi non è stato del tutto gratuito per Carmack. Lui aveva sviluppato un algoritmo per l'audio che utilizzava solamente la cpu. Per usare quegli algoritmi sulle ombre senza beghe legali Carmack ha dovuto, sotto pressione di Creative, per forza inserire il supporto all'accelerazione audio con le audigy e l'EAX Advanced HD a quanto mi pare.
Alberto Falchi
03-11-2004, 21:40
Originariamente inviato da Thunder82
L'utilizzo di quegli algoritmi non è stato del tutto gratuito per Carmack. Lui aveva sviluppato un algoritmo per l'audio che utilizzava solamente la cpu. Per usare quegli algoritmi sulle ombre senza beghe legali Carmack ha dovuto, sotto pressione di Creative, per forza inserire il supporto all'accelerazione audio con le audigy e l'EAX Advanced HD a quanto mi pare.
Non è proprio così. Creative ha consentito a Carmack l'utilizzo del suo algoritmo gratuitamente. Ma JC, indispettito dal brevetto di Creative (che in effetti è uno dei tipici esempi di follia... come il brevetto sulla rappresentazione di immagini 3D su schermo di cui si parla in questi giorni), ha deciso di non supportare le EAX. E, infatti, D3 si basa interamente su un engine software, per l'audio. Nessuno poi sa esattamente come sia andato il dialogo fra i due, ma JC ha annunciato che le prossime versioni del motore (quelle date in licenza, insomma) supporteranno nativamente le API Creative. E per fortuna, aggiungo. Il "dispetto" di Carmack ha infatti impedito a Doom 3 di avere una sezione audio ancora migliore di quella attuale.
Pape
Thunder82
03-11-2004, 21:50
Originariamente inviato da GMCPape
Non è proprio così. Creative ha consentito a Carmack l'utilizzo del suo algoritmo gratuitamente. Ma JC, indispettito dal brevetto di Creative (che in effetti è uno dei tipici esempi di follia... come il brevetto sulla rappresentazione di immagini 3D su schermo di cui si parla in questi giorni), ha deciso di non supportare le EAX. E, infatti, D3 si basa interamente su un engine software, per l'audio. Nessuno poi sa esattamente come sia andato il dialogo fra i due, ma JC ha annunciato che le prossime versioni del motore (quelle date in licenza, insomma) supporteranno nativamente le API Creative. E per fortuna, aggiungo. Il "dispetto" di Carmack ha infatti impedito a Doom 3 di avere una sezione audio ancora migliore di quella attuale.
Pape
Boh alla fine come sono andate veramente le cose lo sapranno solamente JC e i grandi capi di Creative. Io sapevo che Creative lo ha costretto a inserire le EAX in cambio dell'utilizzo di quegli algoritmi sulle ombre senza pagare royalties & co.
yossarian
04-11-2004, 00:35
Originariamente inviato da GMCPape
Si, ma le api di riferimento come vengono scelte? Dai produttori, come indichi giustamente. Ma i produttori, a quanto mi è dato di sapere, si consultano eccome coi guru della programmazione per capire quali siano le loro reali necessità. Le API alla fine sono basate sulle principali esigenze di chi il 3D lo realizza. E esiste un Deus ex Machina che dal nulla decide quali siano le spec più importanti per uno sviluppatore di giochi innovatore, quale un Carmak o un Rein?
ripeto, Carmack non si è attenuto alle specifiche ARB2; sarebbe come se si programmasse un gioco in D3D tenendo conto del TAA o del 3Dc o del fatto che R3x0 rende meglio con calcoli in fp misti a texture e fregandosene del fatto che con un input simile i chip NV (soprattutto la serie NV3x) venisse penalizzata o non riuscisse ad esprimersi al meglio; si potrebbe sostenere4 di essersi attenuti alle specifiche dello SM2.x (con qualche aggiunta di feature proprietarie, cosa fatta, per altro, da Carmack), e nessuno potrebbe obiettare: però di fatto si sarebbero favoriti i chip ATi e si sarebbero penalizzati quelli NV.
Bene, Carmack è andato oltre: non si è neppure attenuto strettamente alle spcifiche ARB2 ma le ha modificate con istruzioni proprietarie NV.
Originariamente inviato da GMCPape
NOn che manchino path specifici per R420, del resto. Il fatto che path nVidia risultino più performanti, poi, non posso sapere da cosa dipenda, se dall'architettura migliore o da "pigrizia" di carmack nel voler ottimizzare anche per ATI.
non mi risulta che esistano path specifiche per R420 o per R300 implementate in Doom3; semmai ne esiste una per R200
Originariamente inviato da GMCPape
Le specifiche nVidia le rispetta, ma il progetto di NV30 e NV40 andava in questa direzione peculiare (perché non supportare FP24 con NV30 ma puntare tutto su FP16 e FP32? Sembra una pazzia, da come dici, eppure...). INsomma, pur rispettando gli standard, si è corso il rischio di accelerare quello che probabilmente sarebbe diventato l'engine di riferimento per anni a venire. Del resto, un rischio nemmeno troppo esagerato, considerando l'influenza di Carmack nel campo videoludico (e il numero di giochi sull'engine di Q3 usciti negli anni passati)
fatto ste che NV3x presenta molte lacune in fatto di compatibilità con lo SM2.0 (anche se, secondo i proclami NV, era più avanzato); non supportava il DM (neppure a livello teorico), né il MRT e neppure l'HDR (neanche in forma parziale o incompleta). Inoltre l'FP32 è del tutto inutilizzabile per l'architettura stessa del chip, e l'fp16 stesso crea non pochi problemi: non è male per un chip che avrebbe dovuto superare le specifiche dello SM2.0 e che, invece, spesso era costretto a ricorrere allo SM1.1. Non è una pazzia, ma scelta di marketing: NV30 non era progettato per lavorare in fp, la cosa è molto semplice, però le specifiche "oltre le DX9" fanno vendere.
E comunque investire tutte le risorse per attenersi alle specifiche di un engine grafico e non della sua API di riferimento è una scelta insensata e poco credibile.
Originariamente inviato da GMCPape
NOn sono un programmatore, quindi non ho idea di cosa risponderti sotto questo profilo. Però, il fatto che Creative (che tra l'altro produceva schede nVidia) avesse patentato "le ombre", mi fa pensare che certe idee di Carmack erano presenti nel motore già da molto tempo.
Ovviamente, sono speculazioni di carattere logico, non certo tecnico ^_^
Pape
Neppure io lo sono però so qualcosa di chip e anche di brevetti; il fatto che Creative abbia brevettato l'uso delle ombre scelto per Doom non vuol dire niente: l'investimento fatto per ottenere un brevetto non sarà mai paragonabile a quello che si fa per progettare e realizzare un chip; la differenza di costi è la stessa esistente tra l'acquisto di una barca a remi e quello del Titanic; l'utilizzo dello shadow buffer (e di conseguenza del tipo di ombre generate dal suo utilizzo) è un'idea vecchia che, se non sbaglio, nVIDIA aveva già proposto ai tempi dell'NV20
Originariamente inviato da GMCPape
PS: Il fatto che nVidia punti molto sullo SM3, già da adesso, non è casuale. L'intero Unreal Engine 3 punta molto sull'utilizzo di complessi shader, che vanno oltre le limitazioni imposte dalla versione 2.0. Sembra un suicidio puntarci ora, ma considerando la collaborazione fra nVidia e Epic per lo sviluppo di NV50, appare una mossa mirata per puntare su un'architettura che faccia da apripista verso tali feature, che in futuro saranno sfruttate da quello che si presume sarà il più interessante engine di prossima generazione.
è del tutto diverso; lo SM3.0 fa parte delle spcifiche DX9 sin dalla prima stesura; quindi, in questo caso, nessun salto nel buoi ma semplice anticipo sui tempi (non fruibile allo stato attuale, ma utile ai programmatori per poter iniziare a prenderci confidenza).
In questo caso non si sta puntando su feature proposte da un engine grafico particolare, ma su caratteristiche proposte dalle API di riferimento a cui si rifà l'engine di U3 (ma che non sono peculiarità di Epic ma di tutti coloro che vorranno adottare lo SM3.0 per progettare i loro motori grafici)
Ripeto: ritengo la posizione di Carmack poco credibile; certo, lui è libero di dire ciò che vuole, però io sono altrettanto libero di non credergli
ciao
Originariamente inviato da yossarian
è del tutto diverso; lo SM3.0 fa parte delle spcifiche DX9 sin dalla prima stesura; quindi, in questo caso, nessun salto nel buoi ma semplice anticipo sui tempi (non fruibile allo stato attuale, ma utile ai programmatori per poter iniziare a prenderci confidenza).
In questo caso non si sta puntando su feature proposte da un engine grafico particolare, ma su caratteristiche proposte dalle API di riferimento a cui si rifà l'engine di U3 (ma che non sono peculiarità di Epic ma di tutti coloro che vorranno adottare lo SM3.0 per progettare i loro motori grafici)
ciao
in ogni caso, considerando il presente, l'utilizzo dello shader model 3.0 rispetto al 2.0b è un indubbio vantaggio, non credi?
e a parere mio un vantaggio del genere equivale a un punto in più nel giudizio di un'architettura rispetto ad un'altra..
bYeZ!
yossarian
04-11-2004, 00:53
Originariamente inviato da ATi7500
in ogni caso, considerando il presente, l'utilizzo dello shader model 3.0 rispetto al 2.0b è un indubbio vantaggio, non credi?
e a parere mio un vantaggio del genere equivale a un punto in più nel giudizio di un'architettura rispetto ad un'altra..
bYeZ!
per quanto riguarda le applicazioni pratiche è un vantaggio solo teorico per vari motivi; certo, se discutiamo sulla bontà delle architetture, è un punto a vantaggio di nVIDIA (ma secondo me ce ne sono altri di cui si parla poco o niente e che, invece, danno vantaggi reali).
D'altra parte, il mio giudizio l'ho già espresso; NV40 potrà, nel complesso, esssere un po' meno veloce di R420 (le frequenze non lo favoriscono), però come architettura mi piace di più
Originariamente inviato da yossarian
per quanto riguarda le applicazioni pratiche è un vantaggio solo teorico per vari motivi; certo, se discutiamo sulla bontà delle architetture, è un punto a vantaggio di nVIDIA (ma secondo me ce ne sono altri di cui si parla poco o niente e che, invece, danno vantaggi reali).
D'altra parte, il mio giudizio l'ho già espresso; NV40 potrà, nel complesso, esssere un po' meno veloce di R420 (le frequenze non lo favoriscono), però come architettura mi piace di più
scusa ma sm 3.0 non era stato definito come l'estensione dei 2.0b (un pò come la differenza tra 1.3 e 1.4), cioè calcoli uguali in meno passaggi?
bYeZ!
yossarian
04-11-2004, 01:19
Originariamente inviato da ATi7500
scusa ma sm 3.0 non era stato definito come l'estensione dei 2.0b (un pò come la differenza tra 1.3 e 1.4), cioè calcoli uguali in meno passaggi?
bYeZ!
non solo (e, a dire la verità, neppure il passaggio tra 1.3 a 1.4 si riduceva esclusivamente a quello) ma anche ad una gestione dinamica del flusso di dati Il dynamic branching, ad esempio, dovrebbe servire ad entrambe le cose ma, allo stato attuale, è realizzabile, molto probabilmente, solo nei vs.
Una delle feature più interessanti, il geometry instancing, pare sia possibile anche con R420.
In realtà non è neppure corretto dire "calcoli uguali in meno passaggi"; si dovrebbe invece dire: stesso risultato con meno passaggi, ma non necessariamente calcoli più semplici, anzi, in alcuni casi, il carico di lavoro della gpu può persino aumentare (si può trattare di meno passagi che però coinvolgono più unità di calcolo diverse in contemporanea).
I vantaggi in termini di prestazioni dello SM3.0, comunque, saranno scarsamente fruibili con questa generazioni di gpu (quella che latita è la potenza di calcolo, per quanto possa sembrare strano)
Dark Schneider
04-11-2004, 02:21
Originariamente inviato da yossarian
per quanto riguarda le applicazioni pratiche è un vantaggio solo teorico per vari motivi; certo, se discutiamo sulla bontà delle architetture, è un punto a vantaggio di nVIDIA (ma secondo me ce ne sono altri di cui si parla poco o niente e che, invece, danno vantaggi reali).
D'altra parte, il mio giudizio l'ho già espresso; NV40 potrà, nel complesso, esssere un po' meno veloce di R420 (le frequenze non lo favoriscono), però come architettura mi piace di più
L'architettura NV40 a mio parere è ottima. R420 deve molto alle sue più alte frequenze se riesce a stare sullo stesso livello. :)
Un po' come succedeva tra le 5900 e 9800..ma al contrario. Anche se c'è da dire poi le 5900 avevano anche un architettura non tanto buona, mentre quella dell'R420 è buona. NV40 è meglio.
Sono curioso di vedere il prossimo prodotto nVidia, ossia il NV48 refresh di NV40. Avrà senz'altro un processo produttivo a 0.11 micron. Quindi vedremo il NV40 a frequenze di Core più elevate. Voglio anche vedere di quanto riuscirà a salire Ati invece a livello di frequenze. :) Secondo me Ati salirà ma non moltissimo. Da nVidia mi aspetto almeno un 500 Mhz di Core. La 6600 GT a 0.11 micron funziona a 500 Mhz..anche se c'è da dire che è meno complessa....ma anche con un sistema di raffreddamento più economico. Staremo a vedere. :)
Originariamente inviato da yossarian
non solo (e, a dire la verità, neppure il passaggio tra 1.3 a 1.4 si riduceva esclusivamente a quello) ma anche ad una gestione dinamica del flusso di dati Il dynamic branching, ad esempio, dovrebbe servire ad entrambe le cose ma, allo stato attuale, è realizzabile, molto probabilmente, solo nei vs.
Una delle feature più interessanti, il geometry instancing, pare sia possibile anche con R420.
In realtà non è neppure corretto dire "calcoli uguali in meno passaggi"; si dovrebbe invece dire: stesso risultato con meno passaggi, ma non necessariamente calcoli più semplici, anzi, in alcuni casi, il carico di lavoro della gpu può persino aumentare (si può trattare di meno passagi che però coinvolgono più unità di calcolo diverse in contemporanea).
I vantaggi in termini di prestazioni dello SM3.0, comunque, saranno scarsamente fruibili con questa generazioni di gpu (quella che latita è la potenza di calcolo, per quanto possa sembrare strano)
potresti spiegarmi perchè nel control center dei cat 4.10, a me ke ho una 9550, mi appare l'opzione per poter abilitare geometry instancing o meglio il suo supporto?
bYeZ!
Thunder82
04-11-2004, 02:45
Originariamente inviato da ATi7500
potresti spiegarmi perchè nel control center dei cat 4.10, a me ke ho una 9550, mi appare l'opzione per poter abilitare geometry instancing o meglio il suo supporto?
bYeZ!
anche a me lo fa. Con Far Cry e la patch 1.3 puoi attivare il geometry instancing tramite una riga di comando in console e attivandolo nel CCC.
Originariamente inviato da Thunder82
anche a me lo fa. Con Far Cry e la patch 1.3 puoi attivare il geometry instancing tramite una riga di comando in console e attivandolo nel CCC.
si beh in effetti me la riconosce come 9600xt :D
e hai notato miglioramenti?
mi puoi dire il comando per attivarla in farcry?
bYeZ!
Thunder82
04-11-2004, 06:01
Originariamente inviato da ATi7500
si beh in effetti me la riconosce come 9600xt :D
e hai notato miglioramenti?
mi puoi dire il comando per attivarla in farcry?
bYeZ!
io non l'ho attivata ancora. I miglioramenti dovrebbero esserci nella foresta e con tanta erba, soprattutto con cpu poco potenti. In teoria così puoi spostare ancora più lontano il LOD eliminando quasi l'effetto "erba che svanisce dopo qualche metro". Il comando ora non me lo ricordo, cmq nelle ultime pagine del thread di far cry lo trovi :) mi pare che sia \r_geominstancing 1 ma non sono sicuro
Alberto Falchi
04-11-2004, 10:25
Originariamente inviato da yossarian
ripeto, Carmack non si è attenuto alle specifiche ARB2; sarebbe come se si programmasse un gioco in D3D tenendo conto del TAA o del 3Dc o del fatto che R3x0 rende meglio con calcoli in fp misti a texture e fregandosene del fatto che con un input simile i chip NV (soprattutto la serie NV3x) venisse penalizzata o non riuscisse ad esprimersi al meglio; si potrebbe sostenere4 di essersi attenuti alle specifiche dello SM2.x (con qualche aggiunta di feature proprietarie, cosa fatta, per altro, da Carmack), e nessuno potrebbe obiettare: però di fatto si sarebbero favoriti i chip ATi e si sarebbero penalizzati quelli NV.
Bene, Carmack è andato oltre: non si è neppure attenuto strettamente alle spcifiche ARB2 ma le ha modificate con istruzioni proprietarie NV.
Mi diresti dove hai trovato tali informazioni? Insomma.. .una (veloce, lo ammetto) ricerca in rete mi ha solo fatto scoprire che, a un certo punto dello sviluppo, JC ha cassato il path NV30 in favore di ARB2. Ma da nessuna parte ho trovato quanto tu dici.
non mi risulta che esistano path specifiche per R420 o per R300 implementate in Doom3; semmai ne esiste una per R200
Si, vero. R200 e ARB2 per NV40 e R420
fatto ste che NV3x presenta molte lacune in fatto di compatibilità con lo SM2.0 (anche se, secondo i proclami NV, era più avanzato); non supportava il DM (neppure a livello teorico), né il MRT e neppure l'HDR (neanche in forma parziale o incompleta). Inoltre l'FP32 è del tutto inutilizzabile per l'architettura stessa del chip, e l'fp16 stesso crea non pochi problemi: non è male per un chip che avrebbe dovuto superare le specifiche dello SM2.0 e che, invece, spesso era costretto a ricorrere allo SM1.1.
Diciamo che l'utilizzo del mixed code, a sentire nVidia, avrebbe risolto il problema. In realtà, il mixed code era uno sbattimento non da poco per i programmatori, e in effetti nessuno si è mai sbattutto troppo per implementarlo, preferendo puntare sullo standard FP24.
Non è una pazzia, ma scelta di marketing: NV30 non era progettato per lavorare in fp, la cosa è molto semplice, però le specifiche "oltre le DX9" fanno vendere.
Più che fanno vendere, non puoi fare una scheda non compatibile con le ultime DirectX. nVidia, per motivi che sa solo lei, ha preferito puntare su FP32 invece che FP24... e ne ha pagato lo scotto. Di contro, l'architettura era "pronta" per essere evoluta quando lo standard per FP sarebbe stato a 32 bit. Personalmente, non ho mai capito il perché di FP24 in directX: mi è sempre sembrato folle... ma avranno avuto i loro motivi.
E comunque investire tutte le risorse per attenersi alle specifiche di un engine grafico e non della sua API di riferimento è una scelta insensata e poco credibile.
Come dicevo... a quanto ne so, D3 è ARB2, ma sono pronto a farmi smentire non appena mi porti prove. Tralasciando questo, puntare su Doom 3 non è folle: insieme a Source, sarà uno degli engine più utilizzati. Ma tralasciando l'engine in se, sono proprio una serie di calcoli, come le volume shadow, a rappresentare il fulcro di tale architettura. Non a caso, anche 3d MArk 03 aveva dei test sulle volume shadows proprio perché gli engine si sarebbero mossi in quella direzione.
Neppure io lo sono però so qualcosa di chip e anche di brevetti; il fatto che Creative abbia brevettato l'uso delle ombre scelto per Doom non vuol dire niente: l'investimento fatto per ottenere un brevetto non sarà mai paragonabile a quello che si fa per progettare e realizzare un chip;
Non c'entra nulla questo. ho citato l'esempio per indicare che era già noto quale strada avesse intrapreso Carmack, e che quindi mi sembrava logico sviluppare architetture adeguate a sfruttare le sue intuizioni.
In questo caso non si sta puntando su feature proposte da un engine grafico particolare, ma su caratteristiche proposte dalle API di riferimento a cui si rifà l'engine di U3 (ma che non sono peculiarità di Epic ma di tutti coloro che vorranno adottare lo SM3.0 per progettare i loro motori grafici)
Anche qui non hai centrato il punto che volevo toccare. Perché nVidia punta, già da ora, su SM3, al contrario di ATI? La mia risposta è: perché Rein ha bisogno di questo. Certo, fa parte di una API, ma non solo: sarà il fulcro dell'engine. E seocndo te chi ha spinto per far entrare SM3 nelle specifiche DX?
Ripeto: ritengo la posizione di Carmack poco credibile; certo, lui è libero di dire ciò che vuole, però io sono altrettanto libero di non credergli
Sicuro, però potresti anche portare delle prove a sostegno della tua tesi ^_^
Pape
halduemilauno
04-11-2004, 10:27
Originariamente inviato da Dark Schneider
L'architettura NV40 a mio parere è ottima. R420 deve molto alle sue più alte frequenze se riesce a stare sullo stesso livello. :)
Un po' come succedeva tra le 5900 e 9800..ma al contrario. Anche se c'è da dire poi le 5900 avevano anche un architettura non tanto buona, mentre quella dell'R420 è buona. NV40 è meglio.
Sono curioso di vedere il prossimo prodotto nVidia, ossia il NV48 refresh di NV40. Avrà senz'altro un processo produttivo a 0.11 micron. Quindi vedremo il NV40 a frequenze di Core più elevate. Voglio anche vedere di quanto riuscirà a salire Ati invece a livello di frequenze. :) Secondo me Ati salirà ma non moltissimo. Da nVidia mi aspetto almeno un 500 Mhz di Core. La 6600 GT a 0.11 micron funziona a 500 Mhz..anche se c'è da dire che è meno complessa....ma anche con un sistema di raffreddamento più economico. Staremo a vedere. :)
550/1600.
;)
yossarian
04-11-2004, 10:35
Originariamente inviato da ATi7500
potresti spiegarmi perchè nel control center dei cat 4.10, a me ke ho una 9550, mi appare l'opzione per poter abilitare geometry instancing o meglio il suo supporto?
bYeZ!
perchè le uniche vere modifiche tra R300 (e quindi RV3x0) e R420, a livello HW, sono la crossbar connection tra vs e pixel pipeline e il circuito che si occupa di effettuare la 3Dc; tutto il resto, compresi geometry instancing e temporal antialiasing erano già presenti sulla precedente generazione
;)
Originariamente inviato da yossarian
perchè le uniche vere modifiche tra R300 (e quindi RV3x0) e R420, a livello HW, sono la crossbar connection tra vs e pixel pipeline e il circuito che si occupa di effettuare la 3Dc; tutto il resto, compresi geometry instancing e temporal antialiasing erano già presenti sulla precedente generazione
;)
cioè anke rv3x0 è capace di supportare lo sm 2.0b? :confused:
bYeZ!
yossarian
04-11-2004, 12:15
Originariamente inviato da GMCPape
Mi diresti dove hai trovato tali informazioni? Insomma.. .una (veloce, lo ammetto) ricerca in rete mi ha solo fatto scoprire che, a un certo punto dello sviluppo, JC ha cassato il path NV30 in favore di ARB2. Ma da nessuna parte ho trovato quanto tu dici.
Doom in origine, nasce in ARB (all'epoca dell'NV20 da cui Carmack ha preso l'idea di usare lo shadow buffer per le ombre); in seguito, con l'evoluzione dell'OGL, è passato all'ARB2 che, però, prevedendo l'utilizzo di calcoli in fp anche per i ps, non si adattava ai chip più vecchi; sono quindi nate la path NV20 e R200; quando si è accorto che sulla serie NV3x girava male, ha tirato fuori la path NV30 (che non mi risulta sia stata accantonata); quindi, che io sappia, l'engine di Doom3 è in una specie di ARB2 (non proprio standard) con in aggiunta path specifiche per NV20, R200 e NV3x. Al contrario R3x0, NV40 e R420 utilizzano la modalità ARB2. Su questa modalità ARB2, c'è da dire che l'utilizzo (per carità, lecito) di texture dependent read in sostituzione di math ops in tutte le situazioni possibili, favorisce l'architettura dell'NV3x e dell'NV40 che hanno il loro punto debole nell'utilizzo simultaneo di texture ops e math ops e non favorisce R3x0 e R420 che in questa situazione raggiungono il loro picco massimo di operazioni per ciclo di clock (24 per R3x0 e 48 per R420, contro le 32 di NV40 e le 6 dell'NV35).
La path NV30, invece, non fa altro che utilizzare in maniera massiccia operazioni di shader replacement, passando dai ps2.0 agli 1.1. Ovvio che utilizzndo, la dove possibile, dependent read, almeno per la serie NV35, le operazioni di shader replacement si rendono meno necessarie (tanto più che sia le specifiche ARB2 che quelle DX9 prevedono l'utilizzo di fp16 in questo caso l'utilizzo di fp16); diversa la situazione per NV30, perchè, comunque, con quella famiglia di chip è opportuno evitare il più possibile operazioni in fp.
Originariamente inviato da GMCPape
Si, vero. R200 e ARB2 per NV40 e R420
anche su R3x0 gira in ARB2
Originariamente inviato da GMCPape
Diciamo che l'utilizzo del mixed code, a sentire nVidia, avrebbe risolto il problema. In realtà, il mixed code era uno sbattimento non da poco per i programmatori, e in effetti nessuno si è mai sbattutto troppo per implementarlo, preferendo puntare sullo standard FP24.
Pape
non lo sarebbe stato se fosse stato realmente utilizzabile; in passato, ad esempio all'epoca dell'NV15 e dell'R100, c'era una situazione simile: il Radeon lavorava, a livello di pixel pipeline sempre a 32 bit (8 per canale), la GF2 a 16 o a 32 bit a seconda delle impostazioni; il risultato era che nel primo le differenze prestazionali tra 16 e 32 bit erano ridotte a qualche fps (e molti davano la colpa ai drivers immaturi che erano buggati sui 16 bit), mentre la seconda arrivava a differenza anche del'ordine del 60-70% tra le due modalità (con notevole calo di qualità a 16 bit, però). Questo per farti capire che la filosofia della modalità singola è sempre stata nel DNA di ATi, come quella della doppia modalità in quello di nVIDIA. Ora, poiche le DX9a (e b) prevedevano l'uso di fp24 come livello di precisione minimo (in realtà ci sono delle eccezioni che permettono l'utilizzo di modalità a precisione inferiore, come l'fp16 o, addirittura, l'fx12) ATi si è attenuta strettamente a queste specifiche creando, tra le altre cose, un chip che risulta in grado di far girare codice SM2.0 in maniera accettabile; al contrario nVIDIA ha puntato a soddsfare le caratteristiche richiesta da ARB2 e dalle DX9c, però solo sulla carta; la scarsa capacità dei registri temporanei di NV30 potrebbero anche indurre a pensare ad un errore di valutazione, però l'utilizzo di sole 4 fpu (per giunta neppure indipendenti dalle tmu) contro le 8 fxu, fanno pensare ad una scelta progettuale ben precisa che orienta l'NV30 verso lo SM1.x piuttosto che verso il 2.0. Per quello sostengo che la piene compatibilità con le DX9 è più qualcosa di facciata che di realmente fruibile. Certo si può anche far girare del SW in ARB2 o utilizzando lo SM2.0 su NV30, a patto di accontentarsi di frame rate a livello di slow motion.
Originariamente inviato da GMCPape
Più che fanno vendere, non puoi fare una scheda non compatibile con le ultime DirectX. nVidia, per motivi che sa solo lei, ha preferito puntare su FP32 invece che FP24... e ne ha pagato lo scotto. Di contro, l'architettura era "pronta" per essere evoluta quando lo standard per FP sarebbe stato a 32 bit. Personalmente, non ho mai capito il perché di FP24 in directX: mi è sempre sembrato folle... ma avranno avuto i loro motivi.
ripeto quanto sopra: il problema non è fp32 al posto di fp24 ma un chip non in grado di lavorare velocemente in fp (qualcosa è migliorato con NV35 grazie alla sostituzione di 4 fxu con 4 fpu, però è rimasta la dipendenza con le tmu); NV40 non presenta gli stessi problemi di NV3x nell'utilizzo della modalità fp e nel passaggio da fp16 a fp32 perde in prestazioni come è normale che sia, ma il crollo non è così drammatico come faceva registrare la serie NV35 (con un letterale dimezzamento del frame rate). Ancora adesso, in ogni caso, la dove possibile, si fa ricorso a fp16 (in Doom l'utilizzo di fp è ridotto all'osso, se pure si usa da qualche parte, proprio grazie all'uso del dependent read che permette di effettuare calcoli in fp16).
La scelta di fp24 (come modalità minima, bada bene, non come modalità unica; quindi anche fp32 va benissimo) non è tanto folle o strana, soprattutto alla luce di quello che avveniva con le precedenti versioni. Lo SM1.1 (e quindi l'1.3) prevede l'uso di fx12 per i ps e di fp32 per i vs (modalità impiegata sui chip NV20 e NV25) mentre con le 1.4 si passa a fx16 per i ps e fp32 per i vs (come sull'R200). La modalità minima indica semplicemente il numero di bit a la tipologia di calcoli necessari a rendere al meglio gli effetti che quella API vuole introdurre. Se si è ritenuto sufficiente adottare 24 bit sarebbe stato insensato fissare come modalità minima la fp32, così come sarebbe risulatto insufficiente la fp16 (in realtà, come ho detto, le specifiche DX9 sono più complesse e prevedono l'uso di più modalità a seconda del tipo di calcolo da effettuare).
Originariamente inviato da GMCPape
Come dicevo... a quanto ne so, D3 è ARB2, ma sono pronto a farmi smentire non appena mi porti prove. Tralasciando questo, puntare su Doom 3 non è folle: insieme a Source, sarà uno degli engine più utilizzati. Ma tralasciando l'engine in se, sono proprio una serie di calcoli, come le volume shadow, a rappresentare il fulcro di tale architettura. Non a caso, anche 3d MArk 03 aveva dei test sulle volume shadows proprio perché gli engine si sarebbero mossi in quella direzione.
Doom3 è in ARB2 (con l'aggiunta di qualche estensione proprietaria NV) ma non gira in ARB2 su NV3x, ma solo su R3x0, R420 e NV40 (con i vantaggi, per NV40, di cui ho parlato sopra).
Gli engine si sono mossi anche in direzione delle n-patches per le HOS, eppure su NV3x non c'è il supporto a questa feature, introdotta da ATi con l'R200 e il truform (tanto che le stesse DX9 hanno adottato l'uso delle n-patches per generare HOS). In ogni caso il vantaggio per nVIDIA, derivante dall'uso delle volume shadow non è paragonabile a quello derivante dalle dependent read; la dimostrazione è che è stata sufficiente una patch (contenuta anche nelle ultime release di catalyst) che sostituisca dependent read con calcoli matematici per far incrementare le prestazioni dei chip ATi di un buon 25-30% (forse più) con Doom3.
L'engine di Doom3 sarà sicuramente molto usato (anche per la fama di ID e del titolo stesso), però nasce già vecchio, proprio per l'utilizzo che viene fatto dei ps.
Originariamente inviato da GMCPape
Non c'entra nulla questo. ho citato l'esempio per indicare che era già noto quale strada avesse intrapreso Carmack, e che quindi mi sembrava logico sviluppare architetture adeguate a sfruttare le sue intuizioni.
in realtà Carmack non ha avuto intuizioni geniali o meno; ha fatto semplicemente uso dello shadow buffer (già presente sull'NV20) per le volume shadow (con estensioni esposte con NV25, di cui una la ARB shadow rientrante nelle spcifiche dello SM1.4 e le ext shadow funcs, proprietarie)
Originariamente inviato da GMCPape
Anche qui non hai centrato il punto che volevo toccare. Perché nVidia punta, già da ora, su SM3, al contrario di ATI? La mia risposta è: perché Rein ha bisogno di questo. Certo, fa parte di una API, ma non solo: sarà il fulcro dell'engine. E seocndo te chi ha spinto per far entrare SM3 nelle specifiche DX?
Pape
lo SM3.0 era già noto ai tempi dell'uscita delle specifiche delle prime DX9, ossia ben prima della presentazione dell'R300; inoltre mi sembra poco credibile che MS si lasci imporre qualcosa da qualcuno. Nel 2006 non ci sarà solo l'engine di U3 a far uso dello SM3.0 (e tocca anche vedere in che misura lo useranno) e per allora ci saranno anche chip ATi SM3.0 compliant (il primo uscirà attorno alla metà del 2005 con processo a 0,9 u).
Che nVIDIA abbia già adottato lo SM3.0 è apprezzabile, però, allo stato attuale, non gli porterà benefici. La situazione presenta delle analogie con quella del 2000, con l'R100 che implementava, anche se utilizzando fixed function e in maniera piuttosto primitiva, alcune feature che sarebbero state successivamente utilizzate sui chip con unità programmabile (keyframe interpolation e skeletal animation, tanto per citarne un paio)
Originariamente inviato da GMCPape
Sicuro, però potresti anche portare delle prove a sostegno della tua tesi ^_^
Pape
se potessi, soddisferei volentieri la tua curiosità
yossarian
04-11-2004, 12:31
Originariamente inviato da ATi7500
cioè anke rv3x0 è capace di supportare lo sm 2.0b? :confused:
bYeZ!
si, almeno per buona parte; questa per i non addetti ai lavori è una delle tante sorprese di R3x0 e RV3x0, per gli addetti ai lavori era cosa già nota (io, comunque, vi avevo avvertiti che R300 andava oltre le specifiche Dx9.a :D ).
Ti faccio l'esempio del TAA (perchè è qualcosa a cui si sarebbe potuto arrivare con un semplice ragionamento) introdotto apparentemente con R420. Se si vanno ad analizzare le modalità di AA dell'R300 si vede che si ha una 4x e poi una 6x definita "ibrida", perchè non era ben chiaro con quale tipo di griglia si fosse ottenuta. In realtà è una 4x RG combinata con una 2x ottenuta dopo una rotazione delle griglia di campionamento; conclusione, la griglia dell'R300 è in grado di ruotare esattamente come quella dell'R420 (basta solo dargli le istruzioni per farlo).
halduemilauno
04-11-2004, 12:36
Originariamente inviato da yossarian
Doom in origine, nasce in ARB (all'epoca dell'NV20 da cui Carmack ha preso l'idea di usare lo shadow buffer per le ombre); in seguito, con l'evoluzione dell'OGL, è passato all'ARB2 che, però, prevedendo l'utilizzo di calcoli in fp anche per i ps, non si adattava ai chip più vecchi; sono quindi nate la path NV20 e R200; quando si è accorto che sulla serie NV3x girava male, ha tirato fuori la path NV30 (che non mi risulta sia stata accantonata); quindi, che io sappia, l'engine di Doom3 è in una specie di ARB2 (non proprio standard) con in aggiunta path specifiche per NV20, R200 e NV3x. Al contrario R3x0, NV40 e R420 utilizzano la modalità ARB2. Su questa modalità ARB2, c'è da dire che l'utilizzo (per carità, lecito) di texture dependent read in sostituzione di math ops in tutte le situazioni possibili, favorisce l'architettura dell'NV3x e dell'NV40 che hanno il loro punto debole nell'utilizzo simultaneo di texture ops e math ops e non favorisce R3x0 e R420 che in questa situazione raggiungono il loro picco massimo di operazioni per ciclo di clock (24 per R3x0 e 48 per R420, contro le 32 di NV40 e le 6 dell'NV35).
La path NV30, invece, non fa altro che utilizzare in maniera massiccia operazioni di shader replacement, passando dai ps2.0 agli 1.1. Ovvio che utilizzndo, la dove possibile, dependent read, almeno per la serie NV35, le operazioni di shader replacement si rendono meno necessarie (tanto più che sia le specifiche ARB2 che quelle DX9 prevedono l'utilizzo di fp16 in questo caso l'utilizzo di fp16); diversa la situazione per NV30, perchè, comunque, con quella famiglia di chip è opportuno evitare il più possibile operazioni in fp.
anche su R3x0 gira in ARB2
non lo sarebbe stato se fosse stato realmente utilizzabile; in passato, ad esempio all'epoca dell'NV15 e dell'R100, c'era una situazione simile: il Radeon lavorava, a livello di pixel pipeline sempre a 32 bit (8 per canale), la GF2 a 16 o a 32 bit a seconda delle impostazioni; il risultato era che nel primo le differenze prestazionali tra 16 e 32 bit erano ridotte a qualche fps (e molti davano la colpa ai drivers immaturi che erano buggati sui 16 bit), mentre la seconda arrivava a differenza anche del'ordine del 60-70% tra le due modalità (con notevole calo di qualità a 16 bit, però). Questo per farti capire che la filosofia della modalità singola è sempre stata nel DNA di ATi, come quella della doppia modalità in quello di nVIDIA. Ora, poiche le DX9a (e b) prevedevano l'uso di fp24 come livello di precisione minimo (in realtà ci sono delle eccezioni che permettono l'utilizzo di modalità a precisione inferiore, come l'fp16 o, addirittura, l'fx12) ATi si è attenuta strettamente a queste specifiche creando, tra le altre cose, un chip che risulta in grado di far girare codice SM2.0 in maniera accettabile; al contrario nVIDIA ha puntato a soddsfare le caratteristiche richiesta da ARB2 e dalle DX9c, però solo sulla carta; la scarsa capacità dei registri temporanei di NV30 potrebbero anche indurre a pensare ad un errore di valutazione, però l'utilizzo di sole 4 fpu (per giunta neppure indipendenti dalle tmu) contro le 8 fxu, fanno pensare ad una scelta progettuale ben precisa che orienta l'NV30 verso lo SM1.x piuttosto che verso il 2.0. Per quello sostengo che la piene compatibilità con le DX9 è più qualcosa di facciata che di realmente fruibile. Certo si può anche far girare del SW in ARB2 o utilizzando lo SM2.0 su NV30, a patto di accontentarsi di frame rate a livello di slow motion.
ripeto quanto sopra: il problema non è fp32 al posto di fp24 ma un chip non in grado di lavorare velocemente in fp (qualcosa è migliorato con NV35 grazie alla sostituzione di 4 fxu con 4 fpu, però è rimasta la dipendenza con le tmu); NV40 non presenta gli stessi problemi di NV3x nell'utilizzo della modalità fp e nel passaggio da fp16 a fp32 perde in prestazioni come è normale che sia, ma il crollo non è così drammatico come faceva registrare la serie NV35 (con un letterale dimezzamento del frame rate). Ancora adesso, in ogni caso, la dove possibile, si fa ricorso a fp16 (in Doom l'utilizzo di fp è ridotto all'osso, se pure si usa da qualche parte, proprio grazie all'uso del dependent read che permette di effettuare calcoli in fp16).
La scelta di fp24 (come modalità minima, bada bene, non come modalità unica; quindi anche fp32 va benissimo) non è tanto folle o strana, soprattutto alla luce di quello che avveniva con le precedenti versioni. Lo SM1.1 (e quindi l'1.3) prevede l'uso di fx12 per i ps e di fp32 per i vs (modalità impiegata sui chip NV20 e NV25) mentre con le 1.4 si passa a fx16 per i ps e fp32 per i vs (come sull'R200). La modalità minima indica semplicemente il numero di bit a la tipologia di calcoli necessari a rendere al meglio gli effetti che quella API vuole introdurre. Se si è ritenuto sufficiente adottare 24 bit sarebbe stato insensato fissare come modalità minima la fp32, così come sarebbe risulatto insufficiente la fp16 (in realtà, come ho detto, le specifiche DX9 sono più complesse e prevedono l'uso di più modalità a seconda del tipo di calcolo da effettuare).
Doom3 è in ARB2 (con l'aggiunta di qualche estensione proprietaria NV) ma non gira in ARB2 su NV3x, ma solo su R3x0, R420 e NV40 (con i vantaggi, per NV40, di cui ho parlato sopra).
Gli engine si sono mossi anche in direzione delle n-patches per le HOS, eppure su NV3x non c'è il supporto a questa feature, introdotta da ATi con l'R200 e il truform (tanto che le stesse DX9 hanno adottato l'uso delle n-patches per generare HOS). In ogni caso il vantaggio per nVIDIA, derivante dall'uso delle volume shadow non è paragonabile a quello derivante dalle dependent read; la dimostrazione è che è stata sufficiente una patch (contenuta anche nelle ultime release di catalyst) che sostituisca dependent read con calcoli matematici per far incrementare le prestazioni dei chip ATi di un buon 25-30% (forse più) con Doom3.
L'engine di Doom3 sarà sicuramente molto usato (anche per la fama di ID e del titolo stesso), però nasce già vecchio, proprio per l'utilizzo che viene fatto dei ps.
in realtà Carmack non ha avuto intuizioni geniali o meno; ha fatto semplicemente uso dello shadow buffer (già presente sull'NV20) per le volume shadow (con estensioni esposte con NV25, di cui una la ARB shadow rientrante nelle spcifiche dello SM1.4 e le ext shadow funcs, proprietarie)
lo SM3.0 era già noto ai tempi dell'uscita delle specifiche delle prime DX9, ossia ben prima della presentazione dell'R300; inoltre mi sembra poco credibile che MS si lasci imporre qualcosa da qualcuno. Nel 2006 non ci sarà solo l'engine di U3 a far uso dello SM3.0 (e tocca anche vedere in che misura lo useranno) e per allora ci saranno anche chip ATi SM3.0 compliant (il primo uscirà attorno alla metà del 2005 con processo a 0,9 u).
Che nVIDIA abbia già adottato lo SM3.0 è apprezzabile, però, allo stato attuale, non gli porterà benefici. La situazione presenta delle analogie con quella del 2000, con l'R100 che implementava, anche se utilizzando fixed function e in maniera piuttosto primitiva, alcune feature che sarebbero state successivamente utilizzate sui chip con unità programmabile (keyframe interpolation e skeletal animation, tanto per citarne un paio)
se potessi, soddisferei volentieri la tua curiosità
capito tutto. tranne una cosa. chi è o cos'è il Dunsinane?
ciao Yossi sei troppo forte.
;)
yossarian
04-11-2004, 12:39
Originariamente inviato da halduemilauno
capito tutto. tranne una cosa. chi è o cos'è il Dunsinane?
ciao Yossi sei troppo forte.
;)
l'ho preso dal MacBeth; è la frase che una delle tre streghe dice a MacBeth, dopo che gli è stato predetto che sarebbe diventato re.
Dunsinane è il castello di MacBeth e il bosco di Birnan è un bosco nei paraggi.
ciao Hal
;)
Alberto Falchi
04-11-2004, 12:57
Originariamente inviato da yossarian
in seguito, con l'evoluzione dell'OGL, è passato all'ARB2 che, però, prevedendo l'utilizzo di calcoli in fp anche per i ps, non si adattava ai chip più vecchi; sono quindi nate la path NV20 e R200; quando si è accorto che sulla serie NV3x girava male, ha tirato fuori la path NV30 (che non mi risulta sia stata accantonata);
Comprendo la necessità di questo path ai tempi (l'architettura nVidia, soprattutto su fascia medio/bassa, era molto diffusa allora, e deteneva gran parte del mercato).
Su questa modalità ARB2, c'è da dire che l'utilizzo (per carità, lecito) di texture dependent read in sostituzione di math ops in tutte le situazioni possibili, favorisce l'architettura dell'NV3x e dell'NV40 che hanno il loro punto debole nell'utilizzo simultaneo di texture ops e math ops e non favorisce R3x0 e R420 che in questa situazione raggiungono il loro picco massimo di operazioni per ciclo di clock (24 per R3x0 e 48 per R420, contro le 32 di NV40 e le 6 dell'NV35).
Esatto. Ma rimane da capire (edè il fulcro di questo scambio di opinioni) se la scelta di tali operazioni sia stata fatta per favorire nVidia o per motivi di carattere tecnico. OK, il TDR favorisce nVidia, e siamo d'accordo, ma siamo sicuro che non fosse la via migliore da utiilizzare (perché è più veloce in genreale, peché meglio si adatta a certi calcoli, o semplicemente perché a JC piace programmare così)?.
ATi si è attenuta strettamente a queste specifiche creando, tra le altre cose, un chip che risulta in grado di far girare codice SM2.0 in maniera accettabile; al contrario nVIDIA ha puntato a soddsfare le caratteristiche richiesta da ARB2 e dalle DX9c, però solo sulla carta; la scarsa capacità dei registri temporanei di NV30 potrebbero anche indurre a pensare ad un errore di valutazione, però l'utilizzo di sole 4 fpu (per giunta neppure indipendenti dalle tmu) contro le 8 fxu, fanno pensare ad una scelta progettuale ben precisa che orienta l'NV30 verso lo SM1.x piuttosto che verso il 2.0. Per quello sostengo che la piene compatibilità con le DX9 è più qualcosa di facciata che di realmente fruibile.
Su questo siamo pienamente d'accordo: la serie NV3X non era all'altezza della concorrenza nel caso di SM2. Più che di facciata, però, si trattava di necessità: non vorrai fare mica una scheda non compatibile (anche se lenta) con le DX più recenti? Un errore di progetto, sicuramente, e nVidia lo ha pagato caro.
Se si è ritenuto sufficiente adottare 24 bit sarebbe stato insensato fissare come modalità minima la fp32, così come sarebbe risulatto insufficiente la fp16 (in realtà, come ho detto, le specifiche DX9 sono più complesse e prevedono l'uso di più modalità a seconda del tipo di calcolo da effettuare).
Il punto è proprio questo. Siamo sicuro che 24 bit bastassero? Io non ne sono certo, e infatti non si è visto uso di HDR, fino a ora. Del resto, nella maggior parte dei casi 16 bit bastano e avanzano, mentre quando davvero servono precisioni elevate, come nel caso di HDR, 24 non sono sufficienti. è per questo che mi chiedo come mai non è stato introdotto da subito FP32, passando per gli "inutili" FP24. ATI è stata ovviamente avvantaggiata in quanto, nel caso di nVidia, la FP era troppo lenta, e la PP a 16 bit presentava gli evidenti problemi di banding che tutti conoscono. Ciò in ogni caso non toglie che la serie NV3X non fosse all'altezza della situazione.
In ogni caso il vantaggio per nVIDIA, derivante dall'uso delle volume shadow non è paragonabile a quello derivante dalle dependent read; la dimostrazione è che è stata sufficiente una patch (contenuta anche nelle ultime release di catalyst) che sostituisca dependent read con calcoli matematici per far incrementare le prestazioni dei chip ATi di un buon 25-30% (forse più) con Doom3.
Creando tra l'altro problemi di visualizzazione, come fa notare lo stesso Carmack. Humus ha fatto un'enorme idiozia con tale patch, danneggiando tra l'altro l'azienda per cui lavora. Un 20/30% di guadagno coisì ottenuto è pari alle cheat di nVidia su 3D MArk, o a quelle di ATI sulle vecchie Radeon con Q3.
L'engine di Doom3 sarà sicuramente molto usato (anche per la fama di ID e del titolo stesso), però nasce già vecchio, proprio per l'utilizzo che viene fatto dei ps.
Nasce sicuramente "vecchio", ma considerando il lungo periodo di gestazione, non me ne stupisco. Del resto, non credo nemmeno che Source nasca "nuovissimo", pur supportando anche 3Dc. Calcolando che per fare un engine a tali livelli ci vogliono anni, non mi stupisco che alcune scelte alla base si possano considerare anacronistiche rispetto al potenziale delle ultime GPU.
Del resto il focus di D3 sono le ombre, non certo gli shader. Come si puòà vedere dai limiti di alcune texture, probabilmente dovuti anche alla mancanza di un HLSL di qualità in ambito OGL.
in realtà Carmack non ha avuto intuizioni geniali o meno; ha fatto semplicemente uso dello shadow buffer (già presente sull'NV20) per le volume shadow (con estensioni esposte con NV25, di cui una la ARB shadow rientrante nelle spcifiche dello SM1.4 e le ext shadow funcs, proprietarie)
la genialità è stato l'utilizzo creativo che ne ha fatto. Le volume shadow non sono una novità in ambito tecnico, ma in ambito di gameplay.
lo SM3.0 era già noto ai tempi dell'uscita delle specifiche delle prime DX9, ossia ben prima della presentazione dell'R300; inoltre mi sembra poco credibile che MS si lasci imporre qualcosa da qualcuno.
MS ha creato delle DX senza ascoltare gli sviluppatori. E per anni, infatti,. tutti i giochi 3D usavano Glide oppure OGL. Dalla release 6 in poi, l'azienda di Redmond ha capito che le sue DX dovevano essere uno strumento per i programmatori, e ha iniziato a sviluppare in relazione alle loro esigenze. A MS non interessa imporre certe specifiche: MS non fa GPU. A MS interessa un ambiente comodo per gli sviluppatori, che li porti ad abbandonare OGL per dedicarsi solo alla piattaforma Windows (e xbox, ovviamente). Quindi ha tutto l'interesse a "farsi imporre" le specifiche.
Nel 2006 non ci sarà solo l'engine di U3 a far uso dello SM3.0 (e tocca anche vedere in che misura lo useranno) e per allora ci saranno anche chip ATi SM3.0 compliant (il primo uscirà attorno alla metà del 2005 con processo a 0,9 u).
Sicuro. Però allo stato attuale Rein collabora attivamente (come ha fatto Carmack in passato per NV30 e NV40) con nVidia per lo sviluppo di NV50.
Che nVIDIA abbia già adottato lo SM3.0 è apprezzabile, però, allo stato attuale, non gli porterà benefici. La situazione presenta delle analogie con quella del 2000, con l'R100 che implementava, anche se utilizzando fixed function e in maniera piuttosto primitiva, alcune feature che sarebbero state successivamente utilizzate sui chip con unità programmabile (keyframe interpolation e skeletal animation, tanto per citarne un paio)
Ora come ora non serve, ma l'averlo introdotto adesso permette a tutti i programmatori di prendere confidenza con l'ambiente, e all'azienda californiana di scoprire in anticipo eventuali magagne, in modo da fare il possibile per poterle correggere in tempo quando uscirà la nuova generazione.
Pape
Originariamente inviato da GMCPape
Si, ma le api di riferimento come vengono scelte? Dai produttori, come indichi giustamente. Ma i produttori, a quanto mi è dato di sapere, si consultano eccome coi guru della programmazione per capire quali siano le loro reali necessità. Le API alla fine sono basate sulle principali esigenze di chi il 3D lo realizza. E esiste un Deus ex Machina che dal nulla decide quali siano le spec più importanti per uno sviluppatore di giochi innovatore, quale un Carmak o un Rein?
L'API delle DirectX e' disegnata da Microsoft in base ai suggerimenti che vengono da un consorzio del quale fanno parte gli IHV (NVIDIA e ATI) e alcuni sviluppatori (ID, Valve, Lionhead, Blizzard e altri che a memoria non ricordo).
Il processo di definizione di OpenGL e' simile.
Si dovrebbe mettere in evidenza questo thread per leggerlo con calma...ho già comprato il marmo per le vostre statue....:D
Come si puòà vedere dai limiti di alcune texture, probabilmente dovuti anche alla mancanza di un HLSL di qualità in ambito OGL.
I limiti sulle texture dipendono dalla memoria video onboard che abbiamo attualmente sulle sk video,la colpa dell'insufficienza di memoria è dovuta alla tecnica utilizzata per le ombre in Doom3.
Alberto Falchi
04-11-2004, 13:33
Originariamente inviato da R@nda
I limiti sulle texture dipendono dalla memoria video onboard che abbiamo attualmente sulle sk video,la colpa dell'insufficienza di memoria è dovuta alla tecnica utilizzata per le ombre in Doom3.
Non intendevo le dimensioni delle texture, quanto l'utilizzo dei PS su di esse. Texture anche semplici possono miracolosamente miglirare con un accorto uso di PS, ma in Doom 3 oggettivamente si è puntato su altro
Pape
Ah ok,si è vero,più volte qui si sono lamentati della semplicità degli shader in Doom3.
(Comunque gira gira si torna sempre a parlare di Doom3...non è possibile :p ).
yossarian
04-11-2004, 14:16
Originariamente inviato da GMCPape
Esatto. Ma rimane da capire (edè il fulcro di questo scambio di opinioni) se la scelta di tali operazioni sia stata fatta per favorire nVidia o per motivi di carattere tecnico. OK, il TDR favorisce nVidia, e siamo d'accordo, ma siamo sicuro che non fosse la via migliore da utiilizzare (perché è più veloce in genreale, peché meglio si adatta a certi calcoli, o semplicemente perché a JC piace programmare così)?.
in realtà non esistono prove (e meno male :D ) che Carmack abbia voluto favorire nVIDIA, però resta il fatto che tutte le sue scelte vanno nella stessa direzione e questo non sposta la questione: le scelte di Carmack hanno, in ogni caso, favorito nVIDIA, prendendo spunto da tecniche proprietarie o utilizzando modalità di rendering più amichevoli con i chip NV; d'altra parte, per sua stessa ammissione, ha sviluppato Doom su NV30; ora, se lo ha fatto perchè riteneva l'architettura nVIDIA più consona alle sue idee o se lo ha fatto per favorire i chip NV (che, oggettivamente, erano quelli più bisognosi di aiuto), non cambia nella sostanza il risultato. Sicuramente le DTR sono più veloci sui chip NV (le specifiche SM2.0 prevedono un massimo di 4 dependent texture, mentre lo SM3.0 ne prevede un numero illimitato, limitato, ovviamente, solo dalla capacità fisica del registro); per i chip ATi sarebbe stato meglio fare massiccio ricorso all'utilizzo di istruzioni matematiche
Originariamente inviato da GMCPape
Il punto è proprio questo. Siamo sicuro che 24 bit bastassero? Io non ne sono certo, e infatti non si è visto uso di HDR, fino a ora. Del resto, nella maggior parte dei casi 16 bit bastano e avanzano, mentre quando davvero servono precisioni elevate, come nel caso di HDR, 24 non sono sufficienti. è per questo che mi chiedo come mai non è stato introdotto da subito FP32, passando per gli "inutili" FP24. ATI è stata ovviamente avvantaggiata in quanto, nel caso di nVidia, la FP era troppo lenta, e la PP a 16 bit presentava gli evidenti problemi di banding che tutti conoscono. Ciò in ogni caso non toglie che la serie NV3X non fosse all'altezza della situazione.
con le specifiche 9b i 24 bit minimi erano sufficienti; se finora non si è visto l'HDR (che si potrebbe ottenere anche con 16 bit, come ha tentato di fare Valve e non so se ci sia riuscita o meno) è perchè l'HW di riferimento non era in grado di far elaborarlo con un frame rate accettabile; inoltre il supporto all'HDR della serie NV3x è praticamente inesistente, per l'R3x0 e l'R420 e solo parziale e, quindi, deve essere, almeno in parte, emulato (con ulteriore calo del framerate). NV40 è l'unico chip con supporto completo in HW (anche se, poi, è da vedere come girerebbe con HDR a fp32).
I problemi di banding sono stati un po' enfatizzati quando si è presentata l'fp32; la full precision è necessaria solo in alcuni casi particolarissimi, oppure in presenza di shader molto lunghi in cui gli errori di approssimazione si sommano, dando luogo ad un errore finale non accettabile. Finora, però, gli shader adoperati sono molto corti e questo fa si che non sia mai stato richiesto l'uso di una modalità superiore a fp16. Inoltre, una volta minimizzato il problema della propagazione degli errori, bisogna tener conto del fatto che le immagini, formate nel frame buffer, hanno solo 8 bit per ciascuno dei 4 canali (10+10+10+4 per Parhelia e R3x0).
Originariamente inviato da GMCPape
Creando tra l'altro problemi di visualizzazione, come fa notare lo stesso Carmack. Humus ha fatto un'enorme idiozia con tale patch, danneggiando tra l'altro l'azienda per cui lavora. Un 20/30% di guadagno coisì ottenuto è pari alle cheat di nVidia su 3D MArk, o a quelle di ATI sulle vecchie Radeon con Q3.
non mi riferivo alla patch di humus (che ha solo aperto la strada e il cui guadagno si aggira intorno ad un 40%) ma a quelkla analoga (anche se meno "spinta") dei catalyst che non mi risulta dia problemi di visualizzaione.
Originariamente inviato da GMCPape
Nasce sicuramente "vecchio", ma considerando il lungo periodo di gestazione, non me ne stupisco. Del resto, non credo nemmeno che Source nasca "nuovissimo", pur supportando anche 3Dc. Calcolando che per fare un engine a tali livelli ci vogliono anni, non mi stupisco che alcune scelte alla base si possano considerare anacronistiche rispetto al potenziale delle ultime GPU.
Del resto il focus di D3 sono le ombre, non certo gli shader. Come si puòà vedere dai limiti di alcune texture, probabilmente dovuti anche alla mancanza di un HLSL di qualità in ambito OGL.
beh, un GLSL è stato introdotto, seppure opzionale, con le OGL1.5 (anzi le OGL1.5 sono state "inventate" proprio per introdurre un linguaggio ad alto livello, visto che non ci si decide a far uscire le 2.0 a causa di disaccordi sulle estensioni da includere in questa versione).
Originariamente inviato da GMCPape
la genialità è stato l'utilizzo creativo che ne ha fatto. Le volume shadow non sono una novità in ambito tecnico, ma in ambito di gameplay.
però ha, comunque, sfruttato una feature proposta di nVIDIA; per carità, sicuramente valida (anche se l'utilizzo dello shadow buffer non sempre è possibile). Non metto in dubbio la genialità di Carmack, ma mi lasciano perplesso certe sue scelte
Originariamente inviato da GMCPape
MS ha creato delle DX senza ascoltare gli sviluppatori. E per anni, infatti,. tutti i giochi 3D usavano Glide oppure OGL. Dalla release 6 in poi, l'azienda di Redmond ha capito che le sue DX dovevano essere uno strumento per i programmatori, e ha iniziato a sviluppare in relazione alle loro esigenze. A MS non interessa imporre certe specifiche: MS non fa GPU. A MS interessa un ambiente comodo per gli sviluppatori, che li porti ad abbandonare OGL per dedicarsi solo alla piattaforma Windows (e xbox, ovviamente). Quindi ha tutto l'interesse a "farsi imporre" le specifiche.
MS ascolta gli sviluppatori, ascolta i produttori di HW, però, alla fine decide lei cosa fare e come farlo; è ovvio che ci si consulti con chi deve utilizzare quelle API per creare giochi e con chi deve progettare HW per farle girare, ma non c'è nessuno che può "imporre" una sua scelta senza l'avallo di MS. Non è detto che le sue scelte siano dettate sempre da ragioni tecniche e siano le più corrette, però è così. Un esempio è quello delle n-patches: sono uno dei tanti algoritmi per generare HOS e non è detto che, in assoluto, sia il migliore; però è stato scelto ufficialemnte per le specifiche DX9 ed è stato scelto in un periodo in cui si iniziaveno ad allacciare rapporti "cordiali" tra ATi e MS, in previsione della realizzazione dell'x-box2. Risultato NV3x non ha il supporto per le n-patches (per scelta di nVIDIA) e quindi non è compatibile in HW con la generazione di HOS.
Carmack non ne ha fatto uso in Doom3 (engine con un numero esiguo di poligoni se paragonato ad altri) dicendo che l'impiego di questa tecnica avrebbe creato problemi con la gestione delle ombre, causando rallentamenti nell'elaborazione. Avrà sicuramente ragione lui, però molti programmatori sono scettici; sicuramente l'utilizzo di n-patches avrebbe penalizzato i chip NV3x che avrebbero dovuto emulare queste funzioni.
Originariamente inviato da GMCPape
Sicuro. Però allo stato attuale Rein collabora attivamente (come ha fatto Carmack in passato per NV30 e NV40) con nVidia per lo sviluppo di NV50.
Rein ha collaborato anche in passato con nVIDIA; c'è stato un caso, col motore di UT2003 che ha fatto gridare al cheating nei confronti di ATi e poi si è scoperto che dipendeva dalla scelta non convenzionale del valore del LoD da parte di Epic che dava artefatti sull'R3x0, mentre era visualizzato correttamente su NV3x (il discorso è piuttosto lungo e coinvolge le scelte fatte da ATi e nVIDIA suk numero di bit per rappresentare il LoD e le scelte di Epic sul LoD minimo per il texture mapping).
Originariamente inviato da GMCPape
Ora come ora non serve, ma l'averlo introdotto adesso permette a tutti i programmatori di prendere confidenza con l'ambiente, e all'azienda californiana di scoprire in anticipo eventuali magagne, in modo da fare il possibile per poterle correggere in tempo quando uscirà la nuova generazione.
Pape
questo è sicuramente vero
ciao
yossarian
04-11-2004, 14:22
Originariamente inviato da fek
L'API delle DirectX e' disegnata da Microsoft in base ai suggerimenti che vengono da un consorzio del quale fanno parte gli IHV (NVIDIA e ATI) e alcuni sviluppatori (ID, Valve, Lionhead, Blizzard e altri che a memoria non ricordo).
Il processo di definizione di OpenGL e' simile.
non ci posso credere..................il mio sviluppatore di SW preferito
;)
Alberto Falchi
04-11-2004, 14:43
Originariamente inviato da yossarian
in realtà non esistono prove (e meno male :D ) che Carmack abbia voluto favorire nVIDIA, però resta il fatto che tutte le sue scelte vanno nella stessa direzione e questo non sposta la questione: le scelte di Carmack hanno, in ogni caso, favorito nVIDIA, prendendo spunto da tecniche proprietarie o utilizzando modalità di rendering più amichevoli con i chip NV; d'altra parte, per sua stessa ammissione, ha sviluppato Doom su NV30; ora, se lo ha fatto perchè riteneva l'architettura nVIDIA più consona alle sue idee o se lo ha fatto per favorire i chip NV (che, oggettivamente, erano quelli più bisognosi di aiuto), non cambia nella sostanza il risultato. Sicuramente le DTR sono più veloci sui chip NV (le specifiche SM2.0 prevedono un massimo di 4 dependent texture, mentre lo SM3.0 ne prevede un numero illimitato, limitato, ovviamente, solo dalla capacità fisica del registro); per i chip ATi sarebbe stato meglio fare massiccio ricorso all'utilizzo di istruzioni matematiche
In generale, indipendentemente dai motivi, D3 gira meglio su nVidia, e su questo ci siamo. Come HL sembra digerire meglio ATI, del resto. Per fortuna, direi anche ^_^. I programmatori sono parecchi, e ognuno sceglie la tecnica che più gli aggrada, il che è un bene in quanto non viene decretata una sola architettura, ma vengono valorizzate tutte quelle esistenti. Quesitoni di marketing o di casualità che siano, credo sia un bene per giocatori.
con le specifiche 9b i 24 bit minimi erano sufficienti; se finora non si è visto l'HDR (che si potrebbe ottenere anche con 16 bit, come ha tentato di fare Valve e non so se ci sia riuscita o meno) è perchè l'HW di riferimento non era in grado di far elaborarlo con un frame rate accettabile; inoltre il supporto all'HDR della serie NV3x è praticamente inesistente, per l'R3x0 e l'R420 e solo parziale e, quindi, deve essere, almeno in parte, emulato (con ulteriore calo del framerate).
HDR probabilmente su NV3X sarebbe stato lento, ma credo che usato intelligentemente sarebbe stato implementabile in molti engine, almeno attraverso un intelligente uso di FP16 e FP32. Ovviamente, essendo la generazione precedente dettata da ATI, i programmatori non hanno sentito la necessità di inserirlo a tutti i costi. Ma credo che sarà una feature fondamentale, d'ora in poi.
NV40 è l'unico chip con supporto completo in HW (anche se, poi, è da vedere come girerebbe con HDR a fp32).
I problemi di banding sono stati un po' enfatizzati quando si è presentata l'fp32; la full precision è necessaria solo in alcuni casi particolarissimi, oppure in presenza di shader molto lunghi in cui gli errori di approssimazione si sommano, dando luogo ad un errore finale non accettabile. Finora, però, gli shader adoperati sono molto corti e questo fa si che non sia mai stato richiesto l'uso di una modalità superiore a fp16.
Esatto, ma chiediamoci perché gli shader sono corti. L'architettura nVidia, sebbene meno efficiente, avrebbe permesso l'uso di shader lunghi e di HDR, ma non essendo supportati da ATI, sarebbe stato un suicidio puntare su queste feature. Insomma.. ATI (un plauso a lei) si è imposta, e questo ha creato anche dei problemi alle feature positive dell'architettura nVidia, che non ha potuto esprimere al meglio il proprio potenziale.
Inoltre, una volta minimizzato il problema della propagazione degli errori, bisogna tener conto del fatto che le immagini, formate nel frame buffer, hanno solo 8 bit per ciascuno dei 4 canali (10+10+10+4 per Parhelia e R3x0).
NOn sono certo che R3X0 supporti un FB a 10 bit.. mi sembra che sia una peculiarità di Parhelia, ma potrei sbagliarmi. In ogni caso, tali vantaggi sono relativi sino all'uscita di Longhorn, dato che WinXP non supporta i 10 bit di canale per colore, e quindi tale vantaggio è limitato a pochi casi. Ritengo che sia più importante il supporto a FP32 che al FB da 10 bit per canale, ora come ora. Con Longhorn, tale feature sarà invece molto importante.
non mi riferivo alla patch di humus (che ha solo aperto la strada e il cui guadagno si aggira intorno ad un 40%) ma a quelkla analoga (anche se meno "spinta") dei catalyst che non mi risulta dia problemi di visualizzaione.
Su questo non saprei che dirti, dato che non ho avuto modo di provarla.
beh, un GLSL è stato introdotto, seppure opzionale, con le OGL1.5 (anzi le OGL1.5 sono state "inventate" proprio per introdurre un linguaggio ad alto livello, visto che non ci si decide a far uscire le 2.0 a causa di disaccordi sulle estensioni da includere in questa versione).
Si, ma non è certo all'altezza di quello, ormai standard, di MS. Anche perché OGL ormai è principalmente dedito alla grafica professionale, che ha ben altre esigenze rispetto a quella per i gamer.
però ha, comunque, sfruttato una feature proposta di nVIDIA; per carità, sicuramente valida (anche se l'utilizzo dell'o shadow buffer non sempre è possibile). Non metto in dubbio la genialità di Carmack, ma mi lasciano perplesso certe sue scelte
[QUOTE]
Attenzione: è nato prima l'uovo o la gallina. Da che mi ricordo, la proposta di nVidia è sempre stata pubblicizzata come punto di forza per D3. Ergo, continuo a credere che sia NVX ad aver puntato sulle scelte di Carmack che viceversa.
[QUOTE]
MS ascolta gli sviluppatori, ascolta i produttori di HW, però, alla fine decide lei cosa fare e come farlo. Non è detto che le sue scelte siano dettate sempre da ragioni tecniche e siano le più corrette, però è così.
Diciamo che tira le somme, e in certi casi non lo fa nella maniera migliore, questo è ovvio. Però sarebbe stupido da parte sua non tenere conto delle richieste dei player più importanti in questo mercato.
Un esempio è quello delle n-patches: sono uno dei tanti algoritmi per generare HOS e non è detto che, in assoluto, sia il migliore; però è stato scelto ufficialemnte per le specifiche DX9 ed è stato scelto in un periodo in cui si iniziaveno ad allacciare rapporti "cordiali" tra ATi e MS, in previsione della realizzazione dell'x-box2.
Ovviamente ^_^
Risultato NV3x non ha il supporto per le n-patches (per scelta di nVIDIA) e quindi non è compatibile in HW con la generazione di HOS.
Carmack non ne ha fatto uso in Doom3 (engine con un numero esiguo di poligoni se paragonato ad altri) dicendo che l'impiego di questa tecnica avrebbe creato problemi con la gestione delle ombre, causando rallentamenti nell'elaborazione. Avrà sicuramente ragione lui, però molti programmatori sono scettici; sicuramente l'utilizzo di n-patches avrebbe penalizzato i chip NV3x che avrebbero dovuto emulare queste funzioni.
Sinceramente non so se abbia ragione JC o lo scetticismo degli altri programmatori. Sono però certo che, per come è strutturato D3, un elevato numero di poligoni non avrebbe migliorato notevolmente l'impatto visivo, consideando che il design di livelli e mostri è basato su altro. Calcola che le ombre di D3 sono viste come veri e propri poligoni, del resto, e forse JC non ha tutti i torti a dire che l'utilizzo di HOS avrebbe interferito (per qualità o prestazioni) sui fragment del programma.
Rein ha collaborato anche in passato con nVIDIA; c'è stato un caso, col motore di UT2003 che ha fatto gridare al cheating nei confronti di ATi e poi si è scoperto che dipendeva dalla scelta non convenzionale del valore del LoD da parte di Epic che dava artefatti sull'R3x0, mentre era visualizzato correttamente su NV3x (il discorso è piuttosto lungo e coinvolge le scelte fatte da ATi e nVIDIA suk numero di bit per rappresentare il LoD e le scelte di Epic sul LoD minimo per il texture mapping).
Ero presente a quell'Editor's Day, in cui Rein "accusava" ATI. In realtà, non ha parlato di cheat (nonostante qualche giornalista troppo zelante e propenso alla polemica abbia riportato ciò), bensì di problemi di visualizzazione su schede ATI. E tale discorso era inserito nel contesto del TWIMTBP, dove Mark indicava che non si trattava di prestazioni, quanto di una resa grafica identica a quella prevista dagli sviluppatori.
Pape
Originariamente inviato da yossarian
non ci posso credere..................il mio sviluppatore di SW preferito
;)
:p
con le specifiche 9b i 24 bit minimi erano sufficienti; se finora non si è visto l'HDR (che si potrebbe ottenere anche con 16 bit, come ha tentato di fare Valve e non so se ci sia riuscita o meno) è perchè l'HW di riferimento non era in grado di far elaborarlo con un frame rate accettabile; inoltre il supporto all'HDR della serie NV3x è praticamente inesistente, per l'R3x0 e l'R420 e solo parziale e, quindi, deve essere, almeno in parte, emulato (con ulteriore calo del framerate). NV40 è l'unico chip con supporto completo in HW (anche se, poi, è da vedere come girerebbe con HDR a fp32).
Il problema dell'HDR in questa generazione e' un altro e non ha a che vedere con il problema 16/24 bit per componente. Ho ultimamente fatto un po' di esperimenti con l'HDR e gli shader che ho scritto sono tutti a 16 bit per componente, a parte alcune istruzioni che hanno a che fare con la distanza del pixel dall'osservatore che ha bisogno di almeno 24 bit.
Il problema risiede nel blending in floating point, che e' al momento supportato solo dall'NV40. Per cercare di semplificare il discorso, tutte le gpu a parte di NV40 non sono in grado di eseguire la seguente operazione "aggiungi il contributo di questa luce al colore di un pixel" se il risultato dell'operazione e' un buffer in HDR dove i valori non sono strettamente da 0 a 1, ma sono in floating point, quindi possono variare da -valore_molto_grande a +valore_molto_grande.
Simulare questa operazione sulle GPU che non sono in grado di svolgerla esplicitamente e' possibile ma porta a rallentamenti inaccettabili in una tecnica che gia' di per se' e' lenta. Per questo, immagino, la Valve ha abbandonato l'idea, giustamente a mio avviso. Il mio prototipo, ad esempio, gira solo su NV40.
Quando comincia Yoss mi prendo un caffè, una sigaretta tra le dita, poi chiudo la porta dell'ufficio ... e comincio la lettura.
Poi riparto da capo xchè non ho capito un ca@@o :D
Grande amico ;)
Originariamente inviato da Maury
Quando comincia Yoss mi prendo un caffè, una sigaretta tra le dita, poi chiudo la porta dell'ufficio ... e comincio la lettura.
Poi riparto da capo xchè non ho capito un ca@@o :D
Grande amico ;)
:D :D
E' vero!!!
Anche Fek e Pape però non scherzano!!
Grandi tutti e tre!!:)
beh....i test del 3d2005 con uso di sm3.0 sono all'occhio di tutti....vantaggi prestazionali = a O anzi lieve svantaggio.....imho e' inutile avere oggi qualcosa che cmq verra' sfruttata domani e sicuramente a livello di supporto sara' completamente rivoluzionata da parte delle gpu....che gia' oggi hanno sopratutto in ambito vs (vedi nvidia) grosse difficolta' a gestire....in puro 2.0....il 3.0 e' un mero specchietto per le allodole allo stato attuale....diverso il discorso sulle shadow maps che comporta reali vantaggi prestazionali....
allo stato attuale esistono pochi games full dx9.0 anzi pochi e' dir "troppo"....inesistenti i DX9c compliant....quindi meglio valutare un acquisto alla luce di quanto supporta il software e dell'hw che esso richiede e non fare il contrario...quando i games saranno sm3.0 dipendenti e le architetture gpu aottimizzate per lavorare in maniera "pura" per tale mod...e lo stesso il software allora si che' servira' e ci saranno reali vantaggi....imho la scelta conservatrice di ATi e' la giusta via....del resto il chip nv30 sulla carta evoluto piu' do ogni altro abbiamo visto di quali lacune era affetto....meglio non anticipare il futuro...perche' potrebbe anche non essere sm3.0 come oggi lo intendiamo....basta vedere le specifiche dx10 per capire che il "vero salto" ci sara' solo tra 9 e 10 e che gli shader 3.0 non siano altro che un mero aggiornamento che allo stato attuale non porta benefici...visto che entrambe le gpu nv40 e r420 nascono per essere sm2.0 dx9 optimized e che sm3.0 sia solo un passo avanti per saggiare cio' che sara' il futuro....
inoltre pare incredibile ma gia' oggi un gioco dx9 metterebbe in ginocchio qualsiasi gpu "state of the art" inutile andare oltre se manca potenza di calcolo....
X yossarian
Ma scrivevi sul forum di PS2.it ai tempi della sua uscita ?(post sempre molto tecnici ed esaustivi).
Non ricordo il nome dell'utente..ma avete lo stesso stile.
Originariamente inviato da Spytek
:D :D
E' vero!!!
Anche Fek e Pape però non scherzano!!
Grandi tutti e tre!!:)
Nah... se quando scrivo qualcosa chi legge non capisce, e' colpa mia :)
Originariamente inviato da TripleX
beh....i test del 3d2005 con uso di sm3.0 sono all'occhio di tutti....vantaggi prestazionali = a O anzi lieve svantaggio.....
Lieve svantaggio? Non so proprio da dove possa arrivare.
Prendere il 3d2005 come indice di prestazioni di qualunque cosa e' sbagliato.
Lo stesso shader scritto in 2.0 o 3.0, al limite, va uguale: il set di istruzioni dei ps3.0 e' un superset di quello dei ps2.0.
Da quello che sapevo io dava un leggero vantaggio, ma la scheda nei test rimaneva sotto lo stesso.
Originariamente inviato da fek
Lieve svantaggio? Non so proprio da dove possa arrivare.
Prendere il 3d2005 come indice di prestazioni di qualunque cosa e' sbagliato.
Lo stesso shader scritto in 2.0 o 3.0, al limite, va uguale: il set di istruzioni dei ps3.0 e' un superset di quello dei ps2.0.
Sicuramente sono d'accordo con la tua affermazione riguardo al 3d mark 2005 come giudice assoluto di tutto .Nè lui,nè tantomeno le versioni precedenti lo sono stati!
A mio avviso,lo score ottenuto dal 3d mark 2005 non fornisce dati attendibili , ma credo invece che ogni test, preso singolarmente,possa fornire dati attraverso i quali è possibile comparare schede video di tipologia diversa. :)
Originariamente inviato da fek
Lieve svantaggio? Non so proprio da dove possa arrivare.
Prendere il 3d2005 come indice di prestazioni di qualunque cosa e' sbagliato.
Lo stesso shader scritto in 2.0 o 3.0, al limite, va uguale: il set di istruzioni dei ps3.0 e' un superset di quello dei ps2.0.
Se non sbaglio il leggero svantaggio dovuto all'uso dei PS 2.0 e 2.0 era dovuto alla disabilitazione forzata del DST.;)
yossarian
04-11-2004, 16:15
Originariamente inviato da fek
:p
Il problema dell'HDR in questa generazione e' un altro e non ha a che vedere con il problema 16/24 bit per componente. Ho ultimamente fatto un po' di esperimenti con l'HDR e gli shader che ho scritto sono tutti a 16 bit per componente, a parte alcune istruzioni che hanno a che fare con la distanza del pixel dall'osservatore che ha bisogno di almeno 24 bit.
Il problema risiede nel blending in floating point, che e' al momento supportato solo dall'NV40. Per cercare di semplificare il discorso, tutte le gpu a parte di NV40 non sono in grado di eseguire la seguente operazione "aggiungi il contributo di questa luce al colore di un pixel" se il risultato dell'operazione e' un buffer in HDR dove i valori non sono strettamente da 0 a 1, ma sono in floating point, quindi possono variare da -valore_molto_grande a +valore_molto_grande.
Simulare questa operazione sulle GPU che non sono in grado di svolgerla esplicitamente e' possibile ma porta a rallentamenti inaccettabili in una tecnica che gia' di per se' e' lenta. Per questo, immagino, la Valve ha abbandonato l'idea, giustamente a mio avviso. Il mio prototipo, ad esempio, gira solo su NV40.
Infatti, è quello che intendevo quando ho detto che R3x0 e R420 hanno un supporto solo parziale il che costringe alla modalità "emulazione" (solo che tu sei stato più tecnico, trattandosi del tuo campo). In effetti Valve aveva fatto qualche tentativo ma, in seguito al fatto che su NV3x non andava proprio e che su R3x0 andava al rallentatore, ha giustamente abbandonato l'idea.
yossarian
04-11-2004, 16:34
Originariamente inviato da GMCPape
HDR probabilmente su NV3X sarebbe stato lento, ma credo che usato intelligentemente sarebbe stato implementabile in molti engine, almeno attraverso un intelligente uso di FP16 e FP32. Ovviamente, essendo la generazione precedente dettata da ATI, i programmatori non hanno sentito la necessità di inserirlo a tutti i costi. Ma credo che sarà una feature fondamentale, d'ora in poi.
[QUOTE]
HDR su NV3x non girava proprio e su R3x0 andava al rallentatore. I motivi li ha illustrati in precedenza fek
[QUOTE]Originariamente inviato da GMCPape
Esatto, ma chiediamoci perché gli shader sono corti. L'architettura nVidia, sebbene meno efficiente, avrebbe permesso l'uso di shader lunghi e di HDR, ma non essendo supportati da ATI, sarebbe stato un suicidio puntare su queste feature. Insomma.. ATI (un plauso a lei) si è imposta, e questo ha creato anche dei problemi alle feature positive dell'architettura nVidia, che non ha potuto esprimere al meglio il proprio potenziale.
al di là delle chiacchiere da salotto dei pr, resta il fatto che nVIDIA è dovuta ricorrere, per la serie NV3x, ad un "compilatore" che spezzettava istruzioni troppo lunghe in altre più brevi, riordinandole a piccoli gruppi (e in presenza di shader 2.0, spesso faceva shader replacement); certo, sulla carta, NV30 è stato presentato come un chip in grado di macinare shader molto lunghi, di lavorare con più quad in contemporanea, di utilizzare la decantata (proprio da Epic) modalità fp32; in pratica si è mostrato incapace di fare tutto ciò per limiti architetturali (non certo per colpa di ATi) e tutto l'anno scorso nVIDIA è dovuta ricorrere a continui sotterfugi, truccando i drivers, per mantenere i suoi chip competitivi. Per fortuna NV40 è di tutt'altra pasta
Originariamente inviato da GMCPape
Si, ma non è certo all'altezza di quello, ormai standard, di MS. Anche perché OGL ormai è principalmente dedito alla grafica professionale, che ha ben altre esigenze rispetto a quella per i gamer.
il GLSL è stato definito da parecchio (da prima dell'uscita di NV30), insieme a molte delle specifiche OGL2.0; se non si è ancora adottata questa versione delle API e si è dovuti ricorrere alle 1.5 solo per introdurre l'uso di un liguaggio ad alto livello (opzionale) e poco altro, è stato solo perchè non ci si è ancora messi d'accordo su altre estensioni da introdurre o meno. Quindi, non lo definirei poi così acerbo.
Originariamente inviato da GMCPape
Sinceramente non so se abbia ragione JC o lo scetticismo degli altri programmatori. Sono però certo che, per come è strutturato D3, un elevato numero di poligoni non avrebbe migliorato notevolmente l'impatto visivo, consideando che il design di livelli e mostri è basato su altro. Calcola che le ombre di D3 sono viste come veri e propri poligoni, del resto, e forse JC non ha tutti i torti a dire che l'utilizzo di HOS avrebbe interferito (per qualità o prestazioni) sui fragment del programma.
Carmack ha parlato di calo notevole di prestazioni a causa di superlavoro dei vs. La cosa strana è che ad effettuare la maggior mole di lavoro sono, nella stragrande maggioranza dei casi, i ps (la cui capacità di calcolo determina il limite effettivo delle prestazioni di un chip). In ogni caso i dubbi restano.
Originariamente inviato da GMCPape
Ero presente a quell'Editor's Day, in cui Rein "accusava" ATI. In realtà, non ha parlato di cheat (nonostante qualche giornalista troppo zelante e propenso alla polemica abbia riportato ciò), bensì di problemi di visualizzazione su schede ATI. E tale discorso era inserito nel contesto del TWIMTBP, dove Mark indicava che non si trattava di prestazioni, quanto di una resa grafica identica a quella prevista dagli sviluppatori.
Pape
Rein non è stato chiaro e le sue parole sono state equivocate da più di qualcuno; i difetti di visualizzazione dipendevano dall'utilizzo da parte di Epic di un valore di LoD positivo, per incrementare le prestazioni (il vantaggio calcolato è stato, forzando il LoD a 0, di un 1% circa peer ATi, con difetti nella visualizzazione di alcune aree e di circa il 4% per nVIDIA, senza artefatti). Il punto è che, avendo ATi utilizzato un circuito semplificato per il LoD (cosa che ha fatto anche per l'anisotropic), con conseguente uso di un numero inferiore di bit (5, ossia il valore minimo previsto per questa applicazione), si è trovata spiazzata quando Epic è ricorsa ad un valore positivo. L'esempio, però, l'ho portato solo perchè testimone di una scelta di Epic fatta conoscendo le caratteristiche dell'NV3x e basandosi su di esse; quindi, la collaborazione tra Epic e nVIDIA non è relativa al solo sviluppo di un'architettura SM3.0 ma è un bel po' più datata.
yossarian
04-11-2004, 16:36
Originariamente inviato da R@nda
X yossarian
Ma scrivevi sul forum di PS2.it ai tempi della sua uscita ?(post sempre molto tecnici ed esaustivi).
Non ricordo il nome dell'utente..ma avete lo stesso stile.
no, non ero io però mi piacerebbe leggere qualcosa di quello che ha scritto.
yossarian
04-11-2004, 16:39
Originariamente inviato da TripleX
inoltre pare incredibile ma gia' oggi un gioco dx9 metterebbe in ginocchio qualsiasi gpu "state of the art" inutile andare oltre se manca potenza di calcolo....
in effetti le cose stanno proprio così e non è un caso che si inizi a pensare a soluzioni multichip o con più vga in parallelo; questo in attesa delle nuove architetture che dovrebbero fornire il boost prestazionale necessario e la flessibilità richiesta dai programmatori.
Alberto Falchi
04-11-2004, 17:03
Originariamente inviato da yossarian
al di là delle chiacchiere da salotto dei pr, resta il fatto che nVIDIA è dovuta ricorrere, per la serie NV3x, ad un "compilatore" che spezzettava istruzioni troppo lunghe in altre più brevi, riordinandole a piccoli gruppi (e in presenza di shader 2.0, spesso faceva shader replacement); certo, sulla carta, NV30 è stato presentato come un chip in grado di macinare shader molto lunghi, di lavorare con più quad in contemporanea, di utilizzare la decantata (proprio da Epic) modalità fp32; in pratica si è mostrato incapace di fare tutto ciò per limiti architetturali (non certo per colpa di ATi) e tutto l'anno scorso nVIDIA è dovuta ricorrere a continui sotterfugi, truccando i drivers, per mantenere i suoi chip competitivi. Per fortuna NV40 è di tutt'altra pasta
NOn è corretto. Il compilatore di nVidia non spezzettava in istruzioni più corte, bensì riordinava i dati in maniera più digeribile dall'architettura di NV3X. Che in certi casi venissero fatti shader replacemente, è un discorso diverso, e a me frega poco, sino a che la qualità dell'immagine non viene toccata. Anche ATI lo fa, del resto, e nessuno se ne può accorgere, se appunto il rendering rimane identico. La modalità FP32, insieme a FP16, a detta di programmatori non era poi così lenta, ma necessitava di un lavoro di ottimizzazione che i programmatori non sempre facevano. E li posso comprendere: perché impazzire per ottimizzare un'architettura quando era più semplice utilizzare altri metodi, per quanto limitanti sotto il profilo o qualitativo o prestazionale? La "colpa" è di ATI nel senso che la sua architettura gestiva molto meglio il codice standard, senza necessitare di ottimizzazioni particolari, e quindi era molto più apprezzata da chi doveva scrivere codice.
il GLSL è stato definito da parecchio (da prima dell'uscita di NV30), insieme a molte delle specifiche OGL2.0; se non si è ancora adottata questa versione delle API e si è dovuti ricorrere alle 1.5 solo per introdurre l'uso di un liguaggio ad alto livello (opzionale) e poco altro, è stato solo perchè non ci si è ancora messi d'accordo su altre estensioni da introdurre o meno. Quindi, non lo definirei poi così acerbo.
Acerbo in relazione a quello di MS, che è lo standard.
Carmack ha parlato di calo notevole di prestazioni a causa di superlavoro dei vs. La cosa strana è che ad effettuare la maggior mole di lavoro sono, nella stragrande maggioranza dei casi, i ps (la cui capacità di calcolo determina il limite effettivo delle prestazioni di un chip). In ogni caso i dubbi restano.
Dipende tutto da come programmi e da cosa devi fare. I PS sono un limite ora, ma principalmente perché non vengono spinte a pieno le unità di VS. Probabilmente, Carmack ne ha fatto invece un pesante utilizzo nel suo engine. Per lo meno stando a quanto dice ^_^
Rein non è stato chiaro e le sue parole sono state equivocate da più di qualcuno; i difetti di visualizzazione dipendevano dall'utilizzo da parte di Epic di un valore di LoD positivo, per incrementare le prestazioni (il vantaggio calcolato è stato, forzando il LoD a 0, di un 1% circa peer ATi, con difetti nella visualizzazione di alcune aree e di circa il 4% per nVIDIA, senza artefatti). Il punto è che, avendo ATi utilizzato un circuito semplificato per il LoD (cosa che ha fatto anche per l'anisotropic), con conseguente uso di un numero inferiore di bit (5, ossia il valore minimo previsto per questa applicazione), si è trovata spiazzata quando Epic è ricorsa ad un valore positivo.
OK, questa è la motivazione. Ma, per l'appunto, non si parlava di cheat o che, quanto di rendering non corretto con ATI. E, come ti ho detto, era un esempio per far capire il significato del logo TWIMBP: il rendering. Le motivazioni poi lasciano il tempo che trovano: che sia colpa di ATI o di Epic, è innegabile che il risultato sia diverso da qiello del reference rasterizer.
L'esempio, però, l'ho portato solo perchè testimone di una scelta di Epic fatta conoscendo le caratteristiche dell'NV3x e basandosi su di esse; quindi, la collaborazione tra Epic e nVIDIA non è relativa al solo sviluppo di un'architettura SM3.0 ma è un bel po' più datata.
Ancora non hai capito cosa voglio dire. Si, diciamo che Epic si è basata su NV3X, e si sta basando su NV50 per U3 Engine, ma si basa su quello perché sono le feature che Sweeney ritiene fondamentali, e la collaborazione con i produttori di GPU serve proprio a far sì che i chip soddisfino queste necessità. ATI, da ultima arrivata sul mercato del 3D (e lo fa con stile, non è certo una critica), si limita a realizzare architetture efficienti e aderenti allo standard. Ma le manca la capacità di innovare, anche a causa del fatto che fino a ora non ha mai avuto un rapporto di collaborazione con i developer come invece tende a fare nVidia. Del resto, alle presetnazioni di ATI ho visto sempre e solo Valve, al contrario di nVidia che porta sviluppatori di ogni software house. è normale: nVidia ha vari individui provenienti da 3dfx fra le sue fila, e ha un'esperienza nel 3D sicuramente più "antica". Ati sembra che ora si stia smuovendo anche sotto questo profilo. Sarà che ha capito che non basta milgiorare, ma è anche necessario innovare per non rischiare di trovarsi indietro?
Pape
Alberto Falchi
04-11-2004, 17:08
Originariamente inviato da yossarian
in effetti le cose stanno proprio così e non è un caso che si inizi a pensare a soluzioni multichip o con più vga in parallelo; questo in attesa delle nuove architetture che dovrebbero fornire il boost prestazionale necessario e la flessibilità richiesta dai programmatori.
Mettere in ginocchio si, ma dipende da cosa si intende per "full DX9". Se si intende un lavoro come Far Cry siamo d'accordo. Ma FC è il miglio esempio di incapacità di design. Tanti effetti buttati a muzzo ovunque, senza un minimo di studio o di ricerca su come e dove utilizzarli. Se invece gli effetti venissero utilizzati solo dove serve, in maniera intelligente, tutte el feature di DX9 sarebbero accessibili senza problemi alle schede attuali. O hai bisogno di mettere PS 2.0 su ogni superfice? Io sono convinto che chi realizza giochi per PC dovrebbe imparare dalle console: non tanto per la qualità del codice, quanto per le scelte stilistiche e la taratura del frame rate perfetta che vedo sulle "piccole" macchine da gioco. Perché sono rari i giochi PC dove il frame rate è costante? Perché le aree di FC non sono state studiate in maniera da non appesantirle con PS 2.0 su ogni sasso?
Pape
yossarian
04-11-2004, 17:57
Originariamente inviato da GMCPape
NOn è corretto. Il compilatore di nVidia non spezzettava in istruzioni più corte, bensì riordinava i dati in maniera più digeribile dall'architettura di NV3X. Che in certi casi venissero fatti shader replacemente, è un discorso diverso, e a me frega poco, sino a che la qualità dell'immagine non viene toccata. Anche ATI lo fa, del resto, e nessuno se ne può accorgere, se appunto il rendering rimane identico. La modalità FP32, insieme a FP16, a detta di programmatori non era poi così lenta, ma necessitava di un lavoro di ottimizzazione che i programmatori non sempre facevano. E li posso comprendere: perché impazzire per ottimizzare un'architettura quando era più semplice utilizzare altri metodi, per quanto limitanti sotto il profilo o qualitativo o prestazionale? La "colpa" è di ATI nel senso che la sua architettura gestiva molto meglio il codice standard, senza necessitare di ottimizzazioni particolari, e quindi era molto più apprezzata da chi doveva scrivere codice.
per rendere i dati più digeribili all'architettura dell'NV3x ci sono solo due sistemi: minimizzare il numero di registri coinvolti nei calcoli e utilizzare il più possibile shader 1.x; queste due cose non fanno il paio con shader più lunghi o con il semplice riordino degli shader. La modalità fp32 insieme a fp16 non è lenta su NV3x? Strano che siano stati così tanti a darsi da fare per ottimizzare codice per le FX (Carmack e la stessa Valve che per HL2 ha previsto e consigliato di far girare NV30 con codice DX8) e nessuno è riuscito a far rendere questa modalità mista; in fondo non sarebbe stato così difficile, sarebbe bastato programmare tutto in fp16 (visto che fp32 è praticamente inutilizzata) per rendere le cose molto semplici; tanto, comunque, ATi avrebbe continuato a lavorare in fp24 a livello di pipeline salvo poi fare downscaling per passare a fp16. Eppure non l'ha fatto nessuno o, quanto meno, nessuno è riuscito a far andare le fx al livello della concorrenza, neppure in fp16.
L'operazione di shader replacement, quando fatta per alterare i risultati di un bench che dovrebbe servire a decretare la "presunta" bontà di un prodotto, che alteri o meno la qualità di immagine, dalle mie parti si chiama truffa. Diverso il discorso nel caso in cui si effettua e si dice:"ok, ho guadagnato 20 fps, però sto facendo shader replacement".
Originariamente inviato da GMCPape
Dipende tutto da come programmi e da cosa devi fare. I PS sono un limite ora, ma principalmente perché non vengono spinte a pieno le unità di VS. Probabilmente, Carmack ne ha fatto invece un pesante utilizzo nel suo engine. Per lo meno stando a quanto dice ^_^
spingere a pieno le unità vs significa aumentare il lavoro anche delle unità ps; nella precedente generazione, il rapporto tra ps e vs era, per ATi, di 2:1 e per nVIDIA di 4:3; adesso si è passati, per entrambe, a 3:8 e, nonnostante tutto, il freno è rappresentato sempre dalle psu.
Originariamente inviato da GMCPape
OK, questa è la motivazione. Ma, per l'appunto, non si parlava di cheat o che, quanto di rendering non corretto con ATI. E, come ti ho detto, era un esempio per far capire il significato del logo TWIMBP: il rendering. Le motivazioni poi lasciano il tempo che trovano: che sia colpa di ATI o di Epic, è innegabile che il risultato sia diverso da qiello del reference rasterizer.
purchè ci si limiti a situazioni come questa, non ci sono problemi, anche perchè la cosa è facilemte risolvibile (in questo caso forzando un diverso valore del LoD); purchè non si vada oltre a scapito di quelli che non scelgono questa o quella casa.
Originariamente inviato da GMCPape
Ancora non hai capito cosa voglio dire. Si, diciamo che Epic si è basata su NV3X, e si sta basando su NV50 per U3 Engine, ma si basa su quello perché sono le feature che Sweeney ritiene fondamentali, e la collaborazione con i produttori di GPU serve proprio a far sì che i chip soddisfino queste necessità. ATI, da ultima arrivata sul mercato del 3D (e lo fa con stile, non è certo una critica), si limita a realizzare architetture efficienti e aderenti allo standard. Ma le manca la capacità di innovare, anche a causa del fatto che fino a ora non ha mai avuto un rapporto di collaborazione con i developer come invece tende a fare nVidia. Del resto, alle presetnazioni di ATI ho visto sempre e solo Valve, al contrario di nVidia che porta sviluppatori di ogni software house. è normale: nVidia ha vari individui provenienti da 3dfx fra le sue fila, e ha un'esperienza nel 3D sicuramente più "antica". Ati sembra che ora si stia smuovendo anche sotto questo profilo. Sarà che ha capito che non basta milgiorare, ma è anche necessario innovare per non rischiare di trovarsi indietro?
Pape
ingegneri 3dfx lavorano anche da ATi che, oltretutto, collabora con SGI in maniera più stretta di quanto non faccia NV. In quanto a innovazioni, si potrebbe affermarem senza tema di smentita che l'R100 era di gran lunga più innovativo dell'NV15, così come l'R200 lo è stato rispetto all'NV20; si potrebbe anche dire che quella dell'R300 è stata l'architettura di riferimento per questa generazione di chip grafici.
Sei così sicuro che il motivo del mancato supporto risieda nel fatto che ATi non ha mai innovato?
yossarian
04-11-2004, 18:03
Originariamente inviato da GMCPape
Mettere in ginocchio si, ma dipende da cosa si intende per "full DX9". Se si intende un lavoro come Far Cry siamo d'accordo. Ma FC è il miglio esempio di incapacità di design. Tanti effetti buttati a muzzo ovunque, senza un minimo di studio o di ricerca su come e dove utilizzarli. Se invece gli effetti venissero utilizzati solo dove serve, in maniera intelligente, tutte el feature di DX9 sarebbero accessibili senza problemi alle schede attuali. O hai bisogno di mettere PS 2.0 su ogni superfice? Io sono convinto che chi realizza giochi per PC dovrebbe imparare dalle console: non tanto per la qualità del codice, quanto per le scelte stilistiche e la taratura del frame rate perfetta che vedo sulle "piccole" macchine da gioco. Perché sono rari i giochi PC dove il frame rate è costante? Perché le aree di FC non sono state studiate in maniera da non appesantirle con PS 2.0 su ogni sasso?
Pape
ad esempio le specifiche dx9 prevedono anche l'applicazione di 16 texel per pixel per pass; al di là dell'utilità di una tale feature, allo stato attuale, a che frame rate pensi che lavorerebbero R420 o NV40 in una situazione del genere? (questo senza contare HDR e quant'altro). Sulle consolle è più facile lavorare: si ha un'architettura di riferimento e si sa che per 3 o 4 anni rimarrà la stessa; per il pc le cose stanno in modo molto diverso: architetture differenti, evoluzione molto più rapida e motori grafici che diventano presto obsoleti
Alberto Falchi
04-11-2004, 18:16
Originariamente inviato da yossarian
per rendere i dati più digeribili all'architettura dell'NV3x ci sono solo due sistemi: minimizzare il numero di registri coinvolti nei calcoli e utilizzare il più possibile shader 1.x; queste due cose non fanno il paio con shader più lunghi o con il semplice riordino degli shader.
E chi ha parlato di riordino shader? Io parlavo del riordino delle istruzioni. La struttura 4x2 di NV30 (contro gli 8x1 di R300) era particolarmente sensibile all'ordine in cui arrivavano le istruzioni (e non gli shader), perché in molti casi si lasciava sprecato del potenziale mentre le unità erano inoperanti, in attesa di istruzioni.
La modalità fp32 insieme a fp16 non è lenta su NV3x? Strano che siano stati così tanti a darsi da fare per ottimizzare codice per le FX (Carmack e la stessa Valve che per HL2 ha previsto e consigliato di far girare NV30 con codice DX8) e nessuno è riuscito a far rendere questa modalità mista; in fondo non sarebbe stato così difficile, sarebbe bastato programmare tutto in fp16 (visto che fp32 è praticamente inutilizzata) per rendere le cose molto semplici;
La FP è richiesta solo da pochissime istruzioni, non ha senso utilizzarla ovunque. In molti dei casi, la PP è più che adeguata e non crea banding o altri artefatti. Certo, non siamo all'altezza di ATI come risultati, ma un'utilizzo più accorto sicuramente avrebbe aiutato le GPU NV3X. Ovviamente, i programmatori non sono obbligati a sbattersi da morire per far funzionare al meglio un titolo: se rimane giocabile, perché impazzire solo per favorire un titolo nei bench? Puoi dirmi tutto cià che vuoi sui limiti di NV3X, e spesso sarò d'accordo con te, ma i giochi ci giravano bene sopra. Più lenti che con ATI, sicuro, ma che senso aveva impazzire per far salire nVidia nei bench se tanto il titolo era più che giocabile e, tranne in rari casi, la qualità visiva era identica?
tanto, comunque, ATi avrebbe continuato a lavorare in fp24 a livello di pipeline salvo poi fare downscaling per passare a fp16. Eppure non l'ha fatto nessuno o, quanto meno, nessuno è riuscito a far andare le fx al livello della concorrenza, neppure in fp16.
Appunto, ATI andava meglio. MA chi se ne frega di 90 o 70 frame? Sino a che non scatta, a me va bene.
L'operazione di shader replacement, quando fatta per alterare i risultati di un bench che dovrebbe servire a decretare la "presunta" bontà di un prodotto, che alteri o meno la qualità di immagine, dalle mie parti si chiama truffa.
Dipende. Se il bench è un gioco, ottimizzi anche il gioco, almeno teoricamente. E se non cambia la qualità visiva, va più che bene, visto che nessuno viene "derubato" di che. Se lo fai col 3D Mark, fai bene lo stesso (sempre che non cheatti usando stati precalcolati o che): 3D Mark è uno strumento di marketing, punto. Ha senso se saputo correttamente interpretare. Se utilizzi il numerino alla fine... beh.. non significa nulla.
Diverso il discorso nel caso in cui si effettua e si dice:"ok, ho guadagnato 20 fps, però sto facendo shader replacement".
Lo fanno tutti, sia ATI sia nVidia. E non te ne accorgerai mai. Se ti rimane invisibile, che te ne frega?
purchè ci si limiti a situazioni come questa, non ci sono problemi, anche perchè la cosa è facilemte risolvibile (in questo caso forzando un diverso valore del LoD); purchè non si vada oltre a scapito di quelli che non scelgono questa o quella casa.
E perché dovrebbe capitare? Sarebbe un suicido da parte di chi produce giochi non supportare tutti i chipset al meglio. Poi ovvio, ATI farà sempre girare meglio qulche gioco, per altri titoli il primato sarà di nVidia. Dal momento che non esiste un leader incontrastato del mercato, è una situazione ovvia. Ma, per l'appunto, si tratta di piccolezze: quale programmatore non farebbe il massimo pur di ottenere la medesima qualità su tutte le schede più diffuse?
ingegneri 3dfx lavorano anche da ATi che, oltretutto, collabora con SGI in maniera più stretta di quanto non faccia NV.
Non si tratta di ingegneri. Ma di persone che coordinano R&D e sviluppatori di giochi. Chiamali evangelisti, uomini di marketing o che, ma sono queste persone che devono mettere a contatto il mondo degli ingegneri e quello dei developer.
In quanto a innovazioni, si potrebbe affermarem senza tema di smentita che l'R100 era di gran lunga più innovativo dell'NV15, così come l'R200 lo è stato rispetto all'NV20; si potrebbe anche dire che quella dell'R300 è stata l'architettura di riferimento per questa generazione di chip grafici.
COsa hanno apportato a livello di feature? Hanno aggiunto qualcosa? O hanno semplicemente fatto meglio ciò che gli altri già facevano? Se io faccio un xbox con una CPU a 2 Ghz e 1 GB di RAM, ho fatto meglio di MS, ma non ho innovato una cippa.
Sei così sicuro che il motivo del mancato supporto risieda nel fatto che ATi non ha mai innovato?
No, del contrario. Cioé che la carenza di innovazioni di ATI sia dovuta ai suoi scarsi contatti coi developer. Contatti inteso come sedersi a tavolino e cercare di capire cosa succederà fra 6 anni, quali feature serviranno, come implementarle e così via.
Pape
Alberto Falchi
04-11-2004, 18:26
Originariamente inviato da yossarian
Sulle consolle è più facile lavorare: si ha un'architettura di riferimento e si sa che per 3 o 4 anni rimarrà la stessa; per il pc le cose stanno in modo molto diverso: architetture differenti, evoluzione molto più rapida e motori grafici che diventano presto obsoleti
E tanta incapacità a livello di desinng, per come la vedo io. Anche sulle console i giochi escono continuamente, rincorrendosi per la palma del migliore. Ma, al ocntrario del PC, i giochi per console sono curati enormemente meglio. Ma anche perché i giocatori su console valutano il gameplay molto più della tecnica, al contrario di quanto accade nel mercato del PC, dove più il gioco stupisce, più è bello. Del resto, questo forum è indicativo: giochi che venhgono criticati perché le texture non sono all'altezza di XXX, perché non vengono usati i PS come YYY. Niente di male in questo, ma un gioco deve divertire. La tecnica è un ottimo spunto di discussione, ma deve rimanere una piccola parte nella valutazione di un gioco.
Pape
Originariamente inviato da yossarian
no, non ero io però mi piacerebbe leggere qualcosa di quello che ha scritto.
Si,credo ti sarebbe piaciuto,peccato che il forum Ps2.it non esiste più...adesso c'è uno shop ps2 senza nessun forum al suo posto.
Scusate l'OT
yossarian
04-11-2004, 19:16
Originariamente inviato da GMCPape
E chi ha parlato di riordino shader? Io parlavo del riordino delle istruzioni. La struttura 4x2 di NV30 (contro gli 8x1 di R300) era particolarmente sensibile all'ordine in cui arrivavano le istruzioni (e non gli shader), perché in molti casi si lasciava sprecato del potenziale mentre le unità erano inoperanti, in attesa di istruzioni.
gli shader sono istruzioni. C'era una leggenda metropolitana che diceva che l'architettura 4x2 lasciva inoperose le seconde tmu; ma era, appunto, una leggenda: bastava valutare il comportamento in multitexturing per rendersi conto che le seconde tmu funzionavano regolarmente. Il problema principale della serie NV3x con i calcoli in floating era l'organizzazione delle fpu e delle tmu. NV30 ha 4 sole fpu, una per pipeline, dipendenti dalle tmu; questo significa che, mediamente, con istruzioni miste (text/fp) 2 pipeline elaboravano operazioni matematiche (in tutto 2) e 2 calcoli sulle texture (al massimo 4); perciò il picco massimo raggiungilbile da NV30 era di 6 operazioni. Altro handicap, i registri temporanei insufficienti che riduce la quantità di variabili che contemporaneamente possono essere messe in gioco; questo, come è facile intendere, fa diminuire il numero di operazioni che si possono svolgere in contemporanea e, quindi, la lunghezza delle istruzioni che è possibile far "digerire" al chip.
Di contro, invece, si avevano 8 unità fx (2 per pipeline), operanti in fx12.
Su NV35 4 unità fx12 sono state sostituite con altrettante unità fp32, però è rimasta la dipendenza tra fpu e tmu e si è aggravato il problema dei registri (una fpu è molto più voluminosa di una fxu e, di conseguenza, lo spazio si è dovuto recuperare altrove).
Originariamente inviato da GMCPape
La FP è richiesta solo da pochissime istruzioni, non ha senso utilizzarla ovunque. In molti dei casi, la PP è più che adeguata e non crea banding o altri artefatti. Certo, non siamo all'altezza di ATI come risultati, ma un'utilizzo più accorto sicuramente avrebbe aiutato le GPU NV3X. Ovviamente, i programmatori non sono obbligati a sbattersi da morire per far funzionare al meglio un titolo: se rimane giocabile, perché impazzire solo per favorire un titolo nei bench? Puoi dirmi tutto cià che vuoi sui limiti di NV3X, e spesso sarò d'accordo con te, ma i giochi ci giravano bene sopra. Più lenti che con ATI, sicuro, ma che senso aveva impazzire per far salire nVidia nei bench se tanto il titolo era più che giocabile e, tranne in rari casi, la qualità visiva era identica?
è quello che ho detto: sarebbe stato molto semplice programmare tutto in fp (utilizzando al massimo 16 bit), andando così incontro alle esigenze delle fx; però o non è stato fatto (non credo che nessuno ci abbia provato) oppure anche l'utilizzo della modalità fp16 non dava la resa sperata.
Certo che con NV3x i titoli passati erano più che giocabili: erano programmati con SM1.x e, nei pochi casi di utilizzo di SM2.0, provvedevano i drivers NV a fare shader replacement. Con i calcoli in virgola fissa, la serie NV3x va tutt'altro che male. L'NV30, parlando dal punto di vista dell'architettura, è un NV25 con in aggiunta una vsu, una fxu e una fpu per pipeline con ovvio aumento del numero di registri (questo volendo riassumere a grandi linee).
Originariamente inviato da GMCPape
Dipende. Se il bench è un gioco, ottimizzi anche il gioco, almeno teoricamente. E se non cambia la qualità visiva, va più che bene, visto che nessuno viene "derubato" di che. Se lo fai col 3D Mark, fai bene lo stesso (sempre che non cheatti usando stati precalcolati o che): 3D Mark è uno strumento di marketing, punto. Ha senso se saputo correttamente interpretare. Se utilizzi il numerino alla fine... beh.. non significa nulla.
se il bench è usato per vendere non è corretto spacciare per buoni risultati fasulli; i ps1.1 sono molto più leggeri dei 2.0 e il frame rate ottenuto è sicuramente più elevato (soprattutto su un chip che ha problemi intrinseci con i 2.0)
Originariamente inviato da GMCPape
Lo fanno tutti, sia ATI sia nVidia. E non te ne accorgerai mai. Se ti rimane invisibile, che te ne frega?
ci sono vari modo per accorgersi se si fa o meno shader replacement; il più semplice è quello di vedere il boost prestazionale di una release di drivers rispetto alla precedente, quando si conosce l'architettura di un chip; un boost eccessivo desta sospetti, si indaga e, puntualmente, si scopre l'inghippo
:D
Originariamente inviato da GMCPape
E perché dovrebbe capitare? Sarebbe un suicido da parte di chi produce giochi non supportare tutti i chipset al meglio. Poi ovvio, ATI farà sempre girare meglio qulche gioco, per altri titoli il primato sarà di nVidia. Dal momento che non esiste un leader incontrastato del mercato, è una situazione ovvia. Ma, per l'appunto, si tratta di piccolezze: quale programmatore non farebbe il massimo pur di ottenere la medesima qualità su tutte le schede più diffuse?
bella domanda: forse quello che riceve qualcosa per far andare un certo prodotto un po' più della concorrenza (senza esagerare, possibilmente)
Originariamente inviato da GMCPape
Non si tratta di ingegneri. Ma di persone che coordinano R&D e sviluppatori di giochi. Chiamali evangelisti, uomini di marketing o che, ma sono queste persone che devono mettere a contatto il mondo degli ingegneri e quello dei developer.
una delle razze peggiori dopo i pr, insomma
:D
Originariamente inviato da GMCPape
COsa hanno apportato a livello di feature? Hanno aggiunto qualcosa? O hanno semplicemente fatto meglio ciò che gli altri già facevano? Se io faccio un xbox con una CPU a 2 Ghz e 1 GB di RAM, ho fatto meglio di MS, ma non ho innovato una cippa.
tanto per citarne qualcuna, le dependent texture read (con l'R200), le n-patches (con l'R200), forme primitive di keyframe interpolation e skeletal animation, seppure realizzate con le fixed function (con l'R100 che aveva 4 istruzioni per le operazioni sui vertici, contro le 2 previste dalle DX7 e implementate sull'NV15).
L'utilizzo di buffer (ormai usati da per tutto) per le operazioni di texturing (Rage128); dell'R300 è inutile parlare, visto che si tratta di un'architettura ancora attuale e competitiva dopo oltre due anni dalla sua uscita.
Originariamente inviato da GMCPape
No, del contrario. Cioé che la carenza di innovazioni di ATI sia dovuta ai suoi scarsi contatti coi developer. Contatti inteso come sedersi a tavolino e cercare di capire cosa succederà fra 6 anni, quali feature serviranno, come implementarle e così via.
Pape
non sono d'accordo con la carenza di innovazioni da parte di ATi
yossarian
04-11-2004, 19:21
Originariamente inviato da GMCPape
E tanta incapacità a livello di desinng, per come la vedo io. Anche sulle console i giochi escono continuamente, rincorrendosi per la palma del migliore. Ma, al ocntrario del PC, i giochi per console sono curati enormemente meglio. Ma anche perché i giocatori su console valutano il gameplay molto più della tecnica, al contrario di quanto accade nel mercato del PC, dove più il gioco stupisce, più è bello. Del resto, questo forum è indicativo: giochi che venhgono criticati perché le texture non sono all'altezza di XXX, perché non vengono usati i PS come YYY. Niente di male in questo, ma un gioco deve divertire. La tecnica è un ottimo spunto di discussione, ma deve rimanere una piccola parte nella valutazione di un gioco.
Pape
ti quoto perchè, per quanto riguarda la bellezza di un gioco sono d'accordo con te. Un gioco deve, innanzitutto essere coinvolgente; se, poi, ha anche una bella grafica, è solo un valore aggiunto. Un gioco con una grafica da urlo ma poco interessante lo si guarda per un po' e poi si passa ad altro.
Per quanto riguarda il discorso consolle, è vero che escono giochi in continuazione, però esiste un punto di riferimento saldo, ossia un'architettura unica, ben conosciuta, immutabile per diversi anni. Con i pc si ha un continuo rincorrersi di giochi, ma anche di API, di architetture, ecc. Questo rende tutto più complicato anche per chi deve sviluppare un gioco.
Alberto Falchi
04-11-2004, 20:36
Originariamente inviato da yossarian
gli shader sono istruzioni. C'era una leggenda metropolitana che diceva che l'architettura 4x2 lasciva inoperose le seconde tmu; ma era, appunto, una leggenda: bastava valutare il comportamento in multitexturing per rendersi conto che le seconde tmu funzionavano regolarmente. Il problema principale della serie NV3x con i calcoli in floating era l'organizzazione delle fpu e delle tmu. NV30 ha 4 sole fpu, una per pipeline, dipendenti dalle tmu; questo significa che, mediamente, con istruzioni miste (text/fp) 2 pipeline elaboravano operazioni matematiche (in tutto 2) e 2 calcoli sulle texture (al massimo 4); perciò il picco massimo raggiungilbile da NV30 era di 6 operazioni.
Inutilizzate è stato un termine infelice, te ne do atto. MI correggo e specifico "non utilizzate al meglio". Poi sulla questione più tecnica hai ragione, ma non hai specificato una piccola cosa: che nella maggior parte dei casi, per come erano programmati i giochi, il massimo delle 6 operazioni non veniva mai sfruttato. Non ti voglio certo dire che NV3X fosse migliore di R3X0 (anzi, sono d'accordo con te che ATI abbia fatto meglio in quella generazione), ma che il divario esagerato era, per l'appunto, dipendente anche da fattori di mancata ottimizzazione. O, meglio, di un'architettura non digerita al meglio dai programmatori. Questi avrebbero potuto fare indubbiamente meglio, se avessero voluto, ma questioni di tempo e di comodità coi compilatori standard, hanno privilegiato ulteriormente l'architettura di ATI.
E, tornando alla radice del discorso, è stata una differenta scelta architetturale. Che si è rivelata errata da parte di nVidia, sicuramente, ma non priva di fondamento.
nVidia aveva puntato su una maggiore versatilità, e principalmente su shader più complessi e meno precisi. I limiti che evidenzi non tengono conto del fatto che, al cotnrario della concorrenza, nVidia aveva delle unità di shading più versatili, che le permettevano (in teoria) di opn avere limiti sul numero delle istruzioni presenti negli shader, e che già da allora ponevano le basi per il dynamic branching presente poi in SM3. Non ti so dire se tale potenziale sarebbe poi stato esprimibile in relazione alla potenza della GPU, ma è un dato di fatto che R3X0 era "limitata" sotto questo profilo. In ogni caso, i limiti di ATI erano indubbiamente meno pesanti rispetto a quelli di nVidia, ma più che di errori nella progettazione, credo che si tratti di intuizioni sbagliate su come avrebbero sfruttato gli shader i programmatori.
è quello che ho detto: sarebbe stato molto semplice programmare tutto in fp (utilizzando al massimo 16 bit), andando così incontro alle esigenze delle fx; però o non è stato fatto (non credo che nessuno ci abbia provato) oppure anche l'utilizzo della modalità fp16 non dava la resa sperata.
In certi casi la resa di FP16 non basta. Ed è necessario passare alla full precision. In molti engine, però (e nei bench sintetici quali 3D Mark), si è fatto un'uso esagerato di FP, favorendo ATI. Ovviamente non per cattiveria e pigrizia da parte dei deevloper, ma per delle loro scelte. E se posso capire la necessità di utilizzare FP nei bench sintentici per valutare le prestazioni in quell'ambito, non capisco il perché sia stato così usato nei motori di gioco. Guardando i bench utilizzati, uno dove nVidia ha sempre sofferto in grossa misura è stato proprio Far Cry, che a mio personalissimo avviso è uno dei peggiori motori mai visti (oltre che un titolo mediocre, ma questo non ha attinenza col discorso). Di contro, molti dei motori più utilizzati nei giochi, ma non sempre utilizzati come bench, davano ragione a nVidia (sempre per piccoli divari, cmq). MI vengono in mente le tonnellate di giochi basati su Q3, ma soprattutto il motore degli ISI (F1 Challenge), raramente usato per valutare le performance ma molto usati dai giochi di guida (e relativi mod).
Un altro esempio che mi viene in mente di bench favrevole ad ATI ma non rappresentativo di nulla è stato Halo: un massiccio utilizzo, inutile, di PS 2.0, che non aggiungevano nulla alla qualità dei Ps 1.4. Anche lì, a mio avviso, è stata una pessima scelta che ha tarpato enormemente le prestazioni a ogni architettura, senza aggiungere nulla. Fortunatamente, il gioco è una figata, però ^_^.
Certo che con NV3x i titoli passati erano più che giocabili: erano programmati con SM1.x e, nei pochi casi di utilizzo di SM2.0, provvedevano i drivers NV a fare shader replacement. Con i calcoli in virgola fissa, la serie NV3x va tutt'altro che male. L'NV30, parlando dal punto di vista dell'architettura, è un NV25 con in aggiunta una vsu, una fxu e una fpu per pipeline con ovvio aumento del numero di registri (questo volendo riassumere a grandi linee).
Ma su quanti di questi titoli vedevi artefatti di qualsiasi tipo? Alla fine, al giocatore interessa che la resa finale non cambi, e tranne rari casi, i giochi erano visivamente identici.
se il bench è usato per vendere non è corretto spacciare per buoni risultati fasulli; i ps1.1 sono molto più leggeri dei 2.0 e il frame rate ottenuto è sicuramente più elevato (soprattutto su un chip che ha problemi intrinseci con i 2.0)
Se il risultato visivo è identico, cosa interessa cosa fa il driver? Certo, inficia i risultati. Ma non esisterà mai un bench intoccabile, per quanto ne so. E i trucchetti li usano sia ati sia nVidia. La lotta è dura ^_^
ci sono vari modo per accorgersi se si fa o meno shader replacement; il più semplice è quello di vedere il boost prestazionale di una release di drivers rispetto alla precedente, quando si conosce l'architettura di un chip; un boost eccessivo desta sospetti, si indaga e, puntualmente, si scopre l'inghippo
Ribadisco: se non ti accorgi di differenze, cosa cambia?
bella domanda: forse quello che riceve qualcosa per far andare un certo prodotto un po' più della concorrenza (senza esagerare, possibilmente)
Forse, si. Ma a quel punto, indipendentemente dalla bontà dell'architettura, vince chi ha più soldi. Ma voglio sperare che non succeda, sebbene alcuni particolari (Far Cry patch 1.2 così come HL2) mi facciano sorgere dei sospetti. Su entrambe le aziende. Ma, chi perderebbe veramente la faccia in caso salti fuori la cosa, sarebbe lo sviluppatore, più che la casa che lo "corrompe".
una delle razze peggiori dopo i pr, insomma
Non dire così, dai. ho fatto il PR anche io, in passato ;-) non sono così cattivi come sembrano... è chi si fa abbindolare da loro, al massimo, a sbagliare.
tanto per citarne qualcuna, le dependent texture read (con l'R200), le n-patches (con l'R200), forme primitive di keyframe interpolation e skeletal animation, seppure realizzate con le fixed function (con l'R100 che aveva 4 istruzioni per le operazioni sui vertici, contro le 2 previste dalle DX7 e implementate sull'NV15)
L'utilizzo di buffer (ormai usati da per tutto) per le operazioni di texturing (Rage128); dell'R300 è inutile parlare, visto che si tratta di un'architettura ancora attuale e competitiva dopo oltre due anni dalla sua uscita.
Quante di queste sono state sfruttate dagli sviluppatori ai tempi? Certo, Trueform era una figata... ma non basta l'idea.. devi anche saperla vendere. E ATI non ci è mai riuscita. Vedremo che saprà fare con 3Dc.
Pape
yossarian
04-11-2004, 21:40
Originariamente inviato da GMCPape
Inutilizzate è stato un termine infelice, te ne do atto. MI correggo e specifico "non utilizzate al meglio". Poi sulla questione più tecnica hai ragione, ma non hai specificato una piccola cosa: che nella maggior parte dei casi, per come erano programmati i giochi, il massimo delle 6 operazioni non veniva mai sfruttato. Non ti voglio certo dire che NV3X fosse migliore di R3X0 (anzi, sono d'accordo con te che ATI abbia fatto meglio in quella generazione), ma che il divario esagerato era, per l'appunto, dipendente anche da fattori di mancata ottimizzazione. O, meglio, di un'architettura non digerita al meglio dai programmatori. Questi avrebbero potuto fare indubbiamente meglio, se avessero voluto, ma questioni di tempo e di comodità coi compilatori standard, hanno privilegiato ulteriormente l'architettura di ATI.
non è che non erano utilizzate le 6 operazioni, ma è che era preferibile avere un input "spezzettato" del tipo math*4 e text*8, cercando di privilegiare queste ultime (come ha fatto Carmack in Doom); lavorando il più possibile con le textue, si può arrivare a 8 operazioni per ciclo. Questo, ovviamente, se i calcoli sono in fp; se sono in fx, invece, con un input del tipo math/text/text per pipeline si arriva a 12 operazioni per ciclo (esattamente quante quelle dell'R300); questo è esattamente quello che fa il compilatore/ottimizzatore introdotto da nVIDIA dai 52.16 in poi.
Comunque, c'è qualcosa che non mi torna nella sua arringa, avvocato ;) ; da un lato mi dice che ATi collabora poco con gli sviluppatori e, di conseguenza, questi fanno riferimento più ai chip nVIDIA per sviluppare i loro titoli, poichè sono quelli che vanno più incontro alle loro esigenza; dall'altro afferma che la serie NV3x (quella che nVIDIA aveva definito come la più rivoluzionaria), sarebbe stata boicottata dalle SWHouse che avrebbero preferito attenersi alle specifiche standard, meglio interpretate da ATi (cosa vera questa)
Originariamente inviato da GMCPape
E, tornando alla radice del discorso, è stata una differenta scelta architetturale. Che si è rivelata errata da parte di nVidia, sicuramente, ma non priva di fondamento.
nVidia aveva puntato su una maggiore versatilità, e principalmente su shader più complessi e meno precisi. I limiti che evidenzi non tengono conto del fatto che, al cotnrario della concorrenza, nVidia aveva delle unità di shading più versatili, che le permettevano (in teoria) di opn avere limiti sul numero delle istruzioni presenti negli shader, e che già da allora ponevano le basi per il dynamic branching presente poi in SM3. Non ti so dire se tale potenziale sarebbe poi stato esprimibile in relazione alla potenza della GPU, ma è un dato di fatto che R3X0 era "limitata" sotto questo profilo. In ogni caso, i limiti di ATI erano indubbiamente meno pesanti rispetto a quelli di nVidia, ma più che di errori nella progettazione, credo che si tratti di intuizioni sbagliate su come avrebbero sfruttato gli shader i programmatori.
hai detto bene: "in teoria"; una raccomandazione che faceva spesso nVIDIA ai programmatori era quella di adoperare il meno possibile i registri temporanei dei ps; ora, proclamare di poter eseguire un numero teoricamente infinito di operazioni quando si sa che il numero di operazioni possibili e direttamente proporzionali al numero di variabili temporanee che si possono mettere in gioco; ora, anche disponendo di una pipeline più lunga (molto probabilmente di tipo recirculating) che richiede un numero di variabili un po' inferiori allo standard, i calcoli erano ugualmente sbagliati. Per quanto riguarda il dynamic branching, per i ps non c'è potenza di calcolo sufficiente neppure con questa generazione di gpu (e inoltre si pongono altri problemi che diventa troppo lungo elencare ed esaminare in dettaglio); diverso il discorso per i vs per cui la cosa, adesso, sarebbe fattibile.
NV3x è nato da idee concettualmente vecchie: non serviva l'architettura nx2 che è un retaggio del periodo in cui ops per clock e per pass coincidevano (si sarebbe potuta già abbandonare con NV20 e, d'altronde, il Kyro poteva applicare fino ad 8 texture per pass con un'architettura 2x1 e il Rage 128 poteva applicare 2 texel su uno stesso pixel o un texel su due diversi pixel, sempre per pass, con un'architettura 1x1); l'utilizzo di 2 fxu per pipeline e dell'architettura interna a 256 bit (con bus a 128 bit per bilanciare il passaggio dei dati da esterno ad interno e viceversa erano un'eredità dell'NV25); non si tratta di errate valutazioni sull'impiego degli shader, ma di un'impostazione orientata verso le DX8.x piuttosto che verso le DX9 (che può anche essere condivisibile, visto che ancora sono le API più usate).
Originariamente inviato da GMCPape
In certi casi la resa di FP16 non basta. Ed è necessario passare alla full precision. In molti engine, però (e nei bench sintetici quali 3D Mark), si è fatto un'uso esagerato di FP, favorendo ATI. Ovviamente non per cattiveria e pigrizia da parte dei deevloper, ma per delle loro scelte. E se posso capire la necessità di utilizzare FP nei bench sintentici per valutare le prestazioni in quell'ambito, non capisco il perché sia stato così usato nei motori di gioco. Guardando i bench utilizzati, uno dove nVidia ha sempre sofferto in grossa misura è stato proprio Far Cry, che a mio personalissimo avviso è uno dei peggiori motori mai visti (oltre che un titolo mediocre, ma questo non ha attinenza col discorso). Di contro, molti dei motori più utilizzati nei giochi, ma non sempre utilizzati come bench, davano ragione a nVidia (sempre per piccoli divari, cmq). MI vengono in mente le tonnellate di giochi basati su Q3, ma soprattutto il motore degli ISI (F1 Challenge), raramente usato per valutare le performance ma molto usati dai giochi di guida (e relativi mod).
Un altro esempio che mi viene in mente di bench favrevole ad ATI ma non rappresentativo di nulla è stato Halo: un massiccio utilizzo, inutile, di PS 2.0, che non aggiungevano nulla alla qualità dei Ps 1.4. Anche lì, a mio avviso, è stata una pessima scelta che ha tarpato enormemente le prestazioni a ogni architettura, senza aggiungere nulla. Fortunatamente, il gioco è una figata, però ^_^.
il 3DMark2003 faceva uso, si e no, di tre istruzioni SM2.0, Aquamark arrivava forse a 4; non ho i dettagli di Halo e di FC (ma che ti ha fatto? :D ); sicuramente sulla qualità e la quantità di effetti dello SM2.0 implementati in questi giochi fek può esere più preciso ed esaustivo di me. Gli altri esempi che hai fatto sono di titoli che, al massimo, utilizzano qualche feature DX8.x. Le mie critiche alle FX non sono da intendere in senso assoluto, ma solo relativamente alla gestione dei PS2.0 e successivi; con i PS1.x si difendono piuttosto bene (anche se, non dimentichiamo che con i PS1.x le FX lavorano a fx12 e le Radeon a fx16).
Originariamente inviato da GMCPape
Ma su quanti di questi titoli vedevi artefatti di qualsiasi tipo? Alla fine, al giocatore interessa che la resa finale non cambi, e tranne rari casi, i giochi erano visivamente identici.
anche i risultati dei ps3.0 possono essere ottenuti utilizzando i 2.0 e, tranne qualche rara feature, anche i ps1.x; l'evoluzione nel linguaggio di programmazione c'è stata anche per andare incontro alle esigenze di chi programma e per facilitargli il lavoro.
Originariamente inviato da GMCPape
Se il risultato visivo è identico, cosa interessa cosa fa il driver? Certo, inficia i risultati. Ma non esisterà mai un bench intoccabile, per quanto ne so. E i trucchetti li usano sia ati sia nVidia. La lotta è dura ^_^
se il risultato mi serve per dimostrare che il mio prodotto è più veloce di quello della concorrenza e, di conseguenza, per vendere di più, allora sto barando: è una questione di etica e la mia filosofia non è quella del "principe" di Machiavelli; siccome i bench non sono fatti per essere fini a sé stessi..................
Bench non truccabili ci sono; ad esempio lo shadermark non permette l'utilizzo di clipping planes ed è dotato di sofisticati strumenti di antidetect (ed è stato uno degli strumenti che ha evidenziato le difficoltà delle FX con i calcoli in fp).
Originariamente inviato da GMCPape
Forse, si. Ma a quel punto, indipendentemente dalla bontà dell'architettura, vince chi ha più soldi. Ma voglio sperare che non succeda, sebbene alcuni particolari (Far Cry patch 1.2 così come HL2) mi facciano sorgere dei sospetti. Su entrambe le aziende. Ma, chi perderebbe veramente la faccia in caso salti fuori la cosa, sarebbe lo sviluppatore, più che la casa che lo "corrompe".
io di sospetti ne ho sempre avuti (e anche ID ed Epic non mi convincono da questo punto di vista). Per fortuna io i chip li valuto in base all'architettura e non ai risultati dei bench :D
Originariamente inviato da GMCPape
Non dire così, dai. ho fatto il PR anche io, in passato ;-) non sono così cattivi come sembrano... è che sio fa abbindolare da loro, al massimo, a sbagliare.
:D
Originariamente inviato da GMCPape
Quante di queste sono state sfruttate dagli sviluppatori ai tempi? Certo, Trueform era una figata... ma non basta l'idea.. devi anche saperla vendere. E ATI non ci è mai riuscita. Vedremo che saprà fare con 3Dc.
Pape
il truform è diventata la base per il DM introdotto con le DX9 che fa uso, appunto, delle n-patches; per altre cose (i buffer per il multitexturing) ad esmepio, si era troppo in anticipo sui tempi (adesso, senza, non si saprebbe come fare); le DTR sono parte integrante delle DX dalla versione SM1.4 in poi, nonchè dell'OGL, dalla 1.3 in poi. L'architettura dell'R300 l'ha venduta bene, visto che l'ha comprata persino la concorrenza :D
Forse non sarà stata all'altezza di nVIDIA, però non si può dire che non abbia innovato e che ciò che ha introdotto sia passato nel dimenticatoio.
ciao
Alberto Falchi
04-11-2004, 22:03
Originariamente inviato da yossarian
non si tratta di errate valutazioni sull'impiego degli shader, ma di un'impostazione orientata verso le DX8.x piuttosto che verso le DX9 (che può anche essere condivisibile, visto che ancora sono le API più usate).
Beh, speravo che leggessi fra le righe ;-)
Il tuo discorro non può essere letto "mettiamo i PS 2.0 perché dobbiamo (compatibilità DX, bau bau da strillare, pizza e fichi, etc) ma puntiamo a far funzionare ciò che serve (e a porre le basi per il futuro come diciamo noi)?"
Ha perso sì la guerra dei benchmark, ma quantomeno non ha deluso troppo i suoi utenti, che cmq giocavano adeguatamente. Del resto, le schede di fascia alta vendute da nVidia erano quasi tutte 5900 o 5950, visto che la 5800 (per fortuna!) praticamente non è stata distribuita.
il 3DMark2003 faceva uso, si e no, di tre istruzioni SM2.0, Aquamark arrivava forse a 4; non ho i dettagli di Halo e di FC (ma che ti ha fatto? :D ); sicuramente sulla qualità e la quantità di effetti dello SM2.0 implementati in questi giochi fek può esere più preciso ed esaustivo di me.
Non è di quante, ma ne fa uso ampiamente, nel benchamrk. O, più correttamente, lo score della sezione PS di 3D Mark ne era influenzato non poco.
In FC e Halo non so dirti quante fossero le istruzioni, ma a guardando il gioco, mi sembra palese che vengano usati in maniera massiccia. Ben più massiccia che nella maggior parte degli altri titoli, per lo meno.
Gli altri esempi che hai fatto sono di titoli che, al massimo, utilizzano qualche feature DX8.x.
Forse che ci ho azzeccato all'inizio di questo msg? :-)
anche i risultati dei ps3.0 possono essere ottenuti utilizzando i 2.0 e, tranne qualche rara feature, anche i ps1.x; l'evoluzione nel linguaggio di programmazione c'è stata anche per andare incontro alle esigenze di chi programma e per facilitargli il lavoro.
E per passare a gradi e senza salti netti alle successive evoluzioni. Invece di ottimizzare pesantemente per ottenere gli stessi risultati, si usa un'astrazione maggiore per velocizzare. Un po' come passare dall'assembler al C (certo che in assembly fai le stesse cose... ma perdio, quanto ci metti?). O, anche, come passare dallo schema di sviluppo attuale a uno più evoluto, passaggio che potrebbe essere velocizzato e semplificato da XNA (sempre che il progetto vada in porto).
se il risultato mi serve per dimostrare che il mio prodotto è più veloce di quello della concorrenza e, di conseguenza, per vendere di più, allora sto barando: è una questione di etica e la mia filosofia non è quella del "principe" di Machiavelli; siccome i bench non sono fatti per essere fini a sé stessi..................
E siccome la filosofia di Machiavelli si adatta al mercato più di quella del buon sammaritano...
Bench non truccabili ci sono; ad esempio lo shadermark non permette l'utilizzo di clipping planes ed è dotato di sofisticati strumenti di antidetect (ed è stato uno degli strumenti che ha evidenziato le difficoltà delle FX con i calcoli in fp).
Ma, per l'appunto, punta tutto sugli shader, rendendolo molto simile alla sezione shading del 3D Mark. Diciamo che shadermark conferma tale test, lo integra, e non lo userei a sé stante (come non prenderei il punteggio finale di 3D Mark a sè stante).
io di sospetti ne ho sempre avuti (e anche ID ed Epic non mi convincono da questo punto di vista). Per fortuna io i chip li valuto in base all'architettura e non ai risultati dei bench :D
Io ti ho detto come la penso, nei preedenti messaggi, sulle scelte architetturali. Poi, attorno a queste, non escludo ci siano i giochetti marketing delle aziende. Ma il marketing si adatta al prodotto, non viceversa. Almeno nell'alta tecnologia.. se parliamo di trend, ovviamente le cose cambiano ^_^
L'architettura dell'R300 l'ha venduta bene, visto che l'ha comprata persino la concorrenza :D
?
Forse non sarà stata all'altezza di nVIDIA, però non si può dire che non abbia innovato e che ciò che ha introdotto sia passato nel dimenticatoio.
Non certo dimenticatoio nè inutile. Del resto, per anni ATI ha dettato sul 2D, ora ha un vantaggio inferiore, ma rimane ancora imbattuta (escludendo forse Matrox) in molti ambiti, HTPC in particolare.
Certo è che sul 3D si è mossa tardi, e che secondo me ha dato contributi meno significativi di quanto abbiano fatto 3dfx e nVidia. Anche l'architettura col Kyro avevano delle ottime intuizioni... eppure non sono bastate.
Pape
Originariamente inviato da GMCPape
Guardando i bench utilizzati, uno dove nVidia ha sempre sofferto in grossa misura è stato proprio Far Cry, che a mio personalissimo avviso è uno dei peggiori motori mai visti (oltre che un titolo mediocre, ma questo non ha attinenza col discorso).
Ma stai scherzando o stai dicendo sul serio ?
Per fortuna che non ho mai comprato la rivista presso la quale militi ... passi il fatto che ti possa piacere poco/nulla, ma sul motore grafico non sono ammissibili simili commenti.
Alberto Falchi
04-11-2004, 22:16
Originariamente inviato da Maury
Ma stai scherzando o stai dicendo sul serio ?
Per fortuna che non ho mai comprato la rivista presso la quale militi ... passi il fatto che ti possa piacere poco/nulla, ma sul motore grafico non sono ammissibili simili commenti.
Mi sembra di aver sottolineato "a mio personalissimo avviso".
Pape
Troppi driver escono tutti beta mai uno ufficiale spero che con l'uscita del gioco halflife 2 faccia uscire dei driver nuovi ufficiali ottimizati meglio per le direct x
:muro:
:cry:
Originariamente inviato da beejey
Troppi driver escono tutti beta mai uno ufficiale spero che con l'uscita del gioco halflife 2 faccia uscire dei driver nuovi ufficiali ottimizati meglio per le direct x
:muro:
:cry:
Ma nelle directX va già benissimo,l'unica cosa da migliorare sarebbero i filtri e i PS..........
Originariamente inviato da GMCPape
Mi sembra di aver sottolineato "a mio personalissimo avviso".
Pape
Perché x te è uno dei motori peggiori mai visti?
Originariamente inviato da GMCPape
Mi sembra di aver sottolineato "a mio personalissimo avviso".
Pape
Valentino Rossi è una me@da come pilota, idem Schumacker, ovviamente tutto IMHO.
Ti pare che regga ? è credibile ?
Se mi parli di un motore che TUTTO il mondo ha visto ed esaltato come se fosse qualcosa di osceno, beh dai, ma fa solo ridere.
Originariamente inviato da Maury
Ma stai scherzando o stai dicendo sul serio ?
Per fortuna che non ho mai comprato la rivista presso la quale militi ... passi il fatto che ti possa piacere poco/nulla, ma sul motore grafico non sono ammissibili simili commenti.
l'unica persona che può dirlo sicuramente più di noi viste le competenze tecniche in materia.
Se Pape sostiene tutto ciò ,è effetivamente cosi'.:)
Originariamente inviato da Spytek
l'unica persona che può dirlo sicuramente più di noi viste le competenze tecniche in materia.
Se Pape sostiene tutto ciò ,è effetivamente cosi'.:)
Ciao.:)
Originariamente inviato da Spytek
l'unica persona che può dirlo sicuramente più di noi viste le competenze tecniche in materia.
Se Pape sostiene tutto ciò ,è effetivamente cosi'.:)
Ma sei fuori ? da dove salti fuori, dall'uovo di Pasqua ?
Originariamente inviato da Spytek
l'unica persona che può dirlo sicuramente più di noi viste le competenze tecniche in materia.
Se Pape sostiene tutto ciò ,è effetivamente cosi'.:)
Mi viene il dubbio, ma eri ironico ? :confused:
Originariamente inviato da Maury
Ma sei fuori ? da dove salti fuori, dall'uovo di Pasqua ?
Prego?
Desidera?
Originariamente inviato da DNA_RNA
Ciao.:)
;)
Originariamente inviato da Maury
Ma sei fuori ? da dove salti fuori, dall'uovo di Pasqua ?
C'è bisogno di usare questi toni?Secondo me no!
Pape è uno che si occupa del settore e cmq tratta giochi:se ha detto che è uno dei motori peggiori mai visti, ci deve pur essere un motivo.
Diamoli la possibilità di esprimersi.
E che bisogno c'è di dare addosso a Spytek?
cosworth6k
04-11-2004, 22:34
Originariamente inviato da Spytek
l'unica persona che può dirlo sicuramente più di noi viste le competenze tecniche in materia.
Se Pape sostiene tutto ciò ,è effetivamente cosi'.:)
Si certo,come a suo tempo,i pr nvidia dicevano che i detonator non utilizzavano cheat :D
Originariamente inviato da Spytek
Prego?
Desidera?
Addio ;)
Originariamente inviato da DNA_RNA
C'è bisogno di usare questi toni?Secondo me no!
Pape è uno che si occupa del settore e cmq tratta giochi:se ha detto che è uno dei motori peggiori mai visti, ci deve pur essere un motivo.
Diamoli la possibilità di esprimersi.
Non ho parole
Originariamente inviato da cosworth6k
Si certo,come a suo tempo,i pr nvidia dicevano che i detonator non utilizzavano cheat :D
ma che centra Pape con i PR nvidia?:rolleyes:
Originariamente inviato da Maury
Non ho parole
forse perché non sai esprimerti?:rolleyes:
Originariamente inviato da DNA_RNA
forse perché non sai esprimerti?:rolleyes:
Ma tu a Far Cry hai mai giocato ?
Scusa ma se guardi la mia custom forse ti fai un'idea di cosa sia qst titolo per me ... e non sn l'ultimo pirla arrivato ;)
Originariamente inviato da cosworth6k
Si certo,come a suo tempo,i pr nvidia dicevano che i detonator non utilizzavano cheat :D
Sinceramente a me non interessa della fortunata uscita di Farcry,e nemmeno del successo che ha destato in tutto il mondo.
Vorrei dire semplicemente che una persona con la preparazione e le indubbie qualità tecniche come Pape,non si sveglia al mattino e dice cavolate.
Credo che ci saranno motivazioni che l' hanno indotto ad operare una critica del genere nei confronti di uno dei titoli più ambito di tutti i tempi.Sicuramente Pape ci fornirà argomentazioni di carattere tecnico che suffragheranno la propria opinione.Nient'altro :)
Originariamente inviato da Spytek
Sinceramente a me non interessa della fortunata uscita di Farcry,e nemmeno del successo che ha destato in tutto il mondo.
Vorrei dire semplicemente che una persona con la preparazione e le indubbie qualità tecniche come Pape,non si sveglia al mattino e dice cavolate.
Credo che ci saranno motivazioni che l' hanno indotto ad operare una critica del genere nei confronti di uno dei titoli più ambito di tutti i tempi.Sicuramente Pape ci fornirà argomentazioni di carattere tecnico che suffragheranno la propria opinione.Nient'altro :)
Non ti preoccupare,le ha date le motivazioni.;)
Originariamente inviato da Maury
Ma tu a Far Cry hai mai giocato ?
Scusa ma se guardi la mia custom forse ti fai un'idea di cosa sia qst titolo per me ... e non sn l'ultimo pirla arrivato ;)
Si, ci ho giocato.
Il fatto che tu lo ami non giustifica il fatto che hai dato addosso a Pape.
Lui ha i suoi motivi.
Quali sono i tuoi?
Originariamente inviato da DNA_RNA
C'è bisogno di usare questi toni?Secondo me no!
Pape è uno che si occupa del settore e cmq tratta giochi:se ha detto che è uno dei motori peggiori mai visti, ci deve pur essere un motivo.
Diamoli la possibilità di esprimersi.
E che bisogno c'è di dare addosso a Spytek?
Grazie Dna.Non temere so sbrigare la cosa.
Mi hai letto proprio nel pensiero quando mi accingevo a scrivere. ;)
Originariamente inviato da DNA_RNA
Si, ci ho giocato.
Il fatto che tu lo ami non giustifica il fatto che hai dato addosso a Pape.
Lui ha i suoi motivi.
Quali sono i tuoi?
ce l'ha in Sign il suo motivo.Ecco tutto!
Originariamente inviato da DNA_RNA
Si, ci ho giocato.
Il fatto che tu lo ami non giustifica il fatto che hai dato addosso a Pape.
Lui ha i suoi motivi.
Quali sono i tuoi?
Vai nel forum dei games e leggiti i 20000000 di post presenti, Far Cry non è un titolo riassumibile in 2 righe, troppo MAESTOSO ...
Originariamente inviato da Maury
Vai nel forum dei games e leggiti i 20000000 di post presenti, Far Cry non è un titolo riassumibile in 2 righe, troppo MAESTOSO ...
Non ho voglia di leggermi 2 milioni di post a quest'ora,perché non mi riassumi tu il motivo percui è così MAESTOSO?
Alberto Falchi
04-11-2004, 22:48
Allora, visto il polverone che ho involontariamente sollevato, vi incollo il PVT mandato a DNA prima che venisse fuori sto casino.
Se volete discutere di quanto dico, però, contattatemi in MP o aprite un altro thread, almeno non andiamo ulteriormente OT :-)
"non mi sembra il caso di parlarne in quel thread, visto che è OT, e preferisco risponderti personalmente.
Ribadisco, rimane una mia impressione (mia di Pape, non mia come Pape di GMC ^_^), ma il motore di FC mi sembra solo un'accozzaglia di effetti messi li per stupire. Un po' come tutto il gioco. Usare tutte le tecnologie supportate dalle DirectX non è il fine di un engine. Il suo vero fine è quello di rendere ambienti (verosimili o meno) nei quali far interagire un giocatore. Possono essere ambienti fotorealistici o completamente fantasiosi/allucinati, ma il punto di vista di un engine è quello di permettere di rendere certe atmosfere.
Doom III punta sulle ombre realistiche (che non sono come quelle, spettacolari ma "finte" di Far Cry) per creare tensione. A scapito di altre feature.
HL2 punta sul radiosity per simulare al meglio le facce e, di conseguenza, le espressioni dei volti. Perché questo gioco punta sul rapporto con gli altri, sulla fiducia/sfiducia con gli NPC. E punta sull'havok per il gameplay. Così come su un certo uso dei PS e del fresner per rendere l'ambiente credibile, non spettacolare.
FC punta sulla spettacolarità e, in teoria, sugli ambienti immensi. Ma i personaggi plasticosi, le bump che sembrano la stagnola di star trek, i cali di frame rate vergognosi, rovinano sia l'effetto del realismo, sia la qualità (e lì non obietto) degli esterni, che sono davvero splendidi da vedere. Ma nessuno di questi effetti è ancorato al gameplay, lo diversifica, aiuta a immedesimare il player. Anzi. Il mix di realismo dell'ambiente e della finzione dei big jim (lasciameli chiamare così, i personaggi ^_^) e del brillucicoso del bump, devastano.
Senza contare che l'eventuale potenziale del motore è stato bruciato dai designer, più contenti di mettere oggetti pieni di effetti ovunque che di selezionare accuratamente quali coprire di dettaglio e quali invece curare di meno."
Pape
Originariamente inviato da DNA_RNA
Non ho voglia di leggermi 2 milioni di post a quest'ora,perché non mi riassumi tu il motivo percui è così MAESTOSO?
Perchè emoziona, stupisce e ammalia ad ogni piè sospinto, cosa che non ha mai fatto nessun altro game, e gioco forse da prima di Pape ...
Cmq c'è un thread ufficiale, trovi tutto li.
Ragazzi la finite per cortesia?
X Maury
Aspettiamo almeno che Pape ci chiarisca un po le idee.
Però basta con questa lite!E smettiamola!
Io ti dico xké mi è piaciuto:
1)è uno sparatutto,e gli sparatutto mi piaccioni.
2)l'intelligenza artificiale è ottima
3)In certi momenti fa paura
4)le ambientazioni sono abbastanza varie, si va dalla giungla al laboratorio
5)La grafica ha degli effetti strepitosi.
e xké non mi è piaciuto
1)personaggi e certi ambienti troppo ''plastici'', con un bump che sembra fittizio
2)trama ridicola
3)grafica non in funzione del gameplay,ma solo per meravigliare.
4)In certi momenti troppo difficile e ripetitivo
Originariamente inviato da Spytek
Ragazzi la finite per cortesia?
X Maury
Aspettiamo almeno che Pape ci chiarisca un po le idee.
Però basta con questa lite!E smettiamola!
Ha spiegato a me xké non gli è piaciuto in PVT.
Originariamente inviato da Maury
Perchè emoziona, stupisce e ammalia ad ogni piè sospinto, cosa che non ha mai fatto nessun altro game, e gioco forse da prima di Pape ...
Cmq c'è un thread ufficiale, trovi tutto li.
Secondo me è dargli troppo credito ad un gioco così,però ha i suoi meriti;)
cosworth6k
04-11-2004, 22:52
Originariamente inviato da Spytek
Sinceramente a me non interessa della fortunata uscita di Farcry,e nemmeno del successo che ha destato in tutto il mondo.
Vorrei dire semplicemente che una persona con la preparazione e le indubbie qualità tecniche come Pape,non si sveglia al mattino e dice cavolate.
Credo che ci saranno motivazioni che l' hanno indotto ad operare una critica del genere nei confronti di uno dei titoli più ambito di tutti i tempi.Sicuramente Pape ci fornirà argomentazioni di carattere tecnico che suffragheranno la propria opinione.Nient'altro :)
E' tutta una questione di punti di vista ;)
Ora rigiro la tua frase (solo x farti capire quello che intendo dire)
Vorrei dire semplicemente che una persona con la preparazione e le indubbie qualità tecniche come i Pr nvidia,non si svegliano al mattino e dicono cavolate.
Ognuno è libero di esprimere le propie opinioni stà a gli altri (coloro ai quali sono rivolte tali affermazioni) crederci oppure no.
Si certo,come a suo tempo,i pr nvidia dicevano che i detonator non utilizzavano cheat
Tutto questo dal mio punto di vista. :sofico:
Raga tenetevi la vs idea, in qst sede non è mia intenzione parlarne, se volete thread ufficiale.
Ciao
Ma il fatto che i PR di Nvidia dicessero che non ci fossero cheat nei driver, mentre poi c'erano, non è un punto di vista, è un dato di fatto.rolleyes:
Un gioco può avere più punti di vista x i più disparati motivi.
Originariamente inviato da DNA_RNA
Secondo me è dargli troppo credito ad un gioco così,però ha i suoi meriti;)
A me è piaciuto tantissimo.Probabilmente,non essendo un programmatore,non riesco ad individuare i difetti di un gioco come lo ha appena fatto Alberto.
Non volevo buttare fango su quel titolo.
Originariamente inviato da Spytek
A me è piaciuto tantissimo.Probabilmente,non essendo un programmatore,non riesco ad individuare i difetti di un gioco come lo ha appena fatto Alberto.
Non volevo buttare fango su quel titolo.
Anche a me è piaciuto,però certe cose mi hanno dato fastidio.............
cosworth6k
04-11-2004, 22:56
Originariamente inviato da DNA_RNA
Ma il fatto che i PR di Nvidia dicessero che non ci fossero cheat nei driver, mentre poi c'erano, non è un punto di vista, è un dato di fatto.rolleyes:
Un gioco può avere più punti di vista x i più disparati motivi.
Come è un dato di fatto che il motore di far cry sia uno dei migliori (se non il migliore) in circolazione. ;)
Originariamente inviato da Maury
Raga tenetevi la vs idea, in qst sede non è mia intenzione parlarne, se volete thread ufficiale.
Ciao
Qui si discute,non si combatte!
Ognuno è libero di esprimere la propria opinione,altri possono sparare caxxate,l'importante è che lo si faccia in modo civile e rispettoso nei confronti di noi del thred e delle persone nuove che si sono iscritte in questo momento.
Non ho mai detto ad una persona :Ma dove esci dall'uovo di Pasqua?
A mio avviso è ingiustificabile!
Basta Ot e ritorniamo It:)
Originariamente inviato da cosworth6k
Come è un dato di fatto che il motore di far cry sia uno dei migliori (se non il migliore) in circolazione. ;)
Xké dovrebbe essere il migliore?
C'è Doom 3 che è ancora meglio a livello di bump,ombre,e poly.
Far Cry aveva dei personaggi che come ha detto Pape sembravano ''Big Jim'', e io sono d'accordo con lui.
Ciò non toglie che la grafica sia ottima.;)
Originariamente inviato da Spytek
Qui si discute,non si combatte!
Ognuno è libero di esprimere la propria opinione,altri possono sparare caxxate,l'importante è che lo si faccia in modo civile e rispettoso nei confronti di noi del thred e delle persone nuove che si sono iscritte in questo momento.
Non ho mai detto ad una persona :Ma dove esci dall'uovo di Pasqua?
A mio avviso è ingiustificabile!
Basta Ot e ritorniamo It:)
E' ingistificabile che una persona dica una cosa del genere:
l'unica persona che può dirlo sicuramente più di noi viste le competenze tecniche in materia.
Se Pape sostiene tutto ciò ,è effetivamente cosi'
e la vs testa ? le Vs idee ? impressioni ? è effettivamente così perchè lo dice Pape ? Scusa ma ho una mente un tantino più audace ;)
yossarian
04-11-2004, 23:02
Originariamente inviato da GMCPape
Beh, speravo che leggessi fra le righe ;-)
Il tuo discorro non può essere letto "mettiamo i PS 2.0 perché dobbiamo (compatibilità DX, bau bau da strillare, pizza e fichi, etc) ma puntiamo a far funzionare ciò che serve (e a porre le basi per il futuro come diciamo noi)?"
Ha perso sì la guerra dei benchmark, ma quantomeno non ha deluso troppo i suoi utenti, che cmq giocavano adeguatamente. Del resto, le schede di fascia alta vendute da nVidia erano quasi tutte 5900 o 5950, visto che la 5800 (per fortuna!) praticamente non è stata distribuita.
le linee guida erano già tracciate e ci si doveva semplicemente attenere a queste; è inutile proporre un chip con fp32 quando neppure gli sviluppatori potevano fruirne; così come era inutile proporre un chip con un supporto solo teorico al controllo dinamico dei flussi di dati; le feature avveniristiche di NV3x, per una serie di motivi (ma non per colpa degli sviluppatori o di MS o di ATi) erano inutilizzabili; restava l'impiego comune e, in quel campo, si comportava come un buon chip DX8 ma come un pessimo prodotto DX9: questo parlando da tecnico
Originariamente inviato da GMCPape
Non è di quante, ma ne fa uso ampiamente, nel benchamrk. O, più correttamente, lo score della sezione PS di 3D Mark ne era influenzato non poco.
In FC e Halo non so dirti quante fossero le istruzioni, ma a guardando il gioco, mi sembra palese che vengano usati in maniera massiccia. Ben più massiccia che nella maggior parte degli altri titoli, per lo meno.
se un bench mi dice che con lo shader x.y il chip z fa 79 fps e il chip w ne fa 38, allora vuol dire (se non ci sono trucchi) che il chip z è veloce il doppio rispetto al chip w; questo non significa essere influenzati o meno da quel tipo di shader ma è un dato oggettivo (aggiungi pure che in molti test relativi ai ps non si fa neppure texturing, quindi il problema dell'utilizzo contemporaneo di fpu e tmu non viene neanche fuori e le prestazioni sono indice dell'efficienza delle sole alu e quelle dell'NV3x, in fp sono veramente scarse).
Originariamente inviato da GMCPape
Forse che ci ho azzeccato all'inizio di questo msg? :-)
forse si, visto che continuo a non capire dove vuoi andare a parare; forse era opportuno creare bench ad hoc che non facessero uso di ps2.0 per far fare bella figura alle FX? A fronte di che, delle grandi innovazioni (inutilizzabili) proposte? Da dove dovrebbe evincersi questa maggior programmabilità e flessibilità d'impiego se uno come Carmack ha dovuto far ricorso a DTR, utilizzando pochissimo gli shader e, quindi, sfruttando poco questo portento di programmabilità? O se la Valve ha dovuto adottare path specifiche per le FX che fanno ampio uso di ps1.1?
Questi sono gli sviluppatori che si sarebbero dovuti sbizzarrire a lavorare sull'NV3x; e cosa hanno tirato fuori? Per un po' metti da parte i proclami di nVIDIA e guarda ai fatti concreti. NV3x è stata la migliore famiglia di chip DX8 e la peggiore DX9 (soprattutto in relazione ai proclami e all'hype da questi derivante).
Originariamente inviato da GMCPape
E siccome la filosofia di Machiavelli si adatta al mercato più di quella del buon sammaritano...
ma siccome io non mi interesso di vendite ma di tecnologia e il mio campo non è il marketing ma la progettazione, allora non posso accettare un discorso del genere; non accetto che si trucchi un bench per far credere alla gente che un prodotto, oggettivamente più lento, vada quanto un altro.
Originariamente inviato da GMCPape
Ma, per l'appunto, punta tutto sugli shader, rendendolo molto simile alla sezione shading del 3D Mark. Diciamo che shadermark conferma tale test, lo integra, e non lo userei a sé stante (come non prenderei il punteggio finale di 3D Mark a sè stante).
è ovvio che punti sugli shader; la versione 2.0 è stato il primo vero bench DX9 ed è normale che facesse uso di SM2.0; d'altra parte serviva a valutare le prestazioni con quelle API specifiche e non con altre. Non mi sembra un discorso assurdo quello di valutare anche il rendimento con i ps2.0 (oltre che con gli 1.x) di un chip che doveva essere il top della precedente generazione.
Originariamente inviato da GMCPape
Io ti ho detto come la penso, nei preedenti messaggi, sulle scelte architetturali. Poi, attorno a queste, non escludo ci siano i giochetti marketing delle aziende. Ma il marketing si adatta al prodotto, non viceversa. Almeno nell'alta tecnologia.. se parliamo di trend, ovviamente le cose cambiano ^_^
beh, l'hai detto tu che al mercato mal si adatta la filosofia del buon samaritano; quindi perchè, se è lecito truccare un bench, non lo è altrettanto pagare uno sviluppatore perchè il suo SW giri meglio su un prodotto anzichè su un altro?
Unico neo, in questo meraviglioso congegno perfettamente oliato, è che i mezzi di indagine sono diventati sempre più subdoli e sofisticati e diventa sempre più dufficile coprire i "magheggi".
Originariamente inviato da GMCPape
?
Pape
esame sommario dell'NV40
vs: identici a quelli dell'R300, con unità fp32 in parallelo ad una di tipo vect fp128 (diversi da quelli di NV30 con una sola unità fp128), con l'aggiunta di una texture unit e di un'unità per il branching per la compatibilità con lo SM3.0
pixel pipeline: architettura nx1 (come quella di R300), con due fpu per pipeline (come R300 e R420 ), solo che la prima non è indipendente dalla tmu (come in NV3x, ma questo è un difetto). Architettura 1+1+1+1, evoluzione della 1+3 dell'R300 piuttosto che della vect fp128 dell'NV30, la cui composizione della pipeline prevedeva 1 fpu e 2 fxu, divenute poi 2 fpu e 1 fxu su NV35)
architettura interna a 512 bit (come R300; NV30 l'aveva a 256 bit)
rop's: identiche a quelle dell'NV3x (unica cos veramente riuscita di quel chip)
Questo senza citare l'AA di tipo MSRG anzjìichè MSOG, perchè questo è un elemento di minor conto nella valutazione complessiva di un'architettura.
Pare proprio che nVIDIA abbia attinto a piene mani dal progetto R300, utilizzando ben poco di quello NV30.
Originariamente inviato da GMCPape
Non certo dimenticatoio nè inutile. Del resto, per anni ATI ha dettato sul 2D, ora ha un vantaggio inferiore, ma rimane ancora imbattuta (escludendo forse Matrox) in molti ambiti, HTPC in particolare.
Certo è che sul 3D si è mossa tardi, e che secondo me ha dato contributi meno significativi di quanto abbiano fatto 3dfx e nVidia. Anche l'architettura col Kyro avevano delle ottime intuizioni... eppure non sono bastate.
Pape
però molte sono state riprese anche dagli altri, ad iniziare dal TBR che è la base degli algoritmi di HSR utilizzati dagli attuali produttori di chip (anche se in versione più sofisticata, soprattutto quello di ATi che ha, addirittura, uno hyerarchical a 3 livelli prima di arrivare all'analisi per pixel)
cosworth6k
04-11-2004, 23:05
Originariamente inviato da DNA_RNA
Xké dovrebbe essere il migliore?
C'è Doom 3 che è ancora meglio a livello di bump,ombre,e poly.
Far Cry aveva dei personaggi che come ha detto Pape sembravano ''Big Jim'', e io sono d'accordo con lui.
Ciò non toglie che la grafica sia ottima.;)
Ultimo reply lo prometto :D
eheheh e le teste "spigolose" in doom3 dove le metti?
Il motore di far cry ha dimostrato "sul campo" di saper gestire sia gli spazi aperti (immensi) che quelli chiusi in modo ottimale.
Se a doom3 togli le ombre cosa rimane?
Vedremo come si comportera l'egine in spazi più ampi (quake 4) ma x il momento............ ;)
Originariamente inviato da cosworth6k
Ultimo reply lo prometto :D
eheheh e le teste "spigolose" in doom3 dove le metti?
Il motore di far cry ha dimostrato "sul campo" di saper gestire sia gli spazi aperti (immensi) che quelli chiusi in modo ottimale.
Se a doom3 togli le ombre cosa rimane?
Vedremo come si comportera l'egine in spazi più ampi (quake 4) ma x il momento............ ;)
Far Cry gestisce gli spazi esterni meglio però ha dei crolli di FPS inspiegabili.
Far cry ha i ''big jim''
Doom 3 ha le teste spigolose,gli rimangono solo le ombre e,come Far Cry,ha una trama pietosa.
Non ci resta che sperare in HALF-LIFE 2.:Perfido:
Quello che fa vedere Far Cry non lo fa vedere nessun gioco al mondo, Doom 3 compreso. Far Cry crea un mondo dove tu puoi fare e impostare una strategia come mai si era visto, sfonda di netto il canone classico delle 4 pareti in croce, va oltre e lo fa con una struttura tecnico/grafica da mascella slogata.
cosworth6k
04-11-2004, 23:11
Originariamente inviato da DNA_RNA
Far Cry gestisce gli spazi esterni meglio però ha dei crolli di FPS inspiegabili.
Far cry ha i ''big jim''
Doom 3 ha le teste spigolose,gli rimangono solo le ombre e,come Far Cry,ha una trama pietosa.
Non ci resta che sperare in HALF-LIFE 2.:Perfido:
La trama (cosa che non ho mai menzionato) non ha nulla a che vedere con il motore grafico. ;)
X quanto riguarda hl2 staremo a vedere.
Originariamente inviato da Maury
Quello che fa vedere Far Cry non lo fa vedere nessun gioco al mondo, Doom 3 compreso. Far Cry crea un mondo dove tu puoi fare e impostare una strategia come mai si era visto, sfonda di netto il canone classico delle 4 pareti in croce, va oltre e lo fa con una struttura tecnico/grafica da mascella slogata.
X il gameplay sono d'accordo,è incredibile, però la trama è pietosa e poi diventa ripetitivo verso la fine x non parlare della difficoltà eccessiva.;)
Originariamente inviato da cosworth6k
La trama (cosa che non ho mai menzionato) non ha nulla a che vedere con il motore grafico. ;)
X quanto riguarda hl2 staremo a vedere.
Giusto:non ha nulla a che vedere con il motore xrò è sempre pietosa!:D
Originariamente inviato da cosworth6k
La trama (cosa che non ho mai menzionato) non ha nulla a che vedere con il motore grafico. ;)
X quanto riguarda hl2 staremo a vedere.
Ho visto in un cd,una dimostrazione di come fosse il gioco.
Sinceramente sono rimasto con la bocca aperta.
Una domanda che vorrei porvi e poi basta con l'andare in Ot.
Sono false le voci di un eventuale ritardo di un anno di HalfLife 2? :)
Originariamente inviato da DNA_RNA
X il gameplay sono d'accordo,è incredibile, però la trama è pietosa e poi diventa ripetitivo verso la fine x non parlare della difficoltà eccessiva.;)
Allora vedi che cominciamo a trovare qualcosa di buono ? :)
Guarda caso ci sto rigiocando con calma e attenzione in qst giorni, la trama nella sua semplicità è perfetta, lega i livelli in modo ottimale (e capita di rado) e ti da un motivo per andare avanti. Purtroppo ora devo andare a ronfare che domani ho una levataccia ma ne parlerò volentieri ;)
Riponiamo le nostre speranze in Half-Life 2, o a limite F.E.A.R.:Perfido:
Quake 4 mi sa tanto di già visto.:rolleyes:
Anch'io vado a dormire..........Buonanotte.:)
PS Celebrate..............non vi dico cosa!:Perfido:
Originariamente inviato da DNA_RNA
X il gameplay sono d'accordo,è incredibile, però la trama è pietosa e poi diventa ripetitivo verso la fine x non parlare della difficoltà eccessiva.;)
Un pò le "difficoltà" che va incontro Doom3,con gli scenari stereotipati e le atmosfere sempre tetre !
Alberto Falchi
04-11-2004, 23:20
Originariamente inviato da yossarian
le linee guida erano già tracciate e ci si doveva semplicemente attenere a queste; è inutile proporre un chip con fp32 quando neppure gli sviluppatori potevano fruirne; così come era inutile proporre un chip con un supporto solo teorico al controllo dinamico dei flussi di dati; le feature avveniristiche di NV3x, per una serie di motivi (ma non per colpa degli sviluppatori o di MS o di ATi) erano inutilizzabili; restava l'impiego comune e, in quel campo, si comportava come un buon chip DX8 ma come un pessimo prodotto DX9: questo parlando da tecnico
TU parli da tecnico, io da appassionato/giornalista. In entrambe le vesti, il mio fine è uno: giudicare un'architettura in relazione a quello che offre al giocatore. Valutare le sottigliezze tecniche è una cosa che mi diverte, eccome, ma quando devo esprimere un giudizio definitivo, lo faccio in funzione del suo utilizzo. è per questo che, pur esaltando R3X0, non boccio NV3X. Entrambe raggiungevano il loro fine. Una meglio, l'altra meno, ma senza un distacco eccessivo. I limiti tecnici, non hanno troppo pesato sulla fruibilità della scheda nelle applicazioni reali.
se un bench mi dice che con lo shader x.y il chip z fa 79 fps e il chip w ne fa 38, allora vuol dire (se non ci sono trucchi) che il chip z è veloce il doppio rispetto al chip w; questo non significa essere influenzati o meno da quel tipo di shader ma è un dato oggettivo (aggiungi pure che in molti test relativi ai ps non si fa neppure texturing, quindi il problema dell'utilizzo contemporaneo di fpu e tmu non viene neanche fuori e le prestazioni sono indice dell'efficienza delle sole alu e quelle dell'NV3x, in fp sono veramente scarse).
Ma quanto quel particolare algoritmo è utilizzato dai giochi? E in quale misura? Io mi pongo questi problemi.
forse si, visto che continuo a non capire dove vuoi andare a parare; forse era opportuno creare bench ad hoc che non facessero uso di ps2.0 per far fare bella figura alle FX? A fronte di che, delle grandi innovazioni (inutilizzabili) proposte? Da dove dovrebbe evincersi questa maggior programmabilità e flessibilità d'impiego se uno come Carmack ha dovuto far ricorso a DTR, utilizzando pochissimo gli shader e, quindi, sfruttando poco questo portento di programmabilità?
Voglio dire che i bench vanno presi per quello che sono, e la promozione o bocciatura di un'architettura sono da ricercare non nella prestazione estrema, quanto nei test "reali". I giochi più diffusi, sono il bench definitivo per l'utente. I test sintetici o particolari engine, per il tecnico.
O se la Valve ha dovuto adottare path specifiche per le FX che fanno ampio uso di ps1.1?
Questi sono gli sviluppatori che si sarebbero dovuti sbizzarrire a lavorare sull'NV3x; e cosa hanno tirato fuori? Per un po' metti da parte i proclami di nVIDIA e guarda ai fatti concreti. NV3x è stata la migliore famiglia di chip DX8 e la peggiore DX9 (soprattutto in relazione ai proclami e all'hype da questi derivante).
Sicuro. Ma i giochi DX9 (la maggior parte) stanno uscendo ora. Non ai tempi di NV3X. è questo il punto del discorso.
ma siccome io non mi interesso di vendite ma di tecnologia e il mio campo non è il marketing ma la progettazione, allora non posso accettare un discorso del genere; non accetto che si trucchi un bench per far credere alla gente che un prodotto, oggettivamente più lento, vada quanto un altro.
Guarda chi collabora attivamente con Futuremark. I due colossi della grafica. Giocano a chi corrompe di più? No, giocano a chi ottimizza meglio e senza usare trucchi illeciti (o senza farsi scoprire, almeno). Se questi si riflettono in una maggiore ricerca sui driver, che poi garantiscono migliori prestazioni nei giochi, mi va bene. Se no, amen. Ed è per questo che nelle mie valutazioni, il 3D mark ha un peso relativo, al contrario degli engine dei giochi più usati (ergo: anche aquamark ha un basso peso, nel mio giudizio)
beh, l'hai detto tu che al mercato mal si adatta la filosofia del buon samaritano; quindi perchè, se è lecito truccare un bench, non lo è altrettanto pagare uno sviluppatore perchè il suo SW giri meglio su un prodotto anzichè su un altro?
Lecito, ma folle. Soprattutto ora, che le due aziende si spartiscono quasi equamente il mercato. Uno sviluppatore si taglierebbe una fetta tanto grande di utenti? Direi di no. Ottimizza meglio per una, per qualunque motivo (soldi, comodità, bla bla)? OK, tanto un 5% di scarto a me non cambia.
Senza contare che mi fa ridere pensare a un collezionista di Ferrari come Carmack che prende soldi da qualche produttore di GPU ^_^
Unico neo, in questo meraviglioso congegno perfettamente oliato, è che i mezzi di indagine sono diventati sempre più subdoli e sofisticati e diventa sempre più dufficile coprire i "magheggi".
NO, è semplice. Invece di giudicare dai bench, basta giocare e prendere i valori solo come analisi tecnica. Del resto, gli audiofili insieme a tante tabelle sulle caratteristiche di un ampli, non passano ore ad ascoltarlo?
Pape
yossarian
05-11-2004, 00:12
Originariamente inviato da GMCPape
TU parli da tecnico, io da appassionato/giornalista. In entrambe le vesti, il mio fine è uno: giudicare un'architettura in relazione a quello che offre al giocatore. Valutare le sottigliezze tecniche è una cosa che mi diverte, eccome, ma quando devo esprimere un giudizio definitivo, lo faccio in funzione del suo utilizzo. è per questo che, pur esaltando R3X0, non boccio NV3X. Entrambe raggiungevano il loro fine. Una meglio, l'altra meno, ma senza un distacco eccessivo. I limiti tecnici, non hanno troppo pesato sulla fruibilità della scheda nelle applicazioni reali.
mai criticate le FX per il loro rendimento con i ps1.x, solo che la mia deformazione mentale mi porta a valutare un'architettura nel suo complesso e non soltanto in relazione ad un utilizzo peculiare (anche se è quello per cui l'architettura è stata progettata); d'altronde, neppure R300 e neppure NV40 e R420 farebbero girare fluidamente codice full SM2.0
Originariamente inviato da GMCPape
Voglio dire che i bench vanno presi per quello che sono, e la promozione o bocciatura di un'architettura sono da ricercare non nella prestazione estrema, quanto nei test "reali". I giochi più diffusi, sono il bench definitivo per l'utente. I test sintetici o particolari engine, per il tecnico.
vero, però cercare il limite estremo ti dà una misura della bontà di quella determinata architettura, ti permette di individuarne i punti deboli e quelli di forza; certo, sono deformazioni da tecnici, però tocca che ti abitui a questo tenore di discussioni; qui, come su altri forum, ci sono diversi tecnici che si occupano di HW o di SW e che spesso si lasciano andare a disamine di questa natura, combinando le rispettive competenze per cercare di carpire i segreti di una determinata architettura. In quest'ottica, il parere di un appassionato di tecnologia che si occupa anche di giochi può essere utile.
Originariamente inviato da GMCPape
Sicuro. Ma i giochi DX9 (la maggior parte) stanno uscendo ora. Non ai tempi di NV3X. è questo il punto del discorso.
se è per questo non sono neppure full DX9 (altrimenti ne vedremmo delle belle :D )
Originariamente inviato da GMCPape
Guarda chi collabora attivamente con Futuremark. I due colossi della grafica. Giocano a chi corrompe di più? No, giocano a chi ottimizza meglio e senza usare trucchi illeciti (o senza farsi scoprire, almeno). Se questi si riflettono in una maggiore ricerca sui driver, che poi garantiscono migliori prestazioni nei giochi, mi va bene. Se no, amen. Ed è per questo che nelle mie valutazioni, il 3D mark ha un peso relativo, al contrario degli engine dei giochi più usati (ergo: anche aquamark ha un basso peso, nel mio giudizio)
lo scorso anno nVIDIA ha usato più di qualche trucco illecito; con NV40, per fortuna non ne ha bisogno.
Originariamente inviato da GMCPape
Lecito, ma folle. Soprattutto ora, che le due aziende si spartiscono quasi equamente il mercato. Uno sviluppatore si taglierebbe una fetta tanto grande di utenti? Direi di no. Ottimizza meglio per una, per qualunque motivo (soldi, comodità, bla bla)? OK, tanto un 5% di scarto a me non cambia.
Senza contare che mi fa ridere pensare a un collezionista di Ferrari come Carmack che prende soldi da qualche produttore di GPU ^_^
Pape
ma infatti, quando dico farlo andare meglio su un'architettura rispetto ad un'altra intendo con differenze dell'ordine di un 5-10% al massimo.
Le Ferrari costa comprarle e costa mantenerle :D
Al di là delle battute, resta il fatto che le scelte di Carmack hanno favorito nVIDIA; che l'abbia fatto per soldi, per simpatia, per convenienza per scelta tecnica o sia stata una semplice casualità (questa è l'eventualità meno probabile, però), quasto solo lui può saperlo.
Originariamente inviato da GMCPape
NO, è semplice. Invece di giudicare dai bench, basta giocare e prendere i valori solo come analisi tecnica. Del resto, gli audiofili insieme a tante tabelle sulle caratteristiche di un ampli, non passano ore ad ascoltarlo?
il fatto è che a me, come ad altri qui dentro, interessa anche l'analisi tecnica; e per fortuna e così; per fortuna c'è sempre più gente che non guarda il numeretto finale del 3DMark ma inizia a porsi domande sui singoli test a cercare di capire perchè quel chip dà quei risultati con quella particolare applicazione. Per fortuna, da un po' di tempo, si parla anche di alu, pipeline, tmu e non solo di fps o di punteggi. Unico neo è che questi forum rappresentano solo una piccola parte della comunità di coloro che fanno uso di un pc.
Vedere come un chip si comporta con un gioco è importante, è la cosiddetta prova su strada; però sapere qualcosa di più della macchina che si sta guidando non fa male e devo dire che, da questo punto di vista, noto una crescita di queste comunità virtuali.
ciao
p.s. purtroppo lo so, ho le mie deformazioni mentali; il fatto è che sono un tecnico con la passione per l'archelogia (e l'archeologia non è per niente facile da comprendere) :D
Mamma mia che bella discussione, era da tempo che non ne leggevo una così! :)
Vorrei fare un paio di domande a yossarian:
a) che differenza c'è fra un'unità fp128 vettoriale (come quella di NV30) e un'unità fb128 classica (tipo R300)?
b) quando parli della migliore organizzazione dei ROP in NV40 fai riferimento a quello che leggo in nell'articolo seguente?
http://www.beyond3d.com/previews/nvidia/nv43/index.php?p=7
Se si, mi pare di capire che questa disposizione dei ROP non era presente in NV3x, che invece aveva una disposizone classica di queste unità (in pratica mancava il controller crossbar tra i quad e i ROP engine).
c) (ultima domada! :p) quali solo le valutazioni tecniche che ti fanno definire NV40 un chip tecnicamente migliore di R420? Personalmente, quardando i dati relativi al single texturing e al multitexturing, perso che R420 posso avere un controller di memoria meno performante rispetto a quello di NV40 oppure che le sue pixel pipe (e le cache che le riforniscono) non riescono a lavorare efficacemente come NV40 in situazione di single texturing. Puoi confermare/smentire questa mia impressione, e in entrambi i casi puoi fornirmi delle motivazioni tecniche?
Scusa se ti stretto con tutte queste domande, ma quando ti becco ti sfrutto fino alla fine! :D
Tornando in topic: personalmente reputo i Catalyst ottimi driver. Anzi, io (e preciso io, che non gioco moltissimo né mi procuro subito gli ultimissimi titoli) non ho avuto problemi neanche quando, a Maggio 2002, acquistai la mia ex 8500LE. Sicuramente però rispetto alla data di uscita della scheda (Ottobre 2001) i driver erano migliorati parecchio.
Un'ultima cosa: ricordo perfettamente (e anche Raven potrà confermarvelo) che la 8500 ha avuto notevoli boost prestazioni con i Catalyst 4.2, usciti a Febbraio 2004: avere un aumento prestazionale da una scheda vecchia di 2 anni (rispetto all'uscita di questi driver) mi sembra un'ottima cosa...
CIAO! :)
yossarian
05-11-2004, 01:10
Originariamente inviato da shodan
Mamma mia che bella discussione, era da tempo che non ne leggevo una così! :)
Vorrei fare un paio di domande a yossarian:
a) che differenza c'è fra un'unità fp128 vettoriale (come quella di NV30) e un'unità fb128 classica (tipo R300)?
b) quando parli della migliore organizzazione dei ROP in NV40 fai riferimento a quello che leggo in nell'articolo seguente?
http://www.beyond3d.com/previews/nvidia/nv43/index.php?p=7
Se si, mi pare di capire che questa disposizione dei ROP non era presente in NV3x, che invece aveva una disposizone classica di queste unità (in pratica mancava il controller crossbar tra i quad e i ROP engine).
c) (ultima domada! :p) quali solo le valutazioni tecniche che ti fanno definire NV40 un chip tecnicamente migliore di R420? Personalmente, quardando i dati relativi al single texturing e al multitexturing, perso che R420 posso avere un controller di memoria meno performante rispetto a quello di NV40 oppure che le sue pixel pipe (e le cache che le riforniscono) non riescono a lavorare efficacemente come NV40 in situazione di single texturing. Puoi confermare/smentire questa mia impressione, e in entrambi i casi puoi fornirmi delle motivazioni tecniche?
Scusa se ti stretto con tutte queste domande, ma quando ti becco ti sfrutto fino alla fine! :D
Tornando in topic: personalmente reputo i Catalyst ottimi driver. Anzi, io (e preciso io, che non gioco moltissimo né mi procuro subito gli ultimissimi titoli) non ho avuto problemi neanche quando, a Maggio 2002, acquistai la mia ex 8500LE. Sicuramente però rispetto alla data di uscita della scheda (Ottobre 2001) i driver erano migliorati parecchio.
Un'ultima cosa: ricordo perfettamente (e anche Raven potrà confermarvelo) che la 8500 ha avuto notevoli boost prestazioni con i Catalyst 4.2, usciti a Febbraio 2004: avere un aumento prestazionale da una scheda vecchia di 2 anni (rispetto all'uscita di questi driver) mi sembra un'ottima cosa...
CIAO! :)
a) un'unità full vect fp128 è composta da 4 unità fp32 in parallelo, gestite da un controller; sono dotate di buffer per i dati in input e in output comuni e sono viste come un'unica unità di calcolo dai dati in ingresso. Questo significa che il loro rendimento massimo si ha quando in input si hanno serie di vettori completi, ossia dotati, ciascuno di 4 componenti; in tal modo tutte e 4 le unità fp32 sono attive. In caso di input di tipo incompleto alcune unità fp32 restano in attive (non possono lavorare su altri dati eventualmente in ingresso, finchè le unità ad esse in parallelo, che sono occupate ad eseguire qualche calcolo, non hanno terminato; questo perchè, a livello di organizzazione logica, un'unità full vect è vista come unica e perciò o è occupata (anche se di fatto alavorare sono solo alcuni suoi elementi) oppure è disponibile. NV30 ha vs composti da unità full vect fp128. R300 ha vs composti da unità full vest fp128 con in parallelo unità fp32 scalari; il vantaggio di questa configurazione è quello di poter processare in parallelo un massimo di 5 dati di cui 4 facenti parte di un vettore e 1 di un altro (contro i 4 dell'NV30).
b) le rop's di NV40 sono identiche a quelle di NV30; hanno entrambe un doppio punto di spilling dei dati e l'unità che si occupa di colour ops che svolge anche z-ops: questo permette, in caso di sole operazioni relative allo z-buffer, di avere in output un numero di pixel doppio (8 per NV30 e 32 per NV40) recanti valori relativi al solo asse z.
La differenza tra NV3x e NV40 è quella che tu hai colto e cioè la presenza di una connessione crossbar che è anche una delle principali responsabili della maggior efficienza delle pixel pipeline dell'NV40 rispetto a quelle dell'R420. Questa connessione permette di ottimizzare il flusso di dati tra pixel pipeline e rop's, indirizzando i dati verso la prima unità disponibile; in tal modo si riducono le code e i tempi di attesa
c) le cose che mi piacciono di più di NV40 sono la crossbar connection tra pixel pipe e rop's e l'architettura siperscalare delle pixel pipeline, che è sicuramente più flessibile di quella dell'R420.
Riallacciandoci al discorso fatto sui vs, dovrebbe esserti facile capire come un'architettura 1+1+1+1 possa, in certe situazioni, risultare più efficiente di una 3+1 come quella di ATi, dove con 1+1+1+1 si intende 4 unità fp32 scalari in parallelo e con 3+1 una unità fp72 vettoriale e una fp24 scalare (la prima è vista come 4 distinte unità di calcolo scalari che possono combinarsi, all'occorrenza, a formare un vettore completo a 4 componenti, oppure in modalità 3+1 o 2+2 ecc, la seconda come due unità in parallelo che si combinano solo in modalità 4+0, 3+1, 2+1, 1+1).
Quello che mi piace meno di NV40 è la dipendenza tra prima alu e tmu che riduce, in caso di texture fetch e calcoli matematici in contemporanea, il potenziale complessivo di NV40 a sole 32 operazioni vettoriali complete, contro le 48 di R420 (ovvio che c'è sempre da tener conto della forma dei dati in input e della morfologia delle pixel pipeline)
ciao
Grazie mille, sei sempre precissimo! :)
Riguarda al link postato ci hai dato un'occhiata? Come lo trovi?
Un'ultima cosa: relativamente al discorso che ho fatto prima circa la presunta minore efficienza del memory controller di R420 rispetto a NV40 puoi darmi qualche info?
Ciao grazie ancora! :)
yossarian
05-11-2004, 01:32
Originariamente inviato da shodan
Grazie mille, sei sempre precissimo! :)
Riguarda al link postato ci hai dato un'occhiata? Come lo trovi?
Un'ultima cosa: relativamente al discorso che ho fatto prima circa la presunta minore efficienza del memory controller di R420 rispetto a NV40 puoi darmi qualche info?
Ciao grazie ancora! :)
si lo avevo già visto; seguo B3D piuttosto spesso (anche il forum); ci sono tanti spunti interessanti.
Riguardo al memory controller, che io sappia, non ci dovrebbe essere una minore efficienza di R420; la differenza nei dati del single texturing la fa la migliore organizzazione delle pixel pipeline dell'NV40. I memory controller di R420 e di NV40 sono molto simili tra loro (4 canali da 64 bit ciascuno); può variare, ma non di molto, la frequenza di funzionamento che per R420 è di 560 Mhz (per NV40 non lo so).
Originariamente inviato da DNA_RNA
Anch'io vado a dormire..........Buonanotte.:)
PS Celebrate..............non vi dico cosa!:Perfido:
buongiorno, al solito ti scopri sempre con questa storia dell'impero nero, ormai hai rotto le scatole.
x spytek
half life esce sicuramente entro breve (mancano circa 11 giorni), già ci sono alcune recensioni in giro.per riferimento puoi usare il topic ufficiale nella sezione giochi per pc del forum. fine ot.
x yossarian
complimenti, al solito spiegazioni cristalline :)
Originariamente inviato da GMCPape
Allora, visto il polverone che ho involontariamente sollevato, vi incollo il PVT mandato a DNA prima che venisse fuori sto casino.
CUT
Del motore di Far Cry può criticare l'uso che i Crytek, al loro primo gioco vorrei sottolineare, ne hanno fatto, ma non del motore in sé. Offre non solo tutto quello che ha l'engine di Doom3, ma molto di più.
Athlon 64 3000+
05-11-2004, 08:36
Dato che la mia scheda video deriva dal progetto R300(che ogni giorno
che passa mi stupisce sempre di più)volevo chiederti quanto potrà influire la dipendenza tra alu e tmu in NV40 in futuro nei giochi.
Poi volevo chiederti,dato che L'r3xx supporta il geometry instacty(o come si chiama) come L'NV40 e R420 quanto può risultare efficiente sulle schede della passata generazione?(9700/9800...)
yossarian
05-11-2004, 09:06
Originariamente inviato da Athlon 64 3000+
Dato che la mia scheda video deriva dal progetto R300(che ogni giorno
che passa mi stupisce sempre di più)volevo chiederti quanto potrà influire la dipendenza tra alu e tmu in NV40 in futuro nei giochi.
Poi volevo chiederti,dato che L'r3xx supporta il geometry instacty(o come si chiama) come L'NV40 e R420 quanto può risultare efficiente sulle schede della passata generazione?(9700/9800...)
la dipendenza tra alu e tmu limita la capacità di calcolo complessiva del chip; ad esempio, nel caso dell'NV40, con 2 alu e 1 tmu per pipeline (come R420), la capacità teorica di calcolo massima si otterrebbe per un input del tipo fp/fp/text, dove fp sta per calcolo in floating point e text sta per operazione sulle texture. In tal caso si otterrebbe un picco di 48 operazioni su vettori completi (ogni alu e ogni tmu è composta da 4 unità scalari fp32) per ciclo di clock; la dipendenza suddetta limita la capacità dell'NV40 a "sole" 32 operazioni per ciclo di clock che possono essere o di tipo fp/text o di tipo fp/fp. Molto dipenderà anche da come sarà scritto il SW e da quanto potrà sfruttare l'architettura superscalare delle pixel pipeline dell'NV40 (ogni unità è composta da 4 unità scalari indipendenti, al contrario di quanto avviene in R420 e R300 dove si hanno 1 unità vettoriale fp72 e 1 scalare fp24). Se, infatti, calcoliamo il numero complessivo di operazioni scalari, nonostante le limitazioni, l'NV40 arriva a 128 operazioni per ciclo contro le 96 di R420 e R300.
Come puoi capire, molto dipende da come i programmatori decideranno di sfruttare l'HW a disposizione; diciamo che, in senso assoluto, la dipendenza in NV40 è un handicap che può essere bilanciato dall'architettura superscalare e dalla maggiore efficienza nel trasferimento dati fornito dalla crossbar connection tra rop's e pixel pipe (la stessa cosa non avveniva nella serie NV3x che non aveva architettura superscalare e neppure crossbar connection e da questa dipendenza traeva solo svantaggi). Un esempio di gioco che non crea problemi all'NV40 è il tanto dibattuto Doom3 in cui le operazioni matematiche sono ridotte ai minimi termini, a vantaggio di quelle sulle texture.
Il geometry instancing permette di replicare uno stesso oggetto; ad esempio, un albero in una foresta oppure, in uno strategico, un soldato. In tal caso, basta "scrivere" il codice relativo ad un singolo oggetto e la gpu si occuperà di allocare quello stesso oggetto in tutte le altre posizioni che gli saranno indicate. E' una feature piuttosto interessante che, però, al momento, non mi risulta sia ancora utilizzata (qui fek può confermare o smentire :D ). L'implementazione fatta sull'R3x0 è identica a quella dell'R420 o dell'NV40 (le uniche differenze sono dovute alle diverse potenze di calcolo tra chip di questa e della passata generazione)
Athlon 64 3000+
05-11-2004, 09:17
Originariamente inviato da yossarian
la dipendenza tra alu e tmu limita la capacità di calcolo complessiva del chip; ad esempio, nel caso dell'NV40, con 2 alu e 1 tmu per pipeline (come R420), la capacità teorica di calcolo massima si otterrebbe per un input del tipo fp/fp/text, dove fp sta per calcolo in floating point e text sta per operazione sulle texture. In tal caso si otterrebbe un picco di 48 operazioni su vettori completi (ogni alu e ogni tmu è composta da 4 unità scalari fp32) per ciclo di clock; la dipendenza suddetta limita la capacità dell'NV40 a "sole" 32 operazioni per ciclo di clock che possono essere o di tipo fp/text o di tipo fp/fp. Molto dipenderà anche da come sarà scritto il SW e da quanto potrà sfruttare l'architettura superscalare delle pixel pipeline dell'NV40 (ogni unità è composta da 4 unità scalari indipendenti, al contrario di quanto avviene in R420 e R300 dove si hanno 1 unità vettoriale fp72 e 1 scalare fp24). Se, infatti, calcoliamo il numero complessivo di operazioni scalari, nonostante le limitazioni, l'NV40 arriva a 128 operazioni per ciclo contro le 96 di R420 e R300.
Come puoi capire, molto dipende da come i programmatori decideranno di sfruttare l'HW a disposizione; diciamo che, in senso assoluto, la dipendenza in NV40 è un handicap che può essere bilanciato dall'architettura superscalare e dalla maggiore efficienza nel trasferimento dati fornito dalla crossbar connection tra rop's e pixel pipe (la stessa cosa non avveniva nella serie NV3x che non aveva architettura superscalare e neppure crossbar connection e da questa dipendenza traeva solo svantaggi). Un esempio di gioco che non crea problemi all'NV40 è il tanto dibattuto Doom3 in cui le operazioni matematiche sono ridotte ai minimi termini, a vantaggio di quelle sulle texture.
Il geometry instancing permette di replicare uno stesso oggetto; ad esempio, un albero in una foresta oppure, in uno strategico, un soldato. In tal caso, basta "scrivere" il codice relativo ad un singolo oggetto e la gpu si occuperà di allocare quello stesso oggetto in tutte le altre posizioni che gli saranno indicate. E' una feature piuttosto interessante che, però, al momento, non mi risulta sia ancora utilizzata (qui fek può confermare o smentire :D ). L'implementazione fatta sull'R3x0 è identica a quella dell'R420 o dell'NV40 (le uniche differenze sono dovute alle diverse potenze di calcolo tra chip di questa e della passata generazione)
Grazie per le informazioni.
Mi ero dimenticato di chiederti una cosa.
Quando fù presentato L'NV40 ad aprile dicevi che l'nv40 si comportava non come una gpu a 16 pipeline,me come una 12+4 per via di una cosa particolare che non mi ricordo.
Come poi è andata a finire questa stranezza?
Originariamente inviato da MaBru
Del motore di Far Cry può criticare l'uso che i Crytek, al loro primo gioco vorrei sottolineare, ne hanno fatto, ma non del motore in sé. Offre non solo tutto quello che ha l'engine di Doom3, ma molto di più.
A dire il vero non è il loro primo motore :)
E' l'estensione di un motore usato per una demo (qualcosa-Isle).
A parte questo, hai centrato perfettamente il punto, nel copia/incolla del privato di Pape ci sono solamente critiche all'uso delle caratteristiche del motore grafico e non critiche al motore grafico in sè, che attualmente è il più evoluto e supporta tutto il supportabile. Se i riflessi sono plasticosi o unti, vuol dire che l'illuminazione usata è stata troppo spinta, ma che il motore supporta tale illuminazione. Semplicemente calibrandola meglio si otterrebbero risultati più veritieri.
Ancora:
"Usare tutte le tecnologie supportate dalle DirectX non è il fine di un engine"
Hai sbagliato, usare tutte le tecnologie supportate dalle DX non è il fine di un GIOCO, ma dare il supporto al più ampio numero di caratteristiche supportate è sicuramente il fine di un ENGINE. Altrimenti facciamo un engine dx 7 e vediamo come lo accogli :)
Hai fatto confusione tra come le caratteristiche vengono usate in Far Cry (gioco) dai game designer o level designer, con le caratteristiche supportate dal Cry Engine (motore grafico).
Che poi per far piacere ad Nvidia più che un gioco, Far Cry, stia diventando un tech demo, non ci piove. Ad esempio, inserisci l'hdr, ok, ma non puoi spararlo al massimo per dire "wow che figo supporta l'hdr e guarda cosa può fare". Ma che il motore grafico supporti l'Hdr è sicuramente una cosa positiva.
Non so se mi sono spiegato :)
Non si può criticare il motore di un gioco perchè gli omini sono disegnati come dei gatti e abbaiano, invece che essere realistici. La colpa non è del motore :)
Originariamente inviato da yossarian
E' una feature piuttosto interessante che, però, al momento, non mi risulta sia ancora utilizzata (qui fek può confermare o smentire :D ).
In Far Cry è stata inserita nella patch 1.2 o 1.3 e usata nei livelli ad esempio per rendere la foresta. Ovviamente nel change log della patch loro l'hanno messa, poi non so dirti se al 100% è usato o meno :)
P.S. Ciao Yoss, è sempre un piacere leggerti e svenire al termine dei tuoi post :asd:
Alberto Falchi
05-11-2004, 11:06
Originariamente inviato da DjLode
Se i riflessi sono plasticosi o unti, vuol dire che l'illuminazione usata è stata troppo spinta, ma che il motore supporta tale illuminazione. Semplicemente calibrandola meglio si otterrebbero risultati più veritieri.
Cutto che sennò era troppo lungo.
I limiti di FC dipendono si pesantemente dal design, ma in parte è proprio l'engine che non è stato studiato per servire, ma solo come showcase. Supporta tutto? Che me ne frega, se nulla è concepito per risultare utile al giocatore? E non parlo solo di come è stato poi usato, ma anche di come i programmatori non lo abbiano studiato attorno a qualche feature utile al gameplay. Citavo le ombre di doom o il radiosity di HL2, entrambi diegetici... FC su cosa punta? Supporta tutto? Ottimo esercizio tecnico, utile per valutare una scheda (utile tanto quanto 3D Mark, però...), ma inutile come lavoro per giocatori. Ovviamente, IMHO.
Pape
Già, ma dicendo che è un ottimo esercizio tecnico e dicendo che come motore è scadente (non ricordo scusami le parole testuali che hai detto ma il succo era questo) si cade in una contraddizione :)
Originariamente inviato da GMCPape
Cutto che sennò era troppo lungo.
I limiti di FC dipendono si pesantemente dal design, ma in parte è proprio l'engine che non è stato studiato per servire, ma solo come showcase. Supporta tutto? Che me ne frega, se nulla è concepito per risultare utile al giocatore? E non parlo solo di come è stato poi usato, ma anche di come i programmatori non lo abbiano studiato attorno a qualche feature utile al gameplay. Citavo le ombre di doom o il radiosity di HL2, entrambi diegetici... FC su cosa punta? Supporta tutto? Ottimo esercizio tecnico, utile per valutare una scheda (utile tanto quanto 3D Mark, però...), ma inutile come lavoro per giocatori. Ovviamente, IMHO.
Pape
Io sono d'accordo con Pape.
Il motore di Far Cry ha TROPPI effetti grafici non in funzione del gameplay, o della giocabilità in generale,che stanno lì solo per meravigliare il giocatore.
IMHO,si sarebbe potuto farne un utilizzo meno scriteriato,infatti come dice Pape l'engine non è usato per servire il gameplay al meglio ma solo per fare da showcase a tutti gli effetti possibili.
Insomma si è sacrificata ancora una volta la giocabilità alla grafica.
Originariamente inviato da DNA_RNA
Io sono d'accordo con Pape.
Il motore di Far Cry ha TROPPI effetti grafici non in funzione del gameplay, o della giocabilità in generale,che stanno lì solo per meravigliare il giocatore.
IMHO,si sarebbe potuto farne un utilizzo meno scriteriato,infatti come dice Pape l'engine non è usato per servire il gameplay al meglio ma solo per fare da showcase a tutti gli effetti possibili.
Insomma si è sacrificata ancora una volta la giocabilità alla grafica.
Ciao,
quello che vuole evidenziare DJLode è proprio questo: alcuni effetti in FC sono utilizzati male, o esagerati. Su questo siamo d'accordo.
Per questo però non si può incolpare il motore, che anzi mette a disposizione tutti gli stumenti necessari, ma il modo in cui sono stati
Ti faccio un esempio banale: immagina di avere una cassetta degli attrezzi. Chiaramente io vorrei che ci fossero più attrezzi possibili (in modo da rispondere ad ogni esigenza), però non è detto che debba utilizzarli tutti: sarebbe illogico togliere una vite con un martello. Ma per questo andrebbe tolto il martello in modo che nessuno lo utilizzi per togliere una vite? Non credo, personalmente mi limiterei a non usare, quando fuori luogo, quel particolare attrezzo.
Per quello che riguarda D3 e l'esaltazione della grafica che ne sento in giro, vorrei dire la mia (anche se vado OT e me ne scuso in anticipo): è sicuramente spettacolare, ma preferisco di gran lunga avere un gioco con texture ben definite come FC che un gioco in cui si punta tutto sulle ombre. OK, rendono molto l'atmosfera, però cavolo le texture sono la base del 3D! Non voglio dire che quelle di D3 siano brutte, ci mancherebbe, però spesso risultano un po' troppo "spalmate" sui poligoni. Chi ha visto UnrealTournament su una Savage4 con texture compresse in S3TC comprende di cosa parlo... uno spettacolo! :) Anche per quello che riguarda la palette delle texture usate, i giochi della ID mi hanno un po' deluso: sempre le solite tonalità di marrone usate dappertutto! Be, per quello che riguarda D3 comunque poco male: i colori sono un po' più vari e la grafica rimane comunque grandiosa.
Inoltre, sinceramente anche io ho avuto l'impressione, confermata anche da fek, che il motore di D3 nasce già vecchio: come dice anche yossarian, è poi stato adattato ai nuovi chip.
Prima che mi linciate, ribadisco il punto: D3 è uno dei giochi con la grafica migliore, davvero. Però a sentire certe persone dovrebbe essere mille volte meglio di altri giochi mentre motori come quello di FC si difendono benissimo (e sono anche più avanzati).
Tutto ciò è solo frutto di una mia riflessione personale! ;)
CIAO! :)
Far Cry imho essendo uno dei primi giochi che ha sfruttato appunto certe features, per forza di cose e' stato programmato in modo che queste si vedano PER FORZA, cosi' da mostrare a tutti la differenza con il resto del mondo videoludico. ;)
yossarian
05-11-2004, 11:58
Originariamente inviato da Athlon 64 3000+
Grazie per le informazioni.
Mi ero dimenticato di chiederti una cosa.
Quando fù presentato L'NV40 ad aprile dicevi che l'nv40 si comportava non come una gpu a 16 pipeline,me come una 12+4 per via di una cosa particolare che non mi ricordo.
Come poi è andata a finire questa stranezza?
era in riferimento allo strano comportamento con gli shader 1.x; faceva registrare prestazioni che facevano intendere che solo 12 delle 16 pipeline emulassero funzionalità fx. Le gpu della serie R3x0, RV3x0, NV4x e R420 non hanno più unità di calcolo in virgola fissa e quando devono eseguire questo tipo di operazioni provvedono le fpu ad emularne il funzionamento; per l'esattezza, occorrono 2 fpu per emulare una fxu anche se, può sembrare paradossale (bisognerebbe dilungarsi in spiegazioni piuttosto noiosesulle architetture interne delle alu), la velocità di calcolo in "emulazione" è leggermente superiore a quella di una fxu originale. Bene, tornando alla domanda, il comportamento dell'NV40 con calcoli in virgola fissa era tipico di un chip con 12 pipeline (come se le altre 4 non fossero dotate della funzionalità emulazione). Ora dovrei andare a controllare i nuovi risultati con i drivers più recenti per vedere se era un problema di immaturità dei drivers oppure se c'è realmente qualcosa a livello di HW.
Originariamente inviato da shodan
Ciao,
quello che vuole evidenziare DJLode è proprio questo: alcuni effetti in FC sono utilizzati male, o esagerati. Su questo siamo d'accordo.
Per questo però non si può incolpare il motore, che anzi mette a disposizione tutti gli stumenti necessari, ma il modo in cui sono stati
Ti faccio un esempio banale: immagina di avere una cassetta degli attrezzi. Chiaramente io vorrei che ci fossero più attrezzi possibili (in modo da rispondere ad ogni esigenza), però non è detto che debba utilizzarli tutti: sarebbe illogico togliere una vite con un martello. Ma per questo andrebbe tolto il martello in modo che nessuno lo utilizzi per togliere una vite? Non credo, personalmente mi limiterei a non usare, quando fuori luogo, quel particolare attrezzo.
Ciao:)
IMHO, la cassetta delgli attrezzi non può essere paragonata al gioco, per il seguente motivo, che un attrezzo che non viene usato non va rimosso perché c'è sempre l'occasione in cui può essere usato,mentre x gli effetti di Far Cry non è che si possino riadattare di volta in volta a una particolare esigenza,stanno solo lì senza alcuna utilità.
Per quello che riguarda D3 e l'esaltazione della grafica che ne sento in giro, vorrei dire la mia (anche se vado OT e me ne scuso in anticipo): è sicuramente spettacolare, ma preferisco di gran lunga avere un gioco con texture ben definite come FC che un gioco in cui si punta tutto sulle ombre. OK, rendono molto l'atmosfera, però cavolo le texture sono la base del 3D! Non voglio dire che quelle di D3 siano brutte, ci mancherebbe, però spesso risultano un po' troppo "spalmate" sui poligoni. Chi ha visto UnrealTournament su una Savage4 con texture compresse in S3TC comprende di cosa parlo... uno spettacolo! :) Anche per quello che riguarda la palette delle texture usate, i giochi della ID mi hanno un po' deluso: sempre le solite tonalità di marrone usate dappertutto! Be, per quello che riguarda D3 comunque poco male: i colori sono un po' più vari e la grafica rimane comunque grandiosa.
Inoltre, sinceramente anche io ho avuto l'impressione, confermata anche da fek, che il motore di D3 nasce già vecchio: come dice anche yossarian, è poi stato adattato ai nuovi chip.
Prima che mi linciate, ribadisco il punto: D3 è uno dei giochi con la grafica migliore, davvero. Però a sentire certe persone dovrebbe essere mille volte meglio di altri giochi mentre motori come quello di FC si difendono benissimo (e sono anche più avanzati).
Tutto ciò è solo frutto di una mia riflessione personale! ;)
CIAO! :)
Anch'io sono d'accordo che la grafica di Doom 3 è nata vecchia:le texture spesso non sono molto definite,la palette monotona come dici tu.E' un gioco che sa leggermente di già visto poiché sono usciti giochi perfettamente in grado di competere con la sua grafica.Inoltre,sempre,IMHO,è monotono e ripetitivo dopo un po', e risente di un impostatura di gioco vecchia.Anch'io devo dire che preferisco Far Cry a Doom 3.
Originariamente inviato da Simon82
Far Cry imho essendo uno dei primi giochi che ha sfruttato appunto certe features, per forza di cose e' stato programmato in modo che queste si vedano PER FORZA, cosi' da mostrare a tutti la differenza con il resto del mondo videoludico. ;)
Probabile.;)
Alberto Falchi
05-11-2004, 12:31
Originariamente inviato da Simon82
Far Cry imho essendo uno dei primi giochi che ha sfruttato appunto certe features, per forza di cose e' stato programmato in modo che queste si vedano PER FORZA, cosi' da mostrare a tutti la differenza con il resto del mondo videoludico. ;)
Che è il primo capitolo del libro "cosa non deve fare un game designer" ^_^
Pape
Originariamente inviato da GMCPape
Che è il primo capitolo del libro "cosa non deve fare un game designer" ^_^
Pape
Giusto,cribbio!
Ormai si abusa delle grafica, a scapito della giocabilità,della trama,e dell'originalità.
Questo è un fenomeno che,IMHO,va invertito a tutti i costi,anche se è solo un utopia.:(
Originariamente inviato da DNA_RNA
Giusto,cribbio!
Ormai si abusa delle grafica, a scapito della giocabilità,della trama,e dell'originalità.
Questo è un fenomeno che,IMHO,va invertito a tutti i costi,anche se è solo un utopia.:(
non credo proprio ke gli ingegneri grafici debbano pensare alla trama e alla giocabilità
ognuno fa il suo lavoro
se mancano idee non si può mica dare la colpa agli artisti ke hanno creato il motore grafico di far cry
bYeZ!
Originariamente inviato da GMCPape
Che è il primo capitolo del libro "cosa non deve fare un game designer" ^_^
Pape
Be'... Far Cry in ogni caso a prescindere dallo spreco di features utilizzate a mo' di "secchiate di shaders qua e la" , e' piaciuto a moltissimi me compreso. Sicuramente e' servito che un gioco sfruttasse esageratamente queste features in modo da poter dire: "Ah ecco.. esistevano i pixel shaders gia da un po' e nessuno ce lo aveva fatto vedere..". ;)
Originariamente inviato da GMCPape
Che è il primo capitolo del libro "cosa non deve fare un game designer" ^_^
Pape
Allora illuminaci tu ... che deve fare un game designer ? Cosa non va nei livelli di Far Cry ? Motiva quello che dici.
Alberto Falchi
05-11-2004, 12:48
Originariamente inviato da DNA_RNA
Anch'io sono d'accordo che la grafica di Doom 3 è nata vecchia:le texture spesso non sono molto definite,la palette monotona come dici tu.E' un gioco che sa leggermente di già visto poiché sono usciti giochi perfettamente in grado di competere con la sua grafica.Inoltre,sempre,IMHO,è monotono e ripetitivo dopo un po', e risente di un impostatura di gioco vecchia.Anch'io devo dire che preferisco Far Cry a Doom 3.
Nato vecchio, con alcuni limiti e una playability anziana e non certo innovativa. Tutto vero, ma il motore di JC era sviluppato in un'ottica particolare, di rendere certe atmosfere. Il gioco può piacere o meno, così come si possono muovere critiche ad alcune texture o allo scarso utilizzo dei PS. Ma non si può negare che lo scopo sia stato raggiunto: l'engine diu D3 doveva gestire al meglio spazi chiusi e claustrofobici, dando ai level designer gli strumenti adatti a ricreare atmosfere sullo stile di AvP. E tale fine è stato raggiunto.
FC su cosa puntava? Su tutto. Per fare che gioco? Uno spara spara un po' all'aperto, un po' al chiuso, un po' realistico e un po' tamarro. Se compro una macchina posso scegliere fra una muscle car per correre a manetta nel deserto e una agile Civic per divertirmi a fare drifting... non esiste certo la pesante muscle adatta a sgommare in derapata. Idem per gli engine dei giochi.
Cercando disperatamente di tornare in topic, vorrei fare alcune riflessioni sul motore di D3 in relazione alle schede video. Alcuni dei limiti evidenziati (texture non di elevatissima qualità e PS usati relativamente poco), fanno parte di precise scelte. Insomma... le texture non fanno parte dell'engine, ma sono realizzate dai grafici, e potranno essere migliorate successivamente. Non sono ad altissima risoluzione? Certo, ma questo è dovuto al fatto che ove serve la qualità, si è puntato su texture di qualità elevatissima (i monitor) o sull'utilizzo di più mappe (specular, normal e così via) per aumentare il dettaglio (sui mostri). Dove cade l'occhio, tutto è realizzato al meglio (relativamente alla potenza dei PC attuali). Dove l'occhio non si sofferma, il dettaglio cala drasticamente. L'engine può insomma supportare quanto si vuole, ma i designer hanno operato precise scelte per non appesantire inutilmente il motore. E, in effetti, il frame rate non oscilla vergognosamente, ma risulta bene o male costante (escludendo alcune mappe). L'uso estremo delle ombre, ha impedito (ma anche reso inutile) l'aggiungere dettagli coi PS, che avrebbero solo appesantito ulteriormente il lavoro della GPU, che invece doveva principalmente gestire il perno della playability: i giochi di luce e la varietà dei materiali (non saranno in alta le texture, ma quante ce ne sono in ogni livello? Altro che pattern ripetutti all'infinito).
Anche HL2, a quanto ho visto dalle immagini (e a quanto mi dice il buon Barone), non utilizza texture sempre bellissime, ma concentra gli sforzi su effetti che rendano l'acqua e i materiali verosimili, ma soprattutto sull'espressività dei volti, feature che gioca un ruolo fondamentale all'interno del gameplay.
Questi, a mio avviso, sono esempi di engine sviluppati con qualcosa in mente, utilizzando in maniera creativa e diegetica alcune feature, e permettendo sì di aggiungere PS, VS e quanto volete, ma non soffermandosi sulla mera spettacolarità.
E questi due engine, sono ovviamente fatti per sfruttare alcune delle caratteristiche salienti delle architetture attuali. Le volume shadow doom, il (quasi)radiosity in real time di HL.
Pape
Originariamente inviato da ATi7500
non credo proprio ke gli ingegneri grafici debbano pensare alla trama e alla giocabilità
ognuno fa il suo lavoro
se mancano idee non si può mica dare la colpa agli artisti ke hanno creato il motore grafico di far cry
bYeZ!
Gli ingegneri grafici hanno fatto il loro lavoro,sono stati sacrificati gli altri aspetti del gioco!;)
Alberto Falchi
05-11-2004, 12:52
Originariamente inviato da Simon82
Be'... Far Cry in ogni caso a prescindere dallo spreco di features utilizzate a mo' di "secchiate di shaders qua e la" , e' piaciuto a moltissimi me compreso. Sicuramente e' servito che un gioco sfruttasse esageratamente queste features in modo da poter dire: "Ah ecco.. esistevano i pixel shaders gia da un po' e nessuno ce lo aveva fatto vedere..". ;)
Si, fico, esistono i PS. E cosa mi cambiano in termini di playability?Le GPU e il loro potenziale sono stsati sfruttati in maniera da renderli parte integrante del gameplay? NO. FC è un gioco che non innova sotto il profilo della giocabilità. è il solito spara ammazza privo di particolari spunti. Che sia divertente non lo metto in dubbio, ma personalmente preferisco qualcosa che si distacchi dalla massa, per considerarlo un passo avanti.
Carmack ha usato le ombre,, stupendo e facendo vedere che si poteva fare. Ma le ombre sono parte integrante del gioco. Toglile, e il titolo perde spessore, e tanto. Togli i PS a FC, e hai lo stesso identico gioco, solo un po' meno spettacolare.
Pape
Alberto Falchi
05-11-2004, 12:55
Originariamente inviato da Maury
Allora illuminaci tu ... che deve fare un game designer ? Cosa non va nei livelli di Far Cry ? Motiva quello che dici.
Frame rate zoppicante sulle architetture di riferimento per quando è uscito. Nessuna trovata originale. Nessun elemento caratterizzante che lo distacchi dai tanti giochi esistenti. Se facevo un Mod di BF 1942 ambientato ai tropici, potevo ottenere le stesse identiche cose, solo un po'ì meno belle a vedersi. NOn esiste un solo elemento caratterizzante del gameplay, che sia la trama, la tatticità dei combattimenti o l'esplorazione. Certo, puioi girare l'isola in lungo e in largo, senza essere gratificato per aver trovato aree importanti, o chicche di qualche tipo.
Prendimi Zelda o Mario come esempi di design, e ti renderai conto che non c'è un solo sasso messo a caso. Prendi FC, e potresti fare a meno del 50% delle aree dell'isola dove non combatti.
Pape
Originariamente inviato da GMCPape
FC è un gioco che non innova sotto il profilo della giocabilità. è il solito spara ammazza privo di particolari spunti. Che sia divertente non lo metto in dubbio, ma personalmente preferisco qualcosa che si distacchi dalla massa, per considerarlo un passo avanti.
Quindi dal lato game play consideri la possibilità di girare in lungo e in largo isole intere, con annessa la possibilità di decidere come impostare la tattica di guerriglia come un qualcosa di vecchio e privo di spunti.
Mi citi un gioco che permette tale impostazione ?
Per ogni situazione ti posso dare almeno 2 o 3 modi di fronteggiarla.... scusa ma non ricordo altri esmepi, forse solo Deus Ex
Originariamente inviato da GMCPape
Certo, puioi girare l'isola in lungo e in largo, senza essere gratificato per aver trovato aree importanti, o chicche di qualche tipo.
Prendimi Zelda o Mario come esempi di design, e ti renderai conto che non c'è un solo sasso messo a caso. Prendi FC, e potresti fare a meno del 50% delle aree dell'isola dove non combatti.
Pape
Su un 'isola oceanica non trovi i bauli con i tesori, cosa speravi di trovare ? c'è quello che in realtà può esserci.
Se l'estensione enorme dei livelli è per te limitante per moltissime altre persone (me ad esempio) è una miccia che invoglia a giocare, da un senso di libertà che poi rende schiavi. Mi dispiace che non sei entrato nello spirito del gioco, ma il limite è tuo non suo.
Mario e Zelda non centrano con il ns discorso, sn paltform che ti fanno girare e rigirare fino alla nausa un medesimo livello. Bello ? non direi.
Originariamente inviato da GMCPape
Nato vecchio, con alcuni limiti e una playability anziana e non certo innovativa. Tutto vero, ma il motore di JC era sviluppato in un'ottica particolare, di rendere certe atmosfere. Il gioco può piacere o meno, così come si possono muovere critiche ad alcune texture o allo scarso utilizzo dei PS. Ma non si può negare che lo scopo sia stato raggiunto: l'engine diu D3 doveva gestire al meglio spazi chiusi e claustrofobici, dando ai level designer gli strumenti adatti a ricreare atmosfere sullo stile di AvP. E tale fine è stato raggiunto.
FC su cosa puntava? Su tutto. Per fare che gioco? Uno spara spara un po' all'aperto, un po' al chiuso, un po' realistico e un po' tamarro. Se compro una macchina posso scegliere fra una muscle car per correre a manetta nel deserto e una agile Civic per divertirmi a fare drifting... non esiste certo la pesante muscle adatta a sgommare in derapata. Idem per gli engine dei giochi.
Cercando disperatamente di tornare in topic, vorrei fare alcune riflessioni sul motore di D3 in relazione alle schede video. Alcuni dei limiti evidenziati (texture non di elevatissima qualità e PS usati relativamente poco), fanno parte di precise scelte. Insomma... le texture non fanno parte dell'engine, ma sono realizzate dai grafici, e potranno essere migliorate successivamente. Non sono ad altissima risoluzione? Certo, ma questo è dovuto al fatto che ove serve la qualità, si è puntato su texture di qualità elevatissima (i monitor) o sull'utilizzo di più mappe (specular, normal e così via) per aumentare il dettaglio (sui mostri). Dove cade l'occhio, tutto è realizzato al meglio (relativamente alla potenza dei PC attuali). Dove l'occhio non si sofferma, il dettaglio cala drasticamente. L'engine può insomma supportare quanto si vuole, ma i designer hanno operato precise scelte per non appesantire inutilmente il motore. E, in effetti, il frame rate non oscilla vergognosamente, ma risulta bene o male costante (escludendo alcune mappe). L'uso estremo delle ombre, ha impedito (ma anche reso inutile) l'aggiungere dettagli coi PS, che avrebbero solo appesantito ulteriormente il lavoro della GPU, che invece doveva principalmente gestire il perno della playability: i giochi di luce e la varietà dei materiali (non saranno in alta le texture, ma quante ce ne sono in ogni livello? Altro che pattern ripetutti all'infinito).
Anche HL2, a quanto ho visto dalle immagini (e a quanto mi dice il buon Barone), non utilizza texture sempre bellissime, ma concentra gli sforzi su effetti che rendano l'acqua e i materiali verosimili, ma soprattutto sull'espressività dei volti, feature che gioca un ruolo fondamentale all'interno del gameplay.
Questi, a mio avviso, sono esempi di engine sviluppati con qualcosa in mente, utilizzando in maniera creativa e diegetica alcune feature, e permettendo sì di aggiungere PS, VS e quanto volete, ma non soffermandosi sulla mera spettacolarità.
E questi due engine, sono ovviamente fatti per sfruttare alcune delle caratteristiche salienti delle architetture attuali. Le volume shadow doom, il (quasi)radiosity in real time di HL.
Pape
Detto brevemente,Far Cry ha una grafica troppo dispersiva e poco finalistica,ma non risulta noioso o vecchio
Doom 3 ha si, una grafica finalizzata al gameplay, però si è fossilizzato in degli schemi di gioco vecchi e troppo ripetuti, senza mai dare un minimo di intraprendenza al giocatore.
Preferirei vedere un Doom 3 con meno effetti grafici,che poi mi ricordano sempre quelli di Far Cry, ma con un gameplay originale e innovativo.
In Far Cry avrei preferito un uso più saggio della grafica ai fini della giocabilità.
Alberto Falchi
05-11-2004, 13:04
Originariamente inviato da Maury
Quindi dal lato game play consideri la possibilità di girare in lungo e in largo isole intere, con annessa la possibilità di decidere come impostare la tattica di guerriglia come un qualcosa di vecchio e privo di spunti.
Cosa c'è in qujeste isole. MI gratifica (oltre all'impatto visivo) girarle in lungo e in largo? Trovo oggetti interessanti nelle zone sperdute? Ci sono cameo o chicche di qualche tipo in queste maledette boscaglie? Mi da vantaggi strategici? non direi proprio. è messo li.. inutilmente. La tattica... non mi sembra che scegliere se cecchinare o sparare alla brutta miseria da vicino siano strategie degne di nota. Il vecchio Hitman prevede rose di azioni indubbiamente più varie. Deus Ex, che tu stesso citi, permette diversi approcci e non ha una sola area inutile ai fini del gameplay. Thief, mi permette di utilizzare quanti approcci voglio. Lo stesso, vecchissimo HL permetteva di elaborare strategie più complesse, e l'IA dei marine è spaventosamente più adeguata al gameplay di quella di FC. Si, è scriptata pesantemente, ma raggiunge l'obiettivo molto meglio (e genera la tanto ricercata suspension of disbelief) di FC
Pape
Alberto Falchi
05-11-2004, 13:09
Originariamente inviato da Maury
Su un 'isola oceanica non trovi i bauli con i tesori, cosa speravi di trovare ? c'è quello che in realtà può esserci.
Se l'estensione enorme dei livelli è per te limitante per moltissime altre persone (me ad esempio) è una miccia che invoglia a giocare, da un senso di libertà che poi rende schiavi. Mi dispiace che non sei entrato nello spirito del gioco, ma il limite è tuo non suo.
MI invoglia a giocare se come giocatore ha senso esplorare. Se no è tempo buttate. Per me che esploro, per i designer a realizzare tali zone.
Mario e Zelda non centrano con il ns discorso, sn paltform che ti fanno girare e rigirare fino alla nausa un medesimo livello. Bello ? non direi.
C'entrano come esempi di game design, invece. Chissà perché, tutta i libri di design e i primi studi semiotici sul videogioco, citano i capollavori di Miyamoto come esempi di ottimo design. E chissà perché sono così venduti, tra l'altro. Un qualsiasi zelda, come commenti della stampa specializzata, del pubblico e come stesse vendite, devasta FC sotto ogni profilo. Invece di sparare a zero sui capolavori, ti consiglierei di provarli senza pregiudizi per capire cosa intendo. Anche se sono "giochini per bambini scemi", come più volte li ho sentiti definire (non da te) su questo forum.
Pape
Alberto Falchi
05-11-2004, 13:15
Originariamente inviato da DNA_RNA
Detto brevemente,Far Cry ha una grafica troppo dispersiva e poco finalistica,ma non risulta noioso o vecchio
Doom 3 ha si, una grafica finalizzata al gameplay, però si è fossilizzato in degli schemi di gioco vecchi e troppo ripetuti, senza mai dare un minimo di intraprendenza al giocatore.
Preferirei vedere un Doom 3 con meno effetti grafici,che poi mi ricordano sempre quelli di Far Cry, ma con un gameplay originale e innovativo.
In Far Cry avrei preferito un uso più saggio della grafica ai fini della giocabilità.
Hai colto il segno. Doom III può non piacere, certo, ma ha raggiunto il suo scopo, e chi ricercava quel gameplay (del resto si chiama doom, non "il nuovo FPS innovativo") fatto di tensione e angoscia, lo ha trovato. Non è certo adatto a tutti, ma fa bene quello che si prefissa. FC voleva essere innovativo, garantire libertà e tutto quanto vuoi, ma si è rivelato uno sparatutto spettacolare in termini di resa visiva, ma che non innova ne stravolge, dove la grafica è fine a sé stessa ma non lo aiuta a elevarsi. Se esplorare l'isola avesse potuto rivelare entrate nascoste, tunnel sotterranei o che verso l'obiettivo finale, o semplicemente depositi di munizioni e armi altrimenti introvabili, sarebbe stato più intrigante. Ma non è fregato a nessuno di farlo. E l'uso delle ombre in FC è si spettacolare, ma non utile ai fini del gameplay, ne alla creazione di atmosfere. Del resto, per fare questo sarebbero state necessarie volume shadow, ingestibili insieme a quella mole di roba presente nell'engine.
Pape
Originariamente inviato da GMCPape
Un qualsiasi zelda, come commenti della stampa specializzata, del pubblico e come stesse vendite, devasta FC sotto ogni profilo.
Che brutto vizio che molti hanno di paragonare due giochi che non c'azzeccano niente uno con l'altro.
Alberto Falchi
05-11-2004, 13:23
Originariamente inviato da MaBru
Che brutto vizio che molti hanno di paragonare due giochi che non c'azzeccano niente uno con l'altro.
Chi ha paragonato i giochi? Ho fatto un esempio di buon design, visto che si parlava di quello. E, se leggi, non mancano riferimenti ad FPS più attinenti per quanto riguarda il discorso engine.
Pape
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.