C’era una volta, tanto tempo fa, una batteria di software house che sviluppavano applicazioni e, in particolare, videogiochi tentando di spremere letteralmente ogni singolo bit che l’hardware gli metteva a disposizione pur di offrire un’esperienza di gioco innovativa, sbalorditiva ed entusiasmante.
Non sempre gli sviluppatori riescono a concretizzare quello che hanno in mente, ma l’idea che mi sono personalmente fatto quando penso all’era pre-PC nel mondo dei videogames, è che all’epoca l’impegno speso nell’ottimizzazione era molto spesso più che evidente.
Oggi, invece, vi parlo di una notizia che ho appreso qualche giorno fa e che contrasta enormemente con quanto vi ho appena riportato. Secondo un articolo riportato su Real World Technologies, nel quale viene analizzato il comportamento della libreria PhysX di NVIDIA, è emerso che quest’ultima non fa uso delle istruzioni multimediali SSE dei processori per elaborare i complessi calcoli alla base delle simulazioni fisiche.
Per chi non la conoscesse, PhysX è una libreria che fornisce essenzialmente una serie di API con l’obiettivo di accelerare l’elaborazione dei calcoli legati alla fisica in maniera analoga a quanto OpenGL e Direct3D fanno con la grafica tridimensionale. PhysX è nato per opera di Ageia, un’azienda fondata nel 2002 che per prima ha proposto una soluzione hardware per l’accelerazione delle elaborazioni fisiche nei videogame.
Il processore fisico PhysX P1 (PPU – Physics Processing Unit) venne commercializzato da Asus e BFG senza di fatto riscontrare un enorme successo probabilmente perché la problematica a cui ha tentato di porre rimedio, cioè migliorare le prestazioni in questo specifico ambito dei videogame, non era particolarmente sentita. Inoltre anche il supporto da parte delle software house non fu particolarmente presente, il che faceva decadere l’utilità di un acquisto simile.
Ageia riuscì comunque ad attirare l’attenzione dei produttori di processori grafici e, in particolare, NVIDIA nel Febbraio 2008 ne acquisì tutte le proprietà. Il colosso californiano non si fece, infatti, sfuggire l’occasione di giocare un ruolo di primo piano nel settore dell’accelerazione in hardware delle elaborazioni fisiche. Forte della sua notevole vitalità commerciale, NVIDIA accantonò da subito il processore PhysX P1 ed implementò l’accelerazione in hardware della libreria PhysX nei suoi processori grafici GeForce.
Inutile affermare che l’enorme parco di PC in cui sono installate schede video GeForce in grado di accelerare PhysX ha spinto le software house a fornirgli un più che discreto supporto al punto che sono diversi i titoli oggi in commercio che utilizzano questa libreria per le elaborazioni della fisica.
A questo punto la domanda che si sono posti in molti è la seguente: come funziona PhysX nel momento in cui non è installata una scheda video GeForce? Secondo le indagini di Real World Technologies, malissimo.
Utilizzando l’Intel VTune Performance Analyzer, uno strumento di profiling certamente noto agli sviluppatori di applicazioni native, per analizzare l’esecuzione del gioco Cryostasis e di una demo di PhysX, è emerso che il codice eseguito all’interno del modulo PhysXCore.dll non integra nemmeno un’istruzione SSE, mentre si affida al 100% ad istruzioni x87.
Le istruzioni Streaming SIMD Extensions (SSE) sono state introdotte da Intel nel lontano 1999 con i Pentium III allo scopo di accelerare l’esecuzione di una serie di operazioni in virgola mobile. Nel corso degli anni diverse sono state le evoluzioni di queste istruzioni al punto che oggi siamo arrivati alla quarta revisione (SSE4).
Senza addentrarci troppo nel dettaglio, la caratteristica fondamentale di queste istruzioni è quella di essere SIMD, Single Instruction Multiple Data, cioè sono particolarmente indicate nel trattare più dati con la medesima istruzione, proprio il tipo di operazione cara ad ambiti come la grafica tridimensionale e le simulazioni fisiche. Utilizzando queste istruzioni è possibile incrementare notevolmente le prestazioni in questo tipo di elaborazioni rispetto all’uso delle classiche istruzioni x87.
Come mai, quindi, all’interno di una libreria per l’elaborazione della fisica non viene fatto uso delle istruzioni SSE? La componente “compatibilità con i vecchi processori” può essere tranquillamente esclusa in quanto qualsiasi CPU dal 2005 ad oggi supporta almeno le SSE2, più che sufficienti ad ottenere un notevole miglioramento delle performance e, anche se si volessero supportare a tutti i costi le CPU più anziane, nulla vieterebbe al setup di installazione di verificare le capacità della CPU e di installare conseguentemente la versione x87 o SSE.
Anche il fattore legato alla precisione di calcolo (fino a 80 bit nelle operazioni x87) è da escludere in quanto il processore PhysX P1 lavorava a 32 bit e anche le schede video GeForce sicuramente useranno 32 bit di precisione internamente per accelerare PhysX considerando anche il supporto di GPU come G80 che non vanno oltre questo valore.
L’articolo arriva all’unica possibile conclusione “PhysX uses x87 because Ageia and now Nvidia want it that way”, cioè essenzialmente la libreria non è ottimizzata per le CPU semplicemente perché così facendo molto probabilmente l’incremento delle prestazioni offerto dall’uso delle GPU GeForce per accelerare PhysX si assottiglierebbe al punto da non poter più utilizzare questa funzionalità nella campagna di marketing NVIDIA.
La notizia ha un certo peso anche perché le capacità di calcolo delle GPU NVIDIA, specie di ultima generazione, dovrebbero garantire comunque un surplus prestazionale tale da non dover arrivare a castrare il calcolo su CPU per fare bella figura. Detto questo, mi sorgono dubbi anche sull’effettiva ottimizzazione di PhysX sulle GPU stesse.
D’accordo al 100%.
La fisica puo’ essere accelerata sulla cpu, e’ solo che nel caso di PhysX si e’ scelto deliberatamente di non abilitare tale funzionalita’ per spingere un ecosistema proprietario.
Si sente sempre dire, ma la cpu perche’ dovrebbe fare i calcoli di fisica, perche’ dovrebbe farsi carico dell’audio etc… Se deleghiamo tutto a processori esterni mi dite l’interesse di avere una cpu ? ^_^
Ad esempio Crysis (motore grafico a parte) dimostro’ come era possibile fare un motore audio completamente software che a livello di effetti non facesse rimpiangere le EAX.
La fisica dovrebbe essere elaborata dalla cpu, ma allora chiunque potrebbe trarne vantaggio. Utenti ATI e Nvidia. Ora invece su pc non e’ cosi’, tanto che la fisica viene vista come un orpello. Qualcosa che si aggiunge per ultimo e che non rivoluziona il gameplay come invece dovrebbe fare.
Detto questo, la colpa di questa situazione non e’ solo di Nvidia che ci guadagna ovviamente, ma anche di ATI che non si da da fare, e di Intel (e ce lo dimentichiamo sempre) che compro’ Havok e uccise Havoc FX (il motore fisico che sarebbe stato accelerato dalle cpu).
Insomma una serie di circostanze e strategie miope hanno fatto della fisica su pc una terra di nessuno. E tutti sono perdenti.
@goldorak
quoto al 100%
…e poi venne Bullet Physics, che viene ottimizzato per le SSE, per CUDA, per il Cell della PS3, ecc… ecc… e che probabilmente da del filo da torcere al costoso pacchetto PhysX della nVidia
“Detto questo, mi sorgono dubbi anche sull’effettiva ottimizzazione di PhysX sulle GPU stesse.”
Tutta questa faccenda è una montatura in realtà: PhysX da quando l’ha acquisito Nvidia è semplicemente fatto male.
Il discorso “usano x87 per peggiorare le prestazioni su CPU” non ha alcun significato dal momento che il codice che usa x87 non gira nemmeno sulla GPU…
la GPU non accelera i corpi rigidi, che anche in presenza di una GeForce vengono calcolati sulla CPU.
L’unica cosa che fa la GPU è un aiuto generico nella broadphase e il calcolo di fluidi e stoffe, che non a caso sono quello che viene aggiunto nei giochi “PhysX enabled”.
Quindi l’ipotetica comparazione “CPU vs GPU” che Nvidia fa sempre nelle PR non solo non è vantaggiosa per la GPU, ma nella maggior parte degli ambiti non può nemmeno essere fatta.
PhysX è semplicemente vecchio (la base di calcolo risale al 2002, e all’epoca aveva senso usare x87) e Nvidia non ha fatto alcuno sforzo per riscriverlo…
@ Tom
In realtà, non ha senso usare le istruzioni x87 da quando esistono le CPU con supporto a SSE, cioè dal Pentium III / Athlon XP in poi.
Non mi si venga a dire che è un problema di compatibilità: i processori che supportano le SSE esistono almeno dal 2001. E non penso proprio che nessuno si sognerebbe di far girare un gioco “PhysX enabled” su processori così vecchi.
La realtà è solo prestazionale: le istruzioni x87 sono molto più lente delle equivalenti SSE, anche se queste ultime vengono usate in modalità scalare e non SIMD. Quindi personalmente non ho il minimo dubbio che il codice x87 sia stato deliberatamente inserito per castrare le prestazioni in assenza di una GPU.
Ciao
Filippo
Nvidia ha dimostrato il suo concetto di concorrenza già ai tempi dell’acquisizione di 3dfx, e da allora non lo ha mai variato di molto.
Morale c’è poco da discutere.
A differenza che in altri campi la concorrenza c’è ed è almeno a pari livello, per cui il migliore sistema per indurla a più miti consigli è non acquistare i suoi prodotti
giorni fa lessi che interpellata sull’argomento nvidia aveva risposto che il codice physx così com’è ha tali e tante pare da non essere riconvertibile alle sse senza andare incontro a problemi e che il “passaggio” ci sarebbe stato con la nuova versione della libreria in uscita fra qualche mese…
purtroppo però non riesco a recuperare la fonte :/
@Filippo
non usare SSE ha senso da un punto di vista tecnico/monetario:
infatti per usare SSE devi processare 4 “threads” assieme, dal momento che ogni singola istruzione processa 4 floats separatamente.
Se la struttura del motore è stata pensata nel 2001 senza il minimo parallelismo, è possibilissimo che ad oggi per trovare questo parallelismo sia più facile buttare giù tutto e rifarlo daccapo.
E’ chiaro che a Nvidia non piace l’idea di dover rifare daccapo un progetto solo per mettere in imbarazzo le proprie GPU ;)
Inoltre Nvidia ha chiaramente comprato PhysX solo come strumento di marketing, infatti la versione 3.0 (con tutta questa bella roba) sarebbe dovuta uscire a Maggio 2008.
Dopo l’acquisizione Nvidia, e dopo 2 anni e mezzo, siamo alla versione 2.8.3.1… solo bugfix e fluidi sulla GPU.
Per dire, mancano ancora i cilindri!
Comunque la 3.0 dovrebbe essere vicina, speriamo bene… ho un progetto legato strettamente a PhysX, purtroppo.
@Tom
montatura fino a un certo punto…si tratta di pubblicità ingannevole a prescindere che il progetto PhysX sia fatto alla pene di seguggio ;)
era una cosa palese gia’ dalla beta di cell factor che scattava paurosamente sul mio ex athlon x2 pur occupando circa meta’ di un core… e non per via della scheda grafica
@Tom:
in riferimento al post #8, direi che l’ipotesi tecnico/monetario non è tanto ammissibile: a convertire l’implementazione per CUDA c’hanno messo poco…!
Cmq per come me lo immagino io, i dati saranno organizzati in tanti array o matrici… quando hai array o matrici non ci vuole molto a pensare una soluzione che usi le SSE.
Tutto sommato non mi sembra una cosa cosi’ strana: NVidia ha acquistato PhysX per farlo diventare un valore aggiunto per le sue schede.
Spendere tempo e risorse per portarlo su CPU (non e’ che ci voglia cosi’ poco, eh) e cosi’ facendo _diminuire_ il valore aggiunto delle sue schede e’ una mossa suicida, e quindi non lo fa.
@Pleg
si ma almeno non vantarti di millantate prestazioni superiori rispetto alle cpu, dato che è pubblicità ingannevole…alla fine è quella la cosa grave
@Tom (#8)
Le SSE non comprendono solo istruzioni SIMD, ma anche istruzioni scalari, cioè istruzioni che processano un solo dato floating point per volta. Intel le ha appositamente introdotte per “disfarsi” della pesante ed inefficiente eredità del codice x87; non solo, ma i processori EM64T / AMD64, cioè quelli in grado di eseguire codice a 64 bit, se usati in modalità nativa 64 bit non supportano affatto il codice x87, ed è quindi obbligatorio usare le SSE/SSE2 per eseguire calcoli in virgola mobile anche su un solo dato alla volta.
Quindi, non occorre a rigore che l’algoritmo sia parallelizzabile a livello di istruzioni macchina per usare le SSE: è sufficiente che debba usare dei dati floating-point e che questi si limitino alla precisione singola (32 bit). Per operazioni scalari con dati floating-point a precisione doppia (64 bit) bisogna usare le SSE2. Non so invece se esistano istruzioni SSE/SSE2/… che supportano la precisione a 80 bit.
Ciao
Filippo
Nvidia ha una storia ricchissima di ‘giochetti’ con i drivers (tirandosi indietro anche ATI) e non mi stupisco di nulla.
Tuttavia il problema di fatto è uno solo: Gli Sviluppatori dei giochi.
Se infatti si rifiutassero di utilizzare PhysX o qualunque API proprietaria (spesso in cambio di soldi) o di ottimizzare i giochi più per l’una che per l’altra, il problema non si porrebbe neppure e dimostrerebbero rispetto verso chi i giochi li acquista.
La colpa è principalmente loro non di Nvidia.