Link alla notizia: http://www.hwupgrade.it/news/skvideo/nvidia-physx-e-cpu-un-binomio-non-ideale_33179.html

Un articolo evidenzia come l'ottimizzazione da lato codice per l'esecuzione di PhysX via CPU sia tutt'altro che ideale, soprattutto confrontandola con quella per GPU

Click sul link per visualizzare la notizia.

Ovvio che castrano questa tecnologia sennò chiunque abbia un processore potente potrebbe non aver bisogno di HW nVidia per far girare PhysiX. Dato che tale tecnologia è proprietaria, e non open source, e che ci hanno investito sopra dei soldi penso sia giusto cercare di averne un ritorno economico.

@nVidia

Siete dei cani morti...
:mad:

In un linguaggio tecnico, questa si chiama "presa per il culo".

E' lo stesso discorso dei compilatori Intel che penalizzano i proci AMD... Il software, sull'hw avversario gira male, così il mio sembra piùffigo di quel che in realtà è, ma gira. Così evito beghe con antitrust e organi vari.

Molto meglio Havok!!! :rolleyes:

cioè, praticamente nvidia ti da un codice che in presenza di proprie gpu va come un treno, mentre se deve girare su cpu, gira castrato.
e per giunta, se facessero le cose fate per bene, col codice ottimizzato, le performance sarebbero superiori utilizzando una cpu multicore invece di una gpu nvidia.
ho capito bene?

E' una vita che si dice che le 4 cose in croce che muove un game con PhysX attivato una cpu di medio livello potrebbe eseguire altrettanto bene.

PhysX è una buffonata, andrebbe boicottato. :muro:

cioè, praticamente nvidia ti da un codice che in presenza di proprie gpu va come un treno, mentre se deve girare su cpu, gira castrato.
e per giunta, se facessero le cose fate per bene, col codice ottimizzato, le performance sarebbero superiori utilizzando una cpu multicore invece di una gpu nvidia.
ho capito bene?

sembrerebbe cosi. ma è normale che utilizzi le cpu, d'altronde physix è sua

Ovvio, se vuoi PhysX devi avere un gpu Nvidia. Così come se uno vuole chessò, Snow Leopard, deve comprarsi il Mac.

if( GPU_NVIDIA ) {
vai come un treno;
.
.
.

} else { vai una ciofeca;}

Non ho capito questa frase: "... cosa da un palo plausibile considerando come l'interesse di NVIDIA stia nel mondo GPU e non in quello CPU.... " .
Che significa "cosa da un palo plausibile"?

adesso che la situazione mi è più chiara, dico che è una mezza figura di xxxxx, al di là della giusta considerazione che essendo physx proprietario è anche comprensibile che Nvidia agisca così

chi lo sà se prenderà una posizione pubblica in merito

if( GPU_NVIDIA ) {
vai come un treno;
.
.
.

} else { vai una ciofeca;}

ok. nonostante la mia gnoranza in fatto di programmazione, questa IF è estremamente esplicativa!
:D


a sto punto però, nvidia faceva piu bella figura a nn supportare x niente physx al di fuori delle proprie gpu. se nn altro il concetto "physx è mio e me lo gestisco io" sarebbe parso meno presa x i fondelli. -_-

Così come se uno vuole chessò, Snow Leopard, deve comprarsi il Mac.

quasi...

@ hermanss

ahahahahaahhahahaha, simpatico questo if XD

Oddio, dicono che senza usare le SSE portano Physix compatibile su qualsiasi processore. A me risulta che le SSE sono disponbili dai Pentium 3... E sfido chiunque a giocare su un processore minore del P3 con physix... Ipocrisia???
Eh si, physix è proprietario però certe cavolate per favore evitatele...
Gpu gpu gpu gpu... Chissà le CPU che fine faranno...

Ho iniziato a sviluppare con PhysX da 3 anni, prima che la comprasse NVidia... il calo di qualità è stato costante, tanto che ora sono in dubbio se spendere 1 mese di tempo per estirparlo dal mio progetto!

Fun facts:
-E' stato comprato alla versione 2.7
-La versione 3.0 era prevista per Maggio 2008 (!!)
-Ad oggi siamo alla versione 2.8.3.1
-Sulla GPU girano solo fluidi e stoffe usate dallo 0.00001% dei giochi
-La GPU non supporta i Corpi Rigidi (rettangoli, sfere, cilindri) che vengono in ogni caso eseguiti sulla CPU
-Il motore fisico sulla CPU ancora single threaded
-Ora esce fuori che nemmeno usa SSE
-Nvidia ha cambiato la licenza da freeware a "pay-if-we-like-ware"

Nvidia dovrebbe seriamente lasciare stare il software... il che restringe il campo :asd:

ottimo articolo del Corsini, denota come anche hwu evidenzi palesi dubbi (fondati) riguardanti PHysx e le strategia nvidia al riguardo ;)
In particolare la parte conclusiva è molto esplicativa e inequivocabile, Nvidia è ora di cambiare atteggiamento

Ho iniziato a sviluppare con PhysX da 3 anni, prima che la comprasse NVidia... il calo di qualità è stato costante, tanto che ora sono in dubbio se spendere 1 mese di tempo per estirparlo dal mio progetto!

Fun facts:
-E' stato comprato alla versione 2.7
-La versione 3.0 era prevista per Maggio 2008 (!!)
-Ad oggi siamo alla versione 2.8.3.1
-Sulla GPU girano solo fluidi e stoffe usate dallo 0.00001% dei giochi
-La GPU non supporta i Corpi Rigidi (rettangoli, sfere, cilindri) che vengono in ogni caso eseguiti sulla CPU
-Il motore fisico sulla CPU ancora single threaded
-Ora esce fuori che nemmeno usa SSE
-Nvidia ha cambiato la licenza da freeware a "pay-if-we-like-ware"

Nvidia dovrebbe seriamente lasciare stare il software... il che restringe il campo :asd:

ho il permesso di stampare questo post, farci un poster gigante e appenderlo in camera mia? :sofico:

Una notizia che mi spiazza... non so prendere posizione... da una parte c'è il legittimo tentativo di controllo sulle proprie tecnologie... dall'altra... MONOTHREAD??? Niente codice SSE???

Boh... ho bisogno di altre info per capire se biasimare o comprendere...

...E' ipotizzabile, del resto, che le prestazioni di una CPU multicore con codice PhysX ottimizzato multithreaded e con SSE possa risultare essere ben più veloce di quanto ottenibile con una GPU NVIDIA di ultima generazione.

Quindi Physics è alla fine in soldoni una grossa presa in giro. Meglio se ottimizzavano tutto per CPU!.

Ah il marketing: il mio è meglio del tuo. Cioè con sw proprietario ti faccio girare peggio il tuo così il mio diventa il migliore

...E' ipotizzabile, del resto, che le prestazioni di una CPU multicore con codice PhysX ottimizzato multithreaded e con SSE possa risultare essere ben più veloce di quanto ottenibile con una GPU NVIDIA di ultima generazione.

Quindi Physics è alla fine in soldoni una grossa presa in giro. Meglio se ottimizzavano tutto per CPU!.

Ah il marketing: il mio è meglio del tuo. Cioè con sw proprietario ti faccio girare peggio il tuo così il mio diventa il migliore

obiettivamente la parola magica è questa...in realtà non sappiamo quanto perfomerebbe una cpu quad-core se il codice fosse ottimizzato per essa, ergo non si possono dare sentenze

Molto meglio Havok!!! :rolleyes:

ma anche no, PhysX con programmazione adeguata sarebbe il top.

non lo hanno fatto perchè altrimenti non rimarrebbe più un motivo per comprare nvidia, con i quad core moderni, lasci la grafica ad amd e la fisica gira bene su cpu.
sarebbe il top, ma no, sti farabutti devono imbrogliare...

if( GPU_NVIDIA ) {
vaiComeUnTreno();
.
.
.

} else { vaiUnaCiofeca();}
FIXED :asd:

ho il permesso di stampare questo post, farci un poster gigante e appenderlo in camera mia? :sofico:

Ma prego :asd:

Puoi aggiungerci anche:
-non supporta Mac nè nessun aggeggio portatile,
-quel poco di fisica su GPU è "write only" cioè la CPU scrive sulla GPU ma non è possibile il viceversa, rendendo il tutto inutile per il gameplay.

@appleroof: performerebbe parecchio bene: guardati i samples di Bullet oppure di Havok.
Per esempio quest'ultimo gestiva 64 "Dottor Breen" di HL2 su un glorioso P4 :asd:
Oppure basta la Garry's Mod per capire che riesce a fare la concorrenza.

A onor del vero PhysX nel lontano 2007 era un signor motore fisico per CPU, poco sotto Havok, e supporta fin da quell'epoca 1 thread separato per la fisica. Ma poi hanno perso pesantemente il treno.

C'é un passaggio in questo articolo che mi lascia perplesso: sostengono che l'elaborazione di physX da CPU sia single threaded, ma se provate ad effettuare qualche benchmark impostando l'affinitá, noterete che é multi-threaded.

C'é un passaggio in questo articolo che mi lascia perplesso: sostengono che l'elaborazione di physX da CPU sia single threaded, ma se provate ad effettuare qualche benchmark impostando l'affinitá, noterete che é multi-threaded.

E' che di default viene eseguito nel suo thread; quindi la fisica è single threaded ma l'app ha 2 thread (uno main e uno di PhysX).
Comunque su processori n-core non è proprio abbastanza.

Piuttosto sarebbe da capire se ciò che ha vincolato l'evoluzione di PhysX sia il fatto che si deve passare per CUDA.
Quando si usa la GPU è così, quando si usa la CPU non so (e mi piacerebbe saperlo) se ci si basa ancora sulle API CUDA come intermediario col processore (CUDA può girare in emulazione sulla CPU senza bisogno di avere una GPU NVidia).

E' che di default viene eseguito nel suo thread; quindi la fisica è single threaded ma l'app ha 2 thread (uno main e uno di PhysX).
Comunque su processori n-core non è proprio abbastanza.

No, se fosse cosi' il benchmark (che, tipicamente, stressa la cpu sul thread della fisica, e non su quello del rendering) non scalerebbe con il numero di core.

cioè, praticamente nvidia ti da un codice che in presenza di proprie gpu va come un treno, mentre se deve girare su cpu, gira castrato.
e per giunta, se facessero le cose fate per bene, col codice ottimizzato, le performance sarebbero superiori utilizzando una cpu multicore invece di una gpu nvidia.
ho capito bene?

Ache se nVidia non ce lo viene a dire, lo sappiamo da anni.
nVidia non puo' certo presenizare una conferenza stampa per dire: "PhysX lato CPU andrebbe a meraviglia!"
Farebbe un autogol al suo mercato delle VGA.

Mentre si spendono fior fiori di quattrini per acquistare componenti hardware, c'è poi chi te lo inibisce in questa maniera.
Sì è così. Ce la mettono nel di dietro dicendo un mare di bugie: si tratta di applicare un filtro per capire la dimensione della castronerie che ci rifilano.
Non possiamo mettere a confronto le capacità di calcolo in virgola mobile delle più recenti CPU multicore con una moderna GPU; ci sarebbe da preoccuparsi un casino se una GPU sorpassasse nella caratteristica più rappresentativa di una CPU (cioè mera forza bruta nell'eseguire i calcoli matematici) quest'ultima stessa.*

nVidia con la sua tecnologia fa quello che vuole, è sua.
Il problema non è questo... o meglio PhysX è solo una conseguenza della linea aziendale adottata da nVidia.
E' la condotta generale dell'azienda a fare storcere il naso.
Essendo nVidia, prima di tutto, una società che possiede industrie a semiconduttori, per me, dovrebbe concentrare le proprie risorse sull'ingegnerizzazione dei chip invece che su soft hw based chiuso per evitare di lavorare meglio sull'hw e uscire fuori dalla competizione
Invece di sviluppare hardware all'avanguardia, corre dietro a PhysX, 3D vision e bla bla dove tanto possono metterci solo loro le mani.
Ti potrà dare in mano l'hardware più orrendo che vuole.... tanto PhysX è chiuso e non esiste alternativa.

D'altro canto, se nVidia fa quello che vuole, anche noi facciamo quello che vogliamo: cioè spalare quanta più merda possiamo su PhysX affinchè si levi di mezzo; e i fanboy possono dire ciò che vogliono.
Del resto queste sono cavolate fatte per essere vendute a noi.

Stando così le cose, nVidia, per riacquistare credibilità, dovrebbe mettere in piedi un'iniziativa del tipo: scegli una nostra GPU e ti rimborsiamo parte della tua spesa bruciata per l'acquisto della CPU

:rolleyes:

* = caxxata spaziale.

Sarebbe sufficiente implementare uno standard per la fiscia (DX12?)

Detto da Intel ci credo poco altrimenti nei nuovi engine dei giochi avrebbero già implementato una libreria PhysY che usi la cpu (sia Intel che AMD). Quando Nivia ha comprato Ageia ha comprato anche il diritto a implementare certe funzioni in hardware cosa che non possono fare AMD/ATI e Intel e quindi devono farlo con istruzioni deiverse aumentanto però i tempi di elaborazione.

Ripeto, dipende se PhysX passa per CUDA quando gira su CPU.....CUDA è quasi è "apribile" senza problemi non appena NVidia lo vuole, dato che è sviluppato per Open64.

Questo cmq potrebbe interessarvi!

http://insidehpc.com/2009/12/30/open-source-ocelot-moves-cuda-to-x86/

Ma prego :asd:

Puoi aggiungerci anche:
-non supporta Mac nè nessun aggeggio portatile,
-quel poco di fisica su GPU è "write only" cioè la CPU scrive sulla GPU ma non è possibile il viceversa, rendendo il tutto inutile per il gameplay.

@appleroof: performerebbe parecchio bene: guardati i samples di Bullet oppure di Havok.
Per esempio quest'ultimo gestiva 64 "Dottor Breen" di HL2 su un glorioso P4 :asd:
Oppure basta la Garry's Mod per capire che riesce a fare la concorrenza.

A onor del vero PhysX nel lontano 2007 era un signor motore fisico per CPU, poco sotto Havok, e supporta fin da quell'epoca 1 thread separato per la fisica. Ma poi hanno perso pesantemente il treno.

ma sono motori diversi no? io non sono un esperto, tu ti sentiresti di affermare con assoluta certezza ed in tutta onestà che performerebbe parecchio bene?

Intanto è da dire che nemmeno l'autore dell'articolo originale si spinge a prendere posizione in merito, perchè non può :D

fatto stà che fino all'arrivo di uno standard proprietario (meglio, dell'affermazione di opencl) o ti mangi stà minestra (ossia compri Nvidia che a sua volta ha speso milioni di dollari per acquisire Ageia) o....

:boh:

Sarebbe sufficiente implementare uno standard per la fiscia (DX12?)

Detto da Intel ci credo poco altrimenti nei nuovi engine dei giochi avrebbero già implementato una libreria PhysY che usi la cpu (sia Intel che AMD). Quando Nivia ha comprato Ageia ha comprato anche il diritto a implementare certe funzioni in hardware cosa che non possono fare AMD/ATI e Intel e quindi devono farlo con istruzioni deiverse aumentanto però i tempi di elaborazione.
Possono farlo eccome, NVidia aveva proposto a sviluppatori indipendenti aiuto per avere il supporto a CUDA (e quindi a PhysX) sulle Radeon, ma ATI ha detto no (per non favorire la diffusione dello standard avversario).

->http://www.tomshardware.com/news/nvidia-ati-physx,5841.html

Eran Badit editor-in-chief of ngohq.com posted an update to the events of last week. He confirmed that he is receiving support from Nvidia to get PhysX to run on ATI cards. "It’s very impressive, inspiring and motivating to see Nvidia’s view on this," he wrote. He believes that Nvidia most likely wants to "take on Intel with CUDA and to deal with the latest Havok threat from both AMD and Intel."

He also noted that he made progress getting his hands on a Radeon 4800 card and noted that his CUDA Radeon library is "almost done." Badit said that "there are some issues that need to be addressed, since adding Radeon support in CUDA isn’t a big deal - but it’s not enough! We also need to add CUDA support on AMD’s driver level and its being addressed as we speak."

Se (ed è un grosso se) fossero furbi migliorerebbero Physix (che da quello che si è detto è praticamente fermo) per la gestione non solo dei fluidi e tessuti, e farebbero in modo che funzioni bene anche su CPU.
Così ci sarebbero più giochi ad usare questa tecnologia (ad oggi non è che sono tantissimi), loro farebbero soldi con le licenze e visto che dovrebbe gestire più roba le GPU sarebbero comunque in vantaggio sulle CPU (chi ha un 6 core è abbastanza fanatico da non volere perdere manco mezzo fps quindi si prenderebbe un GPU adatta per la fisica)
Invece fanno un Physix che se non hai una loro scheda è inutile, così gli sviluppatori si dicono "perchè fare un gioco che solo una fetta di giocatori potrà godere appieno? Inserisco la fisica ma non molto così da non sbilanciar il gameplay a seconda che uno sui ati o nvidia".
Mah.. tra Physix e Fermi non so cosa sia peggio.

Ache se nVidia non ce lo viene a dire, lo sappiamo da anni.
nVidia non puo' certo presenizare una conferenza stampa per dire: "PhysX lato CPU andrebbe a meraviglia!"
Farebbe un autogol al suo mercato delle VGA.

Mentre si spendono fior fiori di quattrini per acquistare componenti hardware, c'è poi chi te lo inibisce in questa maniera.
Sì è così. Ce la mettono nel di dietro dicendo un mare di bugie: si tratta di applicare un filtro per capire la dimensione della castronerie che ci rifilano.
Non possiamo mettere a confronto le capacità di calcolo in virgola mobile delle più recenti CPU multicore con una moderna GPU; ci sarebbe da preoccuparsi un casino se una GPU sorpassasse nella caratteristica più rappresentativa di una CPU (cioè mera forza bruta nell'eseguire i calcoli matematici) quest'ultima stessa.

nVidia con la sua tecnologia fa quello che vuole, è sua.
Il problema non è questo... o meglio PhysX è solo una conseguenza della linea aziendale adottata da nVidia.
E' la condotta generale dell'azienda a fare storcere il naso.
Essendo nVidia, prima di tutto, una società che possiede industrie a semiconduttori, per me, dovrebbe concentrare le proprie risorse sull'ingegnerizzazione dei chip invece che su soft hw based chiuso per evitare di lavorare meglio sull'hw e uscire fuori dalla competizione
Invece di sviluppare hardware all'avanguardia, corre dietro a PhysX, 3D vision e bla bla dove tanto possono metterci solo loro le mani.
Ti potrà dare in mano l'hardware più orrendo che vuole.... tanto PhysX è chiuso e non esiste alternativa.

D'altro canto, se nVidia fa quello che vuole, anche noi facciamo quello che vogliamo: cioè spalare quanta più merda possiamo su PhysX affinchè si levi di mezzo; e i fanboy possono dire ciò che vogliono.
Del resto queste sono cavolate fatte per essere vendute a noi.

Stando così le cose, nVidia, per riacquistare credibilità, dovrebbe mettere in piedi un'iniziativa del tipo: scegli una nostra GPU e ti rimborsiamo parte della tua spesa bruciata per l'acquisto della CPU

:rolleyes:

guarda che la gpu ha una potenza di calcolo enormemente superiore alla cpu nei floating point, la scheda video nasce espressamente proprio per fare conti in virgola mobile e proprio su quello ha un vantaggio netto nel confronto con le cpu
un intel 980xe ha una potenza teorica di 107.55 GFLOPS mentre una 5970 ne ha una di 4.64 TFLOPS ovvero ben 43 volte inferiore (o se vuoi metterlo in percentuale un 980xe ha il 2.3% della potenza di una vga)

il problemi del gpgpu sono altri, di sicuro non la mancanza di forza bruta

le vga hanno si una elevatissima velocitàdi calcolo in virgola mobile ma praticamente fanno solo quello, hanno unità specifiche per fare in maniera efficente i calcoli fp in hardware ma se servono operazioni logiche, anche un semplice confronto tra due valori vanno in crisi e l'implementazione in gpu di queste semplici operazioni è altamente inefficente
IL parallelismo: una gpu è un sistema altamente parallelizzato una gpu ha centinaia di unità di calcolo indipendenti contro i 12 core massimi degli opteron questo fà si che la gpu riesce a dare il massimo solamente in poche applicazioni dove è possibile massimizzare il lavoro in parallelo, c'è da ricordarsi poi la legge di Amdhal


non per niente nei moderni supercomputer si usa un mix tra cpu e gpu in modo da avere una buona efficenza complessiva

Se (ed è un grosso se) fossero furbi migliorerebbero Physix (che da quello che si è detto è praticamente fermo) per la gestione non solo dei fluidi e tessuti, e farebbero in modo che funzioni bene anche su CPU.
Vedo post sopra, l'atteggiamento di NVidia è cambiato quando AMD/ATI ha sbattuto la porta in faccia più di un annetto fa.

@nVidia

Siete dei cani morti...
:mad:

Intanto la gente paga,saranno pure cani morti,ma in quanto a marketing non la batte nessuno la Nvidia.

Possono farlo eccome, NVidia aveva proposto a sviluppatori indipendenti aiuto per avere il supporto a CUDA (e quindi a PhysX) sulle Radeon, ma ATI ha detto no (per non favorire la diffusione dello standard avversario).

->http://www.tomshardware.com/news/nvidia-ati-physx,5841.html

Eran Badit editor-in-chief of ngohq.com posted an update to the events of last week. He confirmed that he is receiving support from Nvidia to get PhysX to run on ATI cards. "It’s very impressive, inspiring and motivating to see Nvidia’s view on this," he wrote. He believes that Nvidia most likely wants to "take on Intel with CUDA and to deal with the latest Havok threat from both AMD and Intel."

He also noted that he made progress getting his hands on a Radeon 4800 card and noted that his CUDA Radeon library is "almost done." Badit said that "there are some issues that need to be addressed, since adding Radeon support in CUDA isn’t a big deal - but it’s not enough! We also need to add CUDA support on AMD’s driver level and its being addressed as we speak."

sai come è, tra opencl e havok (sia cpu che gpu) non si vede proprio il motivo di autolegarsi un cappio al collo e dare il comando della botola nelle mani del peggior concorrente,

aka: se amd implementasse cuda sarebbe nelle mani di nvidia che potrebbe tagliare il supporto dato ad amd dopo che cuda fosse diventato uno standard de facto

ma sono motori diversi no? io non sono un esperto, tu ti sentiresti di affermare con assoluta certezza ed in tutta onestà che performerebbe parecchio bene?

Intanto è da dire che nemmeno l'autore dell'articolo originale si spinge a prendere posizione in merito, perchè non può :D

fatto stà che fino all'arrivo di uno standard proprietario (meglio, dell'affermazione di opencl) o ti mangi stà minestra (ossia compri Nvidia che a sua volta ha speso milioni di dollari per acquisire Ageia) o....

:boh:

o si sviluppa con un altro motore fisico più usato, meglio conosciuto, e che non ha problemi a girare con qualunque marca di hardware in commercio, la fisica non è solo physix: (che poi a meno di usare una scheda dedicata per esso è controproducente in quanto và a pesare sul collo di bottiglia del sistema durante il gaming

Possono farlo eccome, NVidia aveva proposto a sviluppatori indipendenti aiuto per avere il supporto a CUDA (e quindi a PhysX) sulle Radeon, ma ATI ha detto no (per non favorire la diffusione dello standard avversario).

->http://www.tomshardware.com/news/nvidia-ati-physx,5841.html

Eran Badit editor-in-chief of ngohq.com posted an update to the events of last week. He confirmed that he is receiving support from Nvidia to get PhysX to run on ATI cards. "It’s very impressive, inspiring and motivating to see Nvidia’s view on this," he wrote. He believes that Nvidia most likely wants to "take on Intel with CUDA and to deal with the latest Havok threat from both AMD and Intel."

He also noted that he made progress getting his hands on a Radeon 4800 card and noted that his CUDA Radeon library is "almost done." Badit said that "there are some issues that need to be addressed, since adding Radeon support in CUDA isn’t a big deal - but it’s not enough! We also need to add CUDA support on AMD’s driver level and its being addressed as we speak."

intanto sono chiacchere e balle perchè la situazione non è quella , a leggere lì sembra che nVidia volesse regalare qualcosa ma voleva venderlo ( letto da un pr nVidia su un altro forum , non ho voglia di andarmelo a cercare ). Al di là di questo comunque il terreno d' incontro proposto da AMD sono le OpenCL ( Dave Hoff , prima di lavorare per AMD lavorava proprio per nVidia , con CUDA ) ma nVidia ha rifiutato: http://www.rage3d.com/previews/video/ati_hd5870_performance_preview/index.php?p=4

Dire che sia stata ATi a chiudere la porta in faccia a nVidia mi pare abbastanza ridicolo e fazioso... se nVidia fosse disponibile come dici tu non avrebbe disabilitato PhysX quando gira su gpu nVidia ma si usa una scheda ATi per rendering ( e questo basta e avanza per intuire che nVidia non ha proprio intenzione di condividere nulla ).

if( GPU_NVIDIA ) {
vaiComeUnTreno();
.
.
.

} else { vaiUnaCiofeca();}

FIXED

Era pseudocodice:Prrr: :D

guarda che la gpu ha una potenza di calcolo enormemente superiore alla cpu nei floating point, la scheda video nasce espressamente proprio per fare conti in virgola mobile e proprio su quello ha un vantaggio netto nel confronto con le cpu
un intel 980xe ha una potenza teorica di 107.55 GFLOPS mentre una 5970 ne ha una di 4.64 TFLOPS ovvero ben 43 volte inferiore (o se vuoi metterlo in percentuale un 980xe ha il 2.3% della potenza di una vga)

il problemi del gpgpu sono altri, di sicuro non la mancanza di forza bruta

le vga hanno si una elevatissima velocitàdi calcolo in virgola mobile ma praticamente fanno solo quello, hanno unità specifiche per fare in maniera efficente i calcoli fp in hardware ma se servono operazioni logiche, anche un semplice confronto tra due valori vanno in crisi e l'implementazione in gpu di queste semplici operazioni è altamente inefficente
IL parallelismo: una gpu è un sistema altamente parallelizzato una gpu ha centinaia di unità di calcolo indipendenti contro i 12 core massimi degli opteron questo fà si che la gpu riesce a dare il massimo solamente in poche applicazioni dove è possibile massimizzare il lavoro in parallelo, c'è da ricordarsi poi la legge di Amdhal


non per niente nei moderni supercomputer si usa un mix tra cpu e gpu in modo da avere una buona efficenza complessiva

Ho scritto una caxxata abbastanza grossa.
Deve assolutamente essere fatta notare a chi legge quel post.
Fare Edit per toglierla non mi sembra giusto, è meglio infierire.

anche un semplice confronto tra due valori vanno in crisi e l'implementazione in gpu di queste semplici operazioni è altamente inefficente
Beh siamo un tantino oltre il confronto ormai :D
Il problema è per il codice che richiede salti e predizione.....

Cioè questi CASTRANO DI PROPOSITO la fisica su cpu??? ma stiamo scherzando?

che razza di falliti....

sai come è, tra opencl e havok (sia cpu che gpu) non si vede proprio il motivo di autolegarsi un cappio al collo e dare il comando della botola nelle mani del peggior concorrente,

aka: se amd implementasse cuda sarebbe nelle mani di nvidia che potrebbe tagliare il supporto dato ad amd dopo che cuda fosse diventato uno standard de facto
A meno che NVidia non metta in Open Source CUDA.....volendo può farlo senza grossi stravolgimenti: il problema è "Ha senso affiancarlo ad OpenCL?"
Attualmente CUDA è più maturo di OpenCL però è irrimediabilmente legato ad NVidia come tecnologica proprio a livello di percezione.

Cioè questi CASTRANO DI PROPOSITO la fisica su cpu??? ma stiamo scherzando?

che razza di falliti....
Non castrano di proposito, non spingono sull'ottimizzazione :D

Dire che sia stata ATi a chiudere la porta in faccia a nVidia mi pare abbastanza ridicolo e fazioso... se nVidia fosse disponibile come dici tu non avrebbe disabilitato PhysX quando gira su gpu nVidia ma si usa una scheda ATi per rendering ( e questo basta e avanza per intuire che nVidia non ha proprio intenzione di condividere nulla ).
Guarda che questo è successo un anno dopo quei fatti riportati sopra :mbe:
Di mezzo c'è stata la comparsa di Stream di AMD.

A quel punto l'andazzo è stato evidente:

*NVidia->CUDA->PhysX/OpenCL
*ATI->Stream->Havoc/OpenCL

Tanto che la libreria OpenCL non è nei Catalyst ma in Stream :p

Ah, ovviamente sono possessore sia di NVidia che di ATI ;)

Non vedo perché diamine a nVidia dovrebbe importare di ottimizzare phisX su cpu.... già basta che ci giri.
Se poi uno vuole la fisica superveloce multithread con SSE se la scriva da solo.

Non vedo perché diamine a nVidia dovrebbe importare di ottimizzare phisX su cpu.... già basta che ci giri.
Se poi uno vuole la fisica superveloce multithread con SSE se la scriva da solo.
Perchè farebbe da volano per CUDA.....dato che PhysX gira grazie a CUDA (non si appoggia direttamente ai driver, ma passa per CUDA).

Guarda che questo è successo un anno dopo quei fatti riportati sopra :mbe:
Di mezzo c'è stata la comparsa di Stream di AMD.

A quel punto l'andazzo è stato evidente:

*NVidia->CUDA->PhysX/OpenCL
*ATI->Stream->Havoc/OpenCL

Tanto che la libreria OpenCL non è nei Catalyst ma in Stream :p

Ah, ovviamente sono possessore sia di NVidia che di ATI ;)

E che vuol dire... le trattative non si possono riaprire a distanza di tempo ?

Dave Hoff: While it would be easy to convert PhysX from CUDA to OpenCL so it could run on our cards, and I've offered our assistance to do this, I can just imagine PhysX will remain that one app that doesn't ever become open.

Con CUDA ci ha lavorato... saprà bene quel che dice.

Magari ora a qualcuno gli si schiariscono le idee sul perchè Ati non ha tutta sta fretta di mandare "su gpu" Havok o simili...

Magari ora a qualcuno gli si schiariscono le idee sul perchè Ati non ha tutta sta fretta di mandare "su gpu" Havok o simili...

occhio che havok non è di amd ma è di intel :D

esiste una versione per gpu di havok (havok fx) ma non si sa se è ancora in sviluppo o attualmente è stata accantonata
@lowentz mi pare logico che opencl stia in stream invece che nei catalyst con la grafica non c'entra nulla

Magari ora a qualcuno gli si schiariscono le idee sul perchè Ati non ha tutta sta fretta di mandare "su gpu" Havok o simili...

è intel che possiede havok, pensa quanta voglia ha essa.

occhio che havok non è di amd ma è di intel :D

esiste una versione per gpu di havok (havok fx) ma non si sa se è ancora in sviluppo o attualmente è stata accantonata

penso che sia morta insieme a lambaree

Da ignorante faccio un'osservazione molto semplice.

Non essendo PhisiX l'unico motore che gestisce la fisica, e pare manco il più performante, perchè gli sviluppatori non ne usano uno (dicamo il Bullet) che usi a dovere i multi core?

Non sarebbe un vantaggio per loro, dal momento che si rivolgono ad entrambi i possessori di NVIDIA/ATI?
Se ho detto una cavolata, sorvolate XD

Scusate un attimo.
qualcuno può spiegarmi come funziona?
Cioè se la gpu gestisce anche la fisica, parte della potenza di calcolo andrebbe sottratta a tutto il resto: effetti, filtri, anti-aliasing ecc.
quindi la domanda è:

Se per esempio (fantasia pura) esce crysis con PhysX, questo non girerà mai fluido su nvidia che deve pensare anche ad elaborare la fisica.

Sbaglio? Spiegatemi, perché imho scheda video al 110% (che non ce la fa) e processore al 30% va peggio di scheda video al 90% e cpu al 90%!

BO?:confused:

cut
o si sviluppa con un altro motore fisico più usato, meglio conosciuto, e che non ha problemi a girare con qualunque marca di hardware in commercio, la fisica non è solo physix: (che poi a meno di usare una scheda dedicata per esso è controproducente in quanto và a pesare sul collo di bottiglia del sistema durante il gaming

e io che ho detto? :D

cmq il problema non è che Nvidia faccia quello che vuole con le sue cose (chi mi può dire cosa fare a casa mia?) mi sembra di una evidenza assoluta e chi grida allo scandalo o non coglie questo punto oppure è fazioso

ma magari il problema è che gli altri non abbiano la forza di imporre alternative, cosa che mi sembra quantomeno strana (vorrei vedere se Ms, Intel, Amd si accordassero in tal senso); può essere che tra poco tempo questo accadrà (anche qui magari con l'avvento delle nuove consolle, per come ormai è orientato il mercato), fino a quel punto credo valga l'antico proverbio da me prima citato

:boh:

Da ignorante faccio un'osservazione molto semplice.

Non essendo PhisiX l'unico motore che gestisce la fisica, e pare manco il più performante, perchè gli sviluppatori non ne usano uno (dicamo il Bullet) che usi a dovere i multi core?

Non sarebbe un vantaggio per loro, dal momento che si rivolgono ad entrambi i possessori di NVIDIA/ATI?
Se ho detto una cavolata, sorvolate XD

No,perchè i produttori preferiscono prender fior di soldi da Nvidia sponsorizzando il proprio motore fisico PhySix quando è permesso dal gioco.
Finche Ati non farà lo stesso,non cambierà nulla.

Beh, diciamo la verità, per quanto questa cosa sappia di immensa presa per i fondelli verso l'utente, Nvidia ha decisamente solo vantaggi a perseguire una strada di questo tipo.
E che PhysX avesse seri limiti su CPU era comunque cosa abbastanza nota da tempo, ora se ci sono dei dati più oggettivi da valutare.

Del resto è abbastanza palese:
- se non ottimizzo per cpu, il vantaggio della gpu apparirà mirabolante.
- se solo la GPU permette certi effetti, l'utente è spinto a non accontentarsi della fisica su cpu e acquistare schede nvidia.
- il fatto che giri su GPU e abbassi le performance della scheda video va a tutto vantaggio di nvidia, dato che l'utente tenderà ad acquistare schede più potenti o ad cambiare la propria con qualcosa di meglio.
- dato che per la maggior parte degli utenti (quelli che i workaround per far girare PhysX su sistemi con una scheda video ati installata non sanno neppure cosa siano) occorre un ecosistema nvidia, anche l'acquisto di una eventuale seconda scheda solo per la fisica aiuta a guadagnare.
- l'ottimizzazione costa risorse, chi te lo fa fare quando è pure controproducente?

Insomma, nvidia non ha alcun interessa al momento nel creare un buon motore fisico, ma tutte le ragioni per non farlo.


PS: nessuno ha ancora linkato la news sul thread di PhysX?

Da ignorante faccio un'osservazione molto semplice.

Non essendo PhisiX l'unico motore che gestisce la fisica, e pare manco il più performante, perchè gli sviluppatori non ne usano uno (dicamo il Bullet) che usi a dovere i multi core?

Non sarebbe un vantaggio per loro, dal momento che si rivolgono ad entrambi i possessori di NVIDIA/ATI?
Se ho detto una cavolata, sorvolate XD

guarda che gli altri motori fisici sono molto più usati di physix (havok per esempio è usato da centinaia di titoli) ma il marketing nvidia fà da ombrello e parecchi pensano che la fisica ci sia solo con physix

No,perchè i produttori preferiscono prender fior di soldi da Nvidia sponsorizzando il proprio motore fisico PhySix quando è permesso dal gioco.
Finche Ati non farà lo stesso,non cambierà nulla.

Cioè i soldi sganciati da NVIDIA valgono più della fetta di mercato ATI?
Cioè fin'ora ci può anche stare vista com'è gestita la fisica nei giochi (cioè è cosa quasi solo estetica, e a detta di Tommo per un limite delle GPU).
Ma se volessi l'evoluzione di un Unreal Engine o di un Crisys engine, che non usano PhisiX che io sappia... c'è speranza di vedere sti benedetti multicore sfruttati, almeno da questi motori più generici, o devo sempre pagare il pizzo a Nvidia?

Scusate un attimo.
qualcuno può spiegarmi come funziona?
Cioè se la gpu gestisce anche la fisica, parte della potenza di calcolo andrebbe sottratta a tutto il resto: effetti, filtri, anti-aliasing ecc.
quindi la domanda è:

Se per esempio (fantasia pura) esce crysis con PhysX, questo non girerà mai fluido su nvidia che deve pensare anche ad elaborare la fisica.

Sbaglio? Spiegatemi, perché imho scheda video al 110% (che non ce la fa) e processore al 30% va peggio di scheda video al 90% e cpu al 90%!

BO?:confused:

Devi mettere in conto che il CryEngine incorpora, a sua volta, un engine fisico proprietario... e che, dunque, fra le risorse utilizzate della CPU ci stanno quei calcoli.
Si dovrebbe fare la differenza... se metti su PhysX devi togliere quell'altro.
Meglio non pensarci, secondo me.

No,perchè i produttori preferiscono prender fior di soldi da Nvidia sponsorizzando il proprio motore fisico PhySix quando è permesso dal gioco.
Finche Ati non farà lo stesso,non cambierà nulla.

Parli come se tutti i giochi supportassero l' accelerazione via gpu di PhysX ma sono pochi, il novodex è il motore usato dall' Unreal engine da prima che fosse acquisito da nVidia , non so se Epic Games farebbe la stessa scelta oggi visto come stanno le cose. Fatto il tool ci vuole tempo per far uscire i giochi ma pare proprio che arriveranno senza bisogno di pagare: http://www.thinq.co.uk/2010/3/8/amd-gives-away-gpu-physics-tools/

guarda che gli altri motori fisici sono molto più usati di physix (havok per esempio è usato da centinaia di titoli) ma il marketing nvidia fà da ombrello e parecchi pensano che la fisica ci sia solo con physix

Ok, ma quando vedo dei titoloni che usano PhisiX (mi viene in mente Mafia II) penso che chiunque possessore ATI rosicherebbe almeno un po'.

Sarà una politica scorretta quella di Nvidia, ma ottiene quello che vuole.

Poi guardando al futuro, vedo i motori fisici come parte integrante se non fondamentale del gameplay. E pare che la fisica gestita via GPU non porti chissà dove in tal senso (stando alla spiegazione tecnica di Tommo)

@Ciokos
Utilizzare PhisX non implica necessariamente la perdita della quota di mercato di ATI.
Molti videogiocatori sono persino ignari che un certo gioco non va a supportare certe feature a causa della scheda video, e altri quando lo scoprono magari si trovano a pensare la propria scheda video sia scarsa perchè non nvidia e per il successivo acquisto si buttano su nvidia.

Insomma, il vantaggio è reciproco, e a quanto pare ad nvidia conviene investire in questo senso.

Ok, ma quando vedo dei titoloni che usano PhisiX (mi viene in mente Mafia II) penso che chiunque possessore ATI rosicherebbe almeno un po'.

Sarà una politica scorretta quella di Nvidia, ma ottiene quello che vuole.

Poi guardando al futuro, vedo i motori fisici come parte integrante se non fondamentale del gameplay. E pare che la fisica gestita via GPU non porti chissà dove in tal senso (stando alla spiegazione tecnica di Tommo)

Guarda che Mafia II avrà la fisica anche per chi non possiede una GTX.
Non sarà spinta quanto lo sarà per le GTX400.

La domanda è: "E' questa differenza che rovina il gameplay di un videogioco?"

Come qualcuno ha già detto:
PhysX è UN motore fisico, non è IL motore fisico.
Se la fisica, in termini assoluti, fosse gestita solo da nVidia, allora sarebbe più preoccupante proprio come affermi tu.

guarda che gli altri motori fisici sono molto più usati di physix (havok per esempio è usato da centinaia di titoli) ma il marketing nvidia fà da ombrello e parecchi pensano che la fisica ci sia solo con physix

cos'è vogliamo crocifiggere chi fà bene il suo lavoro di marketing? :D

Magari dopo aver assunto altri dirigenti Nvidia, Ati potrebbe prendere quelli del marketing :asd:

scherzo ma attraverso lo scherzo dico una cosa secondo me obiettiva: dove sarebbe la colpa (ammesso che tu non intendessi questo e che io invece non abbia capito male)

guarda che gli altri motori fisici sono molto più usati di physix (havok per esempio è usato da centinaia di titoli) ma il marketing nvidia fà da ombrello e parecchi pensano che la fisica ci sia solo con physix

in + aggiungici le sh come crytek che sviluppano internamente gli engine fisici

Non è una tecnologia all'avangiardia, non permette miglioramenti del gameplay come potrebbero altri motori fisici, è una tecnologia proprietaria; a questo punto il problema sono le SH che accettano di implementare PhysX (non penso gratuitamente).
Non lo facessero avremmo innovazione enl campo dei motori fisici, giochi compatibili con qualsiasi VGA, ATI e Nvidia si dovrebbero sfidare solo sul piano delle prestazioni HW, dei consumi e dei prezzi e ci guadagnerebbero in tutto e per tutto gli utilizzatori finali.

Arrivati a questo punto forse ATI dovrebbe fare qualcosa di simile: un bel parco giochi per ATI ed uno per Nvidia. In un settore (giochi per PC) già pesantemente in crisi, sarebbe forse la mazzata finale per spingere tutti a comprarsi una consolle, ma almeno combatterebbe ad armi pari e (forse), qualcuno che adesso non si preoccupa della cosa visto che compra Nvidia, aprirebbe gli occhi sulla questione delle tecnologie proprietarie.

Ok, mettiamola in altri termini.
Io tra un po' prenderò un multicore x6.
C'ho speranza che venga sfruttato decentemente dai giochi, e in particolare per la fisica, oppure devo odiare Nvidia che mi fa uscire molti titoli di punta ottimizzati per la sua GPU, e con le mie 6 CPU che si grattano dalla noia?

Guarda che Mafia II avrà la fisica anche per chi non possiede una GTX.
Non sarà spinta quanto lo sarà per le GTX400.

cut

credo che la scalabilità in questo senso, in quel gioco, sia molto facilitata da apex http://www.nvidia.it/object/io_1238444783896.html

Non è una tecnologia all'avangiardia, non permette miglioramenti del gameplay come potrebbero altri motori fisici, è una tecnologia proprietaria; a questo punto il problema sono le SH che accettano di implementare PhysX (non penso gratuitamente).
Non lo facessero avremmo innovazione enl campo dei motori fisici, giochi compatibili con qualsiasi VGA, ATI e Nvidia si dovrebbero sfidare solo sul piano delle prestazioni HW, dei consumi e dei prezzi e ci guadagnerebbero in tutto e per tutto gli utilizzatori finali.

Arrivati a questo punto forse ATI dovrebbe fare qualcosa di simile: un bel parco giochi per ATI ed uno per Nvidia. In un settore (giochi per PC) già pesantemente in crisi, sarebbe forse la mazzata finale per spingere tutti a comprarsi una consolle, ma almeno combatterebbe ad armi pari e (forse), qualcuno che adesso non si preoccupa della cosa visto che compra Nvidia, aprirebbe gli occhi sulla questione delle tecnologie proprietarie.

mi sembra troppo enfatica la cosa: la "battaglia" tra i 2 principali attori di questo mercato non si limita ad un aspetto come può essere la fisica nei giochi, ne è prova la grande erosione di quote di mercato di Amd a scapito di Nvidia in questi ultimi mesi (che si gioca sul prodotto nel suo complesso)

inoltre il futuro del gioco su pc è già oggi pesantemente condizionato dalle consolle, che con il loro hw limitano l'innovazione già oggi, che i giochi sono ancora dx9, altro che fisica

Ok, mettiamola in altri termini.
Io tra un po' prenderò un multicore x6.
C'ho speranza che venga sfruttato decentemente dai giochi, e in particolare per la fisica, oppure devo odiare Nvidia che mi fa uscire molti titoli di punta ottimizzati per la sua GPU, e con le mie 6 CPU che si grattano dalla noia?

nei giochi basta a malapena un quad, un six proprio a nulla (almeno nell'immediato e per qualche annetto ancora) e non "per colpa" della fisica: http://www.bit-tech.net/hardware/cpus/2010/07/05/how-many-cpu-cores-do-games-need/1

poi se con il pc non ci giochi e basta allora tutt'altra storia...

Lo scomparso ( dal forum ) Ratatosk lo sosteneva spesso, d'altronde era un'ipotesi plausibile e più che sospettabile.

Aldilà delle colpe di Nvidia e delle software house a lei accondiscendenti,il problema e che ad oggi Amd\Ati non sembra abbia preso posizione su come vuole affrontare il discorso fisica nei giochi.
Belle parole , open ecc... ma nel concreto ci ritroviamo continuamente con giochi (vedi Mafia 2, ma non solo) che continuano a usare PhysiX.
Ati dovrebbe forzare la mano e implementare qualcosa di suo , cosi forse quando ci saranno giochi pro ati e giochi pro nvidia, qualcuno si adoperera per creare uno standard unico per ciò che concerne la fisica nei giochi. Ati può e deve fare qualcosa.

mi sembra troppo enfatica la cosa: la "battaglia" tra i 2 principali attori di questo mercato non si limita ad un aspetto come può essere la fisica nei giochi, ne è prova la grande erosione di quote di mercato di Amd a scapito di Nvidia in questi ultimi mesi (che si gioca sul prodotto nel suo complesso)


Vabbè CUDA e 3D.... poi c'è altro?
Certo non mi puoi venire a dire che l'hardware è un capolavoro di ingegneria, altrimenti c'è da rotolarsi a terra.
Mi sembra che quelle schede si comprano per CUDA e 3D, altrimenti con quello che costano, per quale ragione?
Almeno, quelli che l'hanno acquistata, mi hanno detto questo.
Non è nemmeno troppo difficile immaginarlo. ;)

In un linguaggio tecnico, questa si chiama "presa per il culo".

*

mi sembra troppo enfatica la cosa: la "battaglia" tra i 2 principali attori di questo mercato non si limita ad un aspetto come può essere la fisica nei giochi, ne è prova la grande erosione di quote di mercato di Amd a scapito di Nvidia in questi ultimi mesi (che si gioca sul prodotto nel suo complesso)
Ma a me non interessa di quanto si erodono il mercato a vicenda, ovviamente il nocciolo del problema era un altro.
Un panorama del videogioco su PC fatto di tecnologie proprietarie, porterebbe ad una divisione del già striminzito mercato per PC (e sarebbe la botta finale), impedendo ai possessori di un prodotto di utilizzare giochi fatti su misura per il prodotto della controparte.
Se ATI dovesse intraprendere anche lei questa strada, forse chi adesso o non si accorge o fa finta di non accorgersene o, peggio, trova la cosa giusta, forse cambierebbe idea.

Per quanto riguarda l'aumento della quota di mercato ATI, è comunque limitata proprio dalle features proprietarie e dal marketing messo in campo da Nvidia.
Nvidia alla fine ha perso molto poco se si pensa alla situazione verificatasi, con un pesante ritardo nell'uscita di prodotti dx11, con un'offerta attuale carente nel settore mediobasso e con prodotti nel settore alto che, aldilà delle prestazioni (ininfluenti in quanto in linea con i prezzi), sono comunque penalizzati dai consumi e tmp.

Ma ovviamente non era questo il nocciolo della questione, a me interessava il discorso sulle tecnologie proprietarie, su quanto pesano negativamente nell'innovazione impedendo di fatto una concorrenza su terreni comuni e su quanto poi potrebbero pesare qualora ATI imboccasse la stessa strada.

Ma a me non interessa di quanto si erodono il mercato a vicenda, ovviamente il nocciolo del problema era un altro.
Un panorama del videogioco su PC fatto di tecnologie proprietarie, porterebbe ad una divisione del già striminzito mercato per PC, impedendo ai possessori di un prodotto di utilizzare giochi fatti su misura per il prodotto della controparte.
Se ATI dovesse intraprendere anche lei questa strada, forse chi adesso o non si accorge o fa finta di non accorgersene o, peggio, trova la cosa giusta, forse cambierebbe idea.



centrato in pieno il punto. Se si arrivasse a ciò, il mercato pc davvero che chiuderebbe baracca e burattini :rolleyes:

imho nvidia pensa che tra qualche tempo un pc sarà formato da una vga collegata alla corrente..
nei suoi sogni però.
che azienda del cazz*

Sinceramente credo che Nvidia possa fare quello che vuole col proprio prodotto, però da un punto di vista morale sicuramente non è una bella cosa, considerando anche che praticamente ogni compilatore al mondo oggi tira fuori codice SSE2 ottimizzato al posto di codice x87 e che convertire eventuale codice assembly x87 in codice SSE non è difficile. Questo fa in modo che sembri proprio "fatto apposta".

Poi è chiaro , finchè si rispettano le leggi ognuno fa quel che vuole, però certi comportamenti secondo me fanno male a tutti (anche alla reputazione dell'azienda stessa). E' anche una presa in giro nei confronti dei propri utenti e non sto parlando solo dei giocatori, ma anche degli sviluppatori che decidono di usare uno strumento in un progetto e poi lentamente se lo vedono trasformare da buon prodotto in una mossa di marketing.

Sicuramente non è un comportamento che ispira simpatia.

Ciao

Ma a me non interessa di quanto si erodono il mercato a vicenda, ovviamente il nocciolo del problema era un altro.
Un panorama del videogioco su PC fatto di tecnologie proprietarie, porterebbe ad una divisione del già striminzito mercato per PC (e sarebbe la botta finale), impedendo ai possessori di un prodotto di utilizzare giochi fatti su misura per il prodotto della controparte.
Se ATI dovesse intraprendere anche lei questa strada, forse chi adesso o non si accorge o fa finta di non accorgersene o, peggio, trova la cosa giusta, forse cambierebbe idea.

ripeto, mi sembra troppo enfatico quello che dici, un'azienda non può mettersi a collaborare con le altre per forza a scapito dei suoi interessi, ma deve cercare di proporre il proprio prodotto caratterizzandolo rispetto agli altri, punto. Se poi si arrivasse a quello che dici non sarebbe certo colpa di una sola azienda -in questo caso Nvidia- ma di una serie di circostanze

può piacere o meno -ti parla uno che dai tempi della ps1 gioca solo su pc- ma è così

Per quanto riguarda l'aumento della quota di mercato ATI, è comunque limitata proprio dalle features proprietarie e dal marketing messo in campo da Nvidia.Nvidia alla fine ha perso molto poco se si pensa alla situazione verificatasi, con un pesante ritardo nell'uscita di prodotti dx11, con un'offerta attuale carente nel settore mediobasso e con prodotti nel settore alto che, aldilà delle prestazioni (ininfluenti in quanto in linea con i prezzi), sono comunque penalizzati dai consumi e tmp. [QUOTE]

e quindi? Se fosse così - a me risulta che in termini relativi Amd ha fatto passi di gigante in questi mesi in termini di market share- brava Nvidia che ha limitato i danni :boh:

[QUOTE=DukeIT;32557677]Ma ovviamente non era questo il nocciolo della questione, a me interessava il discorso sulle tecnologie proprietarie, su quanto pesano negativamente nell'innovazione impedendo di fatto una concorrenza su terreni comuni e su quanto poi potrebbero pesare qualora ATI imboccasse la stessa strada.

la penso come te, ma non sarebbe colpa di una sola azienda, come dicevo sopra

ad ogni modo il passato finora ha dimostrato che le soluzioni proprietarie hanno fallito, vediamo a questo giro ma non credo sarà diverso prima o poi chissà

Aldilà delle colpe di Nvidia e delle software house a lei accondiscendenti,il problema e che ad oggi Amd\Ati non sembra abbia preso posizione su come vuole affrontare il discorso fisica nei giochi.
Belle parole , open ecc... ma nel concreto ci ritroviamo continuamente con giochi (vedi Mafia 2, ma non solo) che continuano a usare PhysiX.
Ati dovrebbe forzare la mano e implementare qualcosa di suo , cosi forse quando ci saranno giochi pro ati e giochi pro nvidia, qualcuno si adoperera per creare uno standard unico per ciò che concerne la fisica nei giochi. Ati può e deve fare qualcosa.

Comunque alla fine della giostra, ATI e Nvidia possono spingere quello che gli pare, ma NESSUNO se ne sbatterà di pezza se le console (su cui girano i soldi veri) non potranno supportare la "novità"...

chi glielo fa fare agli sviluppatori di spendere per creare contenuti e gameplay aggiuntivi per la versione che rende di meno?

Vedrete che uscita la prossima versione di console si metteranno tutti magicamente d'accordo su come si fa la fisica :asd:

cioè, praticamente nvidia ti da un codice che in presenza di proprie gpu va come un treno, mentre se deve girare su cpu, gira castrato.
e per giunta, se facessero le cose fate per bene, col codice ottimizzato, le performance sarebbero superiori utilizzando una cpu multicore invece di una gpu nvidia.
ho capito bene?

sono solo supposizioni, dubito fortemente che la cpu piu potente attualmente in commercio sia piu potente di una gtx 480 per questo tipo di calcoli imho. Gia facendo un paragone con cuda le gpu sono piu potenti quindi...

e poi il fatto del multithread che cavolo centra (alla redazione). Il paragone va fatto a seconda del numero di chip: se volete vedere come va un quad core allora paragonatelo a 4 gpu...

ma proprio... :doh:

Comunque alla fine della giostra, ATI e Nvidia possono spingere quello che gli pare, ma NESSUNO se ne sbatterà di pezza se le console (su cui girano i soldi veri) non potranno supportare la "novità"...

chi glielo fa fare agli sviluppatori di spendere per creare contenuti e gameplay aggiuntivi per la versione che rende di meno?

Vedrete che uscita la prossima versione di console si metteranno tutti magicamente d'accordo su come si fa la fisica :asd:

Mah, non ne sono così sicuro sinceramente ...

3 console - 3 sistemi completamente diversi.

Una ha 3 core in-order , Shader unificati, memoria framebuffer on-chip per AA veloce, tessellatore, architettura memoria unificata.

Una ha un DSP come processore, shader specializzati, memoria video dedicata seprarata da quella del processore.

Una ha un classico processore PPC come CPU con una GPU fixed function non troppo diversa da una GPU per PC dei tempi delle DX7.

Insomma, mi sembra che è abbastanza difficile arrivare a decidere degli standard sulle console :fagiano:

Più che altro quello che fanno le console è mettere il limite superiore oltre cui nessuno si spinge nello sviluppo. Ad esempio se la console più potente fosse la X360 allora in pochi si metterebbero a sviluppare giochi con grafica più complessa di quanto una X360 potrebbe muovere. Quindi più che decidere gli standard mi sembra che le console decidano la potenza massima dell'hw per cui sviluppare i giochi :fagiano:

Ciao

Devi mettere in conto che il CryEngine incorpora, a sua volta, un engine fisico proprietario... e che, dunque, fra le risorse utilizzate della CPU ci stanno quei calcoli.
Si dovrebbe fare la differenza... se metti su PhysX devi togliere quell'altro.
Meglio non pensarci, secondo me.

No. non intendevo questo. Forse mi sono espresso male.
al di là di crysis, la mia domanda era, ma far eseguire calcoli di fisica, direi anche abbastanza avanzati, alla scheda video non togle risorse per altri tipi di elaborazioni prettamente grafiche. Cioè, mettiamo che per assurdo che Physx e un altro motore fisico siano uguali qualitativamente parlando ma che uno viene elaborato dalla GPU e uno dal Processore. è possibile quindi che un gioco che adotta il secondo motore fisico abbia degli effetti grafici, quali shader, filtri, luci ecc, nettamente superiori visto che la scheda grafica è sgrava della pesante elaborazione della fisica? ovviamente parlo a parità di fps.

la penso come te, ma non sarebbe colpa di una sola azienda, come dicevo sopraNon la vedi come me, semplicemente perchè tu giustifichi che il marketing di un'azienda sia fondato su tecnologie proprietarie.
E' una strategia miope perchè per mantenere la supremazia nel settore VGA si rischia di uccidere il mercato dei giochi su PC, mentre è l'unico campo dove le due aziende non dovrebbero confrontarsi volendo mantenere vivo il games su PC. Dovrebbero esserci obiettivi comuni per mantenere piena compatibilità ed investire assieme per lo sviluppo di titoli di alto contenuto tecnologico per valorizzare un HW al momento costosissimo a fronte di SW scarso di contenuti, spesso porting da consolle. Più che preoccuparsi di non perdere piccole fette di mercato a causa della concorrenza, dovrebbero preoccuparsi della fetta enorme persa a vantaggio delle consolle.
Quando dici che non sarebbe colpa di una sola azienda intendi che se lo fa solo Nvidia non succede nulla, ma se lo fa anche ATI allora si devono dividere le colpe? Al momento ATI sta spingendo su tecnologie aperte, se un domani fosse costretta a ripiegare anche lei su tecnologie proprietarie, non vedo che colpe gli si potrebbe ascrivere.

infatti che c'è di male? :O

sul fatto di "features" ati dorme proprio, non offre niente rispetto a nvidia :muro:

infatti che c'è di male? :O

sul fatto di "features" ati dorme proprio, non offre niente rispetto a nvidia :muro:CVD :rolleyes:

ma ha aperto la fiera delle banalità e non avvertite?

infatti che c'è di male? :O

sul fatto di "features" ati dorme proprio, non offre niente rispetto a nvidia :muro:

beh si...di standard chiusi...ati non ne offre. E' una questione di scelte, strategie e mercato.

Utenti liberi di scegliere da un lato...i lottizzati dall'altro.

No. non intendevo questo. Forse mi sono espresso male.
al di là di crysis, la mia domanda era, ma far eseguire calcoli di fisica, direi anche abbastanza avanzati, alla scheda video non togle risorse per altri tipi di elaborazioni prettamente grafiche. Cioè, mettiamo che per assurdo che Physx e un altro motore fisico siano uguali qualitativamente parlando ma che uno viene elaborato dalla GPU e uno dal Processore. è possibile quindi che un gioco che adotta il secondo motore fisico abbia degli effetti grafici, quali shader, filtri, luci ecc, nettamente superiori visto che la scheda grafica è sgrava della pesante elaborazione della fisica? ovviamente parlo a parità di fps.

PhysX si appoggia su CUDA.
Fermi, se vogliamo parlare dell'ultima serie, è un'architettura sviluppata per lavorare efficientemente in presenza di forte parallelizzazione di più processi.
Impiegare PhysX su queste schede vuol dire aumentarne di parecchio l'efficienza di elaborazione della GPU. Insomma non aspettano altro.
E' indubbio che, anche in questo caso, ci sia un costo in termini di risorse impegnate della GPU.
E certamente se prendiamo un gioco del calibro di Crysis e ritorniamo indietro nel tempo, quando a momenti non c'erano manco single GPU in grado di farlo girare decentemente, probabilmete innestargli un motore fisico ancora più avanzato e affamato di risorse GPU, come PhysX, avrebbe voluto dire ammazzare di tutto punto il framerate. In questi casi si va per configurazioni multi-GPU SLI... se ne assegna una alla fisica e si finsice di far vedere le stelle di mezzogiorno all'altra. :D

In Batman AA PhysX al max e con una single GPU di fascia alta serie GT200 , il processore grafico ti tiene il framerate a fatica intorno ai 60 e forse anche meno.... e non parliamo di alzare le risoluzioni oltre 1280x1024.
Levandogli il carico di PhysX la GPU sciala letteralmente e prende il volo.

Molto meglio Havok!!! :rolleyes:
painkiller, un gioco del 2004, con una fisica ottima, si rompeva di tutto, i nemici saltavano per aria che era una gioia, il fucilozzo apriva in 2 i barili e le porte :D
basato su havock... governato dalla cpu...
ottimo articolo del Corsini, denota come anche hwu evidenzi palesi dubbi (fondati) riguardanti PHysx e le strategia nvidia al riguardo ;)
In particolare la parte conclusiva è molto esplicativa e inequivocabile, Nvidia è ora di cambiare atteggiamento
quoto,
ma si sapeva già ragazzi, a Voi non è mai venuto il dubbio vedendo i cali di performance anche sui quad core? a me si :)

Se nVidia continua con la stessa politica aziendale, probabilmente arriverà all' orlo del fallimento...

e chi sa che magari non venga acquistata da intel

allora si che ci sarebbe da dire furbo+furbo

ma magari riceverebbe la stessa spinta innovativa ricevuta da ati dopo l' acquisizione da parte di amd

@lowentz mi pare logico che opencl stia in stream invece che nei catalyst con la grafica non c'entra nulla
La DLL chiamata dagli applicativi puoi benissimo metterla nei driver, con CUDA è così; è molto comodo in quanto evita il bisogno di mettere l'SDK per avere il supporto :fagiano:, SDK che dovresti installare anche se poi non lo usi per sviluppare nulla ma solo per avere 'sta benedetta DLL.
E visto che è la scheda ad affrire il supporto alle funzionalità a me pare molto più corretto che stia nei driver della scheda (insieme alle altre DLL che fanno da interfaccia tra DX/OpenGL e GPU, indipendentemente dal fatto che la scheda sia "video" o "audio" o "XYZ".....è una scheda) :boh:

Per quanto concerne il supporto multi CPU di PhysX cmq ecco qui una cosa interessante :D

http://www.geeks3d.com/20100521/gpu-tool-physx-fluidmark-1-2-0-available-with-multi-core-cpu-support/

E qui l'articolo originale dove di parla della questione x87:

http://www.realworldtech.com/page.cfm?ArticleID=RWT070510142143

Scusate, non sto seguendo l'intero thread. Ho fatto qualche ricerca in merito alla tesi per cui l'engine Physx in modalità software sia single threaded, cosa che da test effettuati in passato non mi risultava.
Da questi link:
http://www.nvnews.net/vbulletin/showthread.php?t=148558

http://physxinfo.com/news/2001/next-version-of-fluidmark-will-feature-multi-core-cpu-physx-support/

sembra che si tratti di una limitazione delle vecchie versioni del benchmark fluidmark, che qualcuno di AMD ha voluto far passare come essere dovute all'engine.

Ad ogni modo, potete benissimo scaricare un benchmark e verificare di persona (va bene anche il 3DmarkVantage).

Il comando per impostare l'affinità su Vista, 7 e XP x64 è:

start /affinity <numero processore> comando

sono solo supposizioni, dubito fortemente che la cpu piu potente attualmente in commercio sia piu potente di una gtx 480 per questo tipo di calcoli imho. Gia facendo un paragone con cuda le gpu sono piu potenti quindi...

e poi il fatto del multithread che cavolo centra (alla redazione). Il paragone va fatto a seconda del numero di chip: se volete vedere come va un quad core allora paragonatelo a 4 gpu...

ma proprio... :doh:

La fisica dovrebbe essere gestita dagli stream processor. Quindi per paragonare una singola gtx480 a un processore devi trovare un processore con 480 core a 1,4 GHz. E probabilmente il paragone non ti tornerebbe comunque per differenze di bandwidth e perchè dovresti sapere quanti SP sono dedicati in quel momento al physX e regolare di conseguenza i core attivi del processore.

Da semplice utente pc e videogiocatore probabilmente dirò una cavolata assurda, ma è comunque quello che penso:
non ho mai notato eccellenze degne di nota riguardo alla gestione del 3d quando physx era implementato su scheda grafica nvidia (e all'epoca a cui mi riferisco l'avevo, ovviamente), anzi la fisica degli oggetti e dell persone era più o meno identica a quella di giochi ben programmati che non si fregiavano di tali librerie, come ad esempio Half Life 2.
Boh, probabilmente non sono abbastanza raffinato da gustare simili migliorie di precisione nel calcolo, e in ogni caso, ora che ho una ati, ne faccio tranquillamente a meno non sentendone assolutamente la mancanza. :cool:
Sì, se il gioco ne richiede l'installazione e l'esecuzione da cpu procedo, ma mio malgrado, visto anche notizie come queste. :(

Mah, non ne sono così sicuro sinceramente ...

3 console - 3 sistemi completamente diversi.

Una ha 3 core in-order , Shader unificati, memoria framebuffer on-chip per AA veloce, tessellatore, architettura memoria unificata.

Una ha un DSP come processore, shader specializzati, memoria video dedicata seprarata da quella del processore.

Una ha un classico processore PPC come CPU con una GPU fixed function non troppo diversa da una GPU per PC dei tempi delle DX7.

Insomma, mi sembra che è abbastanza difficile arrivare a decidere degli standard sulle console :fagiano:

Più che altro quello che fanno le console è mettere il limite superiore oltre cui nessuno si spinge nello sviluppo. Ad esempio se la console più potente fosse la X360 allora in pochi si metterebbero a sviluppare giochi con grafica più complessa di quanto una X360 potrebbe muovere. Quindi più che decidere gli standard mi sembra che le console decidano la potenza massima dell'hw per cui sviluppare i giochi :fagiano:

Ciao

I soldi so il meglio standard :D

Per cui si sviluppa semplicemente per il minimo comun denominatore alla faccia di tutte le simpatiche specifiche che mi hai postato.
qualsiasi altra spesa diventa arrischiata e potenzialmente non remunerativa.
Figurarsi supportare la fisica su schede possedute da una minoranza di una minoranza (il mercato pc).
E' puro marketing, non c'è nessun motivo tecnico.

Per quanto concerne il supporto multi CPU di PhysX cmq ecco qui una cosa interessante

http://www.geeks3d.com/20100521/gpu...re-cpu-support/


Scusate, non sto seguendo l'intero thread. Ho fatto qualche ricerca in merito alla tesi per cui l'engine Physx in modalità software sia single threaded, cosa che da test effettuati in passato non mi risultava.
Da questi link:
http://www.nvnews.net/vbulletin/showthread.php?t=148558

http://physxinfo.com/news/2001/next-version-of-fluidmark-will-feature-multi-core-cpu-physx-support/

sembra che si tratti di una limitazione delle vecchie versioni del benchmark fluidmark, che qualcuno di AMD ha voluto far passare come essere dovute all'engine.

con tutto il rispetto... se è il programmatore a dover esplicitamente creare, sincronizzare e gestire i thread, allora è il programma ad essere multithread, non l'engine fisio. Per poter dire che PhysX supporta più thread, dovrebbe essere lo stesso SDK a gestire i thread e tutte le sue funzioni.

Questa dichiarazione nVidia conferma che PhysX non è multithread nel senso più corretto del termine:
“Our PhysX SDK API is designed such that thread control is done explicitly by the application developer, not by the SDK functions themselves."


E qui l'articolo originale dove di parla della questione x87:

http://www.realworldtech.com/page.c...RWT070510142143

questo link cosa dimostra, a parte che nvidia lo fa solo esclusivamente per interessi personali?

"The truth is that there is no technical reason for PhysX to be using x87 code. PhysX uses x87 because Ageia and now Nvidia want it that way. Nvidia already has PhysX running on consoles using the AltiVec extensions for PPC, which are very similar to SSE. It would probably take about a day or two to get PhysX to emit modern packed SSE2 code, and several weeks for compatibility testing. In fact for backwards compatibility, PhysX could select at install time whether to use an SSE2 version or an x87 version – just in case the elusive gamer with a Pentium Overdrive decides to try it. "

con tutto il rispetto... se è il programmatore a dover esplicitamente creare, sincronizzare e gestire i thread, allora è il programma ad essere multithread, non l'engine fisio. Per poter dire che PhysX supporta più thread, dovrebbe essere lo stesso SDK a gestire i thread e tutte le sue funzioni.

Questa dichiarazione nVidia conferma che PhysX non è multithread nel senso più corretto del termine:
“Our PhysX SDK API is designed such that thread control is done explicitly by the application developer, not by the SDK functions themselves."



questo link cosa dimostra, a parte che nvidia lo fa solo esclusivamente per interessi personali?

"The truth is that there is no technical reason for PhysX to be using x87 code. PhysX uses x87 because Ageia and now Nvidia want it that way. Nvidia already has PhysX running on consoles using the AltiVec extensions for PPC, which are very similar to SSE. It would probably take about a day or two to get PhysX to emit modern packed SSE2 code, and several weeks for compatibility testing. In fact for backwards compatibility, PhysX could select at install time whether to use an SSE2 version or an x87 version – just in case the elusive gamer with a Pentium Overdrive decides to try it. "

Con tutto il rispetto, se c'è un solo processo (e l'ho appena verificato...) in esecuzione, che sfrutta tutti i processori, allora l'engine è multi-threaded.

Sarebbe single threaded se venissero avviate più istanze del processo, ma non è quello che succede: viene avviato un solo processo che sfrutta più processori, cioè....multi-threaded. Poco importa a quale livello viene implementata la gestione, se non per futili speculazioni partigiane. Quello che conta è che le prestazioni aumentino con il numero di core in gioco, cosa che avviene.

Ad ogni modo, il benchmark fluidmark è strano: ho appena verificato che per sfruttare più processori dovete impostare un numero di ugelli ("emitters") pari al numero di processori.

Per favore, nella seconda parte del tuo quote stai riferendo erroneamente a me un messaggio di Lowenz, potresti editare?, non è carino.

Con tutto il rispetto, se c'è un solo processo (e l'ho appena verificato...) in esecuzione, che sfrutta tutti i processori, allora l'engine è multi-threaded.

Sarebbe single threaded se venissero avviate più istanze del processo, ma non è quello che succede: viene avviato un solo processo che sfrutta più processori, cioè....multi-threaded. Poco importa a quale livello viene implementata la gestione, se non per futili speculazioni partigiane. Quello che conta è che le prestazioni aumentino con il numero di core in gioco, cosa che avviene.
ma non puoi contestare chi dice che l'engine non è multi-threaded, perché di fatto non lo è; l'engine sarebbe multihread se fosse lui a gestirli, in questo caso è l'applicazione che li crea e gestisce totalmente, è il programmatore deve fare tutto per conto suo, sono due livelli di astrazione completamente diversi.

PS: di quanto aumentano le prestazioni con più core?

Per favore, nella seconda parte del tuo quote stai riferendo erroneamente a me un messaggio di Lowenz, potresti editare?, non è carino.corretto

ma non puoi contestare chi dice che l'engine non è multi-threaded, perché di fatto non lo è; l'engine sarebbe multihread se fosse lui a gestirli, in questo caso è l'applicazione che li crea e gestisce totalmente, è il programmatore deve fare tutto per conto suo, sono due livelli di astrazione completamente diversi.

PS: di quanto aumentano le prestazioni con più core?


Con 10000 particelle e 2 emitters passo da 19 FPS a 39 FPS (la cpu è quella infirma, quindi un dual core). Con un solo emitter il frame rate è 19 si in modalità single che multi threaded. Chi ha un quad core dovrebbe impostare 4 emitters.

Secondo me, con l'affermazione "Physx da cpu è single thread" non si trasmette l'informazione corretta, lasciando intendere che non ci sia modo per gli sviluppatori di sfruttare più più core, mentre con un opportuno design la cosa è fattibilissima. Peraltro, di base il multi threading richiede una programmazione specifica dell'applicazione, non è sufficiente il supporto di hardware e sistema operativo, quindi non mi sembra nemmeno una limitazione cosi' eclatante. Alla fine contano le prestazioni, per l'utenza il livello di astrazione è irrilevante.

infatti che c'è di male? :O

sul fatto di "features" ati dorme proprio, non offre niente rispetto a nvidia :muro:

sarà forse perchè Ati, creando schede video, si preoccupi che funzionino come schede video e nient'altro, come trovo giusto che sia.

e non venitemi a dire "ma la potenza delle gpu è talmente tanta che sarebbe uno spreco non utilizzarla per altro" mentre ci sono ancora giochi che non girano a dovere con le attuali gpu di ultima generazione e non appena usciranno le nuove console la potenza delle gpu non sarà più sufficiente e feature come physix e 3d saranno proibitive.

io continuo a non capire il problema...nvidia ha comprato una tecnologia...è ovvio che spinga perchè venga utilizzata solo dalla sue schede e non ha interesse che sia ottimizzata ed eseguita sulle CPU

ma pensate che ATI avesse fatto diversamente se avesse avuto la possibilità?

e poi avrei una domanda:
non è cmq meglio che la fisica lavori sulla GPU piuttosto che sulla CPU? a me sembra che le ultime schede siano sovradimensionate rispetto al loro utilizzo e che spesso il collo di bottiglia sia la CPU...ora puo' essere vero che a parità di ottimizzazione la fisica girerebbe meglio su CPU ma cmq sarebbe un elemento in più che questa dovrebbe elaborare.

L'ideale sarebbe che a seconda del carico switchasse tra CPU e GPU...però ripeto, Nvidia come tutte le altre società del mondo pensa ai propri utili quindi vedo difficile che si avveri una tale situazione

.....
.....Levandogli il carico di PhysX la GPU sciala letteralmente e prende il volo.

era proprio questo che intendevo.

Un altra cosa: ma in teoria può esistere un motore fisico, super ottimizzato per cpu multicore, che abbia qualità superiore a PhysX e che non impatti sulle prestazioni generali?
è vero che una cpu quad core può eseguire solo 8 thread contemporaneamente (Hyper-Threading), ma va anche a 4 volte la frequenza di una gpu e come potenza di calcolo non scherza mica.

a questo punto direi che sarebbe più sensato tornare all'approccio dell'acceleratore fisico separato, che è ottimizzato per quel lavoro, così da non sprecare una seconda gpu per calcolare solo la fisica e avere delle componenti di quest'ultima non utilizzate.

è intel che possiede havok, pensa quanta voglia ha essa.

beh ad amd va sempre bene sia dire

guardate havock va a palla sulla gpu!!!

oppure

guradate havock va a palla sulle cpu multicore

che gli frega a loro?

e poi il fatto del multithread che cavolo centra (alla redazione). Il paragone va fatto a seconda del numero di chip: se volete vedere come va un quad core allora paragonatelo a 4 gpu...



e come no!

4 core 1 chip
4 gpu 4 chip

per assurdo allora visto che una gpu è multicore tipo 480 unità paragoniamola a 480 cpu!

@ hermanss

ahahahahaahhahahaha, simpatico questo if XD

Oddio, dicono che senza usare le SSE portano Physix compatibile su qualsiasi processore. A me risulta che le SSE sono disponbili dai Pentium 3... E sfido chiunque a giocare su un processore minore del P3 con physix... Ipocrisia???
Eh si, physix è proprietario però certe cavolate per favore evitatele...
Gpu gpu gpu gpu... Chissà le CPU che fine faranno...Non capisco cosa centra. Forse non è così ovvio il pensare che le istruzioni sono più o meno efficaci anche in relazione all'hardware che si utilizza? E poi non è escluso che si trattasse di un generico SSE che prevede tutte le sue release.

io continuo a non capire il problema...nvidia ha comprato una tecnologia...è ovvio che spinga perchè venga utilizzata solo dalla sue schede e non ha interesse che sia ottimizzata ed eseguita sulle CPU

ma pensate che ATI avesse fatto diversamente se avesse avuto la possibilità?

e poi avrei una domanda:
non è cmq meglio che la fisica lavori sulla GPU piuttosto che sulla CPU? a me sembra che le ultime schede siano sovradimensionate rispetto al loro utilizzo e che spesso il collo di bottiglia sia la CPU...ora puo' essere vero che a parità di ottimizzazione la fisica girerebbe meglio su CPU ma cmq sarebbe un elemento in più che questa dovrebbe elaborare.

L'ideale sarebbe che a seconda del carico switchasse tra CPU e GPU...però ripeto, Nvidia come tutte le altre società del mondo pensa ai propri utili quindi vedo difficile che si avveri una tale situazionePer diminiure il collo di bottiglia causato dalla cpu, o lavori a risoluzioni maggiori oppure aumenti il clock della cpu. Aumentare il numero di core non avrebbe senso. Se consideriamo che un quad core è utilizzato molto difficilmente in ambito game, vedi allora che le risorse non sono sfruttate al 100% e se la fisica venisse elaborata da questi core inutilizzati con tutta probabilità l'effetto collo non sarebbe maggiore.

infatti che c'è di male? :O

sul fatto di "features" ati dorme proprio, non offre niente rispetto a nvidia :muro:

certo, infatti nvidia permette di veicolare audio hd in bitstream via hdmi con le nuove fermi fiammanti, è si :stordita:

ma ha aperto la fiera delle banalità e non avvertite?

forse mandavano gli inviti via mail, meglio controllare :D

Il sospetto aleggiava già da tempo...non era possibile che per quegli effetti fisici si aveva un crollo totale inspiegabile se calcolati su CPU, ci doveva essere per forza qualcosa che non andava....ora se ne ha una parziale spiegazione, non che la cosa mi sconvolga (Nvidia ha la proprietà di questa tecnologia quindi nessuno la può obbligare ad ottimizzare il codice per CPU) però è certamente un peccato che questa tecnologia non sia sfruttata appieno, senza contare che le applicazioni di Physx viste sino ad ora sono state abbastanza deludenti o laddove non deludenti altamente esose in termini di risorse.

A questo punto sarei curioso di sapere se prestazionalmente parlando sia meglio fare girare Physx su GPU come ora oppure su CPU con codice ottimizzato...:fagiano:

A questo punto sarei curioso di sapere se prestazionalmente parlando sia meglio fare girare Physx su GPU come ora oppure su CPU con codice ottimizzato...:fagiano:

Mi pare che nell'articolo si dica proprio questo.
Physx (o altro engine fisico) girerebbe molto meglio su una CPU dedicata, cosa per altro fattibilissima con i multicore che per ora, sono sfruttati molto poco.

Cmq a me spiace per quelle softwarehouse che si "vendono" per pubblicizzare sto schifo. Perchè alla lunga è una cosa che danneggia tutto il mercato PC, e si ritorce come un boomerang.

Io penso che non abbiano modificato il codice di ageia se non qualche bugfix, quindi la mandragata l'avrebbe fatta ageia a suo tempo per far vedere la potenza delle loro schede e come fossero scarse le cpu per i calcoli fisici, e nvidia ha abboccato. Ovviamente nvidia non ha alcun interesse nell'investire tempo e risorse ad ottimizzare il codice per la cpu, mi sembra anche normale altrimenti si darebbe la zappa sui piedi!

Mi pare che nell'articolo si dica proprio questo.
Physx (o altro engine fisico) girerebbe molto meglio su una CPU dedicata, cosa per altro fattibilissima con i multicore che per ora, sono sfruttati molto poco.

Cmq a me spiace per quelle softwarehouse che si "vendono" per pubblicizzare sto schifo. Perchè alla lunga è una cosa che danneggia tutto il mercato PC, e si ritorce come un boomerang.
Nell'articolo si dice:

E' ipotizzabile, del resto, che le prestazioni di una CPU multicore con codice PhysX ottimizzato multithreaded e con SSE possa risultare essere ben più veloce di quanto ottenibile con una GPU NVIDIA di ultima generazione.

Quindi non è sicuro (anche perchè bisognerebbe vedere come si comporta a seconda della CPU) vorrei saperlo con più certezza....
Io penso che non abbiano modificato il codice di ageia se non qualche bugfix, quindi la mandragata l'avrebbe fatta ageia a suo tempo per far vedere la potenza delle loro schede e come fossero scarse le cpu per i calcoli fisici, e nvidia ha abboccato. Ovviamente nvidia non ha alcun interesse nell'investire tempo e risorse ad ottimizzare il codice per la cpu, mi sembra anche normale altrimenti si darebbe la zappa sui piedi!
Certamente...anzi a quel tempo era ancora più evidente e pure peggio dato che dovevi aggiungere per forza un'altra scheda (PPU) oltre alla GPU (e ovviamente alla CPU).

Nell'articolo si dice:

E' ipotizzabile, del resto, che le prestazioni di una CPU multicore con codice PhysX ottimizzato multithreaded e con SSE possa risultare essere ben più veloce di quanto ottenibile con una GPU NVIDIA di ultima generazione.

Quindi non è sicuro (anche perchè bisognerebbe vedere come si comporta a seconda della CPU) vorrei saperlo con più certezza....

Certamente...anzi a quel tempo era ancora più evidente e pure peggio dato che dovevi aggiungere per forza un'altra scheda (PPU) oltre alla GPU (e ovviamente alla CPU).

Mi sembra improbabile che in 5 anni non abbiano toccato il codice di Ageia ... soprattutto quando sono stati in grado ti tirare fuori versioni di Physx per PS3, Wii e X360 che funzionano perfettamente usando istruzioni di tipo vettoriale (AltiVec) al contrario di quello che succede su x86.

Mi sembra improbabile che in 5 anni non abbiano toccato il codice di Ageia ... soprattutto quando sono stati in grado ti tirare fuori versioni di Physx per PS3, Wii e X360 che funzionano perfettamente usando istruzioni di tipo vettoriale (AltiVec) al contrario di quello che succede su x86.
Per console certamente che hanno toccato il codice (non avevano alternative) pero' su PC si portano ancora dietro il "peccato originale" di castrare la CPU compiuto da Ageia.

Ma io tutto sto scandalo io non lo vedo.
Mi pare normale che Nvidia col suo soft, favorisca il suo hardware.
Che forse i compilatori Intel producono codice super ottimizzato per CPU AMD?!

Poi per dire, chi vieta ai produttori di CPU, finanziariamente ben più grandi di nvidia, di produrre un motore fisico software per cpu con relativo toolkit da distribuire ai game developer in modo da implementare altri motori oltre a PhysX, che sfrutti e faccia vendere i loro n-mille icori?!

Perchè "dovrebbe" interessare a Nvidia il supporto pieno alle CPU? Beneficenza a Intel?

Evidentemente il game su pc è in netto declino e non interessa più cosi tanto economicamente ad Intel, e in seconda battuta ad Amd che però comunque dispone della sua implementazione per GPU.

il mercato dei videogiochi sarà pure in declino, ma lo prendono in saccoccia le SH, perchè su PC ormai piratano la qualunque. Di certo se c'è una cosa che spinge molti utenti a prendere processori sempre più potenti, sono proprio i videogiochi.

Cmq il quesito di essential__60 è giusto. Perchè ad esempio Intel si disinteressa totalmente della cosa?
Non escluderei una questione di miopia, ma magari lo stanno facendo visto l'andazzo, e la situazione sarà destinata a cambiare, chissà

certo, infatti nvidia permette di veicolare audio hd in bitstream via hdmi con le nuove fermi fiammanti, è si :stordita:


Ghiltanas, questa frase non l'ho capita: a meno che le cose non siano cambiate, le GPU dall'uscita HDMI si limitano a trasmettere quello che ricevono dalla scheda audio tramite l'apposito doppino, quindi non possono essere accusate di nulla....

EDIT: ho capito, le cose sono cambiate, adesso é prevista la veicolazione del flusso audio tramite lo slot PCI-express....
Ad ogni modo, dubito che chi assembla un HTPC pensi ad un Fermi da 150-300W.

Per console certamente che hanno toccato il codice (non avevano alternative) pero' su PC si portano ancora dietro il "peccato originale" di castrare la CPU compiuto da Ageia.

Comprando Ageia hanno comprato anche il peccato originale. Inoltre non credo che il codice di PhysX dal 2005 sia rimasto lo stesso. Sicuramente sarà stato rimaneggiato, aggiornato e possibilmente espanso a livello di funzionalità e nel farlo non hanno neanche scritto il nuovo codice con le estensioni.

Comunque anche nel caso (improbabile) in cui semplicemente il codice x86 di Physx sia lo stesso identico di Ageia del 2005, fare a finta di non vedere non li riabilita davanti ai miei occhi.

Ghiltanas, questa frase non l'ho capita: a meno che le cose non siano cambiate, le GPU dall'uscita HDMI si limitano a trasmettere quello che ricevono dalla scheda audio tramite l'apposito doppino, quindi non possono essere accusate di nulla....

EDIT: ho capito, le cose sono cambiate, adesso é prevista la veicolazione del flusso audio tramite lo slot PCI-express....
Ad ogni modo, dubito che chi assembla un HTPC pensi ad un Fermi da 150-300W.

Ghiltanas ironizzava, rispondendo ad un utente che sosteneva che le ATI dal lato features non avessero granchè, quando invece, per esempio, la serie 5000 riesce a veicolare audio HD come schede audio quali la Xonar HDAV o la Auzentech HT, mentre le Fermi no. Tant'è vero che a leggere nel forum di AVMagazine mi pare che in ambito HTPC le ATI siano la scelta più diffusa.

Ghiltanas ironizzava, rispondendo ad un utente che sosteneva che le ATI dal lato features non avessero granchè, quando invece, per esempio, la serie 5000 riesce a veicolare audio HD come schede audio quali la Xonar HDAV o la Auzentech HT, mentre le Fermi no. Tant'è vero che a leggere nel forum di AVMagazine mi pare che in ambito HTPC le ATI siano la scelta più diffusa.

Si, seguardi avevo giá trovato la risposta.

e come no!

4 core 1 chip
4 gpu 4 chip

per assurdo allora visto che una gpu è multicore tipo 480 unità paragoniamola a 480 cpu!

:doh:

era proprio questo che intendevo.

Un altra cosa: ma in teoria può esistere un motore fisico, super ottimizzato per cpu multicore, che abbia qualità superiore a PhysX e che non impatti sulle prestazioni generali?
è vero che una cpu quad core può eseguire solo 8 thread contemporaneamente (Hyper-Threading), ma va anche a 4 volte la frequenza di una gpu e come potenza di calcolo non scherza mica.

a questo punto direi che sarebbe più sensato tornare all'approccio dell'acceleratore fisico separato, che è ottimizzato per quel lavoro, così da non sprecare una seconda gpu per calcolare solo la fisica e avere delle componenti di quest'ultima non utilizzate.

Beh, si puo' sempre migliorare; è difficile ritenere che meglio di PhysX in futuro non si possa fare... ma se corriamo bruciamo le tappe.
A dirla tutta, attualmente, nessuna SH ha interesse a esasperare la fisica a livello di PhysX... anche perché le console non ce la fanno.
Per questo Havok derivati e similari bastano e avanzano; PhysX è un interesse principalmente di nVidia. PhysX è uno forte strumento di marketing.
Se nVidia non lo libera da quella morsa, sarà vista sempre come la percora nera del gregge.

Per quanto puoi ottimizzare il codice in multithreading... cioè non possiamo pretendere poi di lavorare bene e non consumare niente o poco.... avere, come si dice, la botte piena e la moglie ubriaca. :D
Prendendo come riferimento l'articolo, migrando verso una versione PC dell'engine PhysX convertito per istruzioni SSE il guadagno teorico rispetto alla ver. x87 dovrebbe attestarsi intorno al 200% per processo o thread (così ho letto altrove); con un quad core e tutti i nuclei extra logici (qualora ci fossero) a disposizione, si raggiungerebbero risultati vicini o uguali a PhysX lato GPU.... ma la CPU comunque dovrà darsi da fare e sudare.
Beh sì, la CPU potrebbe sollevare la GPU dall'onere che proviene dai calcoli della fisica ed eventualmente permettere alla seconda di concentrarsi più sui filtri.

con tutto il rispetto... se è il programmatore a dover esplicitamente creare, sincronizzare e gestire i thread, allora è il programma ad essere multithread, non l'engine fisio. Per poter dire che PhysX supporta più thread, dovrebbe essere lo stesso SDK a gestire i thread e tutte le sue funzioni.

Questa dichiarazione nVidia conferma che PhysX non è multithread nel senso più corretto del termine:
“Our PhysX SDK API is designed such that thread control is done explicitly by the application developer, not by the SDK functions themselves."



questo link cosa dimostra, a parte che nvidia lo fa solo esclusivamente per interessi personali?

"The truth is that there is no technical reason for PhysX to be using x87 code. PhysX uses x87 because Ageia and now Nvidia want it that way. Nvidia already has PhysX running on consoles using the AltiVec extensions for PPC, which are very similar to SSE. It would probably take about a day or two to get PhysX to emit modern packed SSE2 code, and several weeks for compatibility testing. In fact for backwards compatibility, PhysX could select at install time whether to use an SSE2 version or an x87 version – just in case the elusive gamer with a Pentium Overdrive decides to try it. "
Non doveva dimostrare niente, era solo l'articolo originale :confused: :mbe:

In un linguaggio tecnico, questa si chiama "presa per il culo".

E' lo stesso discorso dei compilatori Intel che penalizzano i proci AMD... Il software, sull'hw avversario gira male, così il mio sembra piùffigo di quel che in realtà è, ma gira. Così evito beghe con antitrust e organi vari.

ma anke no http://www.appuntidigitali.it/10525/gcc-il-miglior-compilatore-al-mondo/ leggi i commenti

Non posso che inchinarmi davanti all'articolo di Corsini.
Davvero complimenti, ottima analisi :ave:.

Con 10000 particelle e 2 emitters passo da 19 FPS a 39 FPS (la cpu è quella infirma, quindi un dual core). Con un solo emitter il frame rate è 19 si in modalità single che multi threaded. Chi ha un quad core dovrebbe impostare 4 emitters.

Secondo me, con l'affermazione "Physx da cpu è single thread" non si trasmette l'informazione corretta, lasciando intendere che non ci sia modo per gli sviluppatori di sfruttare più più core, mentre con un opportuno design la cosa è fattibilissima. Peraltro, di base il multi threading richiede una programmazione specifica dell'applicazione, non è sufficiente il supporto di hardware e sistema operativo, quindi non mi sembra nemmeno una limitazione cosi' eclatante. Alla fine contano le prestazioni, per l'utenza il livello di astrazione è irrilevante.
in pratica, questa storia degli emitters, mi fa capire che quel benchmark crea un thread per ogni emitter, e sono gestisti in maniera indipendente, i flussi di particelle non si incontrano mai... questo è un trucchetto che può andare bene in un benchmark, ma in un gioco è già più difficile creare dei thread totalmente indipendenti che permettano miglioramenti di prestazioni (che so', il programmatore potrebbe creare un thread per ogni finestra che si rompe, ma non è che durante il gioco uno si mette a rompere tutte le finestre contemporaneamente, quindi le prestazioni rimangono limitate al singolo core)

Se il motore fisico fosse multi-thread alla base, vedresti le prestazioni aumentare su più core, già con un solo emitter.

Non doveva dimostrare niente, era solo l'articolo originale :confused: :mbe:
appunto visto che non dice niente di diverso da quello che c'è scritto nella news, e che nella stessa news c'è il link non capivo il senso di inserirlo in quel contesto.

C'è da notare anche che, al contrario di un benchmark sintetico che falsa i valori in campo per via di carichi differenti, un videogame moderno occupa al 100% la gpu, mentre occupa relativamente poco una cpu multi-core... Quindi le differenze prestazionali, se ottimizzate in entrambi i casi, sarebbero tra una gpu già molto occupata nel rendering, filtri, etc, e una cpu che per metà del tempo dorme... se non addirittura alcuni core interi.

in pratica, questa storia degli emitters, mi fa capire che quel benchmark crea un thread per ogni emitter, e sono gestisti in maniera indipendente, i flussi di particelle non si incontrano mai... questo è un trucchetto che può andare bene in un benchmark, ma in un gioco è già più difficile creare dei thread totalmente indipendenti che permettano miglioramenti di prestazioni (che so', il programmatore potrebbe creare un thread per ogni finestra che si rompe, ma non è che durante il gioco uno si mette a rompere tutte le finestre contemporaneamente, quindi le prestazioni rimangono limitate al singolo core)

Se il motore fisico fosse multi-thread alla base, vedresti le prestazioni aumentare su più core, già con un solo emitter.

Non ricordo bene se i flussi si toccassero, mi sembra pero' che formavano una pozza sulle sfere, e quindi interagissero fra di loro. Piu' che un trucchetto, mi sembra una limitazione propria di questo benchmark, che probabilmente era nato come single thread, ed é stato rappezzato. Non so perché sostieni che i thread siano gestiti in maniera indipendente, non mi risulta che il multi-threading implichi necessariamente rigidi compartimenti stagni, se cosi' fosse nei giochi multi-thread gli asset non potrebbero interagire fra di loro.

Francamente, a me viene da dire l'esatto contrario: é praticamente impossibile che in un gioco ci sia un solo oggetto che si muove in un certo istante, quindi, c'é ampio spazio per assegnare thread a volontá in maniera semplice. Secondo me, se il gioco é multi-thread, non credo ci sia alcuna difficoltá a sfruttare appieno l'engine fisico. E' ovvio che se l'intero gioco é single thread, non mi aspetto che l'engine sia multi thread (anche se c'é qualche titolo che é impostato cosi', ad esempio Crysis, che comunque non utilizza Physx).

Sarebbe interessante effettuare qualche test con altre applicazioni. Mi vengono in mente Warmonger e la demo di Cryostasis, ma il primo non mi sembra che abbia un bench integrato, il secondo temo che sia single threaded.

Ghiltanas, questa frase non l'ho capita: a meno che le cose non siano cambiate, le GPU dall'uscita HDMI si limitano a trasmettere quello che ricevono dalla scheda audio tramite l'apposito doppino, quindi non possono essere accusate di nulla....

EDIT: ho capito, le cose sono cambiate, adesso é prevista la veicolazione del flusso audio tramite lo slot PCI-express....
Ad ogni modo, dubito che chi assembla un HTPC pensi ad un Fermi da 150-300W.

a dire il vero ati veicola l'audio da un pezzo, per la precisione dalla serie 2000 ;) (anche se solo con le 5000 si può avere anche l'audio hd in bitstream)

Possono farlo eccome, NVidia aveva proposto a sviluppatori indipendenti aiuto per avere il supporto a CUDA (e quindi a PhysX) sulle Radeon, ma ATI ha detto no (per non favorire la diffusione dello standard avversario).

->http://www.tomshardware.com/news/nvidia-ati-physx,5841.html

Eran Badit editor-in-chief of ngohq.com posted an update to the events of last week. He confirmed that he is receiving support from Nvidia to get PhysX to run on ATI cards. "It’s very impressive, inspiring and motivating to see Nvidia’s view on this," he wrote. He believes that Nvidia most likely wants to "take on Intel with CUDA and to deal with the latest Havok threat from both AMD and Intel."

He also noted that he made progress getting his hands on a Radeon 4800 card and noted that his CUDA Radeon library is "almost done." Badit said that "there are some issues that need to be addressed, since adding Radeon support in CUDA isn’t a big deal - but it’s not enough! We also need to add CUDA support on AMD’s driver level and its being addressed as we speak."

AMD ha fatto bene (campanilisticamente) a dir di no, perché con un supporto così blando al di fuori di nVidia la piattaforma tenderà ad autoestinguersi visto che i programmatori ci penseranno 50 volte prima di applicarla ad un titolo e rischiare di tagliarsi fuori da metà del mercato.

Per il resto PhysX una volta non girava sull'hardware Ageia ?
Che chip montava quella cavolo di card ?

Dalla testata THNQ....

http://www.thinq.co.uk/2010/7/8/nvidia-were-not-hobbling-cpu-physx/

Bryan Del Rizzo, Nvidia's senior PR manager, says:

Nvidia: We're not hobbling CPU PhysX
SSE will soon be enabled by defaul

Non si erano accorti che non ci fossero. Non li biasimo. :D
Il codice ereditato da Ageia, del resto, li mette in condizione di fare gli gnorry.
Mi pare giusto! :rolleyes:

Estratto pagina 1:

Speaking to THINQ, Nvidia's senior PR manager Bryan Del Rizzo said "any assertion that we are somehow hamstringing the CPU is patently false." Del Rizzo states that "Nvidia has and will continue to invest heavily on PhysX performance for all platforms - including CPU-only on the PC."

Touché!

Estratto pagina 2:

In addition to the new multi-threading features, Del Rizzo also says "SSE will be turned on by default" in the new SDK. However, he notes that "not all developers want SSE enabled by default, because they still want support for older CPUs for their software versions." The original

Quanti sviluppatori potrebbero impiegare PhysX in una CPU obsoleta e soprattutto a quale livello di implementazione? (.... quando un i7 trattato in single thread all'atto pratico e per un po' di fisica a momenti annaspa)
Che gli fanno simulare? Il movimento e la caduta di una singola briciola da un tavolo?
Ah Bryan...Bryan!!! :friend:
Che situazione imbarazzante!!! :mc:

physix è utile nei giochi quanto un pomello di una porta attaccato con la superattack su un sportello di una Ferrari

Le SSE sono state introdotte sui Pentium 3... ci sono programmatori che scrivono giochi che richiedono Phys-X su Pentium 2 ? (ah, lo SLOT1, che nostalgia...)
E'troppo difficile fare un check a runtime e scegliere la libreria adatta (liscia o SSE) in base alla CPU ?

...smells like bullshit.

Peraltro sono strasicuro che il codice Ageia facesse schifo, lo usavano come specchietto per le allodole per venderti il LORO hardware... di sicuro non ottimizzavano nulla (anzi, sparavano demo improbabili in cui si faceva di tutto per mettere in luce l' inadeguatezza della soluzione "CPU only" -magari anche DISOTTIMIZZARE il "driver" CPU only per avere migliori margini).

Le SSE sono state introdotte sui Pentium 3... ci sono programmatori che scrivono giochi che richiedono Phys-X su Pentium 2 ? (ah, lo SLOT1, che nostalgia...)
E'troppo difficile fare un check a runtime e scegliere la libreria adatta (liscia o SSE) in base alla CPU ?

Non è difficile, ma poichè per sfruttare decentemente le SSE non è sufficiente ricompilare con qualche magica opzione di ottimizzazione, ma bisogna adeguare il codice, questo tutorial è abbastanza interessante come esempio

http://www.codeproject.com/KB/recipes/sseintro.aspx

poichè Ageia e quindi PhysX sono stati comprati unicamente per veicolare la vendita di hardware nVidia, e non per creare chissà quale rivoluzione, cosa che abbiamo tutti verificato con le prime demo che giravano su Ageia, che interesse avrebbe avuto nVidia a favorire le cpu multi-core con sse1/2/3..n dei due competitor AMD e Intel ?

Dal tutorial che ho postato per ottimizzare con le SSE un algoritmo che calcola la radice quadrata della somma degli elementi di due array bisogna praticamente riscriverlo tutto, e sono 10 righe di codice, le righe di codice di PhysX che potrebbero essere ottimizzate con SSE sfruttando istruzioni packed quante sono, 10, 100, 100000 ?

Insomma a che pro investire tempo/soldi/risorse, per agevolare hardware che non è il proprio ?

Non è difficile, ma poichè per sfruttare decentemente le SSE non è sufficiente ricompilare con qualche magica opzione di ottimizzazione, ma bisogna adeguare il codice, questo tutorial è abbastanza interessante come esempio

http://www.codeproject.com/KB/recipes/sseintro.aspx

poichè Ageia e quindi PhysX sono stati comprati unicamente per veicolare la vendita di hardware nVidia, e non per creare chissà quale rivoluzione, cosa che abbiamo tutti verificato con le prime demo che giravano su Ageia, che interesse avrebbe avuto nVidia a favorire le cpu multi-core con sse1/2/3..n dei due competitor AMD e Intel ?

Dal tutorial che ho postato per ottimizzare con le SSE un algoritmo che calcola la radice quadrata della somma degli elementi di due array bisogna praticamente riscriverlo tutto, e sono 10 righe di codice, le righe di codice di PhysX che potrebbero essere ottimizzate con SSE sfruttando istruzioni packed quante sono, 10, 100, 100000 ?

Insomma a che pro investire tempo/soldi/risorse, per agevolare hardware che non è il proprio ?

Io ironizzavo sul tizio di nVidia che diceva "beh, aggiungeremo il supporto SSE, ma non so quanto piacerà ai programmatori visto che c'è chi sviluppa titoli per piattaforme che non hanno SSE".
Per il resto capisco perfettamente l'interesse di nVidia a NON ottimizzare il codice CPU.

In coda... so che non è facile riscrivere codice SISD perché vada in SIMD, ma tutto considerato quelli di nVidia qualcosa dovrebbero capirci visto che SIMD e MIMD sono il loro pane quotidiano (ed anche il multithreading non dovrebbe sconvolgerli più di tanto).

tanto rumore per nulla:

Nvidia is apparently planning to introduce new automatic multi-threading features in the forthcoming PhysX 3.0 SDK.

This "uses a task-based approach that was developed in conjunction with our Apex product to add in more automatic support for multi-threading," explains Dell Rizzo.

The new SDK will automatically take advantage of however many cores are available, or the number of cores set by the developer, and will also provide the option of a "thread pool" from which "the physics simulation can draw resources that run across all cores."

http://www.thinq.co.uk/2010/7/8/nvidia-were-not-hobbling-cpu-physx/

edit: letto che era già stato postato; @gnick79: libero di fare dietrologie senza prove, come libero personalmente di credere che, essendo loro produttori di vga, non avevano speso alcuna energia per ottimizzare il codice per le cpu. Adesso vedremo nei prossimi mesi se le cose migliorano per physx su cpu: stando a quel famigerato report gli fps con physx su cpu potrebbero passare da 5 a 10 e tutti felici e contenti :stordita:

Nvidia, che caduta di stile :asd:

FAIL su TEGRA :asd:
FAIL su FERMI :asd:
FAIL su TEGRA2 (ma non doveva essere già uscita?:p ) :asd:
FAIL su ION :asd:
FAIL su ION2 (ma non doveva essere già uscita?:p ) :asd:
FAIL su Physix :asd:

Nvidia, che caduta di stile :asd:

FAIL su TEGRA :asd:
FAIL su FERMI :asd:
FAIL su TEGRA2 (ma non doveva essere già uscita?:p ) :asd:
FAIL su ION :asd:
FAIL su ION2 (ma non doveva essere già uscita?:p ) :asd:
FAIL su Physix :asd:

e Fermi? :D
mesi e mesi di attesa per schede che scaldano come forni e vanno il 10/15% di top gamma di ATI a quasi il modicissimo doppio del prezzo :fagiano:


a aggiungerei anche fail sui chipset per schede madri...con la nuova generazione di processori memory controller integrati nvidia è tagliata fuori
cosa che prima produceva in belle quantità

tanto rumore per nulla:

Nvidia is apparently planning to introduce new automatic multi-threading features in the forthcoming PhysX 3.0 SDK.

This "uses a task-based approach that was developed in conjunction with our Apex product to add in more automatic support for multi-threading," explains Dell Rizzo.

The new SDK will automatically take advantage of however many cores are available, or the number of cores set by the developer, and will also provide the option of a "thread pool" from which "the physics simulation can draw resources that run across all cores."

http://www.thinq.co.uk/2010/7/8/nvidia-were-not-hobbling-cpu-physx/

edit: letto che era già stato postato; @gnick79: libero di fare dietrologie senza prove, come libero personalmente di credere che, essendo loro produttori di vga, non avevano speso alcuna energia per ottimizzare il codice per le cpu. Adesso vedremo nei prossimi mesi se le cose migliorano per physx su cpu: stando a quel famigerato report gli fps con physx su cpu potrebbero passare da 5 a 10 e tutti felici e contenti :stordita:

Il problema non è tanto il supporto multithreading quanto l'uso delle istruzioni floating point "classiche" anziché appoggiarsi al SSE.

Io ironizzavo sul tizio di nVidia che diceva "beh, aggiungeremo il supporto SSE, ma non so quanto piacerà ai programmatori visto che c'è chi sviluppa titoli per piattaforme che non hanno SSE".
Per il resto capisco perfettamente l'interesse di nVidia a NON ottimizzare il codice CPU.

In coda... so che non è facile riscrivere codice SISD perché vada in SIMD, ma tutto considerato quelli di nVidia qualcosa dovrebbero capirci visto che SIMD e MIMD sono il loro pane quotidiano (ed anche il multithreading non dovrebbe sconvolgerli più di tanto).

Ciao
Nonostante tutto però hanno un codice x87 che è ottimizzato per benino, qundi soldi ce ne hanno speso." In fact, PhysXCore.dll is the culprit responsible for 91% of all x87 instructions retired in the entire process. Despite the use of x87, the IPC is fairly high, 1.4 instructions retired per cycles" che è più che ottimo http://www.realworldtech.com/page.cfm?ArticleID=RWT070510142143&p=3 . Ebbene programmare in x87 è leggermente più difficile che utilizzare anche le scalar sse (che comunque non richiedendo manipolazioni dello stack ed agendo su 16 registri Xmmo a Xmm15 al contrario di 8 per l'unità x87) consentirebbero performance maggiori.

A meno di non disassemblare la libreria e vedere come funziona all'interno non possiamo dire molto.

A meno di non disassemblare la libreria e vedere come funziona all'interno non possiamo dire molto.

Ciao
Non si tratta di disassemblare, si tratta di avere pubblici i binari in modo da ricompilarli a freewill. Poi se già uno studio di profiling fatto da kanter con vtune mostra che si potrebbe fare di più, perchè non crederci?

Ciao
Non si tratta di disassemblare, si tratta di avere pubblici i sorgenti in modo da ricompilarli a freewill. Poi se già uno studio di profiling fatto da kanter con vtune mostra che si potrebbe fare di più, perchè non crederci?

Fixed.

Difficile che nVidia tirerà mai fuori i sorgenti, l'unica sarebbe disassemblare il tutto e cercare di capire "come funziona", ma è un lavoro probo.

Fixed.

Difficile che nVidia tirerà mai fuori i sorgenti, l'unica sarebbe disassemblare il tutto e cercare di capire "come funziona", ma è un lavoro probo.

Ciao
:D
Hai ragione. Ci serve il codice sorgente, oppure qualcuno che mastichi assai l'assembly e ci dica cosa succede effettivamente.
Edit. ovviamente usando un disassembler.

e Fermi? :D
mesi e mesi di attesa per schede che scaldano come forni e vanno il 10/15% di top gamma di ATI a quasi il modicissimo doppio del prezzo :fagiano:


a aggiungerei anche fail sui chipset per schede madri...con la nuova generazione di processori memory controller integrati nvidia è tagliata fuori
cosa che prima produceva in belle quantità

ce l'ho messo il FAIL :asd:

Io ironizzavo sul tizio di nVidia che diceva "beh, aggiungeremo il supporto SSE, ma non so quanto piacerà ai programmatori visto che c'è chi sviluppa titoli per piattaforme che non hanno SSE".
Per il resto capisco perfettamente l'interesse di nVidia a NON ottimizzare il codice CPU.

In coda... so che non è facile riscrivere codice SISD perché vada in SIMD, ma tutto considerato quelli di nVidia qualcosa dovrebbero capirci visto che SIMD e MIMD sono il loro pane quotidiano (ed anche il multithreading non dovrebbe sconvolgerli più di tanto).

Certo certo, ma quanti benefici si avrebbero ad usare le istruzioni SIMD delle SSE, l'unica cosa certa è che PhysX girerebbe meglio ma di quanto è un dato non noto, anzi, rileggendo meglio l'articolo c'è un paragrafo particolarmente interessante che riporto


In Cryostasis, there is only one process of significance, cryostasis.exe itself; all others constitute roughly 2% of instructions retired and 10% of the cycles. Strangely enough, Cryostasis uses a tremendous amount of x87 instructions; roughly 31% of the instructions retired are x87. There are plenty of x87 uops, but hardly any SSE floating point uops, roughly a 100:1 ratio. Perhaps at finer granularity, it will be clear exactly where these x87 instructions are coming from. Despite the x87 instructions, the IPC is a respectable 1.15.


Che significa che di tutte le istruzioni eseguite dal processo cryostasis.exe il 37% sono di tipo x87, una parte è SSE, ma le rimantenti sono x86.

Poichè anche le istruzioni x86 usano cicli di clock e quindi tempo cpu, come si fa ad affermare che la sostituzione delle x87 in SSE possa ridurre così drasticamente i tempi ?

Se ad esempio quel 37% equivalesse a due secondi tanto per ragionare con qualche numero, usando le SSE potrebbero diventare 1 secondo, 0.7 secondi, ma se il rimanente 67% corrispondesse a 4 secondi, nel complesso si passerebbe da 6 secondi con x86+x87, a 4.7 con x86+SSE, numeri che non sono poi così entusiasmanti.

Insomma quell'articolo è molto interessante, ma concludere che se fossero state usate le SSE al posto delle x87 PhysX girerebbe da dio anche su CPU mi sembra un tantino azzardato.

Per quanto concerne il multithreading vale lo stesso concetto che ho esposto nel mio primo post.

Qualunque funzione e/o metodo e/o pezzo di codice può essere eseguito da più thread contemporaneamente solamente se la funzione e/o metodo e/o pezzo di codice è thread-safe.

Se PhysX ha porzioni di codice che non sono thread-safe, cosa verosimile se si tratta di codice vecchio, perchè io imprenditore dovrei investire denaro per favorire le cpu dei miei competitor ? :)

Partiamo dal principio che non sappiamo se le istruzioni usate sono usate con criterio oppure no, anche perché avoglia ottimizzare a livello di codice eseguibile se i sorgenti contengono svarioni... ma ovviamente questo non c'è dato saperlo.
Quello che sappiamo è che al momento physX gira monocore in SISD.
Che ci sia qualche istruzione SSE non vuol dire nulla, anch'io azzeravo i registri con XOR EAX,EAX non per questo usavo massicciamente lo XOR nel codice, semplicemente era uno shortcut... bisognerebbe vedere CHI ha aggiunto quelle istruzioni (il programmatore o il compilatore) ed a quale scopo.

Certo certo, ma quanti benefici si avrebbero ad usare le istruzioni SIMD delle SSE, l'unica cosa certa è che PhysX girerebbe meglio ma di quanto è un dato non noto, anzi, rileggendo meglio l'articolo c'è un paragrafo particolarmente interessante che riporto



Che significa che di tutte le istruzioni eseguite dal processo cryostasis.exe il 37% sono di tipo x87, una parte è SSE, ma le rimantenti sono x86.

Poichè anche le istruzioni x86 usano cicli di clock e quindi tempo cpu, come si fa ad affermare che la sostituzione delle x87 in SSE possa ridurre così drasticamente i tempi ?

Se ad esempio quel 37% equivalesse a due secondi tanto per ragionare con qualche numero, usando le SSE potrebbero diventare 1 secondo, 0.7 secondi, ma se il rimanente 67% corrispondesse a 4 secondi, nel complesso si passerebbe da 6 secondi con x86+x87, a 4.7 con x86+SSE, numeri che non sono poi così entusiasmanti.

Insomma quell'articolo è molto interessante, ma concludere che se fossero state usate le SSE al posto delle x87 PhysX girerebbe da dio anche su CPU mi sembra un tantino azzardato.
Cut


Ciao
Per capire quello che chiedi tu bisognerebbe analizzare il numero di cicli di clock impiegato dalla cpu per eseguire quel determinato numero di uops.

@gnick79: libero di fare dietrologie senza prove, come libero personalmente di credere che, essendo loro produttori di vga, non avevano speso alcuna energia per ottimizzare il codice per le cpu. Adesso vedremo nei prossimi mesi se le cose migliorano per physx su cpu: stando a quel famigerato report gli fps con physx su cpu potrebbero passare da 5 a 10 e tutti felici e contenti :stordita:

A rigor di logica, è l'autore stesso dell'articolo originale a fare dietrologie senza prove... arrivando a concludere che le prestazioni di PhysX su una moderna CPU multicore potrebbero arrivare ad eguagliare quelle lato GPU se fatte le dovute ottimizzazioni.

gnicK79 è soltanto uno dei tanti.
Per quello che mi riguarda nVidia potrà anche non fare niente, nemmeno le ottimizzazioni multithreading per l'engine, la cosa non mi tocca.... perché fintanto hanno in mano il sorgente possono dircene quante ne vogliono.
Possono pure togliere il path CPU per quello che mi riguarda e lasciare solo quello GPU, dopotutto PhysX serve solo a vendere schede video... per tutti gli altri non esiste e conta meno di zero.

Quando mai devono essere i potenziali clienti a fare notare a nVidia banalità del genere e soprattutto in questioni tecniche su cui questi ingegneri non dovrebbero avere cadute di stile così evidenti. Non esiste proprio.
Non andiamo da nessuna parte.... perché è la politica di nVidia che è completamente incompatibile con la diffusione di tutti gli altri engine fisici.
nVidia ci racconta le storielle sul loro presunto impegno per il supporto multipiattaforma del suo fantasmagorico engine e noi ne raccontiamo altre.

Certo certo, ma quanti benefici si avrebbero ad usare le istruzioni SIMD delle SSE, l'unica cosa certa è che PhysX girerebbe meglio ma di quanto è un dato non noto, anzi, rileggendo meglio l'articolo c'è un paragrafo particolarmente interessante che riporto



Che significa che di tutte le istruzioni eseguite dal processo cryostasis.exe il 37% sono di tipo x87, una parte è SSE, ma le rimantenti sono x86.

Poichè anche le istruzioni x86 usano cicli di clock e quindi tempo cpu, come si fa ad affermare che la sostituzione delle x87 in SSE possa ridurre così drasticamente i tempi ?

Se ad esempio quel 37% equivalesse a due secondi tanto per ragionare con qualche numero, usando le SSE potrebbero diventare 1 secondo, 0.7 secondi, ma se il rimanente 67% corrispondesse a 4 secondi, nel complesso si passerebbe da 6 secondi con x86+x87, a 4.7 con x86+SSE, numeri che non sono poi così entusiasmanti.

Insomma quell'articolo è molto interessante, ma concludere che se fossero state usate le SSE al posto delle x87 PhysX girerebbe da dio anche su CPU mi sembra un tantino azzardato.

Per quanto concerne il multithreading vale lo stesso concetto che ho esposto nel mio primo post.

Qualunque funzione e/o metodo e/o pezzo di codice può essere eseguito da più thread contemporaneamente solamente se la funzione e/o metodo e/o pezzo di codice è thread-safe.

Se PhysX ha porzioni di codice che non sono thread-safe, cosa verosimile se si tratta di codice vecchio, perchè io imprenditore dovrei investire denaro per favorire le cpu dei miei competitor ? :)


Cryostasis.exe è l'eseguibile principale del gioco. Questo esegue non solo istruzioni relative alla fisica, ma anche molte istruzioni relative alla gestione dei dati di input e al rendering grafico , tutte cose fatte attraverso normali istruzioni x86. Il passaggio alle SSE permetterebbe più prestazioni per due motivi:

1) Le SSE non necessitano la gestione dello stack di registri x87 (ha quindi meno overhead) e ha un numero maggiore di registri che permette una maggiore ottimizzazione del codice

2) E' possibile mettere insieme più calcoli da eseguire in contemporanea con le SSE , visto che è un set di istruzioni vettoriali, mentre con le x87 , che sono scalari, a una istruzione corrisponde una sola operazione matematica (una sola istruzione SSE può fare fino a 4 operazioni matematiche in single-precision)

Quindi da un punto di vista PURAMENTE teorico lo speedup massimo possibile sarebbe oltre il 4x usando le SSE.

Ovviamente difficilmente si raggiungeranno i 4x netti, ma è possibile comunque arrivare oltre i 2x solo usando le SSE. Per quanto riguarda il multithreading poi questo poi migliorerebbe le prestazioni linearmente col numero di cores.

Ciao

PS: Altra cosa. Come fa il codice di Physx a non essere thread safe se gira su GPU dove NECESSARIAMENTE ci devono essere centinaia di threads in-flight per poter girare decentemente (visto che le GPU sono architetture altamente parallelizzate) ?

A rigor di logica, è l'autore stesso dell'articolo originale a fare dietrologie senza prove... arrivando a concludere che le prestazioni di PhysX su una moderna CPU multicore potrebbero arrivare ad eguagliare quelle lato GPU se fatte le dovute ottimizzazioni.

gnicK79 è soltanto uno dei tanti.
Per quello che mi riguarda nVidia potrà anche non fare niente, nemmeno le ottimizzazioni multithreading per l'engine, la cosa non mi tocca.... perché fintanto hanno in mano il sorgente possono dircene quante ne vogliono.
Possono pure togliere il path CPU per quello che mi riguarda e lasciare solo quello GPU, dopotutto PhysX serve solo a vendere schede video... per tutti gli altri non esiste e conta meno di zero.

Quando mai devono essere i potenziali clienti a fare notare a nVidia banalità del genere e soprattutto in questioni tecniche su cui questi ingegneri non dovrebbero avere cadute di stile così evidenti. Non esiste proprio.
Non andiamo da nessuna parte.... perché è la politica di nVidia che è completamente incompatibile con la diffusione di tutti gli altri engine fisici.
nVidia ci racconta le storielle sul loro presunto impegno per il supporto multipiattaforma del suo fantasmagorico engine e noi ne raccontiamo altre.

Bella barzelletta... togliessero la modalità "solo CPU" chi vuoi che userebbe PhiysX ?
Il programmatore del gioco si troverebbe davanti ad un bivio: metto PhysX ed il gioco funziona solo sulle nVidia o non metto PhysX ed il gioco gira ovunque.
Secondo te che fine farebbe PhysX ?

Il programmatore del gioco si troverebbe davanti ad un bivio: metto PhysX ed il gioco funziona solo sulle nVidia o non metto PhysX ed il gioco gira ovunque.
Secondo te che fine farebbe PhysX ?

scaffale? :p

Appunto, da qui la necessità, da parte di nVidia, di far funzionare bene PhysX anche senza GPU.

...da qui la necessità, da parte di nVidia, di far pompare PhysX nei giochi affinché, anche con le ottimizzazioni, si veda il gap.

E torniamo "a bomba"... quanto "tira" davvero PhysX ?

E' ovvio che un software ottimizzato per GPU non lo sia altrettanto per CPU, nVidia poi non ci guadagnerebbe nulla dall'ottimizzazione CPU, cmq il problema è semplice da risolvere,m basta non comprare giochi PhysX e schede video nVidia :D

Cryostasis.exe è l'eseguibile principale del gioco. Questo esegue non solo istruzioni relative alla fisica, ma anche molte istruzioni relative alla gestione dei dati di input e al rendering grafico , tutte cose fatte attraverso normali istruzioni x86. Il passaggio alle SSE permetterebbe più prestazioni per due motivi:

1) Le SSE non necessitano la gestione dello stack di registri x87 (ha quindi meno overhead) e ha un numero maggiore di registri che permette una maggiore ottimizzazione del codice

2) E' possibile mettere insieme più calcoli da eseguire in contemporanea con le SSE , visto che è un set di istruzioni vettoriali, mentre con le x87 , che sono scalari, a una istruzione corrisponde una sola operazione matematica (una sola istruzione SSE può fare fino a 4 operazioni matematiche in single-precision)

Quindi da un punto di vista PURAMENTE teorico lo speedup massimo possibile sarebbe oltre il 4x usando le SSE.

Ovviamente difficilmente si raggiungeranno i 4x netti, ma è possibile comunque arrivare oltre i 2x solo usando le SSE. Per quanto riguarda il multithreading poi questo poi migliorerebbe le prestazioni linearmente col numero di cores.

Ciao

Ma allora non hai capito, le x87 sono il 37% delle istruzioni eseguite dalla CPU. Se la CPU per eseguire il 100% delle istruzioni del processo impiega 10 secondi, assumendo spannometricamente un secondo ogni punto percentuale hai 3.7 secondi da imputare alle x87, e 6.3 secondi per tutto il resto.

Sostituendo le x87 con le SSE al massimo riduci di 4x i 3.7 secondi che diventerebbero 1 secondo.

Quindi passeresti teoricamente da 10 secondi con le x87, a 7.7 secondi con SSE, che equivale a migliorare le prestazioni del 33% e non del 200/400%.


PS: Altra cosa. Come fa il codice di Physx a non essere thread safe se gira su GPU dove NECESSARIAMENTE ci devono essere centinaia di threads in-flight per poter girare decentemente (visto che le GPU sono architetture altamente parallelizzate) ?

Ma cosa c'entra, le GPU mica eseguono codice x86/x87, è proprio codice diverso, quello per le GPU sarà codice shader, mentre quello che va su CPU codice x86/x87.

Quello che va su GPU è stato ottimizzato al meglio da nVidia per sfruttare il parallelismo delle GPU, quello che va su CPU è rimasto quello scritto da Ageia.

Questo non è detto, perché buona parte delle operazioni "integer" possono essere quelle di controllo necessarie per effettuare le operazioni in floating point.
Peraltro viene da se che se hai dei cicli con "dentro" operazioni x87 e x86 riuscire ad operare su quattro operandi in SSE anziché su una in x87 vuol dire ridurre ad un quarto anche i cicli fatti e di conseguenza anche le operazioni x86 eseguite in quei cicli. E questo semplicemente facendo "i conti della serva".

Bella barzelletta... togliessero la modalità "solo CPU" chi vuoi che userebbe PhiysX ?
Il programmatore del gioco si troverebbe davanti ad un bivio: metto PhysX ed il gioco funziona solo sulle nVidia o non metto PhysX ed il gioco gira ovunque.
Secondo te che fine farebbe PhysX ?

Su PhysX c'è veramente tanta confusione...

Ci sono titoli che usano PhysX e che non richiedono l'accelerazione su GPU, questi
http://www.nzone.com/object/nzone_physxgames_all.html

E altri che richiedono l'accelerazione hardware su GPU, questi
http://www.nzone.com/object/nzone_physxgames_home.html

Quindi la domanda che si pone il programmatore non è se usare o meno PhysX, ma se usare di PhysX quelle componenti che senza hardware nVidia vanno da schifo.

E la risposta a questa domanda credo sia palese, vedendo il numero di titoli presenti nel secondo link.

Su PhysX c'è veramente tanta confusione...

Ci sono titoli che usano PhysX e che non richiedono l'accelerazione su GPU, questi
http://www.nzone.com/object/nzone_physxgames_all.html

E altri che richiedono l'accelerazione hardware su GPU, questi
http://www.nzone.com/object/nzone_physxgames_home.html

Quindi la domanda che si pone il programmatore non è se usare o meno PhysX, ma se usare di PhysX quelle componenti che senza hardware nVidia vanno da schifo.

E la risposta a questa domanda credo sia palese, vedendo il numero di titoli presenti nel secondo link.

Non mi sono spiegato.
Come ha detto un programmatore poche pagine addietro il punto è che i vantaggi di PhysX si limitano a pochi ambiti e che lo scotto di usare PhysX è che in quegli ambiti l'engine software è così penalizzante da rendere l'utilizzo fattibile solo quando si usa veramente POCO.

Ovvero:
1. Ci metto PhysX ed allora per fare un gioco che gira bene anche su ATi lo uso poco e nulla
2. Lo uso pesantemente ed in pratica il gioco senza una nVidia mi gira a 5fps
3. Mando in culo PhysX ed uso un altra libreria fisica (tipo havok) che magari non è così spettacolosa ma fa il suo lavoro e non mi rompe le balle sull'hardware che c'è sotto

Questo non è detto, perché buona parte delle operazioni "integer" possono essere quelle di controllo necessarie per effettuare le operazioni in floating point.

Certo

Peraltro viene da se che se hai dei cicli con "dentro" operazioni x87 e x86 riuscire ad operare su quattro operandi in SSE anziché su una in x87 vuol dire ridurre ad un quarto anche i cicli fatti e di conseguenza anche le operazioni x86 eseguite in quei cicli. E questo semplicemente facendo "i conti della serva".
E' vero anche questo

Poi c'è da vedere (e qui non ne so nulla perché è un po'che non guardo alle architetture) se usare le x87 rispetto alle SSE non aggiunga anche problemi d'inquinamento delle cache.
Le operazioni SIMD (SSE/VMX/etc) non dovrebbero interessare le cache, a differenza delle operazioni FPU, perché il contesto di località è diverso.

State guardando il problema dal lato sbagliato:
La 480 gia di suo durante i giochi è sempre al 100% dell'utilizzo nelle fasi con molti oggetti.
Attivando la fisica si ha un calo del 10% (dico un numero a caso).
A parità di gioco ed impostazioni su una 280 si ha un calo del 15%
su una 9800 invece un calo del 35%.
Se si ottimizzasse per bene il codice con non solo le see ma anche con uno scheduler che possa ripartire dinamicamente il carico su cpu e gpu a seconda dei casi chi comprerebbe più una vga di fascia alta per usare la fisica quando una 9800 avrebbe un ipotetico calo del 8-10% sulle prestazioni?

Poi c'è da vedere (e qui non ne so nulla perché è un po'che non guardo alle architetture) se usare le x87 rispetto alle SSE non aggiunga anche problemi d'inquinamento delle cache.
Le operazioni SIMD (SSE/VMX/etc) non dovrebbero interessare le cache, a differenza delle operazioni FPU, perché il contesto di località è diverso.

Ciao
Provo a rispondere per le mie limitate conoscenze.
L'utilizzo delle sse non dovrebbe comportare l'inquinamento della memoria poichè si hanno 16 registri flat di ampiezza di 128 bit, gli operandi possono essere salvati quindi in formato 32 o 64 bit senza problemi, al contrario l'x87 utilizza un formato degli operandi a 80 bit ma quando l'operando viene salvato per poi essere ricaricato viene salvato con formato a 64 bit, gli extra 16 bit vengono dunque troncati. Bisogna fare dunque un pò di attenzione.

Questo non è detto, perché buona parte delle operazioni "integer" possono essere quelle di controllo necessarie per effettuare le operazioni in floating point.
Peraltro viene da se che se hai dei cicli con "dentro" operazioni x87 e x86 riuscire ad operare su quattro operandi in SSE anziché su una in x87 vuol dire ridurre ad un quarto anche i cicli fatti e di conseguenza anche le operazioni x86 eseguite in quei cicli. E questo semplicemente facendo "i conti della serva".

Tra l'altro buona parte di quelle x86 saranno operazioni di memoria.... un bel pò di store ed altrettante load.
Edit se si parla del processo cryostasis exe a meno di divine intercessioni in cui la gpu ha gia gli operandi pronti nel suo framebuffer afforza saranno load e store. Sempre sperando di non aver detto minchiate.

Bella barzelletta... togliessero la modalità "solo CPU" chi vuoi che userebbe PhiysX ?
Il programmatore del gioco si troverebbe davanti ad un bivio: metto PhysX ed il gioco funziona solo sulle nVidia o non metto PhysX ed il gioco gira ovunque.
Secondo te che fine farebbe PhysX ?

Ma PhysX è una barzelletta che ci raccontano da anni.

Non te lo faranno funzionare mai bene su CPU come vorresti... se lo scopo primario di Physx è vendere con la formula "hardware basato su..."
Il giochino è questo.

Bryan è praticamente caduto giù dalle nuvole quando gli si dice: <<ma come mai niente SSE???>> risponde: <<no prlobem! quanto prima verranno abilitate di default come per il multithreading>>

Ma perché, eventualmente, dovevamo venirglielo a dire noi che nei processori attuali le SSE arrivano sino alla versione 4.2? :D
Dobbiamo fare i maliziosi al punto di andare a ficcare il naso sulle questioni tecniche?
Ma certamente lo sapranno, sanno tutto questi... non prendiamoci in giro.

In quell'articolo, se leggi bene, in una parte si giustifica persino che in diversi casi le x87 sono risultate addirittura più veloci delle SSE....

Se PhysX non vien sollevato dagli obblighi di marketing strategicamente non c'è alcuna fretta di farlo andare decentemente su CPU....
Perché questi dovrebbero rischiare di compromettere le vendite delle loro schede quando hanno praticamente basato e puntato tutto il loro business su 3D Vision e PhysX!!!?? Hanno persino investito tutta un'architettura hardware per il GPGPU... con i risultati che già conosci.
Qua ballano soldi e utili per cui la questione è questa.
La speranza che questi cambino testa si sta affievolendo.
Avessero voluto che PhysX diventasse IL motore fisico di riferimento gli avrebbero tolto il guinzaglio già da un bel pezzo. E' evidente che lo scopo è fare soldi e basta.

TWIMTBP... nVidia è questa.

---------------

@eXeS
Lasciare aperte le porte per il path CPU fa tutto parte della strategia per non chiudere completamente le porte ai DEVs e tentare di diffondere quanto più l'engine.
Del resto il codice era già stato scritto da Ageia, codice in cui nVidia non ha mai messo un dito..... e di anni e di acqua sotto i ponti ne è passata tanta.

A meno di non disassemblare la libreria e vedere come funziona all'interno non possiamo dire molto.
Ma mi sembra che il tipo di RealWorldTech abbia fatto proprio così.

In realtà tutto ciò si sapeva da una vita, l'aveva postato il tipo di Future Mark (mi par) su beyond3d oltre un anno fa, con uno spezzone di codice disassemblato. Il problema della situazione è che nVidia fa passare Physix per una "feature" delle sue GPU, mentre è solo un software che rallenta la CPU.

Stando così le cose, che fiducia possiamo avere su tutto il GPGPU in generale e i suoi sviluppi, se non c'è la possibilità di averne un confronto onesto?

Se nVidia deve barare, non deve essere poi 'sto granché.

Ma mi sembra che il tipo di RealWorldTech abbia fatto proprio così.

In realtà tutto ciò si sapeva da una vita, l'aveva postato il tipo di Future Mark (mi par) su beyond3d oltre un anno fa, con uno spezzone di codice disassemblato. Il problema della situazione è che nVidia fa passare Physix per una "feature" delle sue GPU, mentre è solo un software che rallenta la CPU.

Stando così le cose, che fiducia possiamo avere su tutto il GPGPU in generale e i suoi sviluppi, se non c'è la possibilità di averne un confronto onesto?

Se nVidia deve barare, non deve essere poi 'sto granché.

ma va? :asd:

:asd:

Ciao
Provo a rispondere per le mie limitate conoscenze.
L'utilizzo delle sse non dovrebbe comportare l'inquinamento della memoria poichè si hanno 16 registri flat di ampiezza di 128 bit, gli operandi possono essere salvati quindi in formato 32 o 64 bit senza problemi, al contrario l'x87 utilizza un formato degli operandi a 80 bit ma quando l'operando viene salvato per poi essere ricaricato viene salvato con formato a 64 bit, gli extra 16 bit vengono dunque troncati. Bisogna fare dunque un pò di attenzione.

Non è quello che intendevo.
In alcune architetture le load/store delle unità SIMD sono fatte "ai margini" della cache, in pratica il dato letto viene messo nelle cache come "dato poco importante", pronto per un flush appena possibile.
In questo modo i dati elaborati SIMD non restano in cache, anche perché non hanno ragione di starci (non c'è la località tipica degli scalari, anzi... per cui è addirittura dannoso tenere i dati elaborati nella cache a scapito del resto), cosa diversa è per le istruzioni x87.

Nella pratica cosa vuol dire ?
Che un codice x87, anche avesse la velocità dell'equivalente SSE, riempirebbe facilmente la cache dati di quel che elabora, "scaricando" altri frammenti (che sulle architetture multi con cache condivise vuol dire rallentare anche gli altri core) mentre i dati via SSE dovrebbero essere caricati dalla memoria e scaricati su di essa quasi subito, limitando l'impatto di questo genere d'elaborazione dalle cache e preservandole dall'inquinamento di una mole di dati "inutilmente" cachati.

Bravo Corsiniu....finalmente la verità su quella commercialata di Physics...cmq per me dovrebebro multare nvidia perchè foraggia i devs, per spingere e introdurre queste porcate...questo è comportamento scorretto...visto che danneggia i possessori di altre VGA...ma allo stesso modo andrebebro puniti i devs che prendono le mazzette epr fare questo sporco gioco.....ma le dx11 non dovevano porre fine a tutte ste minchiate??? ahhh già, grazie alle console, manco le dx10 ci sono....

Bravo Corsiniu....finalmente la verità su quella commercialata di Physics...cmq per me dovrebebro multare nvidia perchè foraggia i devs, per spingere e introdurre queste porcate...questo è comportamento scorretto...visto che danneggia i possessori di altre VGA...ma allo stesso modo andrebebro puniti i devs che prendono le mazzette epr fare questo sporco gioco.....ma le dx11 non dovevano porre fine a tutte ste minchiate??? ahhh già, grazie alle console, manco le dx10 ci sono....

Le console sono uscite prima delle DX10, e comunque nelle console si campa abbastanza bene anche senza queste bagasciate (peraltro sia gli SPE sia gli stream processor di Xenos possono lavorare come processori programmabili in modo non dissimile da come dovrebbe funzionare CUDA).
Da "quelle parti" poter lavorare molto vicini all'hardware compensa l'assenza di hardware strapompato dell'ultimo trimestre.
Semmai c'è da chiedersi com'è che su una cavolo di 7800 o giù di lì si riesca a fare un Killzone 2 (con tutta la fisica del caso) e su PC invece cercano di venderti una scheda video apposita per fare animazioni di stoffe e similia.

Non è quello che intendevo.
In alcune architetture le load/store delle unità SIMD sono fatte "ai margini" della cache, in pratica il dato letto viene messo nelle cache come "dato poco importante", pronto per un flush appena possibile.
In questo modo i dati elaborati SIMD non restano in cache, anche perché non hanno ragione di starci (non c'è la località tipica degli scalari, anzi... per cui è addirittura dannoso tenere i dati elaborati nella cache a scapito del resto), cosa diversa è per le istruzioni x87.

Nella pratica cosa vuol dire ?
Che un codice x87, anche avesse la velocità dell'equivalente SSE, riempirebbe facilmente la cache dati di quel che elabora, "scaricando" altri frammenti (che sulle architetture multi con cache condivise vuol dire rallentare anche gli altri core) mentre i dati via SSE dovrebbero essere caricati dalla memoria e scaricati su di essa quasi subito, limitando l'impatto di questo genere d'elaborazione dalle cache e preservandole dall'inquinamento di una mole di dati "inutilmente" cachati.

Ciao
In fatti mi ero accorto che non intendevi ciò, comunque il problema della troncazione degli extra 16 bit rimane, per il discorso della località delle istruzioni SIMD, scusami un tantino, se ad ogni operazione compiuta l'operando salvato nella cache rispostato, e qui non ho capito bene, nella ram centrale intendi? in una memoria di distanza maggiore alle executin unit, la possibilità di riutilizzare quel determinato operando non va a farsi benedire? Oltretutto come copri le latenze di un eventuale spostamento nella ram centrale o comunque di livello superiore? A quanto ne so io nemmeno il flush di un dato da L1d a L2 è free ad esempio in architetture con cache di tipo esclusivo. E se ti riserve l'operando che fai sprechi altri cicli di clock per ricalcolarne l'indirizzo?
Mi sa che mi sono perso.
Edit: oltretutto se a che servirebbero i quasi 5,5 mb di registri in architetture SIMD come Rv870, so che non eseguono le sse x86 ma sono pu sempre istruzioni vettoriali.

Ciao
In fatti mi ero accorto che non intendevi ciò, comunque il problema della troncazione degli extra 16 bit rimane, per il discorso della località delle istruzioni SIMD, scusami un tantino, se ad ogni operazione compiuta l'operando salvato nella cache rispostato, e qui non ho capito bene, nella ram centrale intendi? in una memoria di distanza maggiore alle executin unit, la possibilità di riutilizzare quel determinato operando non va a farsi benedire? Oltretutto come copri le latenze di un eventuale spostamento nella ram centrale? E se ti riserve l'operando che fai sprechi altri cicli di clock per ricalcolarne l'indirizzo?
Mi sa che mi sono perso.

La cache opera su un principio che è quello di località dei dati, in pratica se fai un accesso su X è facile che i prossimi siano nell'intorno di X, per cui prendere l'area "intorno" ad X quando si prende X e tenerla in cache vuol dire accelerare il processore, in quanto successive operazioni nell'intorno e sulla stessa cella si effettueranno sulla cache, che ha latenza inferiore rispetto alla RAM.
Sulle SIMD questo non vale, perché i dati sono tipicamente caricati->elaborati->scaricati sequenzialmente, senza essere "ricaricati" per cui mantenere in cache l'area dopo lo store (aspettando che venga "scaricata" a causa dell'aging) è il modo migliore per riempire la cache di roba inutile.

Le CPU x86 hanno un numero abbastanza ridotto di registri, per cui load/store sono abbastanza comuni (anche per conservare risultati intermedi), e qualcosa di simile avviene per le istruzioni x87... sulle SIMD invece spesso e volentieri si riesce a mantenere tutto nei registri interni per tutto il tempo che occorre, per cui quando si fa la STORE è abbastanza probabile che il dato è stato processato e non si dovrà più accedere, nell'immediato, a quell'area... segue che mantenere quell'area in cache aspettando che invecchi è il modo migliore per "inquinare" la cache.

Cut
Sulle SIMD questo non vale, perché i dati sono tipicamente caricati->elaborati->scaricati sequenzialmente, senza essere "ricaricati" per cui mantenere in cache l'area dopo lo store (aspettando che venga "scaricata" a causa dell'aging) è il modo migliore per riempire la cache di roba inutile.

Le CPU x86 hanno un numero abbastanza ridotto di registri, per cui load/store sono abbastanza comuni (anche per conservare risultati intermedi), e qualcosa di simile avviene per le istruzioni x87... sulle SIMD invece spesso e volentieri si riesce a mantenere tutto nei registri interni per tutto il tempo che occorre, per cui quando si fa la STORE è abbastanza probabile che il dato è stato processato e non si dovrà più accedere, nell'immediato, a quell'area... segue che mantenere quell'area in cache aspettando che invecchi è il modo migliore per "inquinare" la cache.

Ciao
Grazie per la spiegazione. In pratica i 16 registri xmm0 xmm15 servono a limitare tutte le load e store. Sopratutto non sapevo che le simd avessero questa proprietà che una volta che la computazione è compiuta si scrivano i risultati in memoria e gli operandi non verrano riutilizzati subito. Ma allora, essendo riusciti loro (nvidia) a mantere un ipc altuccio (1.4) con istruzioni x87, e quindi penso che oltre alle normali load e store per portare gli operandi alla gpu (vertici cordinate ecc ecc) le restanti x86 nel processo cryostasis non siano che oltre ad istruzioni di controllo, salti vari ecc ecc un buon numero siano operazioni di memoria proprio per ottenere gli operandi da dare in pasto alla Fpu, non considerando che programmare in x87 è più difficile che utilizzare pure le sse scalari, per i motivi gia detti prima (istruzioni per manipolare lo stack, attenzione quando si ricaricano i dati per via delle troncazioni) oltretutto che in alcune architetture (amd k10 ad es) gli accesi alla memoria non temporanea sono più veloci, come cacchio hanno pensato di non levarsi un "piccio" e scrivere tutto in sse, sprecando meno tempo ed ottenendo performance maggiori comunque?

Ciao
Grazie per la spiegazione. In pratica i 16 registri xmm0 xmm15 servono a limitare tutte le load e store. Sopratutto non sapevo che le simd avessero questa proprietà che una volta che la computazione è compiuta si scrivano i risultati in memoria e gli operandi non verrano riutilizzati subito. Ma allora, essendo riusciti loro (nvidia) a mantere un ipc altuccio (1.4) con istruzioni x87, e quindi penso che oltre alle normali load e store per portare gli operandi alla gpu (vertici cordinate ecc ecc) le restanti x86 nel processo cryostasis non siano che oltre ad istruzioni di controllo, salti vari ecc ecc un buon numero siano operazioni di memoria proprio per ottenere gli operandi da dare in pasto alla Fpu, non considerando che programmare in x87 è più difficile che utilizzare pure le sse scalari, per i motivi gia detti prima (istruzioni per manipolare lo stack, attenzione quando si ricaricano i dati per via delle troncazioni) oltretutto che in alcune architetture (amd k10 ad es) gli accesi alla memoria non temporanea sono più veloci, come cacchio hanno pensato di non levarsi un "piccio" e scrivere tutto in sse, sprecando meno tempo ed ottenendo performance maggiori comunque?

Se il codice è fatto bene una volta che fai lo store di quello che c'è nei registri SSE quel che scrivi non ti serve più, se non ce la fai probabilmente avrai una penalità dovuta al fatto che la CPU tende a non cachare le aree lette/scritte via SIMD.
Per il resto l'IPC alto lo hai quando il compilatore riesce ad alternarti a dovere le istruzioni in modo che non ci siano lock, in modo da poter usare meglio le pipeline... ma il punto è: se scrivi un codice (es C, C++) che effettua operazioni float senza esplicito ricorso a SSE e lo compili il compilatore ti genera codice x87, anche perché le SIMD vanno "scritte" quasi esplicitamente nel codice sorgente.

E' ipotizzabile, del resto, che le prestazioni di una CPU multicore con codice PhysX ottimizzato multithreaded e con SSE possa risultare essere ben più veloce di quanto ottenibile con una GPU NVIDIA di ultima generazione. La scelta è libera, avendo NVIDIA proprietà di PhysX, ma è evidente come il livello prestazionale ottenibile con elaborazioni via CPU non sia allineato a quanto teoricamente possa venir messo a disposizione degli utenti. E' altrettanto chiaro, a nostro avviso, come con questa strategia si voglia mettere in una luce migliore di quello che tecnicamente potrebbe essere un limite prestazionale delle GPU rispetto alle CPU

scusate ma rimango basito ... (si dice così ? :D )

forse sono rimasto indietro io, ma non si era finora universalmente affermato che per la natura stessa degli algoritmi da applicare, i calcoli di simulazione fisica potevano trarre grande vantaggio dalla diversa arch. delle gpu rispetto alle cpu e che quindi anche ottimizzando al meglio per entrambi i tipi di chip una gpu aberebbe sempre avuto un grosso vantaggio prestazionale, potenzialmente ?

un conto è la questione, per quel che riguarda physX che il codice che viene eseguito quando si usa solo la cpu abbia come target isa una cpu x86 "generica" che potrebeb anche essere una di decenni fa, portando la cosa "casualmente" anche qualche vanatggio di marketing

ma nella conclusione di questa news si afferma qualcosa di generale che è il contrario di quello che per anni è stato affermato da più parti come cosa oggettiva, ovvero si dice che per calcoli di simulazione fisica, o almeno epr quanto finora applicato nel settore videogames, sono le cpu ad essere potenzialmente più performanti delle gpu, anche scrivendo codice ad hoc per entrambe le arch.

:confused:

Se il codice è fatto bene una volta che fai lo store di quello che c'è nei registri SSE quel che scrivi non ti serve più, se non ce la fai probabilmente avrai una penalità dovuta al fatto che la CPU tende a non cachare le aree lette/scritte via SIMD.
Per il resto l'IPC alto lo hai quando il compilatore riesce ad alternarti a dovere le istruzioni in modo che non ci siano lock, in modo da poter usare meglio le pipeline... ma il punto è: se scrivi un codice (es C, C++) che effettua operazioni float senza esplicito ricorso a SSE e lo compili il compilatore ti genera codice x87, anche perché le SIMD vanno "scritte" quasi esplicitamente nel codice sorgente.

Ciao
Grazie per le delucidazioni.

E' ipotizzabile, del resto, che le prestazioni di una CPU multicore con codice PhysX ottimizzato multithreaded e con SSE possa risultare essere ben più veloce di quanto ottenibile con una GPU NVIDIA di ultima generazione. La scelta è libera, avendo NVIDIA proprietà di PhysX, ma è evidente come il livello prestazionale ottenibile con elaborazioni via CPU non sia allineato a quanto teoricamente possa venir messo a disposizione degli utenti. E' altrettanto chiaro, a nostro avviso, come con questa strategia si voglia mettere in una luce migliore di quello che tecnicamente potrebbe essere un limite prestazionale delle GPU rispetto alle CPU

scusate ma rimango basito ... (si dice così ? :D )

forse sono rimasto indietro io, ma non si era finora universalmente affermato che per la natura stessa degli algoritmi da applicare, i calcoli di simulazione fisica potevano trarre grande vantaggio dalla diversa arch. delle gpu rispetto alle cpu e che quindi anche ottimizzando al meglio per entrambi i tipi di chip una gpu aberebbe sempre avuto un grosso vantaggio prestazionale, potenzialmente ?

un conto è la questione, per quel che riguarda physX che il codice che viene eseguito quando si usa solo la cpu abbia come target isa una cpu x86 "generica" che potrebeb anche essere una di decenni fa, portando la cosa "casualmente" anche qualche vanatggio di marketing

ma nella conclusione di questa news si afferma qualcosa di generale che è il contrario di quello che per anni è stato affermato da più parti come cosa oggettiva, ovvero si dice che per calcoli di simulazione fisica, o almeno epr quanto finora applicato nel settore videogames, sono le cpu ad essere potenzialmente più performanti delle gpu, anche scrivendo codice ad hoc per entrambe le arch.

:confused:

Parti dalla considerazione che la GPU dovrebbe fare quei conti SENZA INTACCARE le prestazioni video, altrimenti te ne fai assai di PhysX.
Per il resto che le GPU possano sparare numeri impressionanti come operazioni FP è vero (anche se c'è da dire che le CPU in SIMD si comportano abbastanza bene), ma è anche vero che tutta questa fisica da richiedere calcoli su calcoli nei giochi non c'è... tant'è che sono anni che i videogiochi (chi più, chi meno) la loro bella fisica ce l'hanno.

tant'è che sono anni che i videogiochi (chi più, chi meno) la loro bella fisica ce l'hanno.Trespasser era anni avanti, per quanto riguarda la fisica

Parti dalla considerazione che la GPU dovrebbe fare quei conti SENZA INTACCARE le prestazioni video, altrimenti te ne fai assai di PhysX.
Per il resto che le GPU possano sparare numeri impressionanti come operazioni FP è vero (anche se c'è da dire che le CPU in SIMD si comportano abbastanza bene), ma è anche vero che tutta questa fisica da richiedere calcoli su calcoli nei giochi non c'è... tant'è che sono anni che i videogiochi (chi più, chi meno) la loro bella fisica ce l'hanno.

Mmmmh, se provi ad installare warmonger, che è fluido con qualsiasi scheda dalla G80 in poi, ma è inchiodato con il Physx da CPU, noterai che come quantità di oggetti gestiti dalla fisica, nonchè di realismo delle traiettorie, è fuori parametro rispetto a qualsiasi altro gioco con fisica software, non importa quale sia l'engine (Havoc, Physx).

In altre parole, se prendi titoli come Crysis e F.E.A.R., che vantano engine fisici ritenuti allo stato dell'arte, sono lontanissimi dai livelli di Warmonger. Quindi, se puoi sfruttare la GPU, puoi raggiungere un certo livello, altrimenti ti accontenti.

Per quanto riguarda le performance, una nel mio sistema una GPU G92 (la firma non è aggiornata) è risultata quattro volte più veloce dei due core 6400+ con due thread separati. Ipotizzando una CPU a quattro core, e le opportune ottimizzazioni SIMD, mi viene da dire che comunque una CPU Top di gamma può raggiungere le performance di una GPU per il gaming entry level.

E' ipotizzabile, del resto, che le prestazioni di una CPU multicore con codice PhysX ottimizzato multithreaded e con SSE possa risultare essere ben più veloce di quanto ottenibile con una GPU NVIDIA di ultima generazione. La scelta è libera, avendo NVIDIA proprietà di PhysX, ma è evidente come il livello prestazionale ottenibile con elaborazioni via CPU non sia allineato a quanto teoricamente possa venir messo a disposizione degli utenti. E' altrettanto chiaro, a nostro avviso, come con questa strategia si voglia mettere in una luce migliore di quello che tecnicamente potrebbe essere un limite prestazionale delle GPU rispetto alle CPU

scusate ma rimango basito ... (si dice così ? :D )

forse sono rimasto indietro io, ma non si era finora universalmente affermato che per la natura stessa degli algoritmi da applicare, i calcoli di simulazione fisica potevano trarre grande vantaggio dalla diversa arch. delle gpu rispetto alle cpu e che quindi anche ottimizzando al meglio per entrambi i tipi di chip una gpu aberebbe sempre avuto un grosso vantaggio prestazionale, potenzialmente ?

un conto è la questione, per quel che riguarda physX che il codice che viene eseguito quando si usa solo la cpu abbia come target isa una cpu x86 "generica" che potrebeb anche essere una di decenni fa, portando la cosa "casualmente" anche qualche vanatggio di marketing

ma nella conclusione di questa news si afferma qualcosa di generale che è il contrario di quello che per anni è stato affermato da più parti come cosa oggettiva, ovvero si dice che per calcoli di simulazione fisica, o almeno epr quanto finora applicato nel settore videogames, sono le cpu ad essere potenzialmente più performanti delle gpu, anche scrivendo codice ad hoc per entrambe le arch.

:confused:

La questione è complessa, e il dubbio è legittimo, ma la risposta potremo averla solo quando Physx smetterà di essere fumo da vendere e diventerà una tecnologia.

Nel frattempo, il fatto che le CPU debbano essere castrate per far sembrare questo fumo una tecnologia, fa sorgere qualche legittimo sospetto.

(la mia opinione a naso è che la fisica su GPU non è qualcosa su cui gli sviluppatori hanno interesse a investire, e che gli effetti per cui avrebbe seri guadagni molto si confondono con gli effetti grafici. Anche perché, se pensi che la maggior parte della gente va a IGP, non è che tutti si possono permettere di tenere la CPU in idle mentre la GPU arranca con la sola grafica)

Mmmmh, se provi ad installare warmonger, che è fluido con qualsiasi scheda dalla G80 in poi, ma è inchiodato con il Physx da CPU, noterai che come quantità di oggetti gestiti dalla fisica, nonchè di realismo delle traiettorie, è fuori parametro rispetto a qualsiasi altro gioco con fisica software, non importa quale sia l'engine (Havoc, Physx).

Ma è UN gioco, e buona parte di questa superiorità è dovuta al fatto che nVidia ha (volutamente o meno) castrato l'engine fisico via CPU.

In altre parole, se prendi titoli come Crysis e F.E.A.R., che vantano engine fisici ritenuti allo stato dell'arte, sono lontanissimi dai livelli di Warmonger. Quindi, se puoi sfruttare la GPU, puoi raggiungere un certo livello, altrimenti ti accontenti.

Ma anche no... già su un quad core usando il threading (in pratica con modifiche minime) puoi praticamente quadruplicare le prestazioni "via CPU", usando l'SSE probabilmente hai almeno un altro raddoppio delle prestazioni.
E con otto volte le prestazioni attuali "puoi raggiungere un certo livello".

Per quanto riguarda le performance, una nel mio sistema una GPU G92 (la firma non è aggiornata) è risultata quattro volte più veloce dei due core 6400+ con due thread separati. Ipotizzando una CPU a quattro core, e le opportune ottimizzazioni SIMD, mi viene da dire che comunque una CPU Top di gamma può raggiungere le performance di una GPU per il gaming entry level.

La GPU G92 è risultata 4 volte superiore ad un 6400+ su cui girava PhysX che, come sappiamo dall'articolo, usa solo UN core.
Và da sé che fra riscrivere tutto in SSE (che se non è codificato da cani un raddoppio te lo concede) ed usare il multithreading già così il tuo 6400+ è "alla pari" rispetto al G92.

Trespasser era anni avanti, per quanto riguarda la fisica

gran gioco!!!
dovrebbero farne una versione hd !!


C'.a'.a'.'.a

tra physix e la fisica del frostbite 2.0 preferisco decisamente il frostbite... tutti i processori occupati, ma per lo meno la fisica riguarda ogni aspetto del gioco...( come si sposta il soldato, come si comportano i materiali degli edifici, come reagiscono i proiettili, le nuvole di polvere e di fumo....) nessun gioco physix si avvicina minimamente a queste capacità.... sper che questo motore grafico spopoli.... nativo a dx10, 10.1 e 11.... usa sempre ogni singolo "bit"(per chi sa l'inglese potrebe sembrare una battuta :D) disponibile della macchina(sopratutto il processore) ed é bilanciatissimo negli effetti.

gran gioco!!!
dovrebbero farne una versione hd !!


C'.a'.a'.'.aSi ma alla protagonista sarebbe meglio steccassero quel cazzo di braccio :asd:

La GPU G92 è risultata 4 volte superiore ad un 6400+ su cui girava PhysX che, come sappiamo dall'articolo, usa solo UN core.
Và da sé che fra riscrivere tutto in SSE (che se non è codificato da cani un raddoppio te lo concede) ed usare il multithreading già così il tuo 6400+ è "alla pari" rispetto al G92.

Commento solo questo:

Contezero, potresti leggere i post prima di controbattere? Non siamo nella sezione dedicata alla politica.

- Non é vero che l'engine Physx é single thread, perlomeno non nel senso che lascia intendere l'articolo, nei post precedenti la cosa é stata spiegata
- Io ho avviato il benchmark fluidmark multi-threaded su due core, ottenendo come risultato prestazioni pari ad 1/4 rispetto alla G92. L'ho scritto nel post precedente, perché lo ignori? L'ho avviato anche in single thread, ed ovviamente ho ottenuto un risultato pari ad 1/8 rispetto alla G92, d'altronde la scalabilitá dell'engine con il numero di core é perfetta.
- Considerando quattro core e ottimizzazioni tali da raddoppiare le performance, si arriva ad (1/4)*2*2=1, cioé un quad core a 3.2 GHz arriva alle stesse performance di una G92, che é l'entry level.

Commento solo questo:

Contezero, potresti leggere i post prima di controbattere? Non siamo nella sezione dedicata alla politica.

- Non é vero che l'engine Physx é single thread, perlomeno non nel senso che lascia intendere l'articolo, nei post precedenti la cosa é stata spiegata
- Io ho avviato il benchmark fluidmark multi-threaded su due core, ottenendo come risultato prestazioni pari ad 1/4 rispetto alla G92. L'ho scritto nel post precedente, perché lo ignori? L'ho avviato anche in single thread, ed ovviamente ho ottenuto un risultato pari ad 1/8 rispetto alla G92, d'altronde la scalabilitá dell'engine con il numero di core é perfetta.
- Considerando quattro core e ottimizzazioni tali da raddoppiare le performance, si arriva ad (1/4)*2*2=1, cioé un quad core a 3.2 GHz arriva alle stesse performance di una G92, che é l'entry level.

Ok, allora lasciamo calcolare la fisica alla vga (con tutti i limiti di phisx, quindi niente solidi puri, ma solo stoffe e liquidi) e vediamo se la cpu riesce a far girare la grafica.
Una vga utilizza il 90% delle proprie capacità di calcolo per la grafica, il resto per la fisica.
Quindi quando diciamo che una vga è 10 volte più veloce della cpu nel calcolare la fisica stiamo considerando che la vga nei giochi non sta mai a rigirarsi i pollici, mentre la cpu si?
un'ottimizzazione del codice lato cpu potrebbe far girare molto più velocemente il gioco, semplicemente perchè la vga utilizza solo una minima parte dei propri transistor per la fisica.
Certamente se uno fa un trisli di 480gtx con la terza vga dedicata alla fisica ;)
Tutto il resto ci dice che un'ottimizzazione lato cpu della fisica potrebbe raddoppiare, se non triplicare le performance, riducendo di fatto il calo di framerate ben visibile su vga di fascia media con phisx attivo.

Ok, allora lasciamo calcolare la fisica alla vga (con tutti i limiti di phisx, quindi niente solidi puri, ma solo stoffe e liquidi) e vediamo se la cpu riesce a far girare la grafica.
Una vga utilizza il 90% delle proprie capacità di calcolo per la grafica, il resto per la fisica.
Quindi quando diciamo che una vga è 10 volte più veloce della cpu nel calcolare la fisica stiamo considerando che la vga nei giochi non sta mai a rigirarsi i pollici, mentre la cpu si?
un'ottimizzazione del codice lato cpu potrebbe far girare molto più velocemente il gioco, semplicemente perchè la vga utilizza solo una minima parte dei propri transistor per la fisica.
Certamente se uno fa un trisli di 480gtx con la terza vga dedicata alla fisica ;)
Tutto il resto ci dice che un'ottimizzazione lato cpu della fisica potrebbe raddoppiare, se non triplicare le performance, riducendo di fatto il calo di framerate ben visibile su vga di fascia media con phisx attivo.

In merito alla frase in neretto: non capisco perché,se lasci calcolare la fisica alla GPU, debba per froza essere la CPU ad effettuare il rendering. E infatti non é cosi', in warmonger la GPU si occupa di entrambi, ed il gioco gira senza problemi. E, mi risulta, che sia lo stesso anche con UT3 e Mirror's edge. L'idea di utilizzare la GPU per la fisica non é tanto finalizzata allo scaricamento della CPU, quanto a sfruttare le maggiori unitá di calcolo di quest'ultima. Peraltro, non capisco tutta questa ostilitá dogmatica nei confronti dell'utilizzo della GPU per la fisica: é un opzione in piú, se non ti piace la disattivi.

A meno che non sia la solita crociata Ati vs Nvidia.....

In merito alla frase in neretto: non capisco perché,se lasci calcolare la fisica alla GPU, debba per froza essere la CPU ad effettuare il rendering. E infatti non é cosi', in warmonger la GPU si occupa di entrambi, ed il gioco gira senza problemi. E, mi risulta, che sia lo stesso anche con UT3 e Mirror's edge. L'idea di utilizzare la GPU per la fisica non é tanto finalizzata allo scaricamento della CPU, quanto a sfruttare le maggiori unitá di calcolo di quest'ultima. Peraltro, non capisco tutta questa ostilitá dogmatica nei confronti dell'utilizzo della GPU per la fisica: é un opzione in piú, se non ti piace la disattivi.

A meno che non sia la solita crociata Ati vs Nvidia.....

Come gia spiegato da altri utenti la fisica di phisx può essere calcolata dalla vga solo per alcune funzioni (liquidi, stoffe, nebbia).
I solidi (deformazioni, movimenti, traiettore) sono invece calcolate dalla cpu quindi prima di accusare gli altri di fare crociate assicurati di capire di cosa si stia parlando, o per lo meno abbi l'umiltà di leggere quello che scrivono gli altri.
E non venirmi a dire che una vga di fascia media (le più utilizzate dai videogiocatori pc) non hanno cali prestazionali attivando la fisica, nel mentre la cpu a causa del codice non ottimizzato apporta capacità computazionali di molto inferiori a quello che potrebbe.
Ti sei mai chiesto perchè ci sono giochi con phisx cpu only?
Semplice, la vga calcola pochi effetti fisici, e spesso i programmatori non utilizzano la vga per non avere un calo del frame rate con schede di fascia media.

Trespasser era anni avanti, per quanto riguarda la fisica

vero, era fatto molto bene per quel periodo. Ma cosa fondamentale: la fisica era parte integrante del game play, non un semplice abbellimento grafico.

Rispondo solo a questo perché il resto é ampliamente dimenticabile:

Ti sei mai chiesto perchè ci sono giochi con phisx cpu only?


forse perché la stragrande maggioranza dei giochi che utilizzano Physx é stata sviluppata ben prima che fosse introdotto il supporto al GPU computing da parte di Nvidia........

Rispondo solo a questo perché il resto é ampliamente dimenticabile:


forse perché la stragrande maggioranza dei giochi che utilizzano Physx é stata sviluppata ben prima che fosse introdotto il supporto al GPU computing da parte di Nvidia........

:mc:

:mc:

Non é una arrampicata di specchi, basta sfogliare l'elenco dei titoli per rendersi conto che é cosi'. Physx tipicamente é utilizzato in abbinamento all'Unreal Engine 3, ma quasi tutti i giochi usciti di recente sono seguiti di titoli di qualche anno fa. E' inutile aggiungere il supporto alla GPU in Mass Effect 2 dove i calcoli per la fisica sono ridottissime.

Commento solo questo:

Contezero, potresti leggere i post prima di controbattere? Non siamo nella sezione dedicata alla politica.

- Non é vero che l'engine Physx é single thread, perlomeno non nel senso che lascia intendere l'articolo, nei post precedenti la cosa é stata spiegata
- Io ho avviato il benchmark fluidmark multi-threaded su due core, ottenendo come risultato prestazioni pari ad 1/4 rispetto alla G92. L'ho scritto nel post precedente, perché lo ignori? L'ho avviato anche in single thread, ed ovviamente ho ottenuto un risultato pari ad 1/8 rispetto alla G92, d'altronde la scalabilitá dell'engine con il numero di core é perfetta.
- Considerando quattro core e ottimizzazioni tali da raddoppiare le performance, si arriva ad (1/4)*2*2=1, cioé un quad core a 3.2 GHz arriva alle stesse performance di una G92, che é l'entry level.

Tu non hai letto l'articolo d'apertura allora.
Si parla del fatto che le librerie Ageia PhysX vanno MONOCORE, quindi puoi lanciare fluidmark anche su un cluster di 10.000 processori, ma se fluidmark usa PhysX stai sempre in x87 su un singolo core.

Tu non hai letto l'articolo d'apertura allora.
Si parla del fatto che le librerie Ageia PhysX vanno MONOCORE, quindi puoi lanciare fluidmark anche su un cluster di 10.000 processori, ma se fluidmark usa PhysX stai sempre in x87 su un singolo core.

No, sei tu che invece non hai letto lo sviluppo del thread: questa affermazione si é dimostrata fuorviante, infatti tutti i benchmark storici basati su Physx (es: i test della CPU di 3Dmark 2006 e Vantage) scalano perfettamente con il numero di core.

A dimostrazione di ció, qualche post addietro io ho postato i risultati del fluidmark con 10000 particelle e 2 emitters: 19 FPS in single thread, 39 FPS in multi-thread, 150FPS con la GPU.

Semplicemente, l'engine Physx non ha un meccanismo automatico di gestione dei thread embedded nell'SDK, cosa che verrá introdotta nella release 3.0, per cui gli sviluppatori devono gestirsi autonomamente il multi-core, come in generale in tutte le applicazioni.

Giusto per "chiudere il becco" a Blade:

Ho iniziato a sviluppare con PhysX da 3 anni, prima che la comprasse NVidia... il calo di qualità è stato costante, tanto che ora sono in dubbio se spendere 1 mese di tempo per estirparlo dal mio progetto!

Fun facts:
-E' stato comprato alla versione 2.7
-La versione 3.0 era prevista per Maggio 2008 (!!)
-Ad oggi siamo alla versione 2.8.3.1
-Sulla GPU girano solo fluidi e stoffe usate dallo 0.00001% dei giochi
-La GPU non supporta i Corpi Rigidi (rettangoli, sfere, cilindri) che vengono in ogni caso eseguiti sulla CPU
-Il motore fisico sulla CPU ancora single threaded
-Ora esce fuori che nemmeno usa SSE
-Nvidia ha cambiato la licenza da freeware a "pay-if-we-like-ware"

Nvidia dovrebbe seriamente lasciare stare il software... il che restringe il campo :asd:

Se poi i programmatori "a manina" wrappano PhysX per farlo diventare multithread (multithread sì, ma sempre su x87, non c'è nessun wrapper che trasforma le x87 in SSE :asd:) buon per loro, ma non è pratica diffusa al di fuori dei benchmark.

Giusto per "chiudere il becco" a Blade:



Se poi i programmatori "a manina" wrappano PhysX per farlo diventare multithread (multithread sì, ma sempre su x87, non c'è nessun wrapper che trasforma le x87 in SSE :asd:) buon per loro, ma non è pratica diffusa al di fuori dei benchmark.

Ma quale wrapper?

Peraltro, sai cos'é un wrapper? Io credo di no, perché in questa frase il termine non ha nessun senso.

La gestione multi-thread non é mai stata automatica, e infatti non é sufficiente avere un sistema operativo che lo supporta e una CPU multicore perché tutte le applicazioni siano automaticamente multi-threaded.

Stai affrontando la tematica in maniera eristica, volto solo a buttare in ciaciara la discussione pur di non ammettere un errore.

Ma quale wrapper?

Peraltro, sai cos'é un wrapper? Io credo di no, perché in questa frase il termine non ha nessun senso.

La gestione multi-thread non é mai stata automatica, e infatti non é sufficiente avere un sistema operativo che lo supporta e una CPU multicore perché tutte le applicazioni siano automaticamente multi-threaded.

Stai affrontando la tematica in maniera eristica, volto solo a buttare in ciaciara la discussione pur di non ammettere un errore.

Se il codice è fatto apposta non ci vuole molto a spawnare tot thread (su windows mi pare si chiamino "fiber" *) "figli" (1 x processore) e fargli condividere l'ambito di lavoro... se sono thread... in quell'ambito è cosa facile passare, tramite una chiamata, il numero di thread che si vogliono lanciare (o nulla, se si vuole che sia la libreria a decidere) e trattare il tutto come una black box, lasciando che siano gli internal della libreria ad occuparsi della coabitazione dei thread nello stesso spazio d'indirizzamento.
Non capisco perché debba essere il programmatore a fare lo spawn dei thread figli e dare ai singoli figli le strutture da elaborare separatamente a meno che la libreria PhysX non sia fatta per questo genere di cose (aka non thread-safe) e la soluzione spicciola trovata dai tizi del bench è lanciare X processi separati (processi, non thread, cioè ognuno col suo spazio d'indirizzamento), in contemporanea, e dividere il carico fra i processi, usando l'IPC per fare il dispatch dei dati da elaborare ed il relativo collect.

Se la libreria non è "thread safe" l'unico modo di gestire multicore "dall'estero" è wrappandola in questa maniera, ovvero lanciandone diverse sessioni separate su diversi spazi d'indirizzamento da parallelizzare, ma non è multihreading, è multitasking...

* No, i fiber sono i thread cooperativi (soft), che non c'entrano un cavolo perché per definizione non sono parallelizzabili.

Se il codice è fatto apposta non ci vuole molto a spawnare tot thread (su windows mi pare si chiamino "fiber") "figli" (1 x processore) e fargli condividere l'ambito di lavoro... se sono thread... in quell'ambito è cosa facile passare, tramite una chiamata, il numero di thread che si vogliono lanciare (o nulla, se si vuole che sia la libreria a decidere) e trattare il tutto come una black box, lasciando che siano gli internal della libreria ad occuparsi della coabitazione dei thread nello stesso spazio d'indirizzamento.
Non capisco perché debba essere il programmatore a fare lo spawn dei thread figli e dare ai singoli figli le strutture da elaborare separatamente a meno che la libreria PhysX non sia fatta per questo genere di cose (aka non thread-safe) e la soluzione spicciola trovata dai tizi del bench è lanciare X processi separati (processi, non thread, cioè ognuno col suo spazio d'indirizzamento), in contemporanea, e dividere il carico fra i processi, usando l'IPC per fare il dispatch dei dati da elaborare ed il relativo collect.

Se la libreria non è "thread safe" l'unico modo di gestire multicore "dall'estero" è wrappandola in questa maniera, ovvero lanciandone diverse sessioni separate su diversi spazi d'indirizzamento da parallelizzare, ma non è multihreading, è multitasking...

Non multi-tasking, multiprocessing. Di questo ne abbiamo giá parlato, se fosse cosi' dal task manager dovrebbero comparire i due processi separati con la propria allocazione di risorse. Ma non accade, c'é un solo processo. Da quello che ho notato Fluidmark associa un thread ad ogni ugello ("emitter"), ma il tutto avviene in un unico processo. Se ti fossi letto lo sviluppo dei thread avresti trovato anche questo passaggio.

Possiamo anche continuare a discutere, potrai anche trovare altre obiezioni, magari altri termini, ma, secondo me, se all'atto pratico le prestazioni scalano con il numero di core, affermando che é "single thread" si trasmette il messaggio sbagliato.

E, giusto per precisare: il bench del 3Dmark Vantage utilizza un accorgimento simile al fluidmark, cioé stanzia un macroblocco di oggetti per ogni core, ma quello del 3dmark2006 no, e scala anch'esso con il numero di core.

Altra osservazionev come potete vedere nell'immagine:

http://www.geeks3d.com/20100526/physx-fluidmark-how-to-get-you-multi-core-cpu-busy-at-100/

i thread, cioé gli emitters, interagiscono fra di loro, per cui la tesi secondo cui siano oggetti non comunicanti non é vera.

Non multi-tasking, multiprocessing. Di questo ne abbiamo giá parlato, se fosse cosi' dal task manager dovrebbero comparire i due processi separati con la propria allocazione di risorse. Ma non accade, c'é un solo processo. Da quello che ho notato Fluidmark associa un thread ad ogni ugello ("emitter"), ma il tutto avviene in un unico processo. Se ti fossi letto lo sviluppo dei thread avresti trovato anche questo passaggio.

Possiamo anche continuare a discutere, potrai anche trovare altre obiezioni, magari altri termini, ma, secondo me, se all'atto pratico le prestazioni scalano con il numero di core, affermando che é "single thread" si trasmette il messaggio sbagliato.

Penso che Tommo, che su PhysX ci lavora da anni, lo saprebbe se la libreria fosse thread-safe.
Per il resto il punto non verte tanto su quello quanto sul fatto che il codice usa la FPU anziché le SSE.

Penso che Tommo, che su PhysX ci lavora da anni, lo saprebbe se la libreria fosse thread-safe.


Ho aggiunto un pezzo nel thread precedente dopo che hai postato. Vale la mia osservazione precedente: se le prestazioni scalano con i core, per l'utenza l'applicazione é "multi-threaded". Come lo sia, safe, unsafe, manuale, automatico, sono dettagli tecnici.


Per il resto il punto non verte tanto su quello quanto sul fatto che il codice usa la FPU anziché le SSE.

Su questo io non ho obiettato nulla.

P.S. se qualcuno vuole fare qualche test, fluidmark di base limita il numero di emitters a Ncore-1, se volete lanciare tanti emitters quanti sono i core dovete selezionare "unlock cores".

Ho aggiunto un pezzo nel thread precedente dopo che hai postato. Vale la mia osservazione precedente: se le prestazioni scalano con i core, per l'utenza l'applicazione é "multi-threaded". Come lo sia, safe, unsafe, manuale, automatico, sono dettagli tecnici.

Mica tanto.
Che quelli di fluidmark siano riusciti a fare un sintetico in cui riescono ad usare le PhysX multicore non frega a nessuno se poi nei giochi le implementazioni sono monocore... anzi, non mi stupirebbe se fosse stata nVidia a "spiegargli" come abilitare il multicore giusto per "nascondere" l'inghippo.

Mica tanto.
Che quelli di fluidmark siano riusciti a fare un sintetico in cui riescono ad usare le PhysX multicore non frega a nessuno se poi nei giochi le implementazioni sono monocore... anzi, non mi stupirebbe se fosse stata nVidia a "spiegargli" come abilitare il multicore giusto per "nascondere" l'inghippo.

Conte, tu stai dando per scontato che Fluidmark, 3Dmark2006, 3Dmark Vantage siano tutti "truccati" per essere multi-threaded, mentre nei giochi siano in realtá single thread.

Ora, hai qualche dato a supporto della tesi? Hai effettuato qualche test specifico?

Io non ho mai effettuato test dedicati, se non con Crysis che peró non utilizza Physx. Se mi viene in mente un applicativo adatto faró qualche verifica. Il problema di fondo é che é difficile isolare le performance della fisica in un benchmark applicativo, e non sintetico. Per ora mi attengo ai fatti: conosco tre test di Physx, e tutti e tre sono multi-threaded.

@blade9722

L'autore dell'articolo ad esempio ha notato che Sacred, che è un gioco, era in single thread... quale importanza potrebbe avere FluidMark, che invece è un benchmark, per i nostri scopi se lo fai funzionate multithreading?
Le direttive nell'implementazione in un gioco partono sempre da nVidia che essendone proprietaria è pure l'unica interessata a impiegare quest'engine fisico.
I problemi tecnici di cui avete discusso sono disattenzioni volontarie figlie del marketing chiuso di questa tecnologia.
Risolti i primi, gli altri magicamente scompaiono.

Secondo me l'articolo oltre a non poter darci la controprova inoppugnabile per ovvie ragioni di licenza del prodotto/strumento in questione, non avrebbe lo scopo di dire chi fra path CPU o GPU tirerebbe di più il carretto; è una constatazione dai risvolti più pratici che teorici.... tra l'altro pure già fatti notare da più utenti.
Mi spiego....
Una GPU, a certi livelli di applicazione, non ce la fa a tirare al massimo PhysX mentre deve eseguire i calcoli per il rendering.
Se hai una dual GPU è un altro paio di maniche, ma se è una sola è problematico e non puo' dare libero sfogo a tutta la potenza di parallelizzazione di cui dispone Fermi SOLO per calcolare gli effetti fisici.
La fisica si prende l'eccedenza delle risorse non impegnate dalla GPU... ma i colli di bottiglia sono inevitabili se vuoi fps a 60 filtri tutti attivi, risoluzione più elevata e bla bla....
Premesso questo e che una CPU teoricamente non potrebbe mai arrivare a sfornare risultati assoluti identici per PhysX come su una GPU, all'atto pratico la situazione potrebbe prendere una piega differente per i motivi che ho detto prima.
Fino a un certo livello di applicazione della fisica la CPU potrebbe rivelarsi mediamente sufficiente tanto da ravvicinare i risulati GPGPU... perché tanto la GPU, a causa del carico di rendering, ha il guinzaglio attorno al collo e non va da nessuna parte.

http://www.geeks3d.com/20100711/cpu-physx-x87-sse-and-physx-sdk-3-0/

Estratto:

I did some PhysX CPU tests with FluidMark 1.2.0 by varying the number of particles. I used 3 emitters in order to fully load all X9650 cores. Here are the results:

Test bed:
- CPU: Quad core X9650 @ 3GHz (default clock)
- Windows 7 64-bit
- GPU 1: GTX 480
- GPU 2: GT 240 (dedicated PhysX card)

Common FluidMark settings: 3 emitters, PhysX multi-core ON, Async mode ON, 60sec, 1024×768 windowed.

120,000 particles
- GTX 480: PhysX: 175 (29 SPS) – GraphX: 347 (57 FPS)
- GT 240: PhysX: 86 (14 SPS) – GraphX: 539 (88 FPS)
- CPU: PhysX: 22 (3 SPS) – GraphX: 580 (95 FPS)

10,000 particles
- GTX 480: PhysX: 1312 (215 SPS) – GraphX: 2699 (443 FPS)
- GT 240: PhysX: 935 (153 SPS) – GraphX: 2953 (484 FPS)
- CPU: PhysX: 476 (77 SPS) – GraphX: 2749 (450 FPS)

5,000 particles
- GTX 480: PhysX: 1873 (307 SPS) – GraphX: 3391 (556 FPS)
- GT 240: PhysX: 1607 (263 SPS) – GraphX: 3620 (593 FPS)
- CPU: PhysX: 1311 (214 SPS) – GraphX: 3237 (530 FPS)

With many particles (120k), CPU PhysX is behind GPU PhysX and SSE code won’t change nothing. But it’s another story with few particles (5k): 214 SPS for the CPU and 263 SPS for the GT 240. And if SSE really improves the speed, maybe a CPU could dominate a GeForce in PhysX simulations…


----------------------

Sono usciti i requisiti di gioco di Mafia II, e se in pratica saranno rispettati per avere PhysX al max una GTX480 non ce la fa per simulare quel tipo di realismo che i DEVs avevano intenzione di raggiungere... è necesaria una conf. dual gpu per ripartire il carico di lavoro.
Non è certo il massimo della vita essere in possesso di una GTX480, che gli utenti l'hann comprata praticamente per PhysX e avere tutto a palla nei giochi, e vedere poi che per non scendere a nessun compromesso non basta.... si necessita di una seconda VGA e in molti casi anche di un altro alimentatore.
E' vero che molti degli utenti nVidia sono abituati a scialacquare e sperperare soldi a destra e a manca, ma questa non è un'attenuante per tutti gli altri.
Uno e due va finire che ci vuole sempre una VGA dedicata per PhysX.
Poi ci chiediamo come mai PhysX non riesca a imporsi.... sarà pure il migliore engine fisico per la qualità di realismo che offre ma inizia a diventare proibitivo nell'utilizzo.

@blade9722

cut
Sono usciti i requisiti di gioco di Mafia II, e se in pratica saranno rispettati per avere PhysX al max una GTX480 non ce la fa per simulare quel tipo di realismo che i DEVs avevano intenzione di raggiungere... è necesaria una conf. dual gpu per ripartire il carico di lavoro.
Non è certo il massimo della vita essere in possesso di una GTX480, che gli utenti l'hann comprata praticamente per PhysX e avere tutto a palla nei giochi, e vedere poi che per non scendere a nessun compromesso non basta.... si necessita di una seconda VGA e in molti casi anche di un altro alimentatore.
E' vero che molti degli utenti nVidia sono abituati a scialacquare e sperperare soldi a destra e a manca, ma questa non è un'attenuante per tutti gli altri.
Uno e due va finire che ci vuole sempre una VGA dedicata per PhysX.
Poi ci chiediamo come mai PhysX non riesca a imporsi.... sarà pure il migliore engine fisico per la qualità di realismo che offre ma inizia a diventare proibitivo nell'utilizzo.

Nessuno ti obbliga a spingere il gioco con tutti i dettagli al massimo se al momento non è possibile.
Queste cose sono sempre successe,e non serve citare Crysis che è un caso eccezzionale,e fin troppo eccessivo.
Anche Mafia 1 non girava con tutto quanto al massimo quando è uscito, ci è voluto tempo e nuove top di gamma per goderselo appieno.;)

Nessuno ti obbliga a spingere il gioco con tutti i dettagli al massimo se al momento non è possibile.
Queste cose sono sempre successe,e non serve citare Crysis che è un caso eccezzionale,e fin troppo eccessivo.
Anche Mafia 1 non girava con tutto quanto al massimo quando è uscito, ci è voluto tempo e nuove top di gamma per goderselo appieno.;)

Forse il messaggio non è arrivato. Provo a spiegartelo in un altro modo.
Quella non è una lamentela, è un punto di vista o critica, peraltro nemmeno tanto singolare, su che razza di markenting scellerato esercita nVidia.
Riferendomi a nVidia...
.... Non dai tregua nemmeno a tuoi clienti strapazzati che hanno speso una fortuna per portarsi nel case una GTX480.
Il messaggio trasmesso è questo:
"Tu nei requisiti massimi metti le soluzioni DualGPU e conf SLI perché non ne hai mai abbastanza e non ti basta mai. Spingi l'acceleratore su PhysX al massimo quando una GPU di ultima generazione a medi settaggi alza bandiera bianca."
Nemmeno una soluzione unica dual GPU del tipo GTX295 ce la fa a darti il massimo (almeno così sembra).
Ovvio che nessuno mi obbliga... ma non glieli metti i settaggi al massimo se sono proibitivi.

Messaggio addizionale : E'criminale inserire (tipo trojan) una libreria che, in tutti i contesti in cui non si usa la TUA scheda grafica, và così male da rallentare i giochi.

...arrivano le conferme (http://www.tomshw.it/cont/news/physx-non-e-ottimizzato-ben-2-anni-per-ammetterlo/26257/1.html) da parte di nvidia...per ben due anni codice non otimizzato...e il valore aggiunto tanto decantato quindi?...

...ciao Andrea...

... e di proposito nelle applicazioni, in cui c'è il suo zampino, costringe ad un singolo thread l'engine fisico quando potrebbe andare, senza alcuna remora, in multi-thread e avere tutt'altre prestazioni già senza ottimizzazioni SSE. Vedi trick per Batman AA.

nVidia ha sempre dichiarato di non prendere mazzette per l'implementazione di PhysX nei giochi, ma che in sostanza sono scelte fatte dal cliente, sviluppatore del gioco.
nVidia, invece, a detta loro, si rende disponibile a supportare questi clienti aiutandoli a implementare l'engine fisico e ottimizzare meglio il tutto.
Ma glielo fanno sapere al cliente che, durante questa simpatica collaborazione, si ha intenzione di castrare componenti non di loro proprietà per non fare brutte figure?
La domanda interessante è:
Fanno tutto sottobanco o è il cliente stesso a suggerire di dare priorità all'hw targato nVidia? :asd:
A momenti si faceva una figura migliore dichiarare: <<sì, ci accordiamo e paghiamo profumatamente le SH per PhysX. L'accordo prevede inoltre fare tutto il possibile per evitare di mandare a lucciole tutto il nostro meraviglioso marketing investito su PhysX>>

Dopo la storia dell'AA di Batman questa è un'altra.....
.... continuiamo così che siamo sulla strada giusta.
Qualcuno dica a questi inetti di fare un'inversione ad U e alla svelta.
Un giorno passo a fare i complimenti a nVidia per la GTX460, e il giorno dopo a rendermi conto che tra la divisione responsabile alle nuove tecnologie di nVidia esistono ancora le solite teste calde da calci nel sedere. http://www.xtremesystems.org/forums/images/smilies/smackbum.gif

Dall'articolo si evince che se la CPU potessero getire la fisica attraverso le istruzioni SSE i risultati prestazionali sarebbero migliori rispetto a quelli conseguiti delle GPU (difatti l'unità centrale puù gestire un numero di operazioni al secondo notevolmente superiori alle GPU).

trovano sempre la maniera per gabbare (o fregare se si preferisce) il "consumatore".

Per gestire la fisica non occorrerebbero nè schede apposite (vedasi ageia), nè GPU adeguate, sarebbe sufficiente la CPU.

Non è per scombussolare i ragionamenti e le dichiarazioni di chi è alle spalle del programma di gestione dedicata ageia/nvidia, ma sulle console gli stessi identici titoli, tanto decantati su pc per la fisica separata, funzionano senza hardware specifico o appoggio su gpu nvidia dell'ultima generazione. :)
:fiufiu: Non è che con la storia della fisica gestita a parte ci stanno prendendo ampiamente per il sedere? :D