Link alla notizia: http://www.hwupgrade.it/news/skvideo/fisica-e-gpu-il-punto-di-vista-di-ati_27474.html

Rifiuto delle soluzioni proprietarie e mirare a cambiare l'esperienza di gioco: questa la ricetta ATI per la fisica nei giochi

Click sul link per visualizzare la notizia.

a prescindere della fisica in sè (che comunque male non fa se viene svincolata dalla cpu) havok poi dovrebbe rendere molto più efficiente l'utlizzo di multi-core.

tra havok(intel) e phisix(nvidia) chissa' quale sara' piu' supportato dalle software house :asd:

Mirror's Edge non andrebbe neanche mezionato, si sfiora il ridicolo. Due inutili teloni e dei frammenti quando si avvicinano gli elicotteri. Cambiassero realmente qualcosa...

Tra l'altro nel vidoedi comparazione vi son vere e proprie omissioni.

Uè non è che le cpu son fatte esclusivamente per giocare eh?

ma se della fisica se ne deve occupare soltanto la GPU, si può sapere a che .... servono i quad core? si potrebbe pensare di sfruttare anche loro... a che faceva tutto la CPU adesso si tende a far tutto alla GPU... da un estremo all'altro!

in generale le cpu servono per ben altro, ci sono programmi che le sfruttano a dovere, mica tutti ci giocano al pc ;)

ma se della fisica se ne deve occupare soltanto la GPU, si può sapere a che .... servono i quad core? si potrebbe pensare di sfruttare anche loro... a che faceva tutto la CPU adesso si tende a far tutto alla GPU... da un estremo all'altro!

la tecnologia havok se non sbaglio (essendo sviluppata in collaborazione con Intel che guardacaso produce soprattutto cpu...) punta ad usare in maniera ottimizzata sia tutti i core della cpu che la gpu contemporaneamente.
(poi quanto nella pratica funzioni realmente non lo so, questo tutto quello che so a riguardo)

ops ho sbagliato, doppio post.

visti i giochi che usano havok:
http://www.havok.com/content/blogcategory/29/73/
e quelli che usano physx:
http://it.nzone.com/object/nzone_physxgames_home_it.html

al momento attuale, quale è il metodo che funziona meglio?
Eppoi, se uno ha gpu nvidia e cpu intel potrebbe giocare ai giochi che utilizzano physx (usando quindi physx per gestire la fisica) e un secondo dopo giocare a giochi che usano havok (usando quindi havok per gewstire la fisica) sullo stesso PC? E' possibile questo?

visti i giochi che usano havok:
http://www.havok.com/content/blogcategory/29/73/
e quelli che usano physx:
http://it.nzone.com/object/nzone_physxgames_home_it.html

al momento attuale, quale è il metodo che funziona meglio?
Eppoi, se uno ha gpu nvidia e cpu intel potrebbe giocare ai giochi che utilizzano physx (usando quindi physx per gestire la fisica) e un secondo dopo giocare a giochi che usano havok (usando quindi havok per gewstire la fisica) sullo stesso PC? E' possibile questo?

Si se hai nvidia (la marca di cpu non conta)

"There is no plan for closed and proprietary standards like PhysX. As we have emphasised with our support for OpenCL and DX11"

ma perche la dx11 è uno standard aperto e non proprietario?

in generale le cpu servono per ben altro, ci sono programmi che le sfruttano a dovere, mica tutti ci giocano al pc ;)

be ma fin tanto che sui computer da gioco c'e' una cpu perche' non sfruttarla per snellire il lavoro della gpu? Queste ultime saranno anche piu' veloci, ma e' inutile sovraccaricarle di altro lavoro. Se le gpu dovessero calcolare anche la fisica in GTA4 dovremmo avere tutti almeno uno sli. E allora tanto vale sfruttare la cpu che c'e' gia no?

"There is no plan for closed and proprietary standards like PhysX. As we have emphasised with our support for OpenCL and DX11"
perche' l'havok? Diciamo che non gli piaciono gli standard proprietari che non possono sfruttare ^^

perche' l'havok? Diciamo che non gli piaciono gli standard proprietari che non possono sfruttare ^^
Abbastanza ovvio :D

Anche qui, l'accelerazione fisica diventerà una cosa seria quando le aziende la smetteranno di usarla per vendere le GPU di natale.

Su beyond3d hanno dimostrato che Physix è sostanzialmente rallentato di proposito quando gira sulla CPU. Se si è a questo livello, non è un discorso di tecnologia, ma solo di marketing. Come in troppe cose che riguardano il GPGPU di questi tempi (da ambo le parti).

(la marca di cpu non conta)
Per adesso?
I fanboy sembrano quasi contenti di usare soluzioni proprietarie che li legano a questa o quell'azienda.

Se cominciassero a fare motori fisici su CPU pesantemente ottimizzati per questa o quella CPU magari sarebbero più contenti ancora. Basta poi che le aziende sponsorizzino lo sviluppo di ciascun videogioco per tal tecnologia, sai che estasi.

Così per ogni gioco ti servirebbe la giusta combo CPU+GPU, tra 4 (e presto 6) combinazioni possibili. Sai che gioia. :(

edit.

per quelli che insistono con la storia di Mirror's Edge che gioca sporco non mettendo i "teli" nella versione senza fisica, riporto il mio commento su TVtech:

Sappiate che PhysX non è un'oracolo che magicamente gestisce la fisica.. La geometria degli oggetti (in questo caso i teli) viene generata dalla libreria stessa ( si parla in gergo di "cooking" ) dopo aver specificato dimensione e posizione nello spazio tridimensionale..

Ve lo posso dire con certezza dato che ci lavoro con le PhysX ed in particolare con gli NxCloth (i teli).

PS: ammesso che la versione xbox360 avesse i teli (seppur statici) credete sarebbe cambiato qualcosa? Spingi un soldato contro un telo: o fai finta che il telo non esiste (il soldato ci passa attraverso come fosse Slimer dei GB :P) o lo tratti alla stregua di una parete (non si strappa e il soldato semplicemente ci "rimbalza" contro..

PPS: il punto semmai è un'altro.. perché non hanno abilitato le physx sulla versione 360? :P Sono supportate e girano senza problemi in software mode (tra l'altro nel video noto un basso dettaglio nella simulazione dei teli.. in alcuni casi l'animazione "scatta" -> vengono effettuate meno iterazioni di calcolo -> basso costo computazionale)

Abbastanza ovvio :D

Anche qui, l'accelerazione fisica diventerà una cosa seria quando le aziende la smetteranno di usarla per vendere le GPU di natale.

Su beyond3d hanno dimostrato che Physix è sostanzialmente rallentato di proposito quando gira sulla CPU. Se si è a questo livello, non è un discorso di tecnologia, ma solo di marketing. Come in troppe cose che riguardano il GPGPU di questi tempi (da ambo le parti).

Questo non è vero, oppure ti sei espresso veramente male.
Molti sviluppatori utilizzano PhysX in giochi sviluppati solo per console e giochi per PC in cui PhysX può girare solo su CPU.
Alla luce di questo direi che la tua affermazione è alquanto meno poco fondata.
AMD -> http://snipurl.com/7y2s9

consiglio l'audio :asd:

Questa non l'ho capita...:confused:

Spiegati meglio

per quelli che insistono con la storia di Mirror's Edge che gioca sporco non mettendo i "teli" nella versione senza fisica, riporto il mio commento su TVtech:


Sappiate che PhysX non è un'oracolo che magicamente gestisce la fisica.. La geometria degli oggetti (in questo caso i teli) viene generata dalla libreria stessa ( si parla in gergo di "cooking" ) dopo aver specificato dimensione e posizione nello spazio tridimensionale..

Ve lo posso dire con certezza dato che ci lavoro con le PhysX ed in particolare con gli NxCloth (i teli).

PS: ammesso che la versione xbox360 avesse i teli (seppur statici) credete sarebbe cambiato qualcosa? Spingi un soldato contro un telo: o fai finta che il telo non esiste (il soldato ci passa attraverso come fosse Slimer dei GB :P) o lo tratti alla stregua di una parete (non si strappa e il soldato semplicemente ci "rimbalza" contro..

PPS: il punto semmai è un'altro.. perché non hanno abilitato le physx sulla versione 360? :P Sono supportate e girano senza problemi in software mode (tra l'altro nel video noto un basso dettaglio nella simulazione dei teli.. in alcuni casi l'animazione "scatta" -> vengono effettuate meno iterazioni di calcolo -> basso costo computazionale)

Avevo notato anch'io gli "scatti" nella simulazione dei tessuti, però ho trovato un lo stesso video non rallentato e gli "scatti" si vedono solo in slow motion.
Se interessa posso postare il video.

Questa non l'ho capita...:confused:

Spiegati meglioChe sia un caso questa affermazione sia scaturita a pochi giorni da quest'altra?

http://www.hwupgrade.it/news/skvideo/2k-games-e-ea-scelgono-physx_27419.html

http://www.hypersg1.org/immagini/Rosik.gif

Nell'articolo leggo:

Director of Technical Marketing per la divisione Graphics di AMD e quindi di ATI

Sono contrario a questa equivalenza dal momento che il dipendente è di AMD e non di ATI, che peraltro non esiste più come azienda ma è diventata semplicemente parte del nome con cui AMD vende le sue schede grafiche: prima era solo Radeon, ora ATI Radeon, per ovvie ragioni commerciali.

"There is no plan for closed and proprietary standards like PhysX. As we have emphasised with our support for OpenCL and DX11"

ma perche la dx11 è uno standard aperto e non proprietario?


perche' l'havok? Diciamo che non gli piaciono gli standard proprietari che non possono sfruttare ^^

Abbastanza ovvio :D



ma lol,che ca22oni.. per standard "aperto e non proprietario" intendono una tecnologia utilizzabile da chiunque e non solo da chi la sviluppa. havok,ad esempio,puo' essere utilizzato con schede nvidia. le directx sono utilizzate da ati ed nvidia..etc,etc,etc.. :rolleyes:

edit.

..e pure physx può essere infatti utilizzato da ati.... gratis!
peccato non voglia, chissà come mai :D

non da quando physx e' sotto nvidia..anche se googlando ho letto che Eran Badit di NGOHQ.com ha modificato il layer PhysX per farlo lavorare anche su schede grafiche ATI.

physx lo fanno girare anche con la cpu (xbox360 e wii se nn erro hanno gpu ati)
semplicemente ati nn vuole supportare questa "libreria" per orgoglio personale.

physx lo fanno girare anche con la cpu (xbox360 e wii se nn erro hanno gpu ati)
semplicemente ati nn vuole supportare questa "libreria" per orgoglio personale.

Bhè, ma allora "sò stronzi..." :muro:

ripeto la domanda che ho fatto a pagina 1:
al momento attuale, quale è il metodo che funziona meglio? (tra PhysX e Havok)
o per meglio dire, a quale dei 2 appartengono i giochi che sono (o sembrano) fatti meglio dal lato fisica?

Mirror's Edge non andrebbe neanche mezionato, si sfiora il ridicolo. Due inutili teloni e dei frammenti quando si avvicinano gli elicotteri. Cambiassero realmente qualcosa...

Tra l'altro nel vidoedi comparazione vi son vere e proprie omissioni.

Qui c'è il video

http://www.tvtech.it/video/227/mirror-s-edge-con-e-senza-physx/

è evidente che physx, oltre a gestire la fisica degli oggetti presenti, ne fa apparire di inesistenti (il mago otelma dei tool di sviluppo :D ). Un po' come, in altri game, qualche passaggio di rendering di troppo forzato anche quando e dove non sarebbe necessario, oppure come la stessa physx gestita da cpu, rallentata ad arte :D

Detto ciò, l'implementazione vista in questa demo non è niente di particolare:fisica per nulla realistica e grafica scarna con 4 poligoni e 2 texture in croce.

per quelli che insistono con la storia di Mirror's Edge che gioca sporco non mettendo i "teli" nella versione senza fisica, riporto il mio commento su TVtech:

e i festoni in alto sui corridoi (tanto per dirne una)? Si sarebbero potuti mettere, magari statici, come in altri game (e non col movimento random del video con physx spinti da non si sa cosa). Invece non c'è niente. Contro quelli non ci sbatte nessuno e non c'è alcun effetto da simulare. Tra l'atro, ad essere pignoli, non è necessaria physx, oppure una scheda dedicata, per gestire l'effetto di un telo che si squarcia (o di una parete lesionata da un proiettile). Per nulla realistico anche l'effetto della guardia che vola via neanche fosse investita da un tir sull'autosole. Completamnete innaturali anche gli affetti dei teli nei corridoi, che dovrebbero essere mossi dai proiettili e dall'aria spostata dalla protagonista ma sembrano animati da vita propria e si muovono in maniera del tutto casuale, come investiti da folate di vento con dirrezione variabile. Insomma, non ci siamo per niente.

visti i giochi che usano havok:
http://www.havok.com/content/blogcategory/29/73/
e quelli che usano physx:
http://it.nzone.com/object/nzone_physxgames_home_it.html

al momento attuale, quale è il metodo che funziona meglio?
Eppoi, se uno ha gpu nvidia e cpu intel potrebbe giocare ai giochi che utilizzano physx (usando quindi physx per gestire la fisica) e un secondo dopo giocare a giochi che usano havok (usando quindi havok per gewstire la fisica) sullo stesso PC? E' possibile questo?
Havok e Pysics non sono molto diversi come risultato finale, entrambi emulano leggi fisiche alquanto banali e semplici e le applicano anche in modo limitato (non ho ancora visto nessun gioco applicare fattori come l'onda d'urto, il ritorno di forza, il risucchio ecc in maniera minimamente corretta, persino la forza di gravità e centrifuga, quelle "base", vangono spesso e volentieri applicate alla carlona e soltanto loro..)

La lista dell'havok poi è incompleta, l'havok esiste da molti anni e i itoli che lo supportano sono nettamente superiori, diciamo che si sono sprecati a mettere soltanto gli ultimi titoli.. Pysics di AGEIA è rimasto tale come software, non ha ancora subito alcuna miglioria, NVIDIA ci ha solo implementato il supporto delle chiamate vioa GPU.
Pure la lista di Pysiscs è incompleta: AGEIA avea il pregio di lasciare la licenza liberamente utilizzabile da chiunque, molti giochi casual e underground lo usano tutt'ora, così come aspiranti team professionisti... L'ultimo esempio che mi viene in mente è I-Fluid (lo trovate su Steam), casual-plataform in cui sei una goccia d'acqua in un mondo dominato dal leggi fisice più o meno realitische (a parte il fatto che la goccia d'acqua sia animata e controllata dal giocatore, per ora quel piccolo giochino da 9€ è quello che ho trovato con la fisica realistica, comprese fattori di assorbimento.. altro che qualche barile o cassa che appena la tocchi parte per aria con na traiettoria priva di senso o una granata che non ha effetto per un dislivello di 10 cm rispetto al giocatore, o una cassa di legno antirpg mentre il muro inc emento armato di fianco riesce a far passare i proiettili da 9mm di una beretta...).... pertanto finché non migliorano, e di molto anche, il software, sia havok che pysics via GPU sono una boiata unica.. che me frega di vedere 1000 barili volare per aria al secondo se questi si comportano senza alcuna logica... i giochi in cui vengono messe 10000 cose per farle saltare per aria per far contanti i possessori di una determinata GPU sono giochi rovinati, la fisica nei giochi deve essere applicata per il gameplay e il realismo, non per far vedere quanti se ne possono gestire malamente con una scheda video.. Per ora il pregio di Pysics era la gestione degli effetti particellari (usati anche per i liquidi) e per ora non li ho visti applicati più di tanto... e pure quelli delle techdemo giravano perfettamente sul mio PC e ho un 4800+ x2, non l'ultimo quad occato a 3.7ghz...

Per rispondere alla tua domanda finale: sì, è possibile, basta implementare un doppio motore fisico nel gioco coem anni fa si impleementavano più di un rendering D3D, OGL, Gilde e pure il render software spesso nei giochi del passato si trovavano nello stesso titolo.. oggi la cosa sarebbe più economicamente esosa da fare per ovvi motivi)... La cosa migliroe è che qualunque engine fisico si usi, sia a Open per le chiamate vie hardware.. ma credo sarà difficile per entrambi i casi...

physx lo fanno girare anche con la cpu (xbox360 e wii se nn erro hanno gpu ati)
semplicemente ati nn vuole supportare questa "libreria" per orgoglio personale.
Orgoglio personale? Io direi limitazioni di licenza e codice chiuso a favore delle CPU con architettura intell.. l'orgoglio quando si parla denaro in questi campi cona meno di zero.

Orgoglio personale? Io direi limitazioni di licenza e codice chiuso a favore delle CPU con architettura intell.. l'orgoglio quando si parla denaro in questi campi cona meno di zero.

fa parte della visione di qualche fanboy che vuole la buona e generosa nVIDIA offrire gratuitamente le sue risorse all'ingrata e cattiva ATi che le rifiuta sdegnosamente danneggiando coloro che comprano i suoi prodotti pur di non dare soddisfazioni alla rivale.

E' un sogno da cui qualcuno ancora non si è svegliato :D

visti i giochi che usano havok:
http://www.havok.com/content/blogcategory/29/73/
e quelli che usano physx:
http://it.nzone.com/object/nzone_physxgames_home_it.html

al momento attuale, quale è il metodo che funziona meglio?
Eppoi, se uno ha gpu nvidia e cpu intel potrebbe giocare ai giochi che utilizzano physx (usando quindi physx per gestire la fisica) e un secondo dopo giocare a giochi che usano havok (usando quindi havok per gewstire la fisica) sullo stesso PC? E' possibile questo?

La lista dei giochi che usano PhysX non è completa, sono stati omessi i titoli per PC che non si avvalgono di accelerazione hardware.

Dopo aver visto il meglio che può dare Havok e il meglio che può dare PhysX propendo per il secondo.

Neppure se posto questa gif??
http://www.hypersg1.org/immagini/Rosik.gif




p.s. Non è certo un caso che questa affermazione sia scaturita a pochi giorni da quest'altra:
http://www.hwupgrade.it/news/skvideo/2k-games-e-ea-scelgono-physx_27419.html

Capita... :)
Purtroppo mi sa che hai ragione, tra l'altro AMD voleva acquisire AGEIA, ma poi, probabilmente per ragioni economiche è andata come sappiamo...
Io continuo ha sperare che AMD decida di supportare attivamente PhysX.

ma lol,che ca22oni.. per standard "aperto e non proprietario" intendono una tecnologia utilizzabile da chiunque e non solo da chi la sviluppa. havok,ad esempio,puo' essere utilizzato con schede nvidia. le directx sono utilizzate da ati ed nvidia..etc,etc,etc.. :rolleyes:

Non si cambia il significato delle parole a seconda delle esigenze, "aperto e non proprietario" hanno un altro significato.
Forse avrebbero dovuto scrivere "royalty free", ma ha questo punto in questa cadegoria vi rientrerebbe anche PhysX.

non da quando physx e' sotto nvidia..anche se googlando ho letto che Eran Badit di NGOHQ.com ha modificato il layer PhysX per farlo lavorare anche su schede grafiche ATI.

E hai letto che NVIDIA a deciso di fornire supporto a questo sviluppatore?
E che AMD invece non si è dimostrata interessata?

Qui c'è il video

http://www.tvtech.it/video/227/mirror-s-edge-con-e-senza-physx/

è evidente che physx, oltre a gestire la fisica degli oggetti presenti, ne fa apparire di inesistenti (il mago otelma dei tool di sviluppo :D ). Un po' come, in altri game, qualche passaggio di rendering di troppo forzato anche quando e dove non sarebbe necessario, oppure come la stessa physx gestita da cpu, rallentata ad arte :D

Detto ciò, l'implementazione vista in questa demo non è niente di particolare:fisica per nulla realistica e grafica scarna con 4 poligoni e 2 texture in croce.
Che si potesse fare di meglio non lo metto in dubbio, però in questo genere di gioco e con questo gameplay non è che si possa fare più di qualche effetto cinematografico.

e i festoni in alto sui corridoi (tanto per dirne una)? Si sarebbero potuti mettere, magari statici, come in altri game (e non col movimento random del video con physx spinti da non si sa cosa). Invece non c'è niente. Contro quelli non ci sbatte nessuno e non c'è alcun effetto da simulare. Tra l'atro, ad essere pignoli, non è necessaria physx, oppure una scheda dedicata, per gestire l'effetto di un telo che si squarcia (o di una parete lesionata da un proiettile). Per nulla realistico anche l'effetto della guardia che vola via neanche fosse investita da un tir sull'autosole. Completamnete innaturali anche gli affetti dei teli nei corridoi, che dovrebbero essere mossi dai proiettili e dall'aria spostata dalla protagonista ma sembrano animati da vita propria e si muovono in maniera del tutto casuale, come investiti da folate di vento con dirrezione variabile. Insomma, non ci siamo per niente.

Dì yossarian, quante volte hai sparato a dei festoni o ha delle lastre di vetro?
Che nel movimento dei teli non ci sia niente da simulare è profondamente sbagliato, Eraser|85 che con la simulazione dei tessuti ci lavora te lo può confermare.
Che poi un effetto simile si potesse ottenere con la CPU o attraverso un animazione non lo metto certo in dubbio, infatti Mirror's Edge non è sicuramente un esempio da prendere in considerazione per valutare PhysX.
Gli effetti implementati in questo gioco sono molto cinematografici, come appunto la guardia che viene buttata giù dall'edificio.

Orgoglio personale? Io direi limitazioni di licenza e codice chiuso a favore delle CPU con architettura intell.. l'orgoglio quando si parla denaro in questi campi cona meno di zero.

Il codice di PhysX non è proprio chiuso guarda qui http://developer.nvidia.com/object/physx.htm

fa parte della visione di qualche fanboy che vuole la buona e generosa nVIDIA offrire gratuitamente le sue risorse all'ingrata e cattiva ATi che le rifiuta sdegnosamente danneggiando coloro che comprano i suoi prodotti pur di non dare soddisfazioni alla rivale.

E' un sogno da cui qualcuno ancora non si è svegliato :D
Qui a dormire sembrano in molti...
Io non giudico cattive o buone nessuna delle aziende che hai citato.

Ci sono dei dati di fatto:

A NVIDIA converrebbe se AMD supportasse PhysX, in quanto permetterebbe agli sviluppatori di poter contare su una base installata di acceleratori molto alta, favorendone in questo modo l'adozione su larga scala.

NVIDIA ha deciso di supportare il lavoro di Eran Badit nell'estendere il supporto a PhysX anche alle GPU AMD.
La posizione di AMD la si può leggere in questa news

direttamente dalla fonte:
Nvidia claims they would be happy for ATI to adopt PhysX support on Radeons. To do so would require ATI to build a CUDA driver, with the benefit that of course other CUDA apps would run on Radeons as well. ATI would also be required to license PhysX in order to hardware accelerate it, of course, but Nvidia maintains that the licensing terms are extremely reasonable—it would work out to less than pennies per GPU shipped.

I spoke with Roy Taylor, Nvidia's VP of Content Business Development, and he says his phone hasn't even rung to discuss the issue. "If Richard Huddy wants to call me up, that's a call I'd love to take," he said.

come l'amico Stefem ricorda:
http://developer.nvidia.com/object/physx.htm
What Does It Cost?

The NVIDIA PhysX SDK (binary) is 100% free and available right now for download by developers.

Le persone intelligenti sono sicuro che sapranno tirare da soli le loro conclusioni - i sogni lasciamoli ad altri.

Chissà quanto paga Nvidia alle software house per tutto ciò? Stesso discorso per il logo che si vede all'inizio in molti giochi (...The way it's meant to be played...), dove il gioco è stato programmato e "ottimizzato" per funzionare al meglio su piattaforma Nvidia... poi ci credo che alcuni titoli su Ati vanno meno bene... e svantaggiata già in partenza... mah...

Chissà quanto paga Nvidia alle software house per tutto ciò? Stesso discorso per il logo che si vede all'inizio in molti giochi (...The way it's meant to be played...), dove il gioco è stato programmato e "ottimizzato" per funzionare al meglio su piattaforma Nvidia... poi ci credo che alcuni titoli su Ati vanno meno bene... e svantaggiata già in partenza... mah...

Se non sapete minimamente cosa prevede il programma TWIMTBP, non parlatene, dato che al 99% state per dire una cazzata.

Se non sapete minimamente cosa prevede il programma TWIMTBP, non parlatene, dato che al 99% state per dire una cazzata.

...certo certo, tu sai tutto... lol... ma per piacere

...certo certo, tu sai tutto... lol... ma per piacere

Non è un segreto... basta informarsi...

Vai a vedere in cosa consiste e dopo dimmi se le cose stanno come hai detto tu.

Non è un segreto... basta informarsi...

Vai a vedere in cosa consiste e dopo dimmi se le cose stanno come hai detto tu.

infatti, alla fin fine le cose stanno proprio così... mi è capitato di leggere più di un articolo a riguardo... altrimenti ad uno sviluppatore cosa ci guadagna a sviluppare su piattaforma Nvidia piuttosto che Ati... fai te due conti...

Vai a vedere in cosa consiste e dopo dimmi se le cose stanno come hai detto tu.


O, direttamente dalla fonte:



:muro: :muro: :muro:
(...autocensura senno mi bannano...)

Cito quello che avete citato:
To do so would require ATI to build a CUDA driver
ATI dovrebbe legare lo sviluppo del suo hardware alle specifiche di CUDA, che vengono decise solo da nVidia! Tanto vale che AMD ricompri le GPU nVIdia e le rivendi, a sto punto.

The NVIDIA PhysX SDK (binary) is 100% free and available right now for download by developers.
Per poter supportare PhysiX su CAL, ATI dovrebbe poter modificare il binario di PhysX, Physix è gratuito per chi vuole usarlo per poter fare i giochi, non per chi vuole modificarlo per farlo girare su altre GPU!

Sob... sono sicuro che se avessi un paio di belle tette sarei più convincente.

Le persone intelligenti sono sicuro che sapranno tirare da soli le loro conclusioni - i sogni lasciamoli ad altri.
Ho proprio l'impressione che il rapporto tribale che le aziende riescono ad instaurare con alcuni clienti, oblumini l'intelligenza che pure ci sarebbe. Mah. :(

edit: a proposito di persone intelligenti, discussione su beyond3d a proposito di "CUDA su ATI", se qualcuno fosse interessato ad approfondire.
http://forum.beyond3d.com/showthread.php?t=48435

La premessa della discussione...
I suspect Roy Taylor was joking, but still ... can it be done?

Apart from the fact that it's a significant amount of work which only works to strengthen a rival there are of course the practical problems.
Cioè, là per fare una discussione tecnica son partiti dal dare come ovvio, quello su cui ancora noi qui da 6 mesi siamo a discutere. :cry:

infatti, alla fin fine le cose stanno proprio così... mi è capitato di leggere più di un articolo a riguardo... altrimenti ad uno sviluppatore cosa ci guadagna a sviluppare su piattaforma Nvidia piuttosto che Ati... fai te due conti...


Questo dimostra che non hai capito un bel fico secco di cosa sia e dei vantaggi offerti dal TWIMTBP.

Questo dimostra che non hai capito un bel fico secco di cosa sia e dei vantaggi offerti dal TWIMTBP.

sì, software designato per andare al massimo su hardware Nvidia... un po' estremizzato ma è così... va beh, lasciamo stare... un altro fan boy in action... e sono io a non aver capito un fico secco... (ma lavori per Nvidia per caso...:rolleyes:)

Ma...
http://software.intel.com/sites/havok/

Allora anche di Havok sono gratuitamente e liberamente disponibili solo i binari, e in più, a differenza di PhysX, in caso si voglia utilizzarlo per applicazioni commerciali bisogna comprare una licenza:confused:

Questo dimostra che non hai capito un bel fico secco di cosa sia e dei vantaggi offerti dal TWIMTBP.
Gli atisti s'erano entusiasmati alla notizia che Starcraft II e Diablo III avrebbero avuto il logo ATI da qualche parte.
http://vr-zone.com/articles/blizzard-to-optimize-games-for-ati-radeon-cards/5987.html?doc=5987

A me queste cose paiono inculate per noi utenti, e mi par strano che la gente si entusiasmi per esse.

Gli atisti s'erano entusiasmati alla notizia che Starcraft II e Diablo III avrebbero avuto il logo ATI da qualche parte.
http://vr-zone.com/articles/blizzard-to-optimize-games-for-ati-radeon-cards/5987.html?doc=5987

A me queste cose paiono inculate per noi utenti, e mi par strano che la gente si entusiasmi per esse.

infatti, parole sante

Ma...
Allora anche di Havok sono gratuitamente e liberamente disponibili solo i binari, e in più, a differenza di PhysX, in caso si voglia utilizzarlo per applicazioni commerciali bisogna comprare una licenza:confused:
E con questo? Intendi dire che entrambe le aziende sull'accelerazione fisica ci stanno prendendo in giro?

Sono d'accordissimo, è tutta fuffa. :D

(le cose serie si vedranno con le piattaforme di terzi che sfruttino al meglio GPU e CPU in maniera standard. Open o closed che siano, senza loghi)

sì, software designato per andare al massimo su hardware Nvidia... va beh, lasciamo stare... un altro fan boy in action... e sono io a non aver capito un fico secco... (ma lavori per Nvidia per caso...:rolleyes:)

Allora, facciamo un po' di chiarezza.

In parole povere aderendo al programma TWIMTBP lo sviluppatore si impegna ad apporre il logo TWIMTBP sulla scatola e magari nei filmati che partono quando si avvia il gioco (qui NVIDIA ci guadagna un bel po', tutta pubblicità "quasi gratuita" ed è molto meglio di un banner o di una stampa).
In cambio NVIDIA offre, a parte tutta una serie di utility che sono comunque disponibili a tutti compreso me e te, supporto nell'ideazione e sviluppo di effetti grafici, supporto nell'implementazione di PhysX e raramente le specifiche del nuovo hardware così da permettere agli sviluppatori di delineare le capacita dei PC che saranno disponibili quando sarà rilasciato il gioco.

Inoltre, cosa ENORMEMENTE più importante, NVIDIA offre un testing del software su una base di PC dotati di hardware NVIDIA che copre praticamente ogni versione di GPU e Chipset di schede madri(NVIDIA), dalla GeForce 256 alla GTX 280 (sia SLI che no) passando per le soluzioni grafiche integrate e dall'nForce all/nForce790i, tramite un laboratorio presente in Russia ed uno molto più piccolo in California, fornendo poi un resoconto dei bug riscontrati (in questo modo possono risolvere in anticipo quelli causati dai driver).
Sta poi agli sviluppatori decidere se e quando risolvere questi bug o chiedere supporto per implementare quest'effetto o quella tecnologia.
Gli sviluppatori molto raramente decidono di ottimizzare un gioco per un produttore, sia esso AMD o NVIDIA, perché questo finirebbe immancabilmente per ostacolare le vendite ad una parte dei potenziali clienti.

Ricapitolando, chi guadagna cosa?

NVIDIA: Ottima pubblicità, che tra l'altro va diretta al target, cioè i gamer.

Sviluppatore: Supporto e pubblicità.

Gamer: I driver del suo hardware NVIDIA non saranno(nei limiti dell umanamente possibile, nessuno è perfetto:D ) la causa di problemi con quel gioco (che è lo scopo per cui è nato TWIMTBP).

E con questo? Intendi dire che entrambe le aziende sull'accelerazione fisica ci stanno prendendo in giro?

Sono d'accordissimo, è tutta fuffa. :D

(le cose serie si vedranno con le piattaforme di terzi che sfruttino al meglio GPU e CPU in maniera standard. Open o closed che siano, senza loghi)

No, quello che intendo dire è che ora non capisco le affermazioni di AMD sul voler supportare solo soluzioni open e free "There is no plan for closed and proprietary standards like PhysX."

Almeno i binari dell'SDK PhysX sono gratuiti anche per applicazioni commerciali.

Magari ho letto male...

[...]
Gamer: I driver del suo hardware NVIDIA non saranno(nei limiti dell umanamente possibile, nessuno è perfetto:D ) la causa di problemi con quel gioco (che è lo scopo per cui è nato TWIMTBP).

Appunto, il gioco è stato testato e ottimizzato su hardware Nvidia...
Tu vedi solo una parte della cosa, solo quella che fa comodo a te... Non c'è peggior sordo di chi non vuol sentire... E poi che tutta la cosa per Nvidia sia gratuita e limpida come dici è tutta da dimostrare, a meno che tu non sia un dirigente della suddetta azienda e possa qui smentirmi...

Appunto, il gioco è stato testato e ottimizzato su hardware Nvidia...
Tu vedi solo una parte della cosa, solo quella che fa comodo a te... Non c'è peggior sordo di chi non vuol sentire... E poi che tutta la cosa per Nvidia sia gratuita e limpida come dici è tutta da dimostrare, a meno che tu non sia un dirigente della suddetta azienda e possa qui smentirmi...

Testato sicuramente, ottimizzato è ben altra cosa...

NVIDIA non lo fa certo perché è "gratuita e limpida", lo fa perché gli conviene, i motivi che ho scritto prima mi sembrano sufficienti.
Io non sono un dirigente di nessuna azienda, però ho avuto modo di parlare, anche di questo, con Luciano Alibrandi Director of Product PR EMEAI in NVIDIA.

Ma...
http://software.intel.com/sites/havok/

Allora anche di Havok sono gratuitamente e liberamente disponibili solo i binari, e in più, a differenza di PhysX, in caso si voglia utilizzarlo per applicazioni commerciali bisogna comprare una licenza:confused:

E con questo? Intendi dire che entrambe le aziende sull'accelerazione fisica ci stanno prendendo in giro?

Sono d'accordissimo, è tutta fuffa. :D

(le cose serie si vedranno con le piattaforme di terzi che sfruttino al meglio GPU e CPU in maniera standard. Open o closed che siano, senza loghi)

No, quello che intendo dire è che ora non capisco le affermazioni di AMD sul voler supportare solo soluzioni open e free "There is no plan for closed and proprietary standards like PhysX."

Almeno i binari dell'SDK PhysX sono gratuiti anche per applicazioni commerciali.

Magari ho letto male...

Havok è meglio di PhysX come qualità della simulazione, però è a pagamento (la versione free è molto limitata, non gestisce nemmeno i Cloth, ma solo i Rigid Bodies se non erro).

PhysX è gratuita al 100%, sia per le applicazioni commerciali che quelle "caserecce".. se proprio vuoi fargli na "donazione" puoi comprarti i sorgenti da modificare come ti pare e piace per 50k $.

Noi in azienda avevamo bisogno di un motore per la fisica.. indovinate un po' quale abbiamo scelto? :P
E cmq la nVidia è sempre stata molto disponibile verso gli sviluppatori e per me questo è un grande plus... con la versione 3 delle PhysX inoltre cambieranno un po' di roba e diventerà più competitiva rispetto alle Havok..

AMD a volte si intestardisce e non ne capisco il motivo.. ok la concorrenza ma una soluzione "non proprietaria" (come vuole lei) la vedo ancora molto lontana (DX11.. 1 anno di attesa oltre ai normali tempi di sviluppo...)

Testato sicuramente, ottimizzato è ben altra cosa...

NVIDIA non lo fa certo perché è "gratuita e limpida", lo fa perché gli conviene, i motivi che ho scritto prima mi sembrano sufficienti.
Io non sono un dirigente di nessuna azienda, però ho avuto modo di parlare, anche di questo, con Luciano Alibrandi Director of Product PR EMEAI in NVIDIA.

addirittura...
cmq eh certo che gli conviene... Se fossi un utente Nvidia sarei contento di tutto ciò, ma siccome esiste anche Ati sta "campagna" (come la chiami tu) non è che sia il massimo della vita. Che poi magari avrebbe dovuto farla anche Ati una cosa analoga questo sicuramente.

Havok è meglio di PhysX come qualità della simulazione, però è a pagamento (la versione free è molto limitata, non gestisce nemmeno i Cloth, ma solo i Rigid Bodies se non erro).

PhysX è gratuita al 100%, sia per le applicazioni commerciali che quelle "caserecce".. se proprio vuoi fargli na "donazione" puoi comprarti i sorgenti da modificare come ti pare e piace per 50k $.

Noi in azienda avevamo bisogno di un motore per la fisica.. indovinate un po' quale abbiamo scelto? :P
E cmq la nVidia è sempre stata molto disponibile verso gli sviluppatori e per me questo è un grande plus... con la versione 3 delle PhysX inoltre cambieranno un po' di roba e diventerà più competitiva rispetto alle Havok..

AMD a volte si intestardisce e non ne capisco il motivo.. ok la concorrenza ma una soluzione "non proprietaria" (come vuole lei) la vedo ancora molto lontana (DX11.. 1 anno di attesa oltre ai normali tempi di sviluppo...)
Allora ho letto bene, ora capisco il motivo per cui i minigiochi basati sulla fisica utilizzano PhysX, e ora però non comprendo più i discorsi di AMD:mbe: .

La versione dell'engine PhysX è ancora l'ultima sviluppata da Ageia, giusto?

Secondo me Havok offre una miglior simulazione nella gestione delle collisioni tra Rigid Bodies, almeno, così mi è sembrato, le simulazioni mi hanno sempre affascinato ma non si può dire che sia un Esperto.

Purtroppo non ho lavorato molto con i rigid bodies ma da quello che ho visto la libreria è piuttosto completa da quel punto di vista.

I cloth sono ancora molto limitati ma non è possibile pretendere più di tanto da una simulazione in tempo reale.. questo vale per ogni libreria :)

La versione è praticamente l'ultima sviluppata dalla Ageia, solo che ora supporta l'accelerazione tramite GPU, chiamalo poco :) Per questo secondo me si sono fermati, per dare modo agli ingegneri nVidia di aggiungere il supporto alle GPU.

Purtroppo non ho lavorato molto con i rigid bodies ma da quello che ho visto la libreria è piuttosto completa da quel punto di vista.

I cloth sono ancora molto limitati ma non è possibile pretendere più di tanto da una simulazione in tempo reale.. questo vale per ogni libreria :)

La versione è praticamente l'ultima sviluppata dalla Ageia, solo che ora supporta l'accelerazione tramite GPU, chiamalo poco :) Per questo secondo me si sono fermati, per dare modo agli ingegneri nVidia di aggiungere il supporto alle GPU.

E' quello che ho pensato anch'io, d'altronde non dev'essere stata una cosa banale.

Questo discutere di fisica mi ha fatto venir voglia di fare qualcosa, ho l'SDK installato ma non l'ho mai usato.

Voi per cosa lo usate?

Ricordo di un azienda tessile che aveva acquistato delle Tesla, ma non ho mai saputo con certezza cosa simulassero.

Che si potesse fare di meglio non lo metto in dubbio, però in questo genere di gioco e con questo gameplay non è che si possa fare più di qualche effetto cinematografico.



effetti cinematografici? :rolleyes:



Dì yossarian, quante volte hai sparato a dei festoni o ha delle lastre di vetro?



e tu quante volte lo hai fatto per dire che è ben simulato? :D



Che nel movimento dei teli non ci sia niente da simulare è profondamente sbagliato, Eraser|85 che con la simulazione dei tessuti ci lavora te lo può confermare.

noto che l'abitudine di mettere in bocca cose mai dette e piuttosto invalsa: mi linki dove ho affermato che non ci sia niente da simulare? Ho detto (e lo ripeto) che non si tratta di simulazione della fisica ma di movimenti generati in maniera per nulla realistica e in modalità random



Che poi un effetto simile si potesse ottenere con la CPU o attraverso un animazione non lo metto certo in dubbio, infatti Mirror's Edge non è sicuramente un esempio da prendere in considerazione per valutare PhysX.

ecco, allora non lo prendiamo in considerazione, che è meglio.



Gli effetti implementati in questo gioco sono molto cinematografici, come appunto la guardia che viene buttata giù dall'edificio.



non vedo effetti cinematografici e la guardia che vola giù fa il paio con i barili volanti di fallout 3. Se quella è simulazione fisica, lo sono anche le casse distrutte a colpi di mazza di NWN :D



Qui a dormire sembrano in molti...


c'è chi dormendo si riposa; chi dorme e sogna ma poi si sveglia; chi dorme sogna e confonde i propri sogni con la realtà. Cambiano la qualità del sonno e le modalità di risveglio :D



Io non giudico cattive o buone nessuna delle aziende che hai citato.



ho fatto il tuo nome? Non me lo ricordavo




Ci sono dei dati di fatto:

A NVIDIA converrebbe se AMD supportasse PhysX, in quanto permetterebbe agli sviluppatori di poter contare su una base installata di acceleratori molto alta, favorendone in questo modo l'adozione su larga scala.

NVIDIA ha deciso di supportare il lavoro di Eran Badit nell'estendere il supporto a PhysX anche alle GPU AMD.
La posizione di AMD la si può leggere in questa news

i fatti sono che a nVIDIA converrebbe che AMD supportasse il suo standard per tentare di imporlo alla comunità degli sviluppatori, perchè da sola non ha la forza per farlo. Se ad AMD non dovesse convenire la stessa cosa, mi dai un solo motivo per cui dovrebbe accettare lA corte di nVIDIA?
Poniamo il caso peggiore: da un lato AMD boicotta la fisica via gpu perchè non ha un suo standard da imporre; dall'altro nVIDIA sta boicottando l'adozione delle dx10.1 perchè le sue gpu non le supportano e non sarebbero competitive, così come ha fatto con le dx9 quando aveva la serie FX.

Chi danneggia chi?

e i festoni in alto sui corridoi (tanto per dirne una)? Si sarebbero potuti mettere, magari statici, come in altri game (e non col movimento random del video con physx spinti da non si sa cosa). Invece non c'è niente. Contro quelli non ci sbatte nessuno e non c'è alcun effetto da simulare. Tra l'atro, ad essere pignoli, non è necessaria physx, oppure una scheda dedicata, per gestire l'effetto di un telo che si squarcia (o di una parete lesionata da un proiettile). Per nulla realistico anche l'effetto della guardia che vola via neanche fosse investita da un tir sull'autosole. Completamnete innaturali anche gli affetti dei teli nei corridoi, che dovrebbero essere mossi dai proiettili e dall'aria spostata dalla protagonista ma sembrano animati da vita propria e si muovono in maniera del tutto casuale, come investiti da folate di vento con dirrezione variabile. Insomma, non ci siamo per niente.
noto che l'abitudine di mettere in bocca cose mai dette e piuttosto invalsa: mi linki dove ho affermato che non ci sia niente da simulare? Ho detto (e lo ripeto) che non si tratta di simulazione della fisica ma di movimenti generati in maniera per nulla realistica e in modalità random

Forse ho capito male, non ti riferivi hai teli e festoni del video?

e tu quante volte lo hai fatto per dire che è ben simulato? :D


Mai.

Infatti non ho mai detto che fossero ben simulati e nemmeno il contrario.

Noto anch'io che l'abitudine di mettere in bocca cose mai dette e piuttosto invalsa...
effetti cinematografici? :rolleyes:

non vedo effetti cinematografici e la guardia che vola giù fa il paio con i barili volanti di fallout 3. Se quella è simulazione fisica, lo sono anche le casse distrutte a colpi di mazza di NWN :D

Forse mi hai frainteso, per effetti cinematografici intendevo scene molto "spettacolari" e poco realistiche, come spesso accade nei film.

ho fatto il tuo nome? Non me lo ricordavo

No, volevo solo chiarire il mio punto di vista.

i fatti sono che a nVIDIA converrebbe che AMD supportasse il suo standard per tentare di imporlo alla comunità degli sviluppatori, perchè da sola non ha la forza per farlo. Se ad AMD non dovesse convenire la stessa cosa, mi dai un solo motivo per cui dovrebbe accettare lA corte di nVIDIA?
Poniamo il caso peggiore: da un lato AMD boicotta la fisica via gpu perchè non ha un suo standard da imporre; dall'altro nVIDIA sta boicottando l'adozione delle dx10.1 perchè le sue gpu non le supportano e non sarebbero competitive, così come ha fatto con le dx9 quando aveva la serie FX.

Chi danneggia chi?
Ti espongo il mio punto di vista:

Ad AMD converrebbe poter sfruttare PhysX via GPU, sia dal lato vendite che dal punto di vista dei + offerti al cliente, solo che questo gioverebbe all'immagine del suo concorrente.
Infatti ha detto di non amare le soluzioni chiuse e proprietarie tipo PhysX ("There is no plan for closed and proprietary standards like PhysX") e poi dice di voler appoggiare Havok che da quanto ho potuto leggere sul suo sito è meno free, dato che fornisce gratis solo una versione limitata e per applicazioni commerciali bisogna pagare la licenza, e non è open, se non quanto PhysX dato che se si vogliono i sorgenti bisogna pagarli.

In che modo NVIDIA boicotterebbe l'adozione delle DX10.1(a parte non avendo l'hardware per supportarle)?

Credo che gli sviluppatori adotterebbero senza problemi le DX10.1 se lo ritenessero opportuno dato che migliorerebbe l'esperienza dell'utente AMD e non peggiorerebbe quella dell'utente NVIDIA.
Secondo me chi boicotta le DX10.1 così come le 10 è la stessa Microsoft che non le ha rese disponibili per XP volendo favorire la diffusione di Vista, e questa è anche l'opinione di alcuni importanti sviluppatori.

ATI non ostacolò l'adozione delle DX9.0c con R420?



Chi danneggia chi?

Non so risponderti, ma ho l'impressione che per un motivo ho per l'altro ci finisce di mezzo anche il consumatore.

Forse ho capito male, non ti riferivi hai teli e festoni del video?



hai capito bene; non c'era alcun bisogno di farli sparire dal video senza physx: era sufficiente non simulare quall'assurdo quanto innaturale movimento che manifestano nel video con physx. Non serve sparare a festoni o vetrate per conoscere le leggi fisiche e rendersi conto se una simulazione è ben fatta o no. La senzazione che sdi ha, a parte la direzione del movimento che spesso non ci azzecca niente, è che tutto si muova e voli via con troppa "leggerezza" come se non avesse peso e non opponesse la minima resistenza.


Mai.

Infatti non ho mai detto che fossero ben simulati e nemmeno il contrario.

Noto anch'io che l'abitudine di mettere in bocca cose mai dette e piuttosto invalsa...


noti male, oppure mi spieghi il senso di questo



Dì yossarian, quante volte hai sparato a dei festoni o ha delle lastre di vetro?


E ci aggiungo una domanda: secondo te quelle simulazioni sono ben fatte e realistiche?



Forse mi hai frainteso, per effetti cinematografici intendevo scene molto "spettacolari" e poco realistiche, come spesso accade nei film.


nessun fraintendimento: mi sono limitato a commentare ciò che hai letteralmente affermato. Effetti cinematografici non significa effetti spettacolari. Vetrate che si spaccano come fossero fatte di carta velina e festoni che si muovono animati da vita propria non sono effetti cinematografici e neppure spettacolari. Per la cronaca, di vetrine rotte ne ho viste diverse, ma nessuna con quegli effetti "cinemantografici": neppure al cinema :D



Ti espongo il mio punto di vista:

Ad AMD converrebbe poter sfruttare PhysX via GPU, sia dal lato vendite che dal punto di vista dei + offerti al cliente, solo che questo gioverebbe all'immagine del suo concorrente.
Infatti ha detto di non amare le soluzioni chiuse e proprietarie tipo PhysX ("There is no plan for closed and proprietary standards like PhysX") e poi dice di voler appoggiare Havok che da quanto ho potuto leggere sul suo sito è meno free, dato che fornisce gratis solo una versione limitata e per applicazioni commerciali bisogna pagare la licenza, e non è open, se non quanto PhysX dato che se si vogliono i sorgenti bisogna pagarli.



la tua tesi decade dal momento che anche intel è concorrente quanto e forse più di nVIDIA per AMD. AMD produce sia gpu che cpu e cerca di vendere entrambe, esattamente come intel.



In che modo NVIDIA boicotterebbe l'adozione delle DX10.1(a parte non avendo l'hardware per supportarle)?

Credo che gli sviluppatori adotterebbero senza problemi le DX10.1 se lo ritenessero opportuno dato che migliorerebbe l'esperienza dell'utente AMD e non peggiorerebbe quella dell'utente NVIDIA.


certo, come successo per assassin's creed; in quel caso l'esperienza degli utenti amd migliorava troppo e la cosa non è andata giù a qualcuno :D .
Guarda caso, c'è anche l'intervista ad uno sviluppatore di ubisoft che si è lasciato sfuggire a mezza bocca che in dx10.1 il famoso passaggio di rendering che saltava per errore non era, in realtà un errore ma rientrava nell'ordine delle cose. E guarda caso, tutti i motori che implentano MSAA con deferred rendering fanno uso del pesante render to texture invece di ricorrere al MRT (molto più naturale).



Secondo me chi boicotta le DX10.1 così come le 10 è la stessa Microsoft che non le ha rese disponibili per XP volendo favorire la diffusione di Vista, e questa è anche l'opinione di alcuni importanti sviluppatori.


ci sono anche importanti sviluppatori che sostengono sia nVIDIA a spingere le SWHouse del programma TWIMTBP a boicottare le dx10.1. D'altra parte non fa piacere vedere una costosa 280 GTX, a risoluzioni non frame buffer bounded, al livello di una modesta 4850 con AA 4x :D
Di sicuro non è AMD a boicottarle.



ATI non ostacolò l'adozione delle DX9.0c con R420?


non mi risulta; se hai prove da portare a supporto della tua tesi fallo; piuttosto mi ricordo di titoli che non partivano su hw dx9b, senza alcun motivo (solo chiamate tranquillamente emulabili anche con le dx9a, come accade con le dx10 e le texture array di clear sky). E mi ricordo delle guerre di "religione" fatte da nVIDIA contro futuremark (e dei cheat via driver per raddoppiare il punteggio dei 3dmark con il taglio delle superfici nascoste che non venivano renderizzate affatto) e contro valve che si era permessa di utilizzare dx9 senza sbattersi per tirare fuori una path che permettesse a nv35 di utlizzare quel po' di codice fp16 che il numero limitato di registri e la limitata autonomia delle alu permetteva di usare.



Chi danneggia chi?

Non so risponderti, ma ho l'impressione che per un motivo ho per l'altro ci finisce di mezzo anche il consumatore.
prova a spiegare il concetto ai fanboy

tra havok(intel) e phisix(nvidia) chissa' quale sara' piu' supportato dalle software house :asd:

in effetti non saprei dato che Intel detiene circa il 60% del mercato CPU e Nvidia circa il 60% di quello di schede grafiche...

http://store.steampowered.com/hwsurvey

:muro: :muro: :muro:
(...autocensura senno mi bannano...)

Cito quello che avete citato:

ATI dovrebbe legare lo sviluppo del suo hardware alle specifiche di CUDA, che vengono decise solo da nVidia! Tanto vale che AMD ricompri le GPU nVIdia e le rivendi, a sto punto.


Per poter supportare PhysiX su CAL, ATI dovrebbe poter modificare il binario di PhysX, Physix è gratuito per chi vuole usarlo per poter fare i giochi, non per chi vuole modificarlo per farlo girare su altre GPU!

Sob... sono sicuro che se avessi un paio di belle tette sarei più convincente.

Ho proprio l'impressione che il rapporto tribale che le aziende riescono ad instaurare con alcuni clienti, oblumini l'intelligenza che pure ci sarebbe. Mah. :(

edit: a proposito di persone intelligenti, discussione su beyond3d a proposito di "CUDA su ATI", se qualcuno fosse interessato ad approfondire.
http://forum.beyond3d.com/showthread.php?t=48435

La premessa della discussione...

Cioè, là per fare una discussione tecnica son partiti dal dare come ovvio, quello su cui ancora noi qui da 6 mesi siamo a discutere. :cry:Io mi stupisco sempre più di una cosa:

*VIDIA tira fuori soldi per AGE*A.
*VIDIA tira fuori soldi per CUDA.
*VIDIA tira fuori soldi per PH*SX.
*VIDIA tira fuori soldi per il supporto end-user (anche solo volessero "giocare" con l'SDK).
*VIDIA tira fuori soldi per sviluppatori che si fanno il culo dalla mattina alla sera per creare driver Linux.
*VIDIA tira fuori soldi per laboratori di testing di tutti i suoi prodotti.
*VIDIA tira fuori soldi per il supporto commerciale dei suoi prodotti, con esempi (anche addirittura "per gioco"), consulenti a domicilio, specifiche infinitesimali.
*VIDIA tira fuori soldi e tempo per creare standard liberamente fruibili (come OPENGL ES e OPENCL).
*VIDIA tira fuori soldi, nonostante abbia PH*SX, pure per supportare HAV*K.
*VIDIA tira fuori soldi per continuare a supportare uno standard moribondo, che altri competitor hanno invece lasciato indietro, ovvero OPENGL.
*VIDIA tira fuori soldi (anche solo con il fatto di licenze gratuite - non serve pensare a mazzette) per spingere gli sviluppatori ad implementare la fisica nei giochi.
*VIDIA tira fuori soldi per fare convention (NVISI*N), dove si raduna la "summa" degli sviluppatori grafici.
*VIDIA tira fuori soldi per innovare il mercato con prodotti rivoluzionari, partendo assolutamente da zero (3DSTERE*).
*VIDIA tira fuori soldi per addirittura supportare il porting dei suoi prodotti verso il principale competitor.

Non so in che paese incantato viviate, ma dalle mie parti è usanza non sputare nel piatto di chi si spacca il culo e tira fuori sudore e soldi per creare qualcosa, perdipiù se, pur indirettamente, vi si guadagna tutti.

Quindi, non si dice "che stronza, ha gli accordi con i produttori per il TWIMTBP",
ma ci si chiede com'è che il competitor non muove il culo per fornire un parimento degno supporto (tantopiù non è propriamente il top se parliamo di driver generici).

Neppure si dice "ohibò, svolazzano solo le bandirine, io mi aspettavo una simulazione MatLab in real-time con pure l'equazione di colebrook e calcolando tutte le traiettorie di ogni particella in modo turbolento",
ma ci si chiede perchè finora il competitor non abbia fatto qualcosa di meglio, o anche solo minimamente simile, o anche perchè non muovino il culo per fornirvi una toppa.

La cosa che più mi addolora leggere è proprio questa mancanza di critiche costruttive, ma solo piagnistei del tipo "signora maestra, antonio è cattivo perchè mi ha rubato la palla, non è giusto! gneee gneee" oppure alla "volpe e l'uva", che è meglio stare senza bandierine, "che tanto a me vederle svolazzare sta pure sulle palle che non mi concentro".

A 6 mesi di distanza, e tanti sono passati dalle dichiarazioni del "competitor rosso" per il supporto di HAV*K, io non mi aspetto che tale azienda sputi nel piatto degli altri, e che magari ci siano pure utenti caproni a dargli ragione, ma mi aspetto QUANTOMENO di vedere qualcosa di tangibile che lo rivaleggi (lo sdegno in questo senso cresce se provate ad installare FallO*t 3, l'ultimo titolo che usa HAV*K: lato fisica di gioco, è carente).

In meno tempo (3-4 mesi), *VIDIA è riuscita a rilevare l'azienda AGE*A e a portare interamente l'architettura (prima basata su scheda esterna) sulle sue VGA, addirittura estendendo il supporto a VGA datate 2006 (2 anni prima). Tutto aggratis.

Fatti, non parole.




certo, come successo per assassin's creed; in quel caso l'esperienza degli utenti amd migliorava troppo e la cosa non è andata giù a qualcuno :D .
Guarda caso, c'è anche l'intervista ad uno sviluppatore di ubisoft che si è lasciato sfuggire a mezza bocca che in dx10.1 il famoso passaggio di rendering che saltava per errore non era, in realtà un errore ma rientrava nell'ordine delle cose. E guarda caso, tutti i motori che implentano MSAA con deferred rendering fanno uso del pesante render to texture invece di ricorrere al MRT (molto più naturale).Qua è stato dimostrato come il motore grafico di Assassin's Creed in DX10.1 sia buggato all'infinito, con sfuocature inutili, illuminazione farlocca, e pezzi di scenario che spariscono.
Io non sono un nativo del Brasile, e tralascio anche il fatto si stia parlando di discorsi di Aprile ( :) ), però mi pare di capire che nella foga sei addirittura riuscito a postare un forum dove si mette a confronto DX10 e DX10.1 e si giunge a conclusioni inaspettate (ovvero avalla grandemente l'ipotesi, che poi è l'affermazione ufficiale, per cui l'engine DX10.1 di Assassin's Creed sia effettivamente buggato, e per questo sia stato disabilitato).

http://www.framebuffer.com.br/forum/viewtopic.php?t=2178&postdays=0&postorder=asc&start=0

Dicono (comprovati da screen, eh) :

a) In DX10.1 con l'HDR tutto appare più luminoso del normale (DX10), con alcuni muri che proprio accecano

b) In DX10.1 non si può abilitare, causa bug, il adaptive/transparent anti-aliasing, con conseguenti pixelloni per lo schermo

c) In DX10.1 l'anisotropic-filtering non si può modificare ed è fisso a 8X

d) In DX10.1 attivando l'anti-aliasing scompaiono le cascate di sabbia dai templi

e) In DX10.1 le vetrate, invece che illuminate dal BLOOM, stanno in una misteriosa penombra

f) In DX10.1, saltuariamente, nelle scenette di inframezzo, diventa tutto sfuocato
La tesi del complotto la trovo quindi alquanto ridicola, dato che i problemi sono moltissimi.

ci sono anche importanti sviluppatori che sostengono sia nVIDIA a spingere le SWHouse del programma TWIMTBP a boicottare le dx10.1. D'altra parte non fa piacere vedere una costosa 280 GTX, a risoluzioni non frame buffer bounded, al livello di una modesta 4850 con AA 4x :D
Nomi e link, o sono tutte panzane.
Di sicuro non è AMD a boicottarle.Qualcuno (non io ;) ) potrebbe malignare lo faccia con il GPGPU Computing e l'utilizzo della fisica nei giochi ;)
non mi risulta; se hai prove da portare a supporto della tua tesi fallo; piuttosto mi ricordo di titoli che non partivano su hw dx9b, senza alcun motivo (solo chiamate tranquillamente emulabili anche con le dx9a, come accade con le dx10 e le texture array di clear sky).Io mi ricordo di VGA AT* con solo SM 2.0 (tipo X850XT P.E. , non proprio una della preistoria) che attualmente valgono poco più di fermacarte, dato che alcuni giochi senza supporto SM3.0 neppure partono (GRAW, COLiN, Splinter Cell).
Non mi pare che esistano, invece giochi specificatamente DX10.1.
E mi ricordo delle guerre di "religione" fatte da nVIDIA contro futuremark (e dei cheat via driver per raddoppiare il punteggio dei 3dmark con il taglio delle superfici nascoste che non venivano renderizzate affatto)I, così detti, "cheat", li ricordo anche da parte AT*:
http://www.xbitlabs.com/news/video/display/20030526040035.html
E la stessa ha ammesso pubblicamente tali "ottimizzazioni", quindi stavolta non ci si può nascendere sotto i tipici giustificazionismi del "eh ma non è vero", o simili.
E giusto recentemente mi ricordo tante belle rocce nel terreno che sparivano dal gioco Far Cry 2, proprio nel tentativo di raggiungere le prestazioni delle G92/GT200 che volavano:
http://en.expreview.com/2008/10/29/catalyst-810-hotfix-kidnapped-stones-in-far-cry-2.html
e contro valve che si era permessa di utilizzare dx9 senza sbattersi per tirare fuori una path che permettesse a nv35 di utlizzare quel po' di codice fp16 che il numero limitato di registri e la limitata autonomia delle alu permetteva di usare.D'altra parte, poi era AT* a rosikare con il gioco Doom 3, chiedendosi se era il caso di tutti quei stencil buffer shadow (Carmack Reverse) e a continuare a supportare OpenGL (all'epoca, le schede AT* erano davvero poco performanti con tali librerie).
prova a spiegare il concetto ai fanboySperiamo stavolta capiscano.

P.s. Non so' se vi interessa.....ma su xp e' facilmente utilizzabile una Ati come Vga e una Nvidia solo per l'accelerazione fisica. :asd: Se cercate c'e' la guida su internet. Su vista penso che a breve riescano a fare la stessa cosa. :D

Secondo me se Physx su Geforce sfrutta la GPU e su ATI o altre schede demanda tutto alla CPU è giusto che ATI/AMD si rivolga ad altre soluzioni, anche "closed", che sfruttino a dovere il suo hardware.

Diciamo che in generale (a patto di non andare a risoluzioni stratosferiche con tutti i filtri attivi) è più facile che la CPU sia il collo di bottiglia del sistema piuttosto che la GPU; indi per cui una soluzione che su un brand (Nvidia) sfrutti la GPU e negli altri la già tartassata CPU a me non sembra qualcosa su cui investire, per cui (a parte le baggianate sulle soluzioni "aperte") mi trovo d'accordo con AMD/ATI..

A me basta e avanza quello visto in Source e Hl2 e seguiti o derivazioni.
Tra l'altro, almeno da me, L4D sfrutta a dovere i dual core e quando serve la fisica è veramente riuscita (tipo atterraggio di fortuna dell'aereoplano, ecc..)

Secondo me dovrebbero essere tutte e due le tecnologie degli standard, e di fatto supportati da tutti i produttori di schede video.
Poi ci saranno dei videogiochi (o comunque dei SW) che sceglieranno se utilizzare una piuttosto che l'altra tecnologia.

Qua è stato dimostrato come il motore grafico di Assassin's Creed in DX10.1 sia buggato all'infinito, con sfuocature inutili, illuminazione farlocca, e pezzi di scenario che spariscono.

La tesi del complotto la trovo quindi alquanto ridicola, dato che i problemi sono moltissimi.


qua

http://www.hwupgrade.it/forum/showthread.php?t=1875557&page=9

nel prosiequo della discussione (che non hai citato né linkato) è stato dimostrato ben altro: lo riassumo per brevità, ma consiglio a tutti di leggere la discussione completa.
1) gli artefatti riscontrati nell'illuminazione della path dx10.1 riguardavano, una diversa impostazione del'hdr e si potevano correggere semplicemente operando su quel parametro.
2) a detta di ubisoft né quegli artefatti, né gli altri, dovuti ad un bug nell'imlementazione dell AF che non è stato possibile correggere causa ritiro frettoloso (quanto immotivato della patch) non hanno alcuna influenza sull'aumento di orestazioni fatto registrare con HW dx10.1. Nel prosiequo del thread, ovvero la parte che non hai riportato, c'è un link con un'intervista ad uno del team di sviluppo, in cui si afferma che il passaggio di rendering non viene saltato per un bug ma perchè è previsto dalle dx10.1. E che questo passaggio in meno da un aumento di prestazioni di almeno il 20% (in realtà si arriva al 24% per gpu singola).
3) a detta di ubisoft, i maggiori bug si riscontrano, con path dx10.1, con HW dx10 (nVIDIA?)
4) la path dx10 è altrettanto buggata e non permette il corretto funzionamento dell'AA (ci sono link al riguardo)

aggiungi alla tua lista: nVIDIA paga gli sviluppatori per boicottare i competitor e chi acquista i loro prodotti. :D


Nomi e link, o sono tutte panzane.


nomi e link di chi dice che MS boicotta le dx10 o sono tutte panzane :D



Lei boicotta solo il GPGPU Computing e l'utilizzo della fisica nei giochi ;)


il gpgpu, al momento, è allo stato embrionale e AMD ha il suo programma e i suoi tool di sviluppo; snobbare CUDA non significa boicottare il gpgpu ma, semplicemente, evitare di fare un piacere a nVIDIA (e non c'è una sola ragione per cui dovrebbe farlo); la fisica nei giochi? Intendi quella di mirror's edge? :rotfl: :rotfl:



Io mi ricordo di VGA ATI con solo SM 2.0 (tipo X850XT P.E. , non proprio una della preistoria) che attualmente valgono quanto un fermacarte, dato che alcuni giochi senza supporto SM3.0 neppure partono (GRAW, COLiN, Splinter Cell).


caso strano vero? E chissà come mai era necessario il supporto allo sm3.0 per chiamate che si potevano effettuare anche con lo sm2.0? Un po' come gli effetti volumetrici di clear sky (chjiamata dx10 che può essere sostituita da analoga chiamata dx9 senza alcun problema, ma che non permette di attivare alcuni effetti a chi non ha HW dx10). Aggiungi alla tua lista: nVIDIA paga gli sviluppatori per boicottare gli avversari. E aggiungi anche: nVIDIA paga utenti di alcuni forum per fare da testimonial apparentemente imparziali per i loro prodotti (qualcuno ha nominato un tale del forum di anand, per caso, tale R...o & his jets:sofico:



Non mi pare che esistano, invece giochi DX10.1.

non mi pare che esistano giochi dx10



I cheat li ricordo anche da parte ATI:
http://www.xbitlabs.com/news/video/display/20030526040035.html
E la stesa li ha ammessi, quindi stavolta non ci si può nascendere sotto "eh ma non è vero", o simili.


dal tuo stesso link

Anyway, the company claims it will not cheat again with the 3DMark03 and that is definitely a positive piece of information. But what about NVIDIA?

You can download the patch that defeats cheating mechanisms in drivers by NVIDIA and ATI Technologies for Futuremark’s 3DMark03 here.

Vediamo come imbrogliavano ATi e nVIDIA
Sempre dal tuo link

According to ATI’s representative quoted by Beyond3D in their editorial over here, the 1.9% performance gain came from optimization of the two DirectX 9.0 shaders (water and sky) in Game Test 4. ATI rendered the scene exactly as intended by Futuremark, in full-precision floating point.

Vediamo per nVIDIA

http://news.zdnet.co.uk/hardware/0,1000000091,2135501,00.htm?r=1

In the mean time, new ZDNet lab tests show that the scores of Nvidia's latest hardware dropped by between 14 and 22 percent using Futuremark's updated testing software, although at higher

:read:



E giusto recentemente mi ricordo tante belle rocce nel terreno che sparivano dal gioco Far Cry 2, proprio nel tentativo di raggiungere le prestazioni delle G92/GT200 che volavano:
http://en.expreview.com/2008/10/29/catalyst-810-hotfix-kidnapped-stones-in-far-cry-2.html


sempre dal tuo link

The stones are still there and still being rendered, there is simply a semi-transparent output from the shader responsible for rendering said rocks. The processing is still running for said rocks (Both CPU and GPU) but it’s a minor bug, there is no saving of processing power by having transparent rocks, even if they were removed completely they would not account for any jump of FPS.

A truly foolish endeavour to be complaining about a few ethereal rocks, when you are playing a fantastic game. Not only that but it has been fixed by another hotfix after and engineer noticed the problem. Tis a sad day when people play and FPS and notice that the odd rock or two has gone astray.


Poi, oltre ai già citati clipping plane (col 3dmark2002) grazie a i quali NV30 guadagnava, in maniera truffaldina, il 60% circa nel punteggio finalem potremmo parlare delle numerose operazioni di shader detect e replacement, soprattutto a cavallo tra il 2002 ed il 2003, operazione di per sè lecita quando si tratta di ottimizzare per una determinata architettura, ma che non lo è più quando abbassa la precisione di calcolo per ottenere punteggi più elevati nei bench. Ovvero, non puoi far passare un banche dx9 per tale quando utilizzi codice dx8 per farlo girare.


D'altra parte, poi era ATI a rosikare con il gioco Doom 3, chiedendosi se era il caso di tutti quei stencil buffer shadow (Carmack Reverse) e a continuare a supportare OpenGL (all'epoca, le schede ATI erano assolutamente inutilizzabili con tali librerie).


Cos'è, revisionismo storico?.

http://www.azpoint.net/hardware/video/4157/NV30-Vs-R300-parla-Carmack.asp

The R200 path has a slight speed advantage over the ARB2 path on the R300, but only by a small margin, so it defaults to using the ARB2 path for the quality improvements. The NV30 runs the ARB2 path MUCH slower than the NV30 path. Half the speed at the moment. This is unfortunate, because when you do an exact, apples-to-apples comparison using exactly the same API, the R300 looks twice as fast, but when you use the vendor-specific paths, the NV30 wins

per tua informazione, ARB è lo standard OpenGL e ARB2 era lo standard di allora (l'equivalente di una via di mezzo tra dx8.1 e dx9). R300, assolutamente inutilizzabile con tali librerie, andava, in ARB2, il doppio esatta di NV30 (una scheggia in OpenGL :sofico: ). Tanto che Carmack ha dovuto scrivere una path apposita (chiamata appunto NV30), per pareggiare i conti.


Speriamo stavolta capiscano.

già.

Tanto che Carmack ha dovuto scrivere una path apposita (chiamata appunto NV30), per pareggiare i conti.

Il gioco non è uscito con Path nv30 eppure Nvidia aveva un vantaggio soprattutto con FSAA in ARB2, penso dovuto all'ottimizzazione (ma tu dirai che i driver compilavano il codice in PP e Fixed).
Detto questo non penso ci sia una ditta assolutamente buona e una assolutamente truffaldina, la questione degli standard è complessa e raramente monotematica, alla fine i programmatori sceglieranno, imho, la più fruibile e quella che fa lavorare di meno.

Il gioco non è uscito con Path nv30 eppure Nvidia aveva un vantaggio soprattutto con FSAA in ARB2, penso dovuto all'ottimizzazione (ma tu dirai che i driver compilavano il codice in PP e Fixed).
Detto questo non penso ci sia una ditta assolutamente buona e una assolutamente truffaldina, la questione degli standard è complessa e raramente monotematica, alla fine i programmatori sceglieranno, imho, la più fruibile e quella che fa lavorare di meno.

Il gioco è uscito in arb ma non col la versione originaria ma con quella adattata alla path NV30: quindi, di fatto un arb2 che, pur mantenendosi entro gli standard, andava incontro alle esigenze dell'architettura di NV30: istruzioni INT dove possibile o, al massimo fp16, riordinate ottimizzando per l'architetura NV, ovvero math, text, text). Col codice originario, ovvero arb2 senza ottimizzazioni per alcuno, i risultati erano quelli riportati nell'articolo, ovvero R300 il doppio più veloce di NV30: gli stessi che si verificavano, del resto con codice dx9. Il vantaggio con FSAA dipendeva dal fatto che Carmack aveva adottato una modalità di rendering che prevedeva, prima di tutto, il riempimento dello z-buffer (su cui si eseguono i calcoli relativi al MSAA box). In tal modo, le rop's di NV30 traevano un enorme vantaggio avendo un output doppio rispetto a quello delle rop's di R300 (la branca preposta ad eseguire color ops è in grado di eseguire anche z-ops su NV30, mentre su R300 le due eseguono solo color e z-ops rispettivamente). Quindi, se con una modalità di rendering normale, R300 avrebbe avuto dei vantaggi poichè riempiva contemporaneamente z e color buffer più velocemente di quanto non fosse in grado di fare NV30, avendo il doppio delle rop's, con la modalità scelta da carmack, NV30 riempiva lo z-buffer molto prima di R300 e risultava più rapido nel calcolare il MSAA. Anche questa modalità di rendering, inizialmente, era prevista solo nella path NV30 ma poi è stata adottata per la modalità standard con cui è uscito il gioco.

La questione degli standard è complessa semplicemente perchè spesso non ci si attiene alle regole e si preferisce lesinare sugli investimenti. Il caso NV30 è stato emblematico: nVIDIA ha puntato su un'architettura vecchia (quella di NV2x) con l'aggiunta 4 unità FP, per altro non indipendenti dalle tmu e di un numero di registri costanti (oltre le specifiche dx9) e temporanei (decisamente al di sotto delle specifiche dx9). I primi servivano a ridurre le latenze, i secondi sarebbero dovuti servire a svolgere più operazioni in contemporanea. Il loro numero insufficiente (in realtà era insufficiente solo quando si operava in fp e, in particolare, in fp32), è stato uno dei motivi del fallimento di quel progetto (NV30 aveva anche il problema di non poter eseguire contemporaneamente operazioni di testuring ed operazioni matematiche in floating point, problema in parte corretto su NV35, con la sostituzione delle minialu di tipo INT con minialu di tipo FP)

qua

http://www.hwupgrade.it/forum/showthread.php?t=1875557&page=9

nel prosiequo della discussione (che non hai citato né linkato) è stato dimostrato ben altroUna serie di giustificazioni, ma il fatto rimane: il motore grafico in DX10.1 è buggato. Ciò conferma la scelta di Ubisoft di rimuoverlo.
Inoltre, alquanto strano il fatto tu voglia far credere che il numero maggiori di bug sia con GPU NVID*A: tali problemi da me/loro citati (come le cascate di sabbia che scompaiono, o il tutto sfuocato, per citarne due fra i tanti) si riferiscono infatti a schede DX10.1 di AT*.

aggiungi alla tua lista: nVIDIA paga gli sviluppatori per boicottare i competitor e chi acquista i loro prodotti. :D Questa è pesante.

nomi e link di chi dice che MS boicotta le dx10 o sono tutte panzane :D Perchè, le boicotta?

snobbare CUDA non significa boicottare il gpgpu ma, semplicemente, evitare di fare un piacere a nVIDIA (e non c'è una sola ragione per cui dovrebbe farlo)Non si tratta di snobbare CUDA, ma di snobbare PH*SX, che è diverso.
Ricordo che PH*SX era di una azienda esterna a NVID*A, percui non sarebbe così strano supportare le sue librerie.
Così come non è strano supportare gli EAX di Creat*ve, oppure le DirectX di M*crosoft.
A questi punti è però strano supportare HAV*K che è ugualmente di una azienda concorrente (Int*l).
Si chiama rispetto verso i propri clienti.

la fisica nei giochi? Intendi quella di mirror's edge? :rotfl: :rotfl: Dalle mie parte si dice "piuttosto che niente, meglio il piuttosto".
Dalle tue, presumo ci siano tanti alti vitigni...

caso strano vero? E chissà come mai era necessario il supporto allo sm3.0 per chiamate che si potevano effettuare anche con lo sm2.0? Un po' come gli effetti volumetrici di clear sky (chjiamata dx10 che può essere sostituita da analoga chiamata dx9 senza alcun problema, ma che non permette di attivare alcuni effetti a chi non ha HW dx10).E' tutto un gomplotto ("alla B*scardi"), ma pensa te.
Perchè non scrivevano il gioco direttamente in DX7? Torniamo indietro, invece che avanti.

Aggiungi alla tua lista: nVIDIA paga gli sviluppatori per boicottare gli avversari.Una tua affermazione davvero poco carina.

E aggiungi anche: nVIDIA paga utenti di alcuni forum per fare da testimonial apparentemente imparziali per i loro prodotti (qualcuno ha nominato un tale del forum di anand, per caso, tale R...o & his jets:sofico: Apperò quante ne sai.

non mi pare che esistano giochi dx10 Oihbò! E pensa che c'è chi vuole venderci a tutti i costi VGA DX10.1

dal tuo stesso link
Anyway, the company claims it will not cheat again with the 3DMark03 and that is definitely a positive piece of information. But what about NVIDIA?

You can download the patch that defeats cheating mechanisms in drivers by NVIDIA and ATI Technologies for Futuremark’s 3DMark03 here.

Vediamo come imbrogliavano ATi e nVIDIA
Sempre dal tuo link

According to ATI’s representative quoted by Beyond3D in their editorial over here, the 1.9% performance gain came from optimization of the two DirectX 9.0 shaders (water and sky) in Game Test 4. ATI rendered the scene exactly as intended by Futuremark, in full-precision floating point.

Vediamo per nVIDIA

http://news.zdnet.co.uk/hardware/0,1000000091,2135501,00.htm?r=1

In the mean time, new ZDNet lab tests show that the scores of Nvidia's latest hardware dropped by between 14 and 22 percent using Futuremark's updated testing software, although at higher

:read: Mal comune mezzo gaudio? Sono citate entrambe

sempre dal tuo link
The stones are still there and still being rendered, there is simply a semi-transparent output from the shader responsible for rendering said rocks. The processing is still running for said rocks (Both CPU and GPU) but it’s a minor bug, there is no saving of processing power by having transparent rocks, even if they were removed completely they would not account for any jump of FPS.
A truly foolish endeavour to be complaining about a few ethereal rocks, when you are playing a fantastic game. Not only that but it has been fixed by another hotfix after and engineer noticed the problem. Tis a sad day when people play and FPS and notice that the odd rock or two has gone astray.
Con l'hotfix di AT* si guadagnavano qualche FPS e le rocce sparivano, mentre con l'hotfix dell'hotfix si perdevano i FPS guadagnati e le rocce tornavano a galla.
C'è poco da raccontarci.

potremmo parlare delle numerose operazioni di shader detect e replacement, soprattutto a cavallo tra il 2002 ed il 2003Faccio volentieri a meno di parlare di problemi inerenti 6 anni fa.

Cos'è, revisionismo storico?.

http://www.azpoint.net/hardware/video/4157/NV30-Vs-R300-parla-Carmack.asp

The R200 path has a slight speed advantage over the ARB2 path on the R300, but only by a small margin, so it defaults to using the ARB2 path for the quality improvements. The NV30 runs the ARB2 path MUCH slower than the NV30 path. Half the speed at the moment. This is unfortunate, because when you do an exact, apples-to-apples comparison using exactly the same API, the R300 looks twice as fast, but when you use the vendor-specific paths, the NV30 wins

per tua informazione, ARB è lo standard OpenGL e ARB2 era lo standard di allora (l'equivalente di una via di mezzo tra dx8.1 e dx9). R300, assolutamente inutilizzabile con tali librerie, andava, in ARB2, il doppio esatta di NV30 (una scheggia in OpenGL :sofico: ). Tanto che Carmack ha dovuto scrivere una path apposita (chiamata appunto NV30), per pareggiare i conti. Sembra tu abbia un gusto particolare nel parlare di problemi di 6 anni fa.
Ma lo sai che siamo andati avanti? Che sono cambiate le cose?
Poi, non capisco perchè le cose le dici a metà, e solo quello che ti torna più comodo.
Ti è così difficile essere obiettivo?
Il problema della ARB è che costringeva le VGA NVID*A in FP32 (che a quell'epoca era improponibile, già il FP24 era miracoloso) e a non sfruttare le loro ottimizzazioni interne (misto di FP12, FP16, FP24). Invece R300 (che come architettura era anche più rigida) con l'ARB andava a FP24. Grazie che c'era il performance hit fra i due.
Comunque con il path NV20 oppure le VGA della serie 6 (in cui tale problema era risolto), ma anche i driver successivi, il gioco volava.
Ti sei poi dimenticato di dire che le VGA NVID*A avevano la tecnologia UltraShadow (II), appunto, una loro ottimizzazione hardware, e assolutamente da sfruttare proprio in giochi come Doom3 che utilizzano ampiamente Stencil Buffer e calcoli con Z Buffer.
http://www.nvidia.com/object/feature_ultrashadow2.html
La cosa più incredibile di tutto ciò è comunque che tu voglia far passare Doom 3 come più veloce sulle AT*, e come il supporto AT* OpenGL di 6 anni come più avanzato di quello NVID*A. Su tali affermazioni rimango basito e senza la forza per replicare, sarebbe come cercar di far credere che aveva ragione Tolomeo.

Solo una domanda (tanto siamo in ot): MiKeLezZ hai postato un link per far vedere "Fatto: Con l'hotfix di ATI si guadagnavano qualche FPS e le rocce sparivano" ovviamente sono andato a curiosare ma ingrandendo la foto incriminata le rocce ci sono (cambia il colore come se fossero sporche i fango o altro ed in effetti anche gli altri utenti in quel post hanno la stessa mia impressione), la domanda è quindi (non è polemica ma voglia di capire) il trucco in cosa è consistito per ottenere il guadagno dei frames ?

Mike veramente sei te che hai tirato fuori la storia degli SM2 che non eprmettevano di far aprytire giochi SM3 (che giravano mi pare tranquillamente però su Xbox )...o sbaglio a ricordare io?

Una serie di giustificazioni, ma il fatto rimane: il motore grafico in DX10.1 è buggato. Ciò conferma la scelta di Ubisoft di rimuoverlo.


asolutamente no: i bug si correggono, non si rimuove la path. Inoltre anche il motore dx10 è buggeto (niente msaa); la cosa è riportata anche nei link della discussione che hai omesso di postare.


Inoltre, alquanto strano il fatto tu voglia far credere che il numero maggiori di bug sia con GPU NVIDIA: tali problemi da me/loro citati (come le cascate di sabbia che scompaiono, o il tutto sfuocato, per citarne due fra i tanti) si riferiscono infatti a schede DX10.1 di ATI.

a parte il fatto che il link a cui fai riferimento sono stato io a ppostarlo (vale la pena di ricordarlo), in ogni caso non sono io a far credere qualcosa ma è quello che sostiene ubisoft (leggere gli altri link sempre della solita discussione)


Questa se la legge il country manager, gli potrebbero girare...


e al popolo? On line girano non solo voci ma anche cifre. Vere? False? Per ora sono li e non sono state smentite se non in maniera blanda e poco convincente. Il fatto è che né ubisoft né nVIDIA hanno risposto a precise domande poste da più di qualche sito specializzato sul ritiro della path dx10.1.


Le boicotta?

Non si tratta di snobbare CUDA, ma di snobbare PHYSX.
Ricordo che PHYSX era di una azienda esterna a NVIDIA, percui non sarebbe così strano supportare le sue librerie.
Così come non è strano supportare gli EAX di Creative, oppure le DirectX di Microsoft.
Si chiama rispetto verso i propri clienti.


physx adesso è di nVIDIA e non vedo perchè AMD dovrebbe aiutare nVIDIA. Spiegamelo, se ti riesce.


Dalle mie parte si dice "piuttosto che niente, meglio il piuttosto".
Dalle tue, presumo ci siano tanti alti vitigni...


se il vino fa schifo, preferisco bere acqua :D


E' tutto un gomplotto (alla Biscardi), ma pensa te.
Perchè non scrivevano il gioco direttamente in DX7? Torniamo indietro, invece che avanti.


allora perchè no fare lo stesso con le dx10.1? Ah già, allora a rimetterci è nVIDIA :D


Qua la pressione sale al nostro amico responsabile...



problema suo: la cosa è certa, il nome del tizio è di pubblico dominio e qualche anno fa uscirono svariati articoli ed editoriali sull'argomento, puntando l'indice contro nVIDIA ed Intel in particolare. Documentati


NVIDIA pagava una azienda esterna di marketing, la quale faceva viral marketing nei forum (il famoso Focus Group), pagando in merchandising NVIDIA (M/B, VGA, RAM), questo è dominio pubblico e nulla di cui scandalizzarsi (ci sono altrettanti blog che si potrebbero credere come imparziali, ed invece non sono altro che operazioni di marketing).
Spero che anche ATI paghi alcuni utenti dei forum, e lo dico per loro, più che altro :)
Poi, non serve andare a cercare gli utenti, tante review sono palesemente orchestrare per sviolinare l'una o l'altra (basta infarcire qualche minchiatina tecnica per confondere, e poi si può raccontare quel che si vuole :) ).



quindi è normale che qualcuno paghi gente che si fa passare per comuni utenti, per propagamdare i propri prodotti. Sei pronto a giustificare qualunque cosa faccia nVIDIA, vero? Chissà cosa ne pensano gli altri utenti di questo forum.



Fatto: Imbrogliavano entrambe
Fatto: NVIDIA era più brava nell'ottimizzazione del codice
Fatto: Tali ottimizzazioni poi sono quelle che vediamo nei giochi, e che anche qui fanno, da sempre, sia ATI che NVIDIA
Quindi?



fatto, un 2% di guadagno con delle ottimizzazioni è fisiologico; il 20% non lo è; quindi quelle ottimizzazioni sono, quanto meno sospette; come tante altre di cui si è ampiamente parlato



Fatto: Con l'hotfix di ATI si guadagnavano qualche FPS e le rocce sparivano
Fatto: con l'hotfix dell'hotfix di ATI si perdevano i FPS guadagnati e le rocce tornavano a galla
Che altro c'è da raccontarci.



che se rinomino un neseguibile rendo impossibile al compilatore riconoscere il sw e riordinare il codice. Parlo di cose a te ignote?


Faccio volentieri a meno di parlare di problemi inerenti 6 anni fa.



:rotfl: :rotfl: :rotfl: :rotfl:
infatti, per dimostrare che ATi imbrogliava hai riporato un articolo relativo al 3dmark2003 (in cui, per altro, risulta che nVIDIA imbroglia ben più di ATi)


Sembra tu abbia un gusto particolare nel parlare di problemi di 6 anni fa.
Ma lo sai che siamo andati avanti? Che sono cambiate le cose?
Poi, non capisco perchè le cose le dici a metà, e solo quello che ti torna più comodo.
Ti è così difficile essere obiettivo?
Il problema della ARB è che costringeva le VGA NVIDIA in FP32 (che a quell'epoca era improponibile, già il FP24 era miracoloso) e a non sfruttare le loro ottimizzazioni interne (misto di FP12, FP16, FP24). Invece R300 con l'ARB andava a FP24. Grazie che c'era il performance hit fra i due.
Comunque con il path NV20 oppure le VGA della serie 6 (in cui tale problema era risolto) il gioco volava.
Ti sei poi dimenticato di dire che le VGA NVIDIA avevano la tecnologia UltraShadow (II), appunto, una loro ottimizzazione hardware, e assolutamente da sfruttare proprio in giochi come Doom3 che utilizzano ampiamente Stencil Buffer e calcoli con Z Buffer.
http://www.nvidia.com/object/feature_ultrashadow2.html


NV30 era un chiodo anche in fp16; NV35 un po' meglio di NV30 in fp16 ma sempre molto più lento di R300. Questi sono fatti. La path NV20 fa uso di fixed function. La tecnologia ultrashadow è solo una minima parte delle ottimizzazione che carmack ha fatto per far funzionare in modo decente NV30 e derivati. L'arb2 non forzava fp32 ma prevedeva calcoli in fp16 ed fp32. Quinndi evitiamo di dire stupidaggini.

Sui fatti di sei anni fa ti rimando a qualche riga più in alto. Non osno io a non essere obietivo, sei tu che hai il loghetto di nVIDIA tatuato nel cervello.


La cosa più incredibile di tutto ciò è comunque che tu voglia far passare Doom 3 come più veloce sulle ATI, e come il supporto ATI OpenGL di 6 anni come più avanzato di quello NVIDIA. Io su tali affermazioni non mi viene neppure la forza di rispondere.

ho riportato le parole testuali di carmack. Che altro c'è da aggiungere

Ah, si: evita di quotarmi ancora con post inutili come questo. Ho cose più importanti da fare che perdere tempo con queste stupidaggini e con le tue battaglie personali

hai capito bene; non c'era alcun bisogno di farli sparire dal video senza physx: era sufficiente non simulare quall'assurdo quanto innaturale movimento che manifestano nel video con physx. Non serve sparare a festoni o vetrate per conoscere le leggi fisiche e rendersi conto se una simulazione è ben fatta o no. La senzazione che sdi ha, a parte la direzione del movimento che spesso non ci azzecca niente, è che tutto si muova e voli via con troppa "leggerezza" come se non avesse peso e non opponesse la minima resistenza.



noti male, oppure mi spieghi il senso di questo



E ci aggiungo una domanda: secondo te quelle simulazioni sono ben fatte e realistiche?

Il senso di ciò che ho detto è molto semplice, non avendo mai osservato nella realtà il comportamento di quegli oggetti in quelle situazioni (sia io che tu da quanto ho capito) diventa difficile, se non ha naso, valutare quanto sia realistica la loro simulazione.

nessun fraintendimento: mi sono limitato a commentare ciò che hai letteralmente affermato. Effetti cinematografici non significa effetti spettacolari. Vetrate che si spaccano come fossero fatte di carta velina e festoni che si muovono animati da vita propria non sono effetti cinematografici e neppure spettacolari. Per la cronaca, di vetrine rotte ne ho viste diverse, ma nessuna con quegli effetti "cinemantografici": neppure al cinema :D

Eppure, almeno dalle mie parti, l'uso dell'espressione "effetti cinematografici" in quest'accezione è di uso comune.
Comunque non mi sembra il caso discutere di semantica.

la tua tesi decade dal momento che anche intel è concorrente quanto e forse più di nVIDIA per AMD. AMD produce sia gpu che cpu e cerca di vendere entrambe, esattamente come intel.

In effetti AMD deve cercare di spingere anche dulle CPU oltre che sulle GPU, ma questo non inficia la mia tesi, tuttalpiù la amplia.

certo, come successo per assassin's creed; in quel caso l'esperienza degli utenti amd migliorava troppo e la cosa non è andata giù a qualcuno :D .
Guarda caso, c'è anche l'intervista ad uno sviluppatore di ubisoft che si è lasciato sfuggire a mezza bocca che in dx10.1 il famoso passaggio di rendering che saltava per errore non era, in realtà un errore ma rientrava nell'ordine delle cose. E guarda caso, tutti i motori che implentano MSAA con deferred rendering fanno uso del pesante render to texture invece di ricorrere al MRT (molto più naturale).

Non ricordo di un intervista, io ricordo di un post sul forum di ubisoft da parte di uno sviluppatore, dove effettivamente si diceva che vi era un problema con un effetto di post-processing che veniva saltato.
Dato che credi che NVIDIA spinga gli sviluppatori a non adottare tecniche che migliorino l'esperienza con hardware della concorrenza non ti sei chiesto come mai non abbia obbligato gli sviluppatori a non sviluppare o non pubblicare nemmeno il supporto alle DX10.1?
Perché molti sviluppatori accetterebbero di subire queste imposizioni?

ci sono anche importanti sviluppatori che sostengono sia nVIDIA a spingere le SWHouse del programma TWIMTBP a boicottare le dx10.1. D'altra parte non fa piacere vedere una costosa 280 GTX, a risoluzioni non frame buffer bounded, al livello di una modesta 4850 con AA 4x :D
Di sicuro non è AMD a boicottarle.

Infatti a molti sviluppatori piace l'idea di essere obbligati a produrre software che sfavorisca parte di chi lo utilizzerà, offrendo un esperienza peggiore di quella che poteva essere ottenuta anche con maggior semplicità.
Saranno tutti masochisti.

non mi risulta; se hai prove da portare a supporto della tua tesi fallo; piuttosto mi ricordo di titoli che non partivano su hw dx9b, senza alcun motivo (solo chiamate tranquillamente emulabili anche con le dx9a, come accade con le dx10 e le texture array di clear sky). E mi ricordo delle guerre di "religione" fatte da nVIDIA contro futuremark (e dei cheat via driver per raddoppiare il punteggio dei 3dmark con il taglio delle superfici nascoste che non venivano renderizzate affatto) e contro valve che si era permessa di utilizzare dx9 senza sbattersi per tirare fuori una path che permettesse a nv35 di utlizzare quel po' di codice fp16 che il numero limitato di registri e la limitata autonomia delle alu permetteva di usare.

Che + o - la metà dell'hardware disponibile hai giocatori non supportasse le DX9.0c, mi sembra una limitazione sufficiente(come avviene adesso con le 10.1).
I cheat via driver per aumentare le prestazioni con 3Dmark li ricordo anche per ATI.
Non vorrai mica difendere Futuremark che offriva supporto a pagamento, quindi le aziende che pagavano potevano vedere il loro hardware ottenere risultati migliori, bel modo di fare per un azienda che produce benchmark.
Ricordo anche di un certo Doom 3...

prova a spiegare il concetto ai fanboy
Ci provo continuamente.

physx adesso è di nVIDIA e non vedo perchè AMD dovrebbe aiutare nVIDIA. Spiegamelo, se ti riesce.

Si ma allora, perché AMD dovrebbe aiutare Intel, dato che Havok è suo, se come mi hai appena detto:

intel è concorrente quanto e forse più di nVIDIA per AMD.

Il gioco è uscito in arb ma non col la versione originaria ma con quella adattata alla path NV30: quindi, di fatto un arb2 che, pur mantenendosi entro gli standard, andava incontro alle esigenze dell'architettura di NV30: istruzioni INT dove possibile o, al massimo fp16, riordinate ottimizzando per l'architetura NV, ovvero math, text, text). Col codice originario, ovvero arb2 senza ottimizzazioni per alcuno, i risultati erano quelli riportati nell'articolo, ovvero R300 il doppio più veloce di NV30: gli stessi che si verificavano, del resto con codice dx9. Il vantaggio con FSAA dipendeva dal fatto che Carmack aveva adottato una modalità di rendering che prevedeva, prima di tutto, il riempimento dello z-buffer (su cui si eseguono i calcoli relativi al MSAA box). In tal modo, le rop's di NV30 traevano un enorme vantaggio avendo un output doppio rispetto a quello delle rop's di R300 (la branca preposta ad eseguire color ops è in grado di eseguire anche z-ops su NV30, mentre su R300 le due eseguono solo color e z-ops rispettivamente). Quindi, se con una modalità di rendering normale, R300 avrebbe avuto dei vantaggi poichè riempiva contemporaneamente z e color buffer più velocemente di quanto non fosse in grado di fare NV30, avendo il doppio delle rop's, con la modalità scelta da carmack, NV30 riempiva lo z-buffer molto prima di R300 e risultava più rapido nel calcolare il MSAA. Anche questa modalità di rendering, inizialmente, era prevista solo nella path NV30 ma poi è stata adottata per la modalità standard con cui è uscito il gioco.

La questione degli standard è complessa semplicemente perchè spesso non ci si attiene alle regole e si preferisce lesinare sugli investimenti. Il caso NV30 è stato emblematico: nVIDIA ha puntato su un'architettura vecchia (quella di NV2x) con l'aggiunta 4 unità FP, per altro non indipendenti dalle tmu e di un numero di registri costanti (oltre le specifiche dx9) e temporanei (decisamente al di sotto delle specifiche dx9). I primi servivano a ridurre le latenze, i secondi sarebbero dovuti servire a svolgere più operazioni in contemporanea. Il loro numero insufficiente (in realtà era insufficiente solo quando si operava in fp e, in particolare, in fp32), è stato uno dei motivi del fallimento di quel progetto (NV30 aveva anche il problema di non poter eseguire contemporaneamente operazioni di testuring ed operazioni matematiche in floating point, problema in parte corretto su NV35, con la sostituzione delle minialu di tipo INT con minialu di tipo FP)

Doom3 è uscito in ARB2 su r300 e nv30, il path specifico è stato segato, un po' come successo in Hl2.
Che poi sia un motore più favorevole a Nvidia fuori di dubbio.
Comunque ho capito che ne sai, ma bastavano 2 righe di risposta, se ogni volta ci mettiamo a fare lo storico del perchè Nv30 era un progetto poco riuscito..
La questione degli standard, secondo me, va oltre le visioni complottistiche, ma semplicemente si basano sui numeri, tanto che ai tempi era standard usare fp24 (per nvidia fp32) e Nvidia pagava alla grande in termini di perfomance (mentre in fp16 era solo il 20-30% più lenta), ma sinceramente io vedo solo questioni commerciali.
E' di oggi che XFX farà Ati, mentre anche blizzard sembra supportare più Amd di un tempo, e se si guardano i numeri Amd sta recuperando mercato, tra Havok Intel e Pshyx Nvidia vedo nettamente meglio posizionato il primo, anche se io ripeto, tutta sta corsa si potrebbe fare sfruttando i core della cpu, basta vedere le console che fanno cose impressionanti semplicemente perchè sfruttate molto, ma molto meglio.

In effetti AMD deve cercare di spingere anche dulle CPU oltre che sulle GPU, ma questo non inficia la mia tesi, tuttalpiù la amplia.


proprio perchè deve spingere anche le cpu può adottare una politica di alleanza che le permetta di seguire questa linea; e nVIDIA non può offrire nulla in cambio.



Non ricordo di un intervista, io ricordo di un post sul forum di ubisoft da parte di uno sviluppatore, dove effettivamente si diceva che vi era un problema con un effetto di post-processing che veniva saltato.
Dato che credi che NVIDIA spinga gli sviluppatori a non adottare tecniche che migliorino l'esperienza con hardware della concorrenza non ti sei chiesto come mai non abbia obbligato gli sviluppatori a non sviluppare o non pubblicare nemmeno il supporto alle DX10.1?
Perché molti sviluppatori accetterebbero di subire queste imposizioni?



se c'è stato è stato ampiamente smpentito. Le dx10.1 prevedono un passaggio in meno nell'utilizzo di MSAA con deferred rendering. Questo è un fatto ed è quello che avveniva con la path incriminata, come ha riconosciuto la stessa ubisoft, aggiungendo che i bug non inficiavano questo incremento prestazionale che, quindi, una volta eventualmente corretti i bug sarebbe restato immutato. In uno dei link che ho postato nella discussione linkata in precedenza, c'è l'intervista ad uno sviluppatore di ubisoft che afferma proprio quanto ho appena riportato. La storia del passaggio in meno per errore è solo fuffa e, guarda caso, il passaggio in meno lo faceva solo con HW dx10.1 e non con HW dx10 (le cui prestazioni restano invariate).



Infatti a molti sviluppatori piace l'idea di essere obbligati a produrre software che sfavorisca parte di chi lo utilizzerà, offrendo un esperienza peggiore di quella che poteva essere ottenuta anche con maggior semplicità.
Saranno tutti masochisti.



prova a chiederlo a loro; implementare il MSAA su un engine di tipo deferred ha come soluzione più semplice, più logica e veloce, l'utilizzo di più render target per lo z-buffer. Soluzione che, stranamente, nessuno ha ancora adottato, ricorrendo al più macchinoso render tot texture o, al massimo, come in farcry2 all'utilizzod i un color buffer inizializzato come z-buffer: insomma tutte soluzioni DX10 che non danno alcun vantaggio ad HW dx10.1.
In clear sky si è pensato al'utilizzo di testure array (dx10) per il fumo volumetrico, ma non al cube map array (dx10.1) per l'illuminazione. Strano ma vero :D



Che + o - la metà dell'hardware disponibile hai giocatori non supportasse le DX9.0c, mi sembra una limitazione sufficiente(come avviene adesso con le 10.1).


della serie DUE PESI DUE MISURE? In passato si è tagliato il supporto ad HW sm2.0 perchè supportato dalla metà degli utenti, adesso non si utilizza il supporto ad HW dx10.1 perchè utilizzato da metà degli utenti: guarda caso sempre la stessa metà :rolleyes:



I cheat via driver per aumentare le prestazioni con 3Dmark li ricordo anche per ATI.
Non vorrai mica difendere Futuremark che offriva supporto a pagamento, quindi le aziende che pagavano potevano vedere il loro hardware ottenere risultati migliori, bel modo di fare per un azienda che produce benchmark.
Ricordo anche di un certo Doom 3...


ho rioportato anche le percentuali: il 2% per ATi in 20% per nVIDIA. Ed è solo uno dei tanti casi. Non vorrai mica difendere chi fa driver cheating?
Anche io ricordo di un certo doom3 ritagliato sull'architettura di NV30



Ci provo continuamente.

ottimo impegno

Si ma allora, perché AMD dovrebbe aiutare Intel, dato che Havok è suo, se come mi hai appena detto:

perchè, evidentemente, nel rapporto con Intel ha più da guadagnarci che da quello con nVIDIA. Perchè deve spingere la vendita delle sue cpu (le gpu si vendono bene da sole); perchè non è certo che la fisica nei giochi (non le simulazioni fisiche di tipo gpgpu, quelle sono un'altra cosa), passerà attraverso la gpu, visto che quest'ultima sarà sempre più carica di lavoro mentre le cpu avranno sempre meno cose da fare.


Doom3 è uscito in ARB2 su r300 e nv30, il path specifico è stato segato, un po' come successo in Hl2.
Che poi sia un motore più favorevole a Nvidia fuori di dubbio.
Comunque ho capito che ne sai, ma bastavano 2 righe di risposta, se ogni volta ci mettiamo a fare lo storico del perchè Nv30 era un progetto poco riuscito..
La questione degli standard, secondo me, va oltre le visioni complottistiche, ma semplicemente si basano sui numeri, tanto che ai tempi era standard usare fp24 (per nvidia fp32) e Nvidia pagava alla grande in termini di perfomance (mentre in fp16 era solo il 20-30% più lenta), ma sinceramente io vedo solo questioni commerciali.
E' di oggi che XFX farà Ati, mentre anche blizzard sembra supportare più Amd di un tempo, e se si guardano i numeri Amd sta recuperando mercato, tra Havok Intel e Pshyx Nvidia vedo nettamente meglio posizionato il primo, anche se io ripeto, tutta sta corsa si potrebbe fare sfruttando i core della cpu, basta vedere le console che fanno cose impressionanti semplicemente perchè sfruttate molto, ma molto meglio.

doom3, a detta dello stesso carmack, è stato tagliato e cucito su misura sull'aHW dell'NV30 (su cui ha ammesso di aver sviluppato e per cui ha ottimizzato). Come d'altra parte, valve ha scritto codice dx9 senza preoccuparsi di ottimizzare per chi quel codice non lo digeriva ma obbligando i chip NV ad utilizzare codice dx8 (con cui, per altro, andavano decisamente meglio).
Sul discorso havok-intel vs physx-nVIDIA, anche io vedo in vantaggio i primi: sia per il supporto che intel può vantare dagli sviluppatori e sia per il fatto che il futuro della fisica nei giochi potrebbe non passare attraverso le gpu

se c'è stato è stato ampiamente smpentito. Le dx10.1 prevedono un passaggio in meno nell'utilizzo di MSAA con deferred rendering. Questo è un fatto ed è quello che avveniva con la path incriminata, come ha riconosciuto la stessa ubisoft, aggiungendo che i bug non inficiavano questo incremento prestazionale che, quindi, una volta eventualmente corretti i bug sarebbe restato immutato. In uno dei link che ho postato nella discussione linkata in precedenza, c'è l'intervista ad uno sviluppatore di ubisoft che afferma proprio quanto ho appena riportato. La storia del passaggio in meno per errore è solo fuffa e, guarda caso, il passaggio in meno lo faceva solo con HW dx10.1 e non con HW dx10 (le cui prestazioni restano invariate).

Leggiti i bugfix dell'ultima patch di Assasin's Creed, Ubisoft parla proprio di "broken effect" con DX10.1, prima che venisse fuori tutta questa storia, alcuni notarono una qualità grafica migliorata quando, con le DX10.1 veniva attivato l'AA che andava aldilà dei benefici che questo filtro può portare, questo proprio perché veniva saltato un effetto "post-processing", potrei stilarti una lista più lunga de "I fratelli Karamàzov" di giochi la cui grafica migliora disattivando o attenuando gli effetti "post-processing", perché questi vengono implementati in modo vistosamente esagerato solo per aumentare la "spettacolarità" della grafica.

prova a chiederlo a loro; implementare il MSAA su un engine di tipo deferred ha come soluzione più semplice, più logica e veloce, l'utilizzo di più render target per lo z-buffer. Soluzione che, stranamente, nessuno ha ancora adottato, ricorrendo al più macchinoso render tot texture o, al massimo, come in farcry2 all'utilizzod i un color buffer inizializzato come z-buffer: insomma tutte soluzioni DX10 che non danno alcun vantaggio ad HW dx10.1.
In clear sky si è pensato al'utilizzo di testure array (dx10) per il fumo volumetrico, ma non al cube map array (dx10.1) per l'illuminazione. Strano ma vero :D

Appunto, prima di dire che sono stati plagiati da NVIDIA sarebbe meglio chiedere a loro il perché delle loro scelte tecniche.

della serie DUE PESI DUE MISURE? In passato si è tagliato il supporto ad HW sm2.0 perchè supportato dalla metà degli utenti, adesso non si utilizza il supporto ad HW dx10.1 perchè utilizzato da metà degli utenti: guarda caso sempre la stessa metà :rolleyes:


Io mi riferivo a sm3.0, non a caso ho scritto DX9.0c.
Dimentichi R420 e derivati? non hanno ostacolato l'uso dello sm3.0 da parte degli sviluppatori?
ATI a quel tempo non sosteneva che era sufficiente fp24, è fp32 era praticamente inutile?
Oppure questo caso non conta?
Poi proprio non capisco il tuo commento "DUE PESI DUE MISURE".

Io mi riferivo a sm3.0, non a caso ho scritto DX9.0c.
Dimentichi R420 e derivati? non hanno ostacolato l'uso dello sm3.0 da parte degli sviluppatori?
Oppure questo caso non conta?
Poi proprio non capisco il tuo commento "DUE PESI DUE MISURE".

allora, ricominciamo:
hai quotato un amia frase in cui dicevo che non c'era alcuna ragione tecnica per cui dei giochi non partissero con HW dx9b, se non la scarsa voglia (le cui motivazini non sto a sindacare) di fare patch che abilitassero le stesse funzionalità dx9c in modo che potessero essere riprodotte tramite dx9b.

In risposta aciò, affermi che più o meno metà dei giocatori avevano HW che non supportava dx9c e questa era una limitazione più che sufficiente, come adesso con le dx10.1.Allora, devo dedurre che non hai capito il senso del discorso. Provo con uno schema.
A supporta le dx9c; B supporta le DX9b; escono giochi dx9c che non partono su B.
A supporta le dx10; B supporta le dx10.1; non escono giochi dx10.1 ma solo qualche patch dx10 in modo che giri sia su A che su B.

Nel primo caso B non ha ostacolato un bel niente ed, anzi, è stata danneggiata. Nel secondo caso A sta ostacolando il "progresso" (termine pomposo per semplici giochi, ma visto che qualcuno l'ha chiamato così mi adeguo).

Immagina cosa sarebbe successo se qualcuno avesse, ad esempio, implementato l'illuminazione dinamica tramite cube map array (che non funziona su gpu nVIDIA), precludendo a tutti gli utenti di quel marchio di usufruire di illuminazione dinamica (riproducibile anche in dx10), come è stato per il fumo volumetrico e le dx9 in clear sky. E parlo di un effetto non attivabile, non di un gioco che non parte.

Chiaro adesso il perchè di due pesi due misure?

prova a chiederlo a loro; implementare il MSAA su un engine di tipo deferred ha come soluzione più semplice, più logica e veloce, l'utilizzo di più render target per lo z-buffer. Soluzione che, stranamente, nessuno ha ancora adottato, ricorrendo al più macchinoso render tot texture o, al massimo, come in farcry2 all'utilizzod i un color buffer inizializzato come z-buffer: insomma tutte soluzioni DX10 che non danno alcun vantaggio ad HW dx10.1.
In clear sky si è pensato al'utilizzo di testure array (dx10) per il fumo volumetrico, ma non al cube map array (dx10.1) per l'illuminazione. Strano ma vero :D

Solo una precisazione yoss: il problema non e' nel risolvere l'MSAA con un engine deferred in DX10, perche' questo e' possibile. In DX10 e' permesso fare il fetch dei sample, e poi risolverli nello shader. Cio' che non e' permesso e' il fetch dei sample nel depth buffer (supportato solo in DX10.1), quindi per un'eventuale fase di post processing che avesse bisogno della distanza della camera (depth of field ad esempio), si e' costretti a scrivere il depth per pixel in un passo precedente in DX10 dove in DX10.1 basterebbe il depth buffer. In DX10, inoltre, non e' possibile conoscere la topologia dei sample, in pratica come sono disposti.

Solo una precisazione yoss: il problema non e' nel risolvere l'MSAA con un engine deferred in DX10, perche' questo e' possibile. In DX10 e' permesso fare il fetch dei sample, e poi risolverli nello shader. Cio' che non e' permesso e' il fetch dei sample nel depth buffer (supportato solo in DX10.1), quindi per un'eventuale fase di post processing che avesse bisogno della distanza della camera (depth of field ad esempio), si e' costretti a scrivere il depth per pixel in un passo precedente in DX10 dove in DX10.1 basterebbe il depth buffer. In DX10, inoltre, non e' possibile conoscere la topologia dei sample, in pratica come sono disposti.

infatti, in dx10.1 puoi far uso di più MRT nello z-buffer in cui fare fetch dei sample; in dx10, si può ricorrere ad un color buffer adibito a depth buffer.

OT, che fine hai fatto :)

della serie DUE PESI DUE MISURE? In passato si è tagliato il supporto ad HW sm2.0 perchè supportato dalla metà degli utenti, adesso non si utilizza il supporto ad HW dx10.1 perchè utilizzato da metà degli utenti: guarda caso sempre la stessa metà :rolleyes: A questo link, aggiornato al mese scorso, c'è scritto che il 65% di una buona rappresentanza di videgiocatori utilizza VGA NVID*A, mentre solo il 27% utilizza VGA AT*:
http://store.steampowered.com/hwsurvey

La tua "metà degli utenti" mi sembra quindi una assunzione alquanto irrealistica (siamo in realtà a rapporto 7:3), e il gioco in questione, fra gli altri, veniva regalato con le schedine AT*: fra le due case ci dovevano essere rapporti molto buoni - quindi mi pare ben più che un esempio imparziale (o meglio: di certo non a favore del verde competitor).

Penso che i fatti siano molto importanti nell'esplicazione di una teoria che possa esser ritenuta valida; spesso le parole non bastano.

2% per ATi in 20% per nVIDIA. Ed è solo uno dei tanti casi. Non vorrai mica difendere chi fa driver cheating?Mi sembra che, nell'eventualità, non sia scusabile nessuno dei due.
Un esempio estremizzato, forse per te uno che ruba 10'000 euro merita una punizione più leggera di uno che ne ruba 100'000?

perchè, evidentemente, nel rapporto con Intel ha più da guadagnarci che da quello con nVIDIA. Perchè deve spingere la vendita delle sue cpu (le gpu si vendono bene da sole); perchè non è certo che la fisica nei giochi (non le simulazioni fisiche di tipo gpgpu, quelle sono un'altra cosa), passerà attraverso la gpu, visto che quest'ultima sarà sempre più carica di lavoro mentre le cpu avranno sempre meno cose da fare.Parli in veci di ATI? Difficile conoscere la verità, si può solo presumere.
Fatto è però che al momento tale supporto HAV*K da parte di AT* sembri piuttosto fumoso. Nè un demo, nè una dichiarazione.
Solo un po' di hype lasciato a fermentare nei forum.
Di PH*SX ci saranno due bandierine che sventolano, qualche demo di gioco ancora in sviluppo. Ma ci sono, e sono sfruttabili.

A questo link c'è scritto che il 65% dei videgiocatori utilizza VGA NVIDIA e solo il 27% utilizza VGA ATI:
http://store.steampowered.com/hwsurvey

La tua "metà degli utenti" mi sembra quindi una assunzione alquanto irrealistica, come tante altre ne hai fatte (e il gioco in questione, fra gli altri, veniva regalato con le schedine ATI, tanto era forte il legame fra le due case - quindi mi pare ben più che un esempio imparziale).

Sarebbero graditi più fatti, e meno parole.


da quando gli utilizzatori di steam rappresentano la totalità dei giocatori? Inoltre, le percentuali le ha date stefem, ma si vede che tu riservi a me un'attenzione speciale. Prenderò provvedimenti




Mi sembra che non sia scusabile nessuno dei due.
Oppure, forse per te uno che ruba 10'000 euro merita una punizione più leggera di uno che ne ruba 100'000?

sei tu che scusi sempre e comunque nVIDIA: sia quando rinomina 100 volte le stesse gpu aumentando il prezzo ogni volta, sia quando fa driver cheating (è più brava perchè guadagna di più), per non parlare delle pratiche di viral marketing (è normale che un'azianda pagni qualcuno per fingersi un normale utente di un forum e far propaganda ai suoi prodotti: è normale se è nVIDIA a farlo, vero?). Fatti un'esane di coscienza che è meglio.



Parli in veci di ATI? Peccato che al momento tale supporto HAVOK da parte di ATI sia solo fumo. Nè un demo, nè una dichiarazione.
Solo un po' di hype lasciato fermentare nei forum.
Di PHYSX ci saranno due bandierine che sventolano. Ma ci sono.

parlo per me; tu invece per chi parli?
Meglio l'acqua che il vino scadente. :Prrr:

infatti, in dx10.1 puoi far uso di più MRT nello z-buffer in cui fare fetch dei sample; in dx10, si può ricorrere ad un color buffer adibito a depth buffer.

OT, che fine hai fatto :)

OT, un po' di lavoro per finire un giochino ed ora preparazioni per andare in Germania :)

doom3, a detta dello stesso carmack, è stato tagliato e cucito su misura sull'aHW dell'NV30 (su cui ha ammesso di aver sviluppato e per cui ha ottimizzato). Come d'altra parte, valve ha scritto codice dx9 senza preoccuparsi di ottimizzare per chi quel codice non lo digeriva ma obbligando i chip NV ad utilizzare codice dx8 (con cui, per altro, andavano decisamente meglio).
Sul discorso havok-intel vs physx-nVIDIA, anche io vedo in vantaggio i primi: sia per il supporto che intel può vantare dagli sviluppatori e sia per il fatto che il futuro della fisica nei giochi potrebbe non passare attraverso le gpu

Havok dove l'ho visto non pesa nemmeno tanto e i risultati sono di assoluto pregio, forse sarebbe solo da migliorare la fisicità dei corpi, per il resto mi sembra perfetto.

da quando gli utilizzatori di steam rappresentano la totalità dei giocatori? Inoltre, le percentuali le ha date stefem, ma si vede che tu riservi a me un'attenzione speciale. Prenderò provvedimenti

Io le ho buttate li per non entrare nel dettaglio, anche perché è difficile quantificare quante schede tra quelle AMD siano DX10.1 e quante NVIDIA siano DX10, di schede DX10 se ne vendono parecchie dal 2006 e saranno sicuramente di più delle schede DX10.1, ma non so di preciso in che percentuali.
Cosi come al tempo di NV40 e R420, le schede sm2.0 saranno state sicuramente la maggior parte.

nomi e link di chi dice che MS boicotta le dx10 o sono tutte panzane

Hai ragione, MS ha favorito enormemente la loro adozione rendendole disponibili solo su Vista, sistema operativo straordinario e di cui non si può fare a meno.

Non è che MS voglia boicottarle, ma preferisce "favorire" la diffusione di Vista, il fatto che limiti la diffusione delle DX10 è una conseguenza della sua politica.

Io le ho buttate li per non entrare nel dettaglio, anche perché è difficile quantificare quante schede tra quelle AMD siano DX10.1 e quante NVIDIA siano DX10, di schede DX10 se ne vendono parecchie dal 2006 e saranno sicuramente di più delle schede DX10.1, ma non so di preciso in che percentuali.
Cosi come al tempo di NV40 e R420, le schede sm2.0 saranno state sicuramente la maggior parte.

lo so; tranquillo, non sei tu il problema :)