GPU si PPU separate, cred eu ca ar fi cea mai buna solutie, din punct de vedere al performantei. Daca integreaza PPU in GPU se mareste tipul pt ambele tipuri de calcule, deci apare un bottleneck si ar face mai dificila programarea.
In schimb, daca le fac separate, costul unei asemenea placi video ar creste substantial si ar trebui sa se astepte un an sau doi pana sa se foloseasca PPU-ul masiv in game dev (ma refer la toti programatorii de jocuri, ca mastadontii nu o sa se sinchiseasca de astfel de lucruri).
Sa speram ca o sa gaseasca solutia cea mai buna.

...

Anyway, nVidia a anuntat acu 2 zile ca a inceput munca de jos la portarea librariei aia minune de fizica sa ruleze pe platforma aia CUDA sau cum ii zice de la nVidia, adica pe GPU. (altfel spus, Gramar, nu se schimba cipurile mai deloc, doar porteaza libraria sa ruleze pe GPU)

Suna bine, desi imi imaginez ca tot o sa fie buba cu batch-urile...

Oamenii astia de la nVidia cred ca au vrut sa elimine concurenta. Dupa cum stiti toate placile DX 10 au toate engine-urile complet programabile, deci nu ar fi mare branza sa porteze Physx sa ruleze pe ele. Si eu sunt de acord, nu va fi nici un PPU.

Oh well a incercat cineva fizica accelerata pe GPU ? Eu nu am hardwareul necesar. Dar is curios.
http://www.nvidia.com/object/physx_8.06.12_whql.html

Am testat eu, dar nu pe UT 3 ( ca nu il am ), ci pe 3D Mark Vantage.

Deci pe 9800 GTX, imi scoate cam 126 operatii pe secunda, iar pe CPU ( Q9450 ), cam 18.
Acum chestia ciudata este ca atunci cand rulez doar pe CPU imi foloseste toate cele patru core-uri 100%, iar cand rulez pe GPU la fel !

Daca nu ma insel, ala foloseste tot ce are disponibil. Deci daca rulezi fizica pe CPU, il foloseste la 100%. Daca treci fizica pe GPU, raman o gramada de alte chestii pe CPU, si alea il mananca tot 100%, dar merge totul mai repede, deoarece GPU a preluat o parte mare din munca CPU-ului.

Nu sunt sigur, dar asa pare.

Acuma o intrebare:
Daca fac cat mai multe chestii cu motorul de fizica gameplay related (cu Bounding boxuri la greu, ray-uri etc..) toate trec pe GPU nu ?



Daca folosesc NxMath in jocul meu sa fac calculele pentru ganeplay (sau orice altceva ce foloseste procesorul) o sa treaca toate pe GPU ?

Common sense says 'no'

Nu merge sa accelerezi functii d-astea minuscule cum ar fi abs(), sin() si inmultiri de vectori cu GPU-ul. Un dot product dureaza vreo 10 cicli pe un CPU din era noastra. Un switch in kernel mode (ca sa transfere driverul datele), plus setup-ul pentru o tranzactie pe bus, plus timpul de transfer propriu-zis, plus modelul de sincronizare cu GPU-ul ca sa stii cind iti vin datele inapoi, plus transferul inapoi, plus modelul de sincronizare kernel-user si alte maruntisuri vor dura niste zeci de mii de cicli. Aplicatia iti va merge de o mie de ori mai incet chiar daca GPU-ul vede in viitor si are rezultatul operatiei gata inainte sa-i spui ce are de facut.

Nu asa se accelereaza chestii cu GPU-ul. Trebuie sa-i dai suficient de facut astfel incit timpul de setup sa fie neglijabil comparat cu timpul de calcul, iar timpul de calcul sa fie mult mai mic decit daca ai rula acelasi lucru pe CPU. Sa-i dai sa rezolve toate coliziunile dintr-o scena e OK. Sa-l pui sa calculeze un dot product nu e deloc OK.

Cu un API d-asta clasic cu niste clase de vectori, matrici etc. nu se poate face nimic. Design-ul unui API facut pentru accelerare cu GPU este foarte diferit de modelul asta si-ti impune o multime de restrictii pentru ca sa poata acumula operatii pe care sa le ruleze cu o singura tranzactie cu GPU-ul.

Deci nu, NxMath nu-i facut pentru a-ti accelera dot product-urile, e facut in primul rind pentru structurile de date din el - vectori, matrici, aabb-uri si ce-o mai fi - pentru ca trebuie sa poti da valorile lor API-ului ca sa se spele pe cap cu ele. Operatiile sint acolo ca sa-ti usureze tie un pic munca daca nu vrei sa tot convertesti intre vectorii tai, care au operatii prin cod scris de tine, si vectorii lor.

Meh. Explicatia mea era mai scurta...

ai putea sa folosesti GPU de exemplu sa calculezi normalele pentru un high-poly mesh, dar ii dai datele intr-o textura RGBA (XYZ?), GPU-ului sa ii dai un chunk mare de date si le rumega, ca-i place, apoi iti returneaza rezultatele intr-un buffer; ce vroia Dark sa zica: "e mai mare deranjul" pentru o singura chestie mica.

Nu ma refeream la ceva simplu cum ar fi dotproduct.

Spre exemplu sa zicem un pathfinder pe un grid de rezolutie mare care sa faca calcule mai mereu in functie de player si obiecte dinamice.
Asa daca fac calculul gasirii pathului dupa niste date trimise el sa duca mai departe (tot in GPU) la procesarea fizica care misca entitatea sau reactioneaza altfel (asta tot pe GPU in cazul in care fizica e pe GPU). Apoi spre final tot la GPU se duce spre operatiile banale de afisarea graficii.

Asa s-ar imbina bine cred eu. Adica tot cu fizica mut un obiect din scena fizica pe GPU (calculele fizice )ca apoi tot pe GPU sa testez daca sa refac pathul etc.

daca nu e ceva per frame, ci adaptiv dupa o anumita conditie de update path, poate ca ar fi ok, acum depinde ce fel de structuri de date ai, ce ii trimiti aluia sa calculeze, etc., un exercitiu experimental bun , good luck.

Da, foarte frumos, dar nu poti face asta folosind NxMath cum intrebai mai sus. Codul poate arata asa:



caz in care nu se poate ca API-ul ala amarit sa-ti accelereze aplicatia in mod magic. Se poate doar daca codul arata asa:



Dupa cum vezi, in afara de faptul ca biblioteca trebuie sa implementeze ea toata smecheria, ca sa nu fie mai mare deranjul cum zice nekitu, in mod ideal trebuie sa si procesezi rezultatul asincron. Daca imediat dupa ce ai trimis request-ul astepti sa ti se intoarca n-o sa mearga stralucit. Ideea e sa utilizezi CPU-ul si GPU-ul in paralel, nu sa astepti in CPU sa se termine ce ai cerut de la GPU.

Mecanismul ideal e similar cu ala de la occlusion queries (de exemplu), unde dai query-ul, faci alta treaba, si dupa un timp intrebi daca e gata rezultatul. Daca tot nu-i gata mai faci alte chestii pina e gata. E usor de zis, dar e multa bataie de cap sa implementezi asa ceva.