Jump to content

Aspettando Fermi ......


Achille GForce

Recommended Posts

in ambito gaming non si sfruttano i 64 bit. Si lavora a fp32, fp16, in alcuni casi addirittura INT8 (vedi MSAA box)

 

 

 

alcune applicazioni che girano su cuda sfruttano la dp; physx no.

La maggior parte dei sw in ambito consumer usa, al più, fp32. Ovviamente non parliamo di gpgpu nel senso stretto del termine (anche physx è un giocherello rispetto alla "vera" fisica su gpu o cpu che sia).

 

 

 

 

 

 

cuda usa la dp; physx no e neppure i sw di tipo consumer "spacciati" per gpgpu (tipo badaboom e simili).

 

 

 

il tessellator lavora al massimo a fp32 (il vero e proprio tessellator è di tipo fixed function anche gli hull shader hanno una parte di tipo ff).

 

 

MA è fantastico quindi non perderebbe nulla nè in ambito gamer nè in quello applicativo da desktop ! Manterrebbe sia il potenziale del tessellator sia di Physx per non parlare degli applicativi di conversione praticamente intatti ! :clapclap::clapclap:

 

Ma scusate allora perchè ci sono tutte ste lamentele sul taglio del DP ? praticamente da quanto ha detto Yossarian sono unità morte su desktop non servono proprio a niente a noi. A sto punto se vogliono tagliere i DP che non servono una mazza che taglino pure e non capisco perchè non lo abbiano fatto prima !

Edited by Achille GForce
Link to comment
Share on other sites



  • Replies 2.3k
  • Created
  • Last Reply

Top Posters In This Topic

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

una delle chiamate che permettono lo sviluppo di tool ottimizzati per sistemi operativi a 64 bit,funzionalità introdotta proprio con la versione

 

..... 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 ;)

 

 

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

2.8.3. Physx non può far uso di fp64: sarebbe un autogol clamoroso, visto che gt200 in dp è un chiodo e g80 e derivati (quindi fino alla 250 compresa) non fanno calcoli in fp64.

 

 

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 ;)

 

i43280_physx-sdk-v2.8.3.jpgi43280_physx-sdk-v2.8.3.jpg

 

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

Link to comment
Share on other sites

per essere spettacolare è spettacolare ma in un gioco, niente di aulico quindi :asd:, 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:

 

i43288_1.jpg

 

:asd:

Link to comment
Share on other sites

..... 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 ;)

 

i43280_physx-sdk-v2.8.3.jpgi43280_physx-sdk-v2.8.3.jpg

 

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)

Edited by yossarian
Link to comment
Share on other sites

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 ;)

 

 

 

 

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

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? :asd:).

 

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

 

:)

Link to comment
Share on other sites

.... 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? :asd:).

 

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 :asd:).

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)

Edited by yossarian
Link to comment
Share on other sites

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 :asd:).

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).

 

 

O0

 

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

 

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 :)

Link to comment
Share on other sites

O0

 

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

 

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.

Link to comment
Share on other sites

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!" :asd:

 

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

 

:azz:

 

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

 

 

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

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...