Aspettando Fermi ......
-
Iantikas ha scritto:
[..........]
...PhysX e tutte le applicazioni basate su CUDA che girano sulle Geforce sfruttano le potenzialità delle gpu in singola o doppia precisione?...
direi proprio di si, sia FP32 che FP64, ed in special modo in CUDA nelle applicazioni di calcolo prettamente di natura scientifica
Iantikas ha scritto:
[..........]
...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?...
direi sostanzialmente di no, a patto che la gpu non esegua calcoli sulla fisica
-
Achille GForce ha scritto:
io sapevo invece che tutto l'ambito gaming si basava solo sul SP.come fa Physx ad essere double precision ? Il tessellation uguale suppongo vero ?
a parte che la news sarebbe da confermare, non è nulla di confermato per ora.
Aspettiamo la smentita da pate di Nvidia.
-
Achille GForce ha scritto:
io sapevo invece che tutto l'ambito gaming si basava solo sul SP.come fa Physx ad essere double precision ? Il tessellation uguale suppongo vero ?
[..........]
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:
Detto questo, ovviamente, che poi vengano proficuamente utilizzati o meno, questo è un altro discorso
-
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
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
-
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
-
gianni1879 ha scritto:
fudzilla lo prenderei sempre e comunque con le pinzeeh già...
:asd: -
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.
-
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 scientificadirei 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.3anche ATI sembra andare nella stessa direzione con il suo Stream SDK v2.0:
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).
-
Taurus ha scritto:
p.s. non bannatemi
ot mode on:
Questo video è veramente grottesco...
ot mode off
-
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?
-
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?
-
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.
-
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
altrimenti dovresti indicarmi il senso di poter impostare anche profondità a 24bit e 53bit
-
Fluids Techdemo GF100 :
Bella.
-
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? -
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:
-
dj883u2 ha scritto:
Chiaramente....è una Techdemo....lascia il tempo che trova.
Ecco la foto della GTX380 che circola su xtremesystems!:AAAAH:
Carina
:asd: -
ahahahahahahahahahahahahahahahah
XD
-
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)
-
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
C KernelsCiao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi