Newsgroup: it.comp.hardware.video-3d
Titolo: Physx in futuro probabilmente migrerà a OpenCL...

Era prevedibile una mossa del genere...
Poi una frase "divertente" da un manager di physx:
"Se iniziassimo a usare OpenCL, c'è la possibilità che le funzionalità 
lavorino anche su schede ATI; tuttavia, non ho idea delle prestazioni 
che potrebbero avere. In precedenza, osservando cose come Folding@Home, 
le prestazioni di calcolo delle GPU ATI si sono rivelate inferiori a 
quelle Nvidia. Questo, probabilmente, riflette il fatto che le loro GPU 
*sono un paio di generazioni dietro le nostre*".
ROTFL!!
http://www.tomshw.it/news.php?newsid=17565


diciamo che si cagano sotto di vedere le loro "GPGPU" a 250 euro essere 
surclassate dai teraflop di quelle da 150 euro di ati...
-- 
SimBus82.net coming soon - 
http://www.simbus82.net
Photo&DGTArt - 
http://simbus82.deviantart.com/
BodyWorkout - 
http://simbus82-workout.blogspot.com/
Combatti on-line con 
http://re-caio.labrute.fr
 

 *sono un paio di generazioni dietro le nostre*".
Essendo un campo esplorativo nuovo, l'architettura più efficiente 
dipende FORTEMENTE dal tipo di benchmark. Nulla vieta che le GPU nVidia 
siano più veloci in folding@home (di quanto, poi?) e che le ATI vadano 
2-3 volte meglio in altri tipi di calcolo massivamente parallelo. 
L'ultima frase è quindi un'ovvia boiata: in campo di rendering 3D le 
schede si equivalgono.
Spero comunque che presto anche ATi abbia supporto PhysX.
-- 
Ing. Danilo Pianini
"DanySK"
MSN: danysk_AT_alientech_DOT_it
Skype: 
dany.sk

 Spero comunque che presto anche ATi abbia supporto PhysX.
Per quale motivo? Quando Havok propone Physics + AI + Cloth tutto accelerato 
on GPU?
Diciamo che il "presto" dovrebbe essere riferito all'uscita dei nuovi giochi 
che integrano queste tecnologie e che andranno sia su schede ati nvidia sia 
su intel... grazie ad Havok.
Physx è stato chiaramente rifiutato sia da Ati che da Intel, anche se è da 
un anno che c'è chi ha fatto girare software "cuda" sulle Ati... sarà per 
motivi di marketing, ma 2 case contro 1, soluzione completa vs soluzione 
abbozzata ... le speranze di vedere Physx soppravvire sono moooooolto poche.


 abbozzata ... le speranze di vedere Physx soppravvire sono moooooolto poche.
Io non guardo le speranze ma i fatti. Ho imparato che nell'informatica 
fare previsioni porta solo a errori. PhysX esiste, i giochi lo usano, se 
può essere supportato MEGLIO.



scusa ma parliamo di physx a se o di cosa cambia quando la fisica è 
accelerata on gpu? no perchè in questo caso che physx giri o non giri su gpu 
non centra una mazza... per ora dove physx cambia "qualcosa" esiste SOLO 
mirror-edge...  (e tra l'altro portando via sp disponibili per il calcolo 
del 3d).


 del 3d).
Anche l'AA "porta via SP", personalmente preferisco passare dall'8x al 
4x (o al 2x, o anche cavarlo) e tenermi PhysX on. Mi sembra un discorso 
piuttosto strano: se gira su CPU porta via quintalate di CPU ed è 
inutilizzabile, se gira su GPU le prestazioni sono nettamente superiori. 
Quindi più che "porta via SP" direi che "usa bene SP e libera CPU".
Poi, è chiaro che non accelerando PhysX le prestazioni sono 
INACCETTABILI, a meno di non avere un mostro al posto della CPU. Quindi 
quando parlo di PhysX parlo:
1) Del fatto che se viene usato decentemente l'effetto è quantomeno 
gradevole
2) Del fatto che se non viene accelerato su GPU sia inutilizzabile.


 paio di generazioni dietro le nostre*".
innegabile, le ati son ancora alle dx 8.0 mentre nvidia è alle 11 e sta 
per sfornare le 12
e magari qualcuno ci crede pure alle sparate di questo idiota

 surclassate dai teraflop di quelle da 150 euro di ati...
si vabbè, ciao physx
http://www.fudzilla.com/index.php?option=com_content&task=view&id=12888&Itemid=1
AMD promises GPU physics on OpenCL
Havok based
AMD is working on its versions of physics acceleration based on the 
Havok engine, and as it was promised some time ago, this physics engine 
should be accelerated on both GPU and CPU.
It is quite interesting that Havok is owned by Intel, AMD’s biggest 
competitor but yet, when it comes to graphics card based physics, these 
two companies will work together as friends.
At least two things are currently running on ATI DirectX 10.1 GPUs and 
CPUs, realistic cloth physics and destruction with a lot of realism. 
There are over 200 games that are using Havok, and 100 more are coming, 
so if AMD accelerates Havoc right, Nvidia’s PhysX will get a nasty 
competitor.

 competitor.
Peccato che chi scrive queste cose non abbia proprio chiara l'idea che 
Havok andrà riscritto/ricompilato o come minimo wrappato, per cui il 
parco di 200 giochi non sarà accelerato :(


 e magari qualcuno ci crede pure alle sparate di questo idiota
Dal commento, si riferiva al GPGPU computing, non alla computazione 
grafica. Effettivamente, quantomeno come disponibilità di API/SDK e 
sistemi di calcolo dedicati sono abbastanza avanti (CUDA/Tesla).
Quanto a effettiva potenzialità dell'hardware, tutto è da dimostrare. Si 
attende OpenCL.


 giochi non sarà accelerato :(
ci sarà da ridere

 attende OpenCL.
Esatto, tutto è da dimostrare. Da una parte quanto dall'altra: la 
partita si giocherà sulle implementazioni di compute shader e di OpenCL, 
allora lì vedremo chi tra CUDA e Stream, come tra le due differenti 
arichettura, saprà farla da padrone.
p.bes

 serve in un solo posto, dal day one.
Non è poco. Se io ora volessi sviluppare software che gira su GPU, con 
nVidia avrei più punti di partenza (CUDA per C/++, le estensioni Matlab, 
JBLAS o come si chiama quella per i calcoli complessi su Java). Se 
volessi fare lo stesso su ATI non saprei sinceramente da dove partire (a 
meno che non sia tanto folle da prendermi l'ISA di R700 e scrivere in 
assembly XD).
Di conseguenza, dal mio punto di vista nVidia al momento è avanti. Poi è 
ovvio che non si possa giudicare l'esito di un GP dalla classifica alla 
prima curva ^^


 dove partire
ah no? sei allergico al sito di amd?
sei allergico al forum dei developer, aperto a tutti?
sei allergico al download del buonissomo SDK di Ati Stream?
Sei allergico alla documentazione allegata?
A volte ragioni proprio da prevenuto, seppur mascheri tutto dietro al fatto 
del "io ho amd".
Mah...


 Mah...
ti risparmio pure google
http://developer.amd.com/
http://forums.amd.com/devforum/
http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx
http://developer.amd.com/gpu/acmlgpu/Pages/default.aspx
visto che citi software matematici...
ah e visto che di nvidia si parla tanto che CUDA gira anche sulle schede da 
50 euro....
http://developer.amd.com/gpu/ATIStreamSDK/pages/ATIStreamSystemRequirements.aspx
Schede supportate da Ati Stream
ATI Radeon
HD 2350
2400 Pro
2400 XT
2400 LE
2600 Pro
2600 XT
2900 GT
2900 Pro
2900 XT
3690
3830
3850
3870
3870 X2
4350
4550
4650
4670
4830
4850
4850 X2
4870
4870 X2
ATI FirePro
V3750
V5700
V7750
V8700
V8750
AMD FireStream
9170
9250
9270
ATI Mobility Radeon HD
3650
3670
4300 Series
4500 Series
4650
4670
Prima di sparare VALANGHE di cazzate (come tutto l'ambaradan su havok, tanto 
che nei forum si vocifera che basterebbero poche dll modificate per 
sbilanciare on gpu il calcolo della fisica) informati.
Ati e il GPGPU č in moto da eoni fa... molto prima che nvidia desse un nome 
a cuda!


 
notare come sia simile il codice.
- OpenCL di suo fa abbastanza schifino: inutilizzabile sia da C++ che da 
Java. È una libreria C "secca", di livello piuttosto basso per giunta. 
Per Java comunque non dovrebbe esser proibitivo sfruttare le JNI... si 
spera. Spero sorga un progetto analogo a JME che porti OpenCL ad alto 
livello: così com'è è piuttosto legnoso.


 di rimangiarmi tutto.
ti ripeto, ci sarà da ridere, prepara un buon digestivo ;)

 Matlab e Java (Jacuzzi). Non trovo nulla di equivalente per Stream.
che schifo, Stream Computing è utilizzato dall'intera suite Adobe 
(Acrobat Reader, Photoshop CD4 Extended, After Effects CS4, Flash 10), 
ma anche CyberLink PowerDirector 7, ArcSoft TotalMedia Theater e 
Microsoft Windows Vista, Expression Encoder, Office PowerPoint 2007, 
Silverlight.. etc
però il piccolo plugin per matlab manca, disastro, nvidia più avanti
*MA PER FAVORE*

 prima curva ^^
Non stiamo dicendo nulla di nuovo. Ho detto esattamente le stesse cose 
alla tizia che, in teoria, dovrebbe essere la responsabile per tutto il 
discorso GPGPU di AMD (aveva partecipato a una conferenza di 
presentazione a Milano, per la penultima serie di schede FireGL): "se 
voglio sviluppare per CUDA, vado in un solo posto e trovo tutto quello 
che mi serve, se voglio sviluppare per Stream, devo zompare tra dieci 
siti diversi e almeno un paio di forum, cercare l'SDK, la documentazione 
e gli altri eventuali strumenti alla spicciolata e alla fine uno si 
stanca prima ancora di cominciare. Mi spiace dirvelo: Nvidia sotto 
questo aspetto è indubbiamente più avanti". Risposta: "metteremo 
ordine". Che voi sappiate, l'hanno poi fatto?
p.bes

 Risposta: "metteremo ordine". Che voi sappiate, l'hanno poi fatto?
http://developer.amd.com/
secondo te?
-_-


 ti ripeto, ci sarà da ridere, prepara un buon digestivo ;)
Il tuo bicchiere di Jager è pronto, alla salute!


 *MA PER FAVORE*
A me appare evidente che non riesci a valutare il peso delle 
applicazioni. Accelerare di 4-5 volte alcuni calcoli di Matlab può 
essere di beneficio assoluto per chi lavora in ambito scientifico. Aver 
PowerPoint che mostra le slide in modo più smooth... Non è esattamente 
una grossa conquista.
Poi tu puoi tranquillamente pensarla come ti pare, io resto della mia 
idea che Brook+, ottima idea di base, ha finito per fare danni visto che 
ha complicato l'integrazione con altri linguaggi di Stream. Di fatto, 
considero CUDA avere avuto più successo e penetrazione di Stream (pur 
ribadendo da ingegnere del software che preferisco molto il livello di 
astrazione di quest'ultimo) Tanto più che se ti leggi i documenti di 
OpenCL pare di leggere CUDA driver level.


 ordine". Che voi sappiate, l'hanno poi fatto?
Pare di sì: la documentazione e l'SDK sono accessibili. Peraltro 
(giudizio personale) preferisco il paper AMD a quello nVidia, è meno 
pesante e più guidato.
Paolo, sai per caso se nVidia ha ancora intenzione di tenere un layer 
CUDA sotto OpenCL, ora che lo standard è definito? Mi sono letto un po' 
di code examples, è estremamente simile a CUDA driver... Potrebbero 
anche pensare di supportarlo direttamente modificando/integrando CUDA 
invece che aggiungendolo come layer.


 invece che aggiungendolo come layer.
Da quel che ho capito io, Nvidia chiama sotto l'unico nome di "CUDA" 
parecchie tecnologie a livelli diversi, che spaziano dalla macchina 
virtuale che si occupa di mettere in comunicazione le API con il 
metallo, all'insieme di strumenti e librerie necessarie per la 
programmazione. In altre parole è "CUDA" tanto il layer di astrazione 
dell'hardware quanto le librerie matematiche necessarie per programmare 
in C sulla scheda video.
Trovo che sia abbastanza ovvio che una parte a più alto livello di CUDA 
sia ridondante con le OpenCL e con i compute shaders, mentre quella più 
a basso livello debba continuare a fornire, tanto alle librerie di 
Nvidia quanto a quelle di Microsoft e alle OpenCL, tutto il supporto 
necessario per usare i transistor della GPU.
Quindi, trai tu le tue debite conclusioni.
p.bes