Aspettando Fermi ......

gianni1879

Achille GForce ha scritto:

FuDZilla colpisce ancora

Fudzilla - Fermi to be the hottest single chip ever

Sembra che Fermi sarà il chip più caloroso mai prodotto

Fudzilla

Quà invece buone notizie, Fermi potrebbe essere anticipato e i primi lotti potrebbero arrivare prima di Marzo

Intanto nessuna conferma oggi in nessun portale del presunto taglio nel DP su GeForce.

fudzilla lo prenderei sempre e comunque con le pinze

Taurus

si ma dico io, fare qualche scheda per delle recensioni?? non vedo dove sia il problema :cheazz:

la cosa mi puzza...

comunque ecco qui una dimostrazione di Physicità di Fermi, che potenza

p.s. non bannatemi :asd:

delly

gianni1879 ha scritto:

fudzilla lo prenderei sempre e comunque con le pinze

eh già... :asd: :asd:

Totocellux

Achille GForce ha scritto:

[.........]

MA quello che interesserebbe sono le potenzialità di calcolo geometrico ( triangoli ) e il tessellation sono in DP o no ?

seguendo direttamente le specifiche Direct3D v.11, la Tessellation Unit, è controllata da due nuovi shader, per altro di diversa tipologia:

1) Hull Shader che in buona sostanza svolge due lavori:

a) prepara da una parte le coordinate e ne calcola i Tessellation factors dei singoli punti di controllo (inviati direttamente al Domain Shader)

b) dall'altra calcola i Tessellation factors che serviranno al Tessellator vero e proprio per dividere ogni singolo triangolo in triangoli più piccoli. Il Tessellator può così inviare output (sempre al Domain Shader) le coordinate spaziali (UVW) di ogni singolo vertex

2) Domain Shader che alla fine dei conti è quello che riceve entrambi i precedenti output, e si incarica di deformare la maglia creata sia con i punti di controllo calcolati dall'Hull Shader sia tramite le coordinate spaziali dei vertex risolte dal Tessellator, in modo tale da poter finalmente sfruttare una profondità di geometria molto più fine e dettagliata.

Considerato che la Model Shader v5.0 supporta la doppia precisione (in formato IEEE-754 con piena precisione 0.5 Unit of List Precision), la mia risposta è si, le predette operazioni potrebbero essere svolte in doppia precisione.

yossarian

gianni1879 ha scritto:

in ambito gaming ti do ragione, ma le tesla sono vga per ben altri scopi.
Ridurre la potenza di calcolo in DP ad 1/4 non è una bella cosa nelle GF, significa che i problemi ci sono eccome.

in ambito domestico non mi pare che ci siano sw in grado di sfruttare la DP. (cmq quì meglio sentire Yoss)

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

Iantikas ha scritto:

lo riscrivo in questo post casomai in quello più lungo uno si noia a leggere ...
...PhysX e tutte le applicazioni basate su CUDA che girano sulle Geforce sfruttano le potenzialità delle gpu in singola o doppia precisione?...

...l'aver ridotto di 1/4 da 256 a 64 FMA ops/clock le potenzialità teoriche in DP di fermi può portare qualche svantaggio in ambito consumer?...

...ciao

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

Totocellux ha scritto:

direi proprio di si, sia FP32 che FP64, ed in special modo in CUDA nelle applicazioni di calcolo prettamente di natura scientifica
direi sostanzialmente di no, a patto che la gpu non esegua calcoli sulla fisica

Totocellux ha scritto:

Physx è predisposto alla doppia precisione a partire dall'SDK v2.8.3
anche ATI sembra andare nella stessa direzione con il suo Stream SDK v2.0:

KB88 - Preview Feature: ATI Stream SDK v2.0 Support for Double-Precision Floating Point Basic Arithmetic in OpenCL C Kernels

Detto questo, ovviamente, che poi vengano proficuamente utilizzati o meno, questo è un altro discorso

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

Totocellux ha scritto:

seguendo direttamente le specifiche Direct3D v.11, la Tessellation Unit, è controllata da due nuovi shader, per altro di diversa tipologia:
1) Hull Shader che in buona sostanza svolge due lavori:

a) prepara da una parte le coordinate e ne calcola i Tessellation factors dei singoli punti di controllo (inviati direttamente al Domain Shader)

b) dall'altra calcola i Tessellation factors che serviranno al Tessellator vero e proprio per dividere ogni singolo triangolo in triangoli più piccoli. Il Tessellator può così inviare output (sempre al Domain Shader) le coordinate spaziali (UVW) di ogni singolo vertex

2) Domain Shader che alla fine dei conti è quello che riceve entrambi i precedenti output, e si incarica di deformare la maglia creata sia con i punti di controllo calcolati dall'Hull Shader sia tramite le coordinate spaziali dei vertex risolte dal Tessellator, in modo tale da poter finalmente sfruttare una profondità di geometria molto più fine e dettagliata.

Considerato che la Model Shader v5.0 supporta la doppia precisione (in formato IEEE-754 con piena precisione 0.5 Unit of List Precision), la mia risposta è si, le predette operazioni potrebbero essere svolte in doppia precisione.

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

Darkcool

Taurus ha scritto:

p.s. non bannatemi

ot mode on:

Questo video è veramente grottesco... :2funny:

ot mode off

Severnaya

no fa paura : |

Yoss scusa una domanda, ma tu personalmente l'architettura di fermi come la vedi? ti convince? soprattutto per sbocchi futuri come nuovi nodi, o è na ciofeca da buttare?

Totocellux

yossarian ha scritto:

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

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

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

cuda usa la dp; physx no

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

sapresti allora indicarmi l'utilità della funzione nxsetfpuprecision64() all'interno della NxUtilLib presente nel Physx SDK v2.8.3?

yossarian

Severnaya ha scritto:

no fa paura : |
Yoss scusa una domanda, ma tu personalmente l'architettura di fermi come la vedi? ti convince? soprattutto per sbocchi futuri come nuovi nodi, o è na ciofeca da buttare?

la trovo piuttosto interessante. La bontà di certe scelte sarà da verificare sul campo, però, l'idea di parallelizzare lo stadio di setup della geometria, ad esempio, mi sembra buona. Anche quella di realizzare, in pratica, una gpu che è la somma di 4 G80, va nella direzione di fornire una soluzione al problema delle gpu di fascia bassa, proposto dal chippone.

Direi che è tutt'altro che "'na ciofeca da buttare".

Certo, sta avendo un parto travagliato ma, d'altra parte, è una nuova architettura con nuovo processo produttivo. Mi sarei meravigliato se fosse andato tutto liscio, considerata anche la complessità del progetto.

Totocellux ha scritto:

sapresti allora indicarmi l'utilità della funzione nxsetfpuprecision64() all'interno della NxUtilLib presente nel Physx SDK v2.8.3?

una delle chiamate che permettono lo sviluppo di tool ottimizzati per sistemi operativi a 64 bit,funzionalità introdotta proprio con la versione 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.

Totocellux

yossarian ha scritto:

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

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

yossarian ha scritto:

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

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

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

dj883u2

Fluids Techdemo GF100 :

Bella.

Severnaya

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?

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:

:asd:

swattolo

dj883u2 ha scritto:

Chiaramente....è una Techdemo....lascia il tempo che trova.
Ecco la foto della GTX380 che circola su xtremesystems!:AAAAH:

Carina :asd: :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? :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

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

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

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