Nvidia ondersteunt PhysX-project voor Radeon-kaarten

Nvidia gaat Eran Badit, beheerder van de website Ngohq, helpen met de ondersteuning van Physx voor videokaarten van AMD. Nvidia is er ogenschijnlijk veel aan gelegen om Physx te laten prevaleren boven Intels Havok.

Badit kondigde op 26 juni aan dat hij Physx-ondersteuning werkend had gekregen op een Radeon HD 3870 van AMD. Nvidia heeft nu tegenover TGDaily verklaard dat Badit door Nvidia is uitgenodigd om mee te doen aan Nvidia's 'registered developer program'. Hierdoor heeft Badit de beschikking over ontwikkeltools, documentatie en directe ondersteuning met betrekking tot Nvidia's gpgpu-ontwikkelomgeving Cuda, waarin Nvidia de Physx-api heeft geïntegreerd.

De Cuda Radeon-library is volgens Badit bijna af, en er wordt ook gewerkt aan Cuda-ondersteuning in de drivers van AMD. Tot dusverre heeft AMD verzoeken om ondersteuning met betrekking tot Badits werk aan Physx op Radeon-videokaarten nog niet gehonoreerd. Mogelijk spelen hierbij politieke motieven een rol: AMD heeft zich voor het gebruik van de gpu voor hardwarematige versnelling van natuurkundige berekeningen aan de zijde van Intels Havok geschaard.

Reacties (46)

[leeuwtje1]

Ik had dit nieuws al eerder gelezen op tom's hardware. Dit is een hele mooie ontwikkeling. Ati was niet van plan daadwerkelijk havoc te implementeren in zijn kaarten. Nu kunnen mensen met een ati-kaart ook cuda en physx gerelateerde applicaties draaien.

Ik vind het trouwens niet gek dat DAAMIT geen ondersteuning wil geven voor Physx. Zij hebben gekozen voor havoc(meer gebruikt), om een andere weg in te slaan dan hun concurent. Als zij hier ondersteuning aan geven gaan ze hun eigen strategie in de weg staan.

Een zeer mooie ontwikkeling. Dit was ook maar de enige reden voor mij om te twijfelen aan een hd4xxx -serie aanschaf. Dit word nu weggenomen. Op ngohq word duidelijk dat ze binnen niet al te lange tijd klaar zijn met de ontwikkeling van cuda en physx voor Radeon's

[Ackermans1973]

Op zich helemaal niet raar, of onmogelijk of bijzonder.

Een GPU is nog steeds een reken-aparaatje. En aangezien de GPU flink wat rekenkracht heeft, kan deze mooi aangewend worden.

En het is niet PhysX die op een Ati draait, het is CUDA die op Radeon draait.

Als CUDA draait, kan allles wat in CUDA geschreven is, os PhysX, op dat platform werken. Simpel zat.

[blspjnl]

Officieel zou AMD gek zijn om dit aan te moedigen, maar het is wel extra marketing voor hun 48x0 series, die hebben veel meer shadervermogen, dan bijv. 38x0's, dus zal de PhysX load iets beter verdragen worden, zeker bij een X2-variant.
Het is toch ideaal dat je GPU's beiden ''standaarden'' ondersteunen...misschien heeft AMD dit vantevoren wel bedacht dat Nvidia zoiets zou doen, ze denken even na, en voila! We gaan met Havok samenwerken! Nvidia, eigenwijs als altijd wil dat RV670 ook CUDA aankan en helpt er zelfs ontwikkelaars mee... ( strategisch gezien is dit geen slechte zet, maar pas op dat het geen tweefrontenoorlog tegen je wordt).

[Stidge]

Ik ga nu even een heel zeikerige opmerking maken: het is toch havoK?

Btw, ik vind het zeer netjes dat men probeert deze physics te integreren in de grafische kaarten. De handheldmarkt profiteert bijvoorbeeld ook van processoren waarin het grafische deel bij in gesloten zit. Ik hoef op deze manier iig geen PhysX-kaartje meer te kopen ;D.

[SG]

D'r wordt niks geintergreerd.

GPU's hebben SM4.x shader voor te renderen. Die kunnen dus ook GPGPU taken doen zoals PhysX. 'n shader die PhysX doet doet geen renderen.
D'r wordt 'n extra task (PhysX) erbij gedaan. Die dringt dus met de huidige task(3Drenderen) en gaat met mekaar strijden om de SM4.x shader resources.
Dus je 8800GTX g80 met 128 shaders wordt effectief als 'n 96shader ding. dat kan wat schelen in FPS. 'n CPU ontlasting van 112+16 3D/PX verhouding zal nog wel gaan. Wat 'n lichte CPU PhysX ontlasting is kan nog wel. Maar zware PhysX game krijg je een flinke FPS terugval. Tov PPU.
'n 8600GTS+ PPU vs 'n 8600GTS. Die GPU die twee dingen moet doen wordt dan dubbel zwaar gestressed. slide show dus.

Dit is gebenched met UT3 trouwens met wat sneller GPU die laten deze fenomeen goed zien.

PhysX komt niet for free. het komt als load erbij. Dus als je 'n optimale PhysX capable render bak wilt dan hou je rekening dat je wat extra shader power hebt zodat er voldoende shader power hebt voor beide taken. Die CPU die dit moet voorzien moet je ook niet te licht pakken. Aangezien PhysX maar één van de vele CPU task was. En een vergrote PhysX task gericht op veel shader power belast het algehele systeem zwaarder.


Met high-end GPU heb je iets meer speling. Zolang je situatie. Game hardware en settings niet zo GPU gelimiteerd zijn.

Zolang er nog geen zware nVPhysX game zijn hou ik het nog by mijn PPU's. Als ik de PPU vervang hou ik rekening dat er voldoende renderpower nodig is voor ook toekomstige games en extra render power die 'n stuk meer is dan 'n PPU.

Twee GTX260 in SLI bijvoorbeeld.

[humbug]

Feit is dat de huidige GPUs krachtig genoeg zijn om zelfs de meest extreme games goed te draaien op hoge resoluties. nVidia en Ati zoeken dus naar manieren om extra werk naar de GPU toe te schuiven om zo hun toekomstige, nog snellere kaarten, aantrekkelijk te houden. Het hele PhysX gebeuren komt dus als geroepen. Jij roep twee GTX260's in SLI. Ik denk 1 next gen high end kaart of 1 mid end kaartje van de daarop volgende generatie. In een jaar of twee drie moet PhysX zijn doorgebroken, anders kan de gemiddelde intel geintegreerde GPU oplossing elke game draaien. En dan zijn Ati en nVidia een flink deel van hun markt kwijt.

[darkjeric]

Dat geloof je nu toch zelf niet? Mijn Intel-GPU'tje (onboard) van vorige maand kan nog altijd geen Dawn of War draaien, toch al een spel van 2004. Ik zie het niet gebeuren hoor dat een IGP binnen 3 jaar een spel als Crysis kan trekken.

GPU's zijn er om te blijven. Het enige waarom nVidia/ATI andere manieren zoeken om de gPU te gebruiken is om hun markt te vergroten en zo nog meer omzet te halen. En dat is natuurlijk wat elk gezond kapitalistisch bedrijf tracht te doen.

[Ultraman]

Voor ons een leuke ontwikkeling, mogelijke ondersteuning voor zowel Havok als PhysX op GPUs van AMD.
Alleen vraag ik me af of AMD hier wel zo blij mee is of ze weten gewoon niet zo goed wat ze er mee aan moeten, waarom ze waarschijnlijk ook geen woord van zich hebben laten horen om dit te gaan ondersteunen.
Ze zijn namelijk samen met Intel in de Havok boot gesprongen.
Nou weet ik het fijne niet van de deal, maar ik denk niet dat het blauwe team het zal waarderen als AMD ervoor kiest om van twee walletjes te eten.
Ben benieuwd wat AMD nu gaat doen, markttechnisch is de ondersteuning van beide physics-engines namelijk helemaal niet onaardig

[Reactie gewijzigd door Ultraman op 23 juli 2024 02:43]

[mjtdevries]

Uiteraard is AMD hier helemaal niet zo blij mee.

Je wilt absoluut niet dat de volgende physics standaard er eentje is die door Nvidia bepaald wordt.
Met de ervaringen uit het verleden kun je dan op je vingers natellen dat Nvidia dan allerlei truukjes gaat gebruiken om te zorgen dat AMD altijd achter de feiten aanloopt met hun implementaties. (Wat dat betreft is Nvidia net zo betrouwbaar als Microsoft)

AMD zou veel liever een physics standaard zien die echt open is en waarbij AMD en Nvidia gezamenlijk vaststellen wat er in nieuwe versies komt. Of eentje waarbij Microsoft de regie heeft.
Maar meeliften op een standaard die volledig door Nvidia bepaald wordt wil je natuurlijk nooit.

Maar als een 3rd party zorgt dat physX ook werkt op AMD kaarten, dan is dat laatste scenario juist een stuk dichterbij gekomen.

[Rygir]

Dat is een typische redenatie waaruit volgt dat je je uitvindingen geheim wilt houden, closed-source om het zo te zeggen. Maar omgekeerd heeft AMD nu net als verkoopsargument dat ze toch compatibel zijn met PhysX en bovendien ook het alternatief (Havok) ondersteunen. Bijgevolg zou ieder weldenkend mens als al de rest hetzelfde is (performance, prijs,...) kiezen voor die wat het meest flexibel is. Als dat zo zou worden, dan zou AMD populairder kunnen worden en de trendsetter worden.

Maar zo'n vaart zal het vast niet lopen.

[humbug]

Ati mag dan "compatible" worden door zo'n community driver maar zoals mjtdevries al aangeeft is het waarschijnlijk dat ze altijd op nVidia zullen achterlopen met PhysX. Als PhysX dan de standaard wordt en Ati is consequent 10% langzamer is dat niet goed voor Ati. Je zegt het zelf al, na prijs en performance komt de flexibiliteit pas om de hoek kijken. Het risico om met nVidia in zee te gaan is dus erg groot voor Ati. Terwijl men door met Intel in zee te gaan juist een voorsprong tov nVidia kan opbouwen als Havoc "wint".

Dus ja, het is een redenatie waarin mjtdevries ervan uit gaat dat nVidia haar eigen Physx ontwerp voornamelijk voor haar eigen gewin wil gebruiken. Dat lijkt mij niet heel onrealistisch, zolang nVidia Physx niet aan een onafhankelijke stichting geeft waar ook Ati en bv Intel wat te zeggen hebben.

[i-chat]

ik ben dan ook vooral benieuwd naar of er dan ook drivers komen die dit onder linux ondersteunen..

maar voor ati is dit zeker een luxe probleem, toch zal het zelfs als ati er zich totaal niet mee wil bemoeien, toch een pluspunt voor ze, want zelfs als de cumunity het bouwd blijft amd TOCH nog steeds geschikt voor beide systemen.

[Ultraman]

Een "luxe" probleem inderdaad

Alleen kan het misschien ook een dubbelsnijdend zwaard worden.
De tijd zal het leren nietwaar?

[Verwijderd]

En zoals ik hier uitleg maakt dit hele physics op GPU/PPU gedoe geen enkele steek zo lang ze cheaten. Ik ben dan ook heel benieuwd wat Intel/Havok's antwoord hierop wordt.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 02:43]

[justice strike]

als ik het goed lees wordt er maar 16% van de tijd besteed aan die module. Dus waar gaat de overige 84% van de tijd naartoe? Als dit namelijk het enige stukje code is dan hoeft dat ansich niet veel uit te maken.

verder maak je nogal veel assumpties op basis van de assembler, terwijl het heel goed zou kunnen dat de compiler dit gewoon zo gecompiled heeft. Zo weet ik dat je de gnu c compiler zo kunt instrueren dat je de x87 coprocessor oneigelijk gebruikt voor doeleindes waar hij in de eerste instantie niet voor bedoelt is.

Je kunt dus niet zonder meer iets zeggen over de performance en "hoe slecht ie is"

[.oisyn]

Het is niet 16% van de tijd besteed aan die module, het is 16% van alle keren dat het in de module was, was het in die 19 (!!!) instructies. 16% van de tijd in een zeer kleine en geisoleerde plek in je code is heel erg veel. En aangezien het de nummer 1 hotspot is, is dat sowieso de plek waar je als eerst gaat optimaliseren. Dat is niet gedaan, waardoor de conclusie dat de CPU code eigenlijk helemaal niet zo goed geoptimaliseerd is eigenlijk onvermijdelijk is.

verder maak je nogal veel assumpties op basis van de assembler, terwijl het heel goed zou kunnen dat de compiler dit gewoon zo gecompiled heeft

Het doet er niet toe waar de assembly code vandaan kwam (en zal idd waarschijnlijk wel uit een compiler komen). Hij is zo niet goed - de FPU is langzaam vergeleken met de SSE unit, en het zit bovendien vol met stalls. Dat hij uit een compiler is komen rollen is geen excuus. Als je compiler dit soort code produceert bij een dergelijke hotspot dan heb je als programmeur de keuze om die compiler-opties te tweaken of zelf met de hand een asm implementatie te schrijven. En de meeste fatsoenlijke compilers (GCC, MSVC++, Intel C++) ondersteunen gewoon SSE intrinsics, waardoor je met SSE registers en instructies kunt werken alsof het gewoon variabelen en functies zijn. Wrap dat in een fatsoenlijke vector library en je hebt leesbare code wat ook nog eens snel is.

[Reactie gewijzigd door .oisyn op 23 juli 2024 02:43]

[Verwijderd]

Dus waar gaat de overige 84% van de tijd naartoe?

Naar zeer soortgelijke ongeoptimaliseerde code. Ik kan niet alles in een post plaatsen he. Het is trouwens niet zo heel erg moeilijk om zelf een experiment te doen met CodeAnalyst.

Je kunt dus niet zonder meer iets zeggen over de performance en "hoe slecht ie is"

Dat kan ik wel. CodeAnalyst is een profiler. Hij toont de plekken die het meeste tijd innemen. Als je dan stoot op zulke scalaire code in plaats van vectorcode, dan is de conclusie snel gemaakt. Bemerk dat de PPU en GPU juist zo worden geprezen voor hun rekenkracht dankzij de vectorinstructies. Maar het is een oneerlijke vergelijking als er geen gebruik wordt gemaakt van SSE, de vectorinstructies van de CPU.

[kiang]

dus jij neemt een stukje asm, en ziet er geen SSE in, en neemt direct aan dat eht daarom valselijk vertraagd is? Betaalt de CPU-lobby jou ofzo?

Om te beginnen is SSE miss wel niet geschikt voor dit stuk code.
Vervolgens heb je op geen enkel moment aangetoond dat die code efficiënter kan.
Verder haal je slecht enkele lijnen code boven: Hoe zit het met de rest?

Je hebt dus niets uitgelegd, je hebt even een michael moore petje opgezet en staan roepen in een of ander forum...

Ik weet dat physics er sinds de PPU voor het eerst realistisch uitzien. Ik weet ook dat Physics baat hebben bij massale parallelle rekenkracht (nauwkeurige boxing, collision detection, ...), en dat een aparte PPU of de GPU die beter leveren dan de CPU.

Het enige dat ik wil is dat games/3d simulaties er beter gaan uitzien. Daarvoor maakt het me niet uit wat er gebruikt wordt, maar als ik de dingen die ik al weet in acht neem, volg ik nVidia met zn Physics API voor de GPU.

[Verwijderd]

dus jij neemt een stukje asm, en ziet er geen SSE in, en neemt direct aan dat eht daarom valselijk vertraagd is?

Wat valt er aan te nemen? Dit zijn feiten. SSE werkt met vectoren van vier elementen terwijl x87 met scalaire getallen werkt. Bovendien heeft SSE onafhankelijke registers in plaats van een onhandige stack, en een aantal interessante benaderingsinstructies. Geen gebruik maken van SSE betekent dan ook 3-5 keer lagere prestaties.

En ja, deze code is zeer geschikt voor vectorisatie. SSE is equivalent aan de SIMD eenheden in zowel de PPU als de GPU.

Ik weet ook dat Physics baat hebben bij massale parallelle rekenkracht...

Mooi, dan weet je ook dat een Core 2 Quad meer GFLOPS kan leveren dan een GeForce 8600 GTS. Alleen jammer dat zo'n CPU maar een fractie zo efficient gebruikt wordt door de PhysX driver als mogelijk had geweest. Maar niet getreurd, Intel heeft nu Havok in handen en we zullen dus niet te lang meer moeten wachten op geoptimaliseerde software.

[SG]

Weet je ook dat veel PhysX nodes procesing weer afhankelijk zijn van de andere. En vaak de resultaat van de andere vorige nodes moeten hebben. Waarom 'n PhysX array van Copronodes een hoge interne bandbreedte moet hebben. Dat per 128 node procesen beter is dan per 16 en die weer beter is dan per 4 serieel. De PPU voordeel tov een CELL CPU de interne bandbreedte. 'n dedicated GPU heeft na de eerste computing slag al 128 mogelijke nodige resultaten voor de tweede slag klaar. Dit geld dus zwaar voor massive parralel PhysX task zoals Fluid PhysX. Waar fluid particle intensief met mekaar interacten.
Weapon fire in ene game is 'n CPU voldoende paralistisch voor. Tenzij je complexe balistic gaat doen en dat ook nog eens met gaitlingguns.

Daarnaast wat nagenoeg feitelijk is, dat dev's voor CPU en ook consoles 'n CPU load gebruiken die de mainstream CPU aankunnen. En consoles is sowieso fixed. Dus voor Low en midrange CPU's. Dat worden al snel dus lichte Physics games. Single en mogelijk al dual core. Is de physics target voor CPU Physics door dev's.

Daarnaast is die aantijging over onoptimised code maar de helft van het verhaal. Terwijl de dev's amper quadcore gebruiken. En wat wel nodig is om bijvoorbeeld de PhysX load te kunnen aanpassen om ook quadcore te kunnen stressen ook op verschillende kloksneheden.

Omdat deze PhysX in games vaak 'n Fix load is niet instelbaar zoals als die render optie setings. Pakken ze de load niet hoog. rekening houdend met mainstream target.
Quad is nog geen mainstream Dual mogelijk wel.
Word quad SMP wel ondersteund, dan wordt vaker die magere Physics setting alleen maar opgesplits over 4 cores. Waarbij de load per core nog lichter geworden is. Dus de load wordt niet zwaarder omdat er op eens meer mogelijk is. Die mogelijkheid wordt niet gebruikt. Ze willen de game ervaring incsief AI en PhysX voor elke speler uniform maken. ongeacht CPU type. Wat 'n reden is om maximale cPU utalisatie nauwelijks niet toe te passen. 'n quadcore heb je nog steeds niet nodig voor 'n redelijke gamebak.
Dat schiet niet op Dev's laten mogelijk heden liggen. Zo ook AI.
Dus 'n quadcore brengt geen slimmere AI en meer PhysX. Maar is er wel sneller mee klaar zodat de CPU timeslice van de te renderen frame setup time korter wordt. Krijgt de GPU meer tijd. Leuk voor fps of extreem render settings. Want de GPU kan je wel de load van verzwaren met 'n uitgebreide setting screen.

Nu met single dual quad en binnenkort six cores en verder. Zouden voor pure CPU taken ook uitgebreide settingscreen moeten komen. Zoals ook voor AI. Dat 'n krachtigere cPU ook van uit de software volledig benut wordt. En dan wordt optimaliseren belang rijk om het voledige potentiel te laten zien.

Probleem is alles wat gameplay invloed heeft AI en PhysX deel. Is vooral Fix.
Effect Physics kan makkelijk optioneel zijn.
'n uitzondering is bijvoorbeeld BF2 met de AI slider.

PPU en GPGPU maakt de target platform kwa physics reken kracht nog extreem breder. En omdat daar ook 'n pletora aan GFlops aan PhysX rendering kracht is.
Is de nood voor 'n PhysX uitgebreide option screen met 'n pletora aan settings hoog nodig. probleem is dus dat de gamers opgedeelt moeten worden in lichte en zware PhysX deel. Als ook de Gameplay PhysX deels aanpasbaar wordt.

Wat ik zie 'n hoop kopzorgen en complexiteit voor game produktie.

[Reactie gewijzigd door SG op 23 juli 2024 02:43]

[mjtdevries]

Begrijp ik je goed dat je bedoelt dat PhysX met opzet langzame/verouderde CPU code gebruikt, zodat de hardware kaarten gunstig afsteken tov cpu's?

Kun je aangeven in welke orde van grootte het verschil is?
Praten we hier over code die 10% langzamer is dan wat zou kunnen, of gaat het honderden procenten. Ik kan me voorstellen dat het code is waar SSE zeer efficient ingezet zou kunnen worden en dat het dan gigantisch scheelt.

[Verwijderd]

Begrijp ik je goed dat je bedoelt dat PhysX met opzet langzame/verouderde CPU code gebruikt, zodat de hardware kaarten gunstig afsteken tov cpu's?

Inderdaad.

Kun je aangeven in welke orde van grootte het verschil is?

Naar mijn ervaring met SSE kan dit zo'n 3-5 keer sneller.

[humbug]

Dus? Niemand die je tegenhoudt om je eigen CPU based PhysX lib te schrijven.

[mjtdevries]

Beetje vreemd dat het volgende in het artikel staat:

Tot dusverre heeft AMD verzoeken om ondersteuning met betrekking tot Badits werk aan Physx op Radeon-videokaarten nog niet gehonoreerd

Terwijl op TGDaily (waar dit nieuwsitem op gebaseerd is) het volgende staat:

According to Badit, it took AMD seven days to respond and send the requested documents

m.a.w. AMD heeft wel degelijk gereageerd.

Het mag toch niet verrassend zijn dat AMD even tijd nodig had om te bepalen hoe ze hierop zouden reageren. Zoals in de discussie hierboven al door vele mensen is aangekaart komt AMD met PhysX support op Radeons in een lastig parket.

[Rob Coops]

Wat Physics betreft ik denk dat we zo wel van AMD als van Intel nog wat mogen verwachten op dit gebied. Bijde zijn al tijden druk bezig met een general purpose CPU en een GPU samen te voegen en op die manier ATI en Nvidia te verslaan in de toekomst. Nu AMD ATI in handen heeft kan dat voor AMD betekenen dat zij op dit gebied een voorsprong op de groote concurend zouden kunnen nemen.
Intel heeft natuurlijk genoeg mensen en kennis in huis om toch een groote speler te worden op de graphics markt en als ik hun aankondigingen en voorspellingen zie denk ik dat ze binnen nu en 4 jaar nog wel eens een hele intresante optie zouden kunnen bieden.

Cuda is denk ik alleen maar gebaat bij draaien op meer verschillende kaarten of het nu Nvidia kaarten zijn of niet als je code op meer dan een platform draait is de kans op aceptatie een stuk groter. En van mij mag het best hoor een beetje extra parrallele reken kracht in de PC.

[psychicist]

Wie zegt, dat Nvidia geen Physics op basis van Cuda zal kunnen laten draaien op huidige of toekomstige implementaties in zijn Tegra processorlijn? Dat is weliswaar een op een ARM11 core gebaseerde SoC, maar Nvidia heeft dus wel degelijk een combinatie van een general purpose CPU met een GPU.

[MarCreative]

Ik kan eigenlijk niks anders zeggen dan: mooie ontwikkeling. Op deze manier kun je zien dat het ook anders kan. (Creative).

[DLGandalf]

heb je er al is aangedacht dat dit meer zelfbelang is om iedereen over te krijgen naar physX inplaats van havoc van concurrent ATI?

[Sinester]

Havok is niet van concurrent ATI maar van Intel
wel heeft ATI besloten om met intel mee tegaan in de Havok boot

[Electrowolf]

Maar dat is toch altijd eigenbelang voor een bedrijf?

Voor creative is het ook eigenbelang om betere drivers voor hun hardware te hebben. Netzo als hier zou het dan mooi meegenomen zijn als iemand anders dat vuile werk dan voor je opknapt.

Dus iedereen overkrijgen naar physx of iedereen overkrijgen naar soundblasters, het is allebij uit eigenbelang .

[Simon Verhoeven]

Goede ontwikkeling maar of zelfs dit ervoor gaat zorgen dat ze het van Havoc gaan halen betwijfel ik toch ten zeerste.
Ray tracing is gemakkelijker realistisch te krijgen dan rasterization + scaled beter.

[mjtdevries]

Wat heeft PhysX met Raytracing te maken??

[Simon Verhoeven]

Wat denk je dat Intel mee gaat pushen?
En je moet het geheel van de mogelijkheden bekijken.

[|sWORDs|]

http://eric_rollins.home.mindspring.com/ray/cuda.html

[Splash]

Een rendertechniek als raytracing heeft niks te maken met het simuleren van physics, en je opmerking raakt dus kant nog wal.