Aspettando Fermi ......

[dj883u2]

Fluids Techdemo GF100 :

Bella.

[Severnaya]

per essere spettacolare è spettacolare ma in un gioco, niente di aulico quindi , che possibilità ho di sfruttare un effetto del genere senza confondere il gameplay con un wallpaper?

[dj883u2]

Severnaya ha scritto:

per essere spettacolare è spettacolare ma in un gioco, niente di aulico quindi , che possibilità ho di sfruttare un effetto del genere senza confondere il gameplay con un wallpaper?

Chiaramente....è una Techdemo....lascia il tempo che trova.

Ecco la foto della GTX380 che circola su xtremesystems!:AAAAH:

[swattolo]

dj883u2 ha scritto:

Chiaramente....è una Techdemo....lascia il tempo che trova.

Ecco la foto della GTX380 che circola su xtremesystems!:AAAAH:

Carina :asd:

[Severnaya]

ahahahahahahahahahahahahahahahah

XD

[yossarian]

Totocellux ha scritto:

..... come?

non vorrei insistere, ma la capacità di dialogare con cpu e ss.oo. che sfruttano registri a 64bit, se mai è possibile definirla e dichiararla al compilatore e/o al linker in fase di compilazione e/o link-editaggio

non abbiamo parlato finora di efficienza operativa nè di Physx tantomeno delle modalità lato hardware.

Il quid è, se ben ricordo: Physx attualmente è predisposto ai calcoli in virgola mobile in precisione doppia?

tornando al SDK v2.8.3 questa è la descrizione sintetica della funzione a cui facevo riferimento:

virtual void NxSetFPUPrecision64 ()=0 Set FPU precision

imo, sembra che non faccia assolutamente riferimento ad un ambiente operativo o a cpu a 64bit, ma direttamente alla impostazione dell'unità di calcolo in virgola mobile a doppia precisione

altrimenti dovresti indicarmi il senso di poter impostare anche profondità a 24bit e 53bit

mi ero fatto l'idea che la questione fosse: sarà o meno fermi in version e geforce penalizzato dalla ridotta potenza di calcolo in fp64. Se la questione è quella, la risposta è no. Alla domanda physx è predisposto per i calcoli in fp64 la risposta è (molto probabilmente, non te lo do per certo perchè non mi occupo di sviluppare tool con physx) si; questo per lo stesso motivo per cui le dx11 prevedono l'adozione di fp64 e l'uso di fma anche se, per ora, non se ne farà affatto uso. Ossia per una compatibilità con lo standard IEEE 754-2008.

Arriviamo al'sdk 2.8.3

queste le release note

Release Notes - NVIDIA PhysX SDK 2.8.3

 

30th September 2009

 

What's New In NVIDIA PhysX 2.8.3

 

General

 

· This release enables clothing simulation. These new features are required to run the APEX clothing module

 

· The release also adds a hierarchical solver for cloth

 

· Introduction of split pair notification for cloth (existed for soft bodies only in previous versions)

 

· Improved statistics to track GPU memory utilization

 

· Updated with 64Bit Windows support

 

Supported Devices

 

· The supported devices are the same as for PhysX 2.8.1 (see below), except that the AGEIA PhysX Processor (PPU) device support was removed

 

http://developer.nvidia.com/object/physx_downloads.html

seguono indicazioni sulle performance e sui bugfix. Nella sezione generale, le cose più rilevanti sono la rimozione del supporto alle PPU e il supporto a win64. Rispetto alle passate versioni non parla di update con calcoli fp64 su gpu.

Altra cosa "strana", il livello di precisione che è indicato nelle impostazioni.

Se quelli sono i livelli di precisione abilitati su gpu c'è più di qualcosa che non torna.

Ad esempio fp53 non esiste nel modo più assoluto. 53 bit, semmai è il numero di bit complessivi della mantissa a fp64 (52 bit di storage + 1 per la normalizzazione); inoltre, che senso ha dichiarare fp24 (che è supportato dalle dx9a) e non fp16 ed fp32?

E' proprio il senso di impostare 24 e 53 che non riesco a trovare (se lo guardo nell'ottica delle precisioni di calcolo che è possibile impostare su una gpu). Aggiungo un paio di cose: nei giochi, le alu fp64 di gt200 non vengono attivate (neppure quando si una physx). Physx non ha solo le gpu come piattaforma di riferimento (la stragrande maggioranza dei titoli che attualmente fanno uso di physx su pc si appoggiano alla cpu, così come la totalità dei titoli per xbox360 e ps3)

[Totocellux]

yossarian ha scritto:

andiamo per ordina: alla domanda physx è predisposto per i calcoli in fp64 la risposta è (molto probabilmente, non te lo do per certo perchè non mi occupo di sviluppare tool con physx) si; questo per lo stesso motivo per cui le dx11 prevedono l'adozione di fp64 e l'uso di fma anche se, per ora, non se ne farà affatto uso. Ossia per una compatibilità con lo standard IEEE 754-2008.

[..........]

.... ora siamo in perfetta sintonia

Comunque, nemmeno io sviluppo alcunché in Physx ....... cerco di comprendere ciò che mi sta o mi viene incontro

yossarian ha scritto:

[..........]

Arriviamo al'sdk 2.8.3

[..........]

E' proprio il senso di impostare 24 e 53 che non riesco a trovare (se lo guardo nell'ottica delle precisioni di calcolo che è possibile impostare su una gpu). Aggiungo un paio di cose: nei giochi, le alu fp64 di gt200 non vengono attivate (neppure quando si una physx). Physx non ha solo le gpu come piattaforma di riferimento (la stragrande maggioranza dei titoli che attualmente fanno uso di physx su pc si appoggiano alla cpu, così come la totalità dei titoli per xbox360 e ps3)

qui posso ora seguirti un pò più da vicino rispetto a prima: è vero che esiste una qualche incongruenza (in perfetta coerenza direi: tutta questa storia di Fermi attualmente non lo è in fondo? ).

Dal tuo ragionamento continui però a darmi l'impressione di osservare la situazione dal solo punto di vista GT200: quello è il passato, mentre ciò che potrebbe spiegare il tutto sta proprio nella tendenza generalizzata dello sviluppo del software di anticipare il corrispettivo lavoro sull'hardware.

In particolare personalmente penso che, siccome le specifiche della v2.8.3 sono da solo pochi mesi state riviste, queste potenzialità potrebbero essere state inserite proprio in previsione di avvantaggiarsene tramite le rinnovate ed ampliate capacità di Fermi in precisione doppia, rispetto al passato

[yossarian]

Totocellux ha scritto:

.... ora siamo in perfetta sintonia

Comunque, nemmeno io sviluppo alcunché in Physx ....... cerco di comprendere ciò che mi sta o mi viene incontro

qui posso ora seguirti un pò più da vicino rispetto a prima: è vero che esiste una qualche incongruenza (in perfetta coerenza direi: tutta questa storia di Fermi attualmente non lo è in fondo? ).

Dal tuo ragionamento continui però a darmi l'impressione di osservare la situazione dal solo punto di vista GT200: quello è il passato, mentre ciò che potrebbe spiegare il tutto sta proprio nella tendenza generalizzata dello sviluppo del software di anticipare il corrispettivo lavoro sull'hardware.

In particolare personalmente penso che, siccome le specifiche della v2.8.3 sono da solo pochi mesi state riviste, queste potenzialità potrebbero essere state inserite proprio in previsione di avvantaggiarsene tramite le rinnovate ed ampliate capacità di Fermi in precisione doppia, rispetto al passato

fermi implementa la stessa precisione di calcolo di gt200. Per quanto riguarda le unità in floating point, in particolare, fp16, fp24, fp32 ed fp64 (non ti sto a tediare con i calcoli in virgola fissa o interi ).

L'unica differenza, a livello di precisione di calcolo, è che fermi usa fma al posto di madd anche in fp32 (mentre gt200 ha alu fp32 di tipo madd e alu fp64 dedicate che fanno fma).

Per il resto non cambia assolutamente nulla (almeno sotto questo aspetto, per chè per il resto ci sono cambiamenti architetturale anche piuttosto importanti).

La maggior capacità di calcolo di fermi in fp64 servirà ad avvantaggiare il gpgpu ma non le applicazioni di physx per i giochi. Considera che in fermi, ogni caclolo in dp impegna due alu di tipo sp e quando si eseguono calcoli in dp non è possibile eseguire calcoli di altro tipo (ad esempio special function). Quindi, l'utilizzo contestuale su uno SP di 32 alu di dp, con sp e sfu, ad esempio, sarebbe impossibile e questo abbatterebbe di molto la capacità di calcolo in sp di fermi. Ad essere precisi, l'utilizzo di dp inibisce la possibilità di utilizzare il doppio warpscheduler presente in ogni SP, il che significa che hai l'equivalente di 16 alu fp64 con un unico scheduler (il che significa impossibilità di elaborare due thread indipendenti in parallelo e ridotte capacità di fare thread switching rispetto all'utilizzo dif p32)

[Totocellux]

yossarian ha scritto:

fermi implementa la stessa precisione di calcolo di gt200. Per quanto riguarda le unità in floating point, in particolare, fp16, fp24, fp32 ed fp64 (non ti sto a tediare con i calcoli in virgola fissa o interi ).

L'unica differenza, a livello di precisione di calcolo, è che fermi usa fma al posto di madd anche in fp32 (mentre gt200 ha alu fp32 di tipo madd e alu fp64 dedicate che fanno fma).

Per il resto non cambia assolutamente nulla (almeno sotto questo aspetto, perchè per il resto ci sono cambiamenti architetturale anche piuttosto importanti).

era in fondo quello a cui volevo arrivare e .... penso anche dove vorrebbe arrivare nVidia (lo spero per loro, altrimenti sarà davvero una catastrofe

a seguito di queste profonde mutazioni architetturali, la capacità complessiva di calcolo in fp64, stando ai pochi bench e notizie ricevute dovrebbe realmente divenire di gran lunga superiore a ciò che è stato finora

[Severnaya]

dj883u2 ha scritto:

cerco di comprendere ciò che mi sta o mi viene incontro

posso affermare con certezza che Milly D'Abbraccio ha detto la stessa cosa

[yossarian]

Totocellux ha scritto:

era in fondo quello a cui volevo arrivare e .... penso anche dove vorrebbe arrivare nVidia (lo spero per loro, altrimenti sarà davvero una catastrofe

a seguito di queste profonde mutazioni architetturali, la capacità complessiva di calcolo in fp64, stando ai pochi bench e notizie ricevute dovrebbe realmente divenire di gran lunga superiore a ciò che è stato finora

sicuramente, anche perchè la capacità di calcolo di gt200 in fp64 è veramente poca cosa. Fermi in versione tesla avrà una capacità di calcolo, con i modelli annunciati, paragonabile a quella di rv870 (mentre gt200 era di molto inferiore a rv770). Questo grazie all'abbandono di hardware dedicato e all'uso di dua alu fp32 per ricavarne una fp64 (sul modello di larrabee). Nei chip ATi, un'alu fp64 è ricavata da un'alu fp32 5-way vliw, quindi ogni 5 unità fp32 si ha un'alu fp64.

Come detto, questa potenza in più, però, sarà dedicata ad applicazioni che facciano uso di fp64 e non ai giochi (per cui si usa fp32). Anche perchè l'utilizzo di dp inibisce la possibilità di utilizzare il doppio warp scheduler presente in ogni SP, il che significa che hai l'equivalente di 16 alu fp64 con un unico scheduler (il che significa impossibilità di elaborare due thread indipendenti in parallelo e ridotte capacità di fare thread switching rispetto all'utilizzo dif p32). In pratica, in fermi, quando uno SP di 32 alu imposta calcoli in fp64, diventa l'equivalente di uno sp di 16 alu fp64 che possono eseguire un solo thread (rigorosamente fp64) per volta e non diversi tipi di calcolo in contemporanea.

[Totocellux]

Severnaya ha scritto:

posso affermare con certezza che Milly D'Abbraccio ha detto la stessa cosa

devo dire che non sei stato particolarmente attento quando parlava!

Lei ha detto con precisione: "cerco di comprendere ciò che mi sta o mi viene dietro!"

[yossarian]

Totocellux ha scritto:

devo dire che non sei stato particolarmente attento quando parlava!

Lei ha detto con precisione: "cerco di comprendere ciò che mi sta o mi viene dietro!"

non era "cerco si afferrare................................." ?

[Totocellux]

yossarian ha scritto:

non era "cerco si afferrare................................." ?

..... non dirmi che ero disattento anch'io!?

[delly]

dj883u2 ha scritto:

Ecco la foto della GTX380 che circola su xtremesystems!:AAAAH:

bellissimo il "The way it's meant to be rebarged!"

[Totocellux]

delly ha scritto:

bellissimo il "The way it's meant to be rebarged!"

beh, se questo è il prototipo finale, direi che di palesemente scopiazzato dalla 5870 vi è il disegno e il posizionamento delle due bocchette di immissione d'aria

[Severnaya]

Totocellux ha scritto:

devo dire che non sei stato particolarmente attento quando parlava!

Lei ha detto con precisione: "cerco di comprendere ciò che mi sta o mi viene dietro!"

yossarian ha scritto:

non era "cerco si afferrare................................." ?

Totocellux ha scritto:

..... non dirmi che ero disattento anch'io!?

devo cercare di stare più attento anch'io, certi dettagli nn vanno sottovalutati!

[Taurus]

Achille GForce ha scritto:

Nvidia usa platica altro tipo di plastica non quella ruvida economica.

la prima cosa che ho notato quando ho preso la 5970 è stata la plastica e le finiture di gran lunga migliori della GTX280 che ho ancora

[Severnaya]

Achille GForce ha scritto:

mah veramente la GTX 200 non aveva nessuna sbavatura ed era realizzata con plastica ludica e non ruvida. che abbia rifiniture migliori è impossibile.

ossignur... ma hai degli alieni come vicini di casa?

[dj883u2]

Achille GForce ha scritto:

Nvidia usa platica altro tipo di plastica non quella ruvida economica.

Achille GForce ha scritto:

mah veramente la GTX 200 non aveva nessuna sbavatura ed era realizzata con plastica ludica e non ruvida. che abbia rifiniture migliori è impossibile.

Tu sai sempre qualcosa + di tutti!:AAAAH:.....ma se non hai neanche una HD5000....perchè parli? Solo per consumare aria?....aspetta...adesso mi dirai che grazie ad un tuo amico sai come è!:clapclap: