'PhysX-berekeningen op cpu traag door slechte optimalisatie'

Uit tests zou blijken dat de slechte prestaties van PhysX-berekeningen op een normale cpu voortvloeien uit een gebrek aan optimalisaties. De driver zou verouderde x87-instructies gebruiken in plaats van de snellere sse-instructies.

David Kanter van de website Real World Technologies heeft onderzocht hoe het komt dat de prestaties van de PhysX-api in een systeem zonder Nvidia-gpu relatief zo slecht zijn. Normaal draaien de PhysX-berekeningen op de cuda-cores van de Nvidia-gpu en als deze niet aanwezig is, wordt deze taak door de cpu overgenomen. Kanter vond het verschil in prestaties zo groot dat hij heeft uitgezocht hoe de cpu-kant van de PhysX-driver in elkaar steekt.

Door tijdens het draaien van PhysX-benchmarks de processen met Intels VTune-software te analyseren, kwam Kanter erachter dat de PhysX-driver veelvuldig gebruikmaakt van de ouderwetse x87-instructies. Sinds de Pentium 3 verkiezen veel ontwikkelaars de sse-instructies boven x87, omdat deze in bijna alle gevallen sneller zouden zijn. Ook viel op dat de PhysX-berekeningen singlethreaded waren en geen gebruikmaakten van de extra aanwezige cores. Kanter stelt dat als gebruik zou worden gemaakt van sse-instructies en multithreading, de PhysX-prestaties op systemen zonder Nvidia-kaart een stuk hoger zouden liggen.

Omdat PhysX op consoles wel multithreaded is en daar instructies gebruikt die vergelijkbaar zijn met sse, beweert Kanter dat Nvidia de driver opzettelijk niet heeft geoptimaliseerd, om mensen aan te sporen Nvidia videokaarten te kopen. De website Semiaccurate, altijd kritisch ten opzichte van Nvidia, deelt deze mening en vermeldt dat compilers tegenwoordig automatisch sse gebruiken en je deze instelling dus bewust moet uitschakelen. De site stelt dat een geoptimaliseerde PhysX-driver berekeningen op de cpu sneller kan uitvoeren dan op de gpu.

Nvidia ontkent de beschuldigingen en zegt er alles aan te doen om PhysX ook op systemen zonder Nvidia-videokaart zo snel mogelijk te laten draaien. Het bedrijf weerlegt de claim over singlethreading en zegt dat het absoluut mogelijk is om de code multithreaded te draaien, maar dat het aan ontwikkelaars is om dit te implementeren. Het zou niet standaard in de driver gebeuren, omdat de originele code stamt uit de tijd dat multicore-processors nog geen gemeengoed waren, aldus het bedrijf. In versie 3 van de PhysX-sdk moeten multithreading en sse-instructies wel standaard zijn ingeschakeld, al claimt het bedrijf dat sse niet in alle gevallen sneller is. Ook zijn er volgens Nvidia nog steeds ontwikkelaars die liever geen gebruikmaken van de instructies, omdat ze mensen met oudere hardware niet buiten willen sluiten. Dat argument lijkt echter niet sterk, omdat cpu's sinds de Pentium 3 sse ondersteunen.

Reacties (134)

[GewoonWatSpulle]

x87 is a floating point-related subset (originally an extension) of the x86 architecture instruction set.

Bron: Wikipedia: x87

Verder is dit eigenlijk wel te verwachten, ze wilden die physx kaarten in den beginne zelf slijten.

En waarom werken de physics in de Source Engine wel op de CPU?

[Reactie gewijzigd door GewoonWatSpulle op 24 juli 2024 03:58]

[Qreed]

En waarom werken de physics in de Source Engine wel op de CPU?

Omdat die gebruik maakt van die Havok engine.

[Flowmo]

Precies, dus het *kan* wel. Ageia / Nvidia pretenderen al jaren dat deze berekeningen te complex zijn om uit te voeren op de cpu, maar als ik naar een willkeurige Alan Wake tech demo kijk van jaren geleden, dan ga ik toch anders denken.

[SG]

Hallo !
Punt Één. Heel belangrijk de PPU kwam uit in 2006 dus CPU en GPU uit die tijd moet je het dan mee vergelijken. Vergeet die six cores van nu. Dual was high-end. G80 moest nog komen. ATI zette de tegen aanval met R520 dé GPGPU platform van die tijd. nV deed toen niet me mat hin zwake branch shaders

PPU lijkt veel op de Cell CPU. PhysX is kwa CPU crossplatform. Ook de Wii.
Dit is Physics middle ware dat ook console support. Op PS3 benut PhysX gewoon de SPE's De Cell cPU dus.

Alan wake was het oude parade paardtje voor Havok FX. GPGPU tegenhanger.
Wat Alanwake deed. Kregen we later deels met Ageia UT3 PHysics maps. De Twister.

Dit is al uitgebreid gebenched en gerieveiwed en PPU deed zijn werk nog steed goed zelfs na ruim 2 jaar. Met UT3.
'n dedicated PPU met snelle CPU en snelle GPU was het beste. PPU gaf een boost.
Waar nondedicated CPU en GPU zich veslikt in deze zware dubbele taak.


Dan tweede punt wat heel belangrijk is. Met dedicated hardware Physics versnelling kan je veel complexere en verfinde Physics loads en uitgebreidere Physics featutures introduceren.
Graw Ageia island was een mooi voorbeeld. Vijanden neer knallen met een m249 door een houten hut waarin ze bevonden te schredden met de saw. Heb extra physics details. Maar de fidelity was voor sommige physics feature gewoon te laag. Maar tov games uit toen een grote stap vooruit.

Maar nu in 2010 zou men met dedicated hardware zoals een extra 1 teraflops GPGPU op 'n kaart. Maar dan als niet die middleware iNtel/nV fiasco er was. Hypothetisch met HavokFX versie 3 gebruikmakende van OpenCL of DX11 computeshaders. Een hele shit load aan dozijn Physics features in meer realistice detail simultaan weergegeven kunnen worden. En doordat het GPU merk onafhankelijk zou zijn. Ook een 10 voudige level hogere gameplay Physics mogelijk zijn niet gelimiteerd aan cPU default belasting.

Zoals die Crysis jungle trailers maar dan in game en op allevlakken veel gedetaileerde Physics en game world interactie en object gedrag.

Physics detail en features zijn zeer schaal baar.

This niet voorniets dat supercomputers het weer voorspellen. Want dat is fluid physics op grote schaal. Met de meeste belangrijke variablen.

Nu voor games zou dit mogelijk zijn. Een game waar twee V.O.C zeil schepen mekaar slopen. Of twee ruimteshepen die mekaar shredden door dat de hull als metal sheet doorzeefd wordt.

Maar iNTel en nV hebben deze dedicated hardware physics zowat de nek omgedraaid. En die vooruitgang is dus flink gestalled. Jammer.

Al maakt deze pletora aan Phsyics opties voor games de game development weer een flinke stap complexer. Plus deze interactie moet ook online gesynchroniseerd worden. Maar ja het SP genre is ook groot.. En in LAN is ook wat meer mogelijk kwa synchroniseren dan online.

[freaq]

op zich is PHysx zijn doel veel meer particles te kunnen gebruiken.
en in een paar demo's van Nvidia gebeurt dat ook
http://www.youtube.com/watch?v=RuZQpWo9Qhs
echter dat wordt nog niet echt gedaan in games.
(omdat de rest van de game ook kracht kost.

echter kijkend naar wat havok presteerd op de CPU
kan je niet anders concluderen dat PhysX ontzettend ongeoptimaliseerd is. (op de CPU)
en aangezien het potentieel van PhysX niet eens benaderd wordt omdat de GPU ook andere dingen moet doen....

tsja..

ik vindt nog steeds laat de CPU de physics maar doen,
de GPU heeft het al zwaar genoeg.

[bwerg]

echter dat wordt nog niet echt gedaan in games.
(omdat de rest van de game ook kracht kost.

En omdat een spel dan NVidia-only wordt als je te veel op de PhysX gaat leunen, als je ATI en intel-gebruikers ook een game wilt kunnen laten spelen kun je eigenlijk al geen zware physx implementeren die invloed heeft op de gameplay.

Dus het argument dat NVidia geen gamers wilt buitensluiten is totale kul. Dat willen ze maar al te graag. Ik ben trouwens benieuwd of er uberhaupt spellen met physX bestaan die nog fatsoenlijk draaien op een pentium 2?

[computerjunky]

niks recents draait op een pentium 2 of 3 waarom zou een game moeten draaien op een 5 generaties oude cpu.

en je kan een game zo ontwikkelen dat physx onderdelen alleen gebruikt word als je er de hardware voor heb hetzelfde word gedaan met games die verschillende dx versies ondersteunen.

@freaq : het kost de gpu juist maar een fractie van de tijd/rekenkracht voor een berekening die anders de cpu zou doen dat is ook waarom er langzaamaan overgegaan word naar alles berekenen via de gpu.

als je zware berekeningen door de cpu laat doen vertraag je de gpu weer waardoor de game ook vertraagd maar wel voor langere periode omdat deze trager is
als je dezelfde opdracht aan de gpu geefd is ie sneller klaar met de opdracht waardoor de vertraging korter duurd en de gpu optimaler drsaait omdat de cpu volledig gebruikt word om de gpu te ondersteunen.
gpu computing is de toekomst totdat cpu's revolutionair veranderen wat ik niet zie gebeuren.

[freaq]

dat klopt.

en Havok is ook bezig met OpelCL implementaties.
http://il.youtube.com/watch?v=MCaGb40Bz58

echter als men niet enorm veel physics hoeft te doen.
(wat nu dus ook nog niet gebeurt)
heeft het geen zin deze op de GPU te doen.
dat doet Havok net zo goed, en met minder impact op de framerate.

als men ineens echt veel particles gaat simuleren heeft het wel zin.
maar tot nu toe gebeurt dat niet en heeft het dus nog geen nut.

in de toekomst heeft het waarschijnlijk wel zin.
maar tot die tijd zijn bij de meeste games 2 cpu cores vrij.
en blijt physx aanzetten op de gpu een flinke performance hit opleveren.
en extra physics op die twee cores berekenen niet.

*uitgaande van quadcore cpu's

[Reactie gewijzigd door freaq op 24 juli 2024 03:58]

[SG]

Er wordt niet veel met physics gedaan omdat hardware accelerated physics markt inelkaar gezakt is door overnames van middleware.
Ageia heefd leuke voorbeelden dat gameplay Physics tot unieke en veel meer interacieve werelden kan leiden en ook lijd tot ander soort gameplay.

Dat moeten wij gamers maar missen vawege deze bedrijven soap.

Helaas zijn er geen triple A kaskrakers die dit goed hebben uitgewerkt en dit is wat men eigenlijk mist. Top games die extra zware Physics load goed in game benutten.
Tot op heden niet aanwezig. Maar al lang mogelijk. Veel verder dan moderne CPU's kan aanbieden zelfs met optimale multitreading .


gameplatform is dit.
Frame procesing loop.
Gebruik makende van "Triangle" van PU system die ongoing cycle van frames voorbereiding snel moeten vervullen.

Je kijkt welke PU het krachtigs is en laat die het meeste doen ontlast de andere

PU1 + PU2 + .. PUn
G = GFlops
T= Teraflops

CPU 5G + GPU 200G+ PPU 100G // De PPU CPU GPU triangle
CPU 10G + GPU 1T
CPU 20G + PPU 100G + GPU 500G
CPU 50 G + GPU 200G + GPU 900G
CPU 30G + CPU 30G + GPU 1T + GPU 2T
CPU 80G + GPU 500G
CPU 40G + 2* GPU 1T
....
CP....+ .....
etc....

Je ziet dat er zwakke systemen kunnen zijn met ook CPU vs GPU onbalance in elke richting. Grote tot lichte CPU GPU onbalans.
Meerdere CPU. variable aantal cores. een of meerdere GPU's.verschillende GPU's.

Afhankelijk wat de game detecteerd. En dat is het mooie van OpenCL. Het ondersteunt elke PU waar fabrikant OpenCL me support. Je kan je units op de grote heap gooien van PU beschikbaar. De software tread manager kan die treads verdelen ook in opzich waar iets het beste verwerkt kan worden.

De gamer zou met een uitgebreide optie screen dit ook kunnen doen waar het wil dat zijn physics berekend wordt.
Zoals met Cuda.PhysX

Meeste PC worden gekocht aan de hand van CPU en vaak zit er licht GPU in. In dat geval settings low en PhysX op CPU.

Tja als je dikke CPU hebt en dikke GPU en extra voor PhysX dan dedicated physics en het loop als een trein in vol detail.
Mainstream CPU redelijke GPU die wat ruim voldoet. Dan PhysX op die ene GPU.
beetje gamer heeft minstens iets degelijks kwa GPU.

Zoals men al tijden games voor zijn PC systeem tweaked door vele instellingen.
Zo ook Physics en soms zelfs AI.

Ik zelf kijk naar de future en de toekomst is meer interactieve game werelden. Meer emersie. De vooruitgang is veel suptieler in de bighit klasse. Maar het valt me wel op.
PPU was toen in 2006 opeens een bigstep.

Ik denk waarom zou triple A games hier niet aan beginnen. Ten eerste ze richten zich op een heel groot publiek. en high-end gamers zijn dat niet. ME textra $€ 200,-
Zware Physics zorgt dat je sterk onderschied tov andere games maar je market wordt klein. En console markt kan je dan vergeten. De reken kracht is daar voor lange tijd fixed.

Zware PhysX games zijn eigenlijk test of tech demo's gericht op PC markt. Aangezien je daar een kleine target had met de PPU. Cellfactor demo en full game en warmonger zijn voorbeelden.

Met HAvok FX zou dit probleem enigzins weg vallen. Volkstammen zat met een vorige gen kaart. En nu met DX11 genoeg DX10 vorige gen. Om erbij te prikken. Hardware Physics accelerate zou goed oppakken. Maar omdat dmv cuda en nV ownership van PhysX en intel havok. gaat die vlieger niet op.

Games zoals warmonger zouden dan wel een aantrekkelijke genoeg grote markt voor zijn. Gameplay limiet gaat dan voorbij mainstream cPU. De GPU eisen groeien dan wel wat hoger.

[Sinester]

Ik ben trouwens benieuwd of er uberhaupt spellen met physX bestaan die nog fatsoenlijk draaien op een pentium 2?
Reactie formulier Reageer:

Zijn er uberhaupt kaarten die physX ondersteunen, die je in zo'n antieke PCI/AGP slot kan stoppen?

[Reactie gewijzigd door Sinester op 24 juli 2024 03:58]

[knirfie244]

Ook zijn er volgens Nvidia nog steeds ontwikkelaars die liever geen gebruikmaken van de instructies, omdat ze mensen met oudere hardware niet buiten willen sluiten.

Normaal gesproken maak je je software zo, dat je gebruik maakt van bepaalde instructiesets als deze aanwezig zijn, en dat je terugvalt op oudere minder efficiente instructies als de nieuwere sets niet aanwezig zijn.

Sterker nog, als het goed is regelt de compiler dit automatisch voor je.

Als dat niet mogelijk zou zijn zou dat dus inhouden dat je nooit gebruik kan maken van nieuwste instructiesets zonder meteen 95% van de markt uit te sluiten.

[Reactie gewijzigd door knirfie244 op 24 juli 2024 03:58]

[Qreed]

Normaal gesproken maak je je software zo, dat als de instructies aanwezig zijn, dat je daar dan gebruik van maakt en dat je terugvalt op oudere minder efficiente instructies als de nieuwere niet aanwezig zijn.

In dit geval zal je een nieuwe executable moeten compileren met juist wel of juist niet die instructie set. (Net zoals je een andere target hebt tussen x86 & x64)

[corl]

Waarom kan je niet detecteren of de CPU de instructies ondersteund? En afhankelijk daarvan verschillende code uitvoeren?

[Countess]

dat gebeurt normaal gesproken ook zo. automatische regereld door de compiler zelfs.
Nvidia moet echt bewust tegen hun compiler hebben zegt dat hij geen SSE moet gebruiken.

[.oisyn]

dat gebeurt normaal gesproken ook zo

Nee, dat gebeurt niet. Wellicht voor een paar standaard library functies, maar niet eens omdat de compiler dat doet maar omdat de standaard library zo is gebouwd.

[Reactie gewijzigd door .oisyn op 24 juli 2024 03:58]

[mvdejong]

Nee, want het gaat om dezelfde basis-instructieset (x86), met een aantal extensies zoals SSE, en de eventuele beschikbaarheid van meerdere cores.
De processor heeft registers die je kunt uitlezen om te bepalen of SSE ondersteund wordt, en het aantal beschikbare cores bepalen is ook een uitdaging.
Bij x86 vs. x64 heb je serieuze verschillen in de manier waarop je hele driver/programma gebouwd moet zijn, met name op het gebied van geheugen-adressering.

[.oisyn]

Normaal gesproken maak je je software zo, dat je gebruik maakt van bepaalde instructiesets als deze aanwezig zijn, en dat je terugvalt op oudere minder efficiente instructies als de nieuwere sets niet aanwezig zijn.

Nee, in de regel developt men, wat games betreft, gewoon voor de minimale systeemeisen. Sommigen doen ook moeite om bijv. een x64 binary te releasen, maar dat is het dan ook wel. Verschillende CPU codepaths voor verschillende architecturen zie je tegenwoordig nog maar zelden.

Sterker nog, als het goed is regelt de compiler dit automatisch voor je.

Sorry maar dat is echt grote onzin . Jij zegt tegen de compiler voor welke instructieset hij moet optimaliseren, en de compiler doet dat. Hij gaat echt niet kijken of die instructies wel mogen, daar ben je zelf geheel voor verantwoordelijk. Bovendien zul je gewoon meerdere versies van je hele applicatie / library moeten maken, omdat floating point berekeningen overal gebruikt worden, en niet slechts maar in bepaalde situaties.

Als dat niet mogelijk zou zijn zou dat dus inhouden dat je nooit gebruik kan maken van nieuwste instructiesets zonder meteen 95% van de markt uit te sluiten.

Dat klopt. SSE4 en hoger zie je dan ook totaal niet in games. Is ook totaal niet interessant - als een SSE2 platform het soepel kan draaien, waarom zou je dan ook nog eens gaan optimaliseren voor het SSE4 platform die in de regel toch al klok-voor-klok sneller is?

[Reactie gewijzigd door .oisyn op 24 juli 2024 03:58]

[Solid_Aapie]

Hier een test waarin alleen getoond word wat er gebeurt als je PhysX op alle cores van de cpu draait:
http://physxinfo.com/news...luidmark-1-2-first-tests/

Dit is dus zonder SSE en nog steeds is de cpu sneller dan een GTX275 als de cpu gebruikt maakt van al zijn cores.

[Flowmo]

"Ook zijn er volgens Nvidia nog steeds ontwikkelaars die liever geen gebruikmaken van de instructies, omdat ze mensen met oudere hardware niet buiten willen sluiten."
Wat een out-dated kul argument... Toont weer dat ze de developers / end-users weer serieus nemen.

Het is ook belachelijk dat PhysX niet op de CPU kan draaien, veel systemen zijn multi-threaded, games maken vooralsnog niet veel gebruik van een tweede of meer cores, dus kan je de PhysX thread in feite op een andere core laten draaien dan je main game thread..

[HerrPino]

"Ook zijn er volgens Nvidia nog steeds ontwikkelaars die liever geen gebruikmaken van de instructies, omdat ze mensen met oudere hardware niet buiten willen sluiten."
Dat is idd een onzinnig argument. Het is zeer eenvoudig om verschillende calculatie paden te schrijven welke dezelfde interface gebruiken. 1 references path (met x87 instructies) en geoptimaliseerde paden voor MMX, SSE, 3DNow, SSE2, SSE3, etc.

[ten99]

De kans dat iemand op een pentium 2 of ouder een game met physX speelt lijkt me nul. Letterlijk nul.

NVidia heeft geem enkel excuus voor het compileren van hun driver met expliciet de optie 'produceer code voor x87'. Zoals gezegd, het is niet eens de default optie.

Nee, dit is weer zo'n typisch voorbeeld van waarom we zo snel mogelijk af moeten van proprietary API's zoals PhysX. Gelukkig lost dit zich meestal vanzelf op. Kijk maar naar GLIDE van 3DFX. Ironisch trouwens dat het toendertijd NVidia was dat door te gokken op OpenGL en later DirectX, 3DFX uit de markt duwde.

[.oisyn]

NVidia heeft geem enkel excuus voor het compileren van hun driver met expliciet de optie 'produceer code voor x87'. Zoals gezegd, het is niet eens de default optie.

Wat nonsens is. Standaard doet de MS VC++ compiler, de meest gebruikte C++ compiler voor het Windows platform, geen SSE floating point berekeningen. Pas als je instelt dat hij moet optimaliseren voor een SSE architectuur is dat zo. Dat is nog steeds het geval met MS VC++ 10 (VS 2010).

Daarnaast wordt SSE overigens pas echt bruikbaar als je zelf moeite gaat doen om SIMD te programmeren. En dus niet normale float bewerkingen en hopen dat de compiler het wel oplost, maar echt nadenken over welke 4 componenten je in een SSE register wil hebben en wat voor bewerkingen je daarop toe gaat passen.

That said, wij compileren onze games al jááren voor SSE2. Ik zie geen enkele reden voor nVidia om niet ook gewoon een SSE2 binary te releasen. Eigenlijk zie ik niet eens een reden om nog x87 binaries te gebruiken, maar goed, dat hangt natuurlijk maar net van je klant af.

[Reactie gewijzigd door .oisyn op 24 juli 2024 03:58]

[ten99]

Ok, ik neem aan dat je wat Visual Studio betreft gelijk hebt.
Maar ook zonder gebruik te maken van SIMD levert het gebruik van SSE voor floating point berekeningen winst op, omdat geen gebruik gemaakt wordt van het stack-based x87. Je hoeft dus niet te pushen en te poppen.

Gebruik maken van SIMD zou weer extra winst opleveren, maar daar is wellicht handwerk voor nodig, omdat auto-vectorizatie nog altijd niet zo goed werkt.

[Reactie gewijzigd door ten99 op 24 juli 2024 03:58]

[.oisyn]

SSE code is in de regel iets sneller ja, maar vergeet niet dat SSE geen support heeft voor trigonometrische functies. Als je die wilt hebben in de precisie die x87 je levert dan kun je beter gebruik maken van de x87 instructies, maar conversie van SSE naar x87 en terug moet via het geheugen en dan krijg je te maken met stalls. Ook is de x87 pipeline enorm geoptimaliseerd in hedendaagse CPU's. Het hangt dus nogal van de situatie af of het voordeliger is om SSE of x87 te gebruiken.

Gaat het je om snelheid en niet om precisie, dan zijn de Taylor-reeksen van de trigonometrische functies goed en snel te implementeren met SSE.

[Reactie gewijzigd door .oisyn op 24 juli 2024 03:58]

[ten99]

Als je bedoelt dat software in dit geval spellen 80 bits precisie willen i.p.v. 64 bits dan lijkt me dat grote onzin. En x87 trigonometrische functies worden voor spellen toch niet gebruikt zeker? Hiervoor gebruikt men naar ik aanneem tabellen of de door jou genoemde taylor-reeksen.

Ik geloof ook niet dat tegenwoordig nog een spel ontwikkeld wordt, dat gecompileerd wordt zonder de optie aan te vinken dat gebruik gemaakt mag worden van SSE.

Dat niet doen in de PhysX driver moet simpelweg moedwillig gedaan zijn. De argumenten die NVidia daarvoor geeft zijn onzin. Ze hebben er belang bij (denken ze) om het te laten lijken alsof de GPU dat allemaal beter en sneller kan.
Daar werden al vraagtekens bij gezet in het verleden, maar dit was op theoretische gronden. Nu is daar gedegen onderzoek naar gedaan door David Kanter.

Je denkt toch niet serieus dat Nvidia niet compileert voor SSE omdat het dan langzamer wordt vanwege de technische argumenten waar jij mee komt aanzetten? Er is altjd wel een pathalogisch geval te bedenken waar x87 sneller is, of waar 80 bits precisie nodig is (maar dat is meestal alleen zo in de wetenschap en bijzondere engineering toepassingen, niet in games).
Jij bent game-developer nietwaar? Ik weet niet of je slechts advocaat van de duivel speelt, maar ik denk dat je moet oppassen om niet je geloofwaardigheid op het spel te zetten. Ben je voor een open standaard of voor een proprietary standaard? Vind je dat Nvidia met kul argumenten komt of niet?

[Reactie gewijzigd door ten99 op 24 juli 2024 03:58]

[.oisyn]

Als je bedoelt dat software in dit geval spellen 80 bits precisie willen i.p.v. 64 bits dan lijkt me dat grote onzin.

Nee ik bedoel de volledige 32 bits (of eigenlijk 24, het gaat slechts om de mantissa) van de x87 ipv nog minder bits van de benadering met een Taylor reeks op SSE.

En x87 trigonometrische functies worden voor spellen toch niet gebruikt zeker?

Oh nee? Hoe maak je een rotatiematrix? Door gebruik te maken van sin() en cos(). Dat PhysX dat niet nodig heeft klopt, maar dat beweerde ik ook helemaal niet. Ik zei dat in de situatie dat je veel trigonometrische functies nodig hebt x87 niet zo'n verkeerde keuze is. De rest van je reactie gaat ook over PhysX en je compleet uit de lucht gegrepen gevoel dat ik nVidia aan het verdedigen ben, dat negeer ik dan maar even, want daar had ik het helemaal niet over. Ik zeg slechts dat kiezen voor SSE niet zonder meer sneller is. Dat de PhysX driver niet SSE optimized is vind ik knap stom.

[Reactie gewijzigd door .oisyn op 24 juli 2024 03:58]

[ten99]

Je maakt geen rotatiematrix, maar een tabel om sin en cos waarden op te zoeken i.p.v. te berekenen. Dit kan zolang je maar niet al te grote precisie verlangt.

Dat SSE niet zonder meer sneller is is zo, maar ik geloof ook niet dat iemand dat ontkent. Ik zeg alleen dat het heel onwaarschijnlijk is dat SSE minder snel is dan x87 voor zowel spellen als PhysX. En het gaat hier al met al over PhysX.

Ik denk dat we het al met al niet oneens zijn. Ik heb kennelijk de verkeerde indruk gekregen uit je antwoord in dat ik er in las dat je Nvidia verdedigt. Sorry hiervoor.

[.oisyn]

Je maakt geen rotatiematrix, maar een tabel om sin en cos waarden op te zoeken i.p.v. te berekenen. Dit kan zolang je maar niet al te grote precisie verlangt.

Ah ja, zodat je je cache elke keer vernaggelt door die tabelletjes, of dat je memory stalls krijgt. Je leeft 10 jaar geleden . Een fsin instructie zit om mijn core 2 rond de 70 cycles. Een memory stall om en nabij de 400. MS' SSE sin() implementatie kost in het gunstigste geval 200 cycles, maar dat schommelt nogal

[Reactie gewijzigd door .oisyn op 24 juli 2024 03:58]

[ten99]

Oei, dat is inderdaad funest. Je zou er nog voor kunnen zorgen dat de tabel niet in de cache geladen wordt, maar 200 cycles of meer is niet te verbergen met out of order execution van de CPU :-)
Je zit trouwens dicht bij de waarheid dat het zo'n 10 jaar geleden is dat ik me serieus met dit soor zaken heb beziggehouden ;-)

Hoe groot zou ongeveer zo'n tabel zijn? Kun je voorkomen dat een bepaald blok uit de level2 cache gestoten wordt nadat je het met een prefetch geladen hebt?
Maar ik kan me voorstellen dat het niet de moeite is.

[.oisyn]

Ach, voor gamedevelopment is een niet zo precieze sin() en cos() prima. Dan moet je denken aan een Taylor reeks met 3 of 4 termen. Hier staat een aardig artikel over een 6-cycle sinus en 9-cycle cosinus implementatie, die ook nog eens 4 componenten tegelijk doen (alhoewel de input wel tussen -pi en pi moeten liggen)

[Reactie gewijzigd door .oisyn op 24 juli 2024 03:58]

[koelpasta]

"Maar ook zonder gebruik te maken van SIMD levert het gebruik van SSE voor floating point berekeningen winst op, omdat geen gebruik gemaakt wordt van het stack-based x87. Je hoeft dus niet te pushen en te poppen."

Waa?..
Volgens mij ben je in de war met wat dingen.
Stack heb je altijd nodig, of je nou de FP unit gebruikt of SSE.
De hele architectuur is gebaseerd op een call stack en daarnaast zijn er OS stacks voor objecten etc.
Het boeit verder niet welke instructies er uitgevoerd worden, je komt er niet omheen om een stack te gebruiken.

Wat WEL echt een probleem is is het omschakelen naar SSE mode. Dit kost veel cycles. De SSE 'subcore' moet dan als het ware op de plek van een rekeneenheid geschakeld worden en die initialisatie kost tijd.
Je wilt je code dus in blokken verdelen, of je doet een bulk SSE berekleningen, of je doet (meestal) een bulk FP berekeningen. Maar als je gaat mixen dan moet je boeten voor de omschakeling. De boete en onder welke omstandigheden je er mee te maken krijgt is afhankelijk van de feitelijke architectuur van de CPU.

[.oisyn]

De x87 architectuur is een stack-based architectuur. Dat heeft niets met 'de stack' te maken, maar met het feit dat je een FPU stack hebt van 8 registers, ST(0) t/m ST(7), waar je waarden op pusht en popt en waar je berekeningen mee doet. ST(0) is altijd de top van de stack. Het vermenigvuldigen van 2 getallen gaat dan zo:

FLD a ;load 'a'
FMUL b ;multiply
FSTP result ;store 'result' and pop stack

Merk op dat er hier niet eens registers worden genoemd, die zijn namelijk impliciet. Een FLD pusht een waarde op de stack, die komt dan in ST(0). De waarde die op ST(0) stond is vanaf dan benaderbaar via ST(1), etc. Een FMUL opereert op de top van de stack, dus ST(0), en een tweede optionele operand (zoals een geheugenadres of FPU register). De FSTP stored het resultaat en popt tegelijkertijd de stack. Met alleen een FST blijft de waarde in ST(0) staan, wat handig is als je er mee door wilt rekenen maar anders niet.

Dit itt SSE, waarvan de registers gewoon vrij aanspreekbaar zijn:

MOVSS xmm0, a ;load 'a' in xmm0
MULSS xmm0, b ;multiply xmm0 with 'b'
MOVSS result, xmm0 ;store 'result'

Nou zit hier nog niet zo heel veel verschil in aangezien het maar een simpele operatie is, maar op de FPU stack moet elke operatie via ST(0). Je kunt dus niet ST(3) met ST(5) vermenigvuldigen, daarvoor moet je eerst een van de twee naar de top van de stack moven, bijvoorbeeld door te swappen:

FXCH ST(3) ;swap ST(0) and ST(3)
FMUL ST(5) ;multiply ST(0) with ST(5), store the result in ST(0)

En dat brengt weer de nodige stalls met zich mee.
Leesvoer

Wat WEL echt een probleem is is het omschakelen naar SSE mode. Dit kost veel cycles. De SSE 'subcore' moet dan als het ware op de plek van een rekeneenheid geschakeld worden en die initialisatie kost tijd.

En nu ben jij degene die in de war is. Mode switching kost tijd tussen MMX en FPU operaties, mede omdat de MMX registers mm0 t/m mm7 eigenlijk overlappen met de FPU stack. Daardoor is de relatief dure EMMS of iets snellere FEMMS instructie nodig om te switchen tussen x87 en MMX mode. SSE heeft dat probleem totaal niet en x87 code kan dus gewoon gemixed worden met SSE code. Echter, wat wel weer een voordeel is vanaf SSE2 is dat je vrij kunt moven van/naar MMX registers. Door geen x87 te gebruiken heb je dus 8 extra 64 bits registers over waar je data in kunt stoppen. Daarmee kun je weliswaar niet direct floatingpoint berekeningen op doen, maar je kunt het dus wel gebruiken als tijdelijke opslag voor floating point waarden. En als je met int-berekeningen werkt dan kun je ze wel direct gebruiken.

Tot zover deze veel te late post die waarschijnlijk door niemand gelezen gaat worden

[Reactie gewijzigd door .oisyn op 24 juli 2024 03:58]

[koelpasta]

Hah!
Thanks voor de info.
Blijkbaar loop ik wat achter
Maar dan is die 'stack' dus gewoon een soort programmeerbare pipeline.

[*Dutch-Force*]

Worden er eigenlijk wel kaarten met physx geproduceerd welke op pre MMX systemen werken?

[iceheart]

geforce 8600 uit m'n hoofd nog op PCI, dus ja.

of het praktisch is...

[TheGhostInc]

"Ook zijn er volgens Nvidia nog steeds ontwikkelaars die liever geen gebruikmaken van de instructies, omdat ze mensen met oudere hardware niet buiten willen sluiten."
Wat een out-dated kul argument... Toont weer dat ze de developers / end-users weer serieus nemen.

Het is nog veel erger dan dat! nVidia heeft zelfs optimalisaties per GPU & CPU type in de GPU drivers zitten en is op de ontwikkeling van drivers echt geen beginner. Een keuze als deze is dan ook 100% bewust en onderbouwd gebeurd. (Hoewel dat ook door een groep eigenwijze programmeurs kan zijn gedaan) De mannen van PhysX hebben de kennis om voor elke actie zelf te bepalen of een x86, x87, mmx of sse instructie te gebruiken.

Nu maar hopen dat PhysX weer snel naar de prullenbak kan en deze politieke spelletjes weer verleden tijd zijn.

[SG]

Nou nee havok en PhysX zijn marktleiders kwa Physics middle ware. En van huis uit dus oorspronkelijk onder steunen ze CPU.
Van PC conosle dus ook de CELL. CPU en ook de Wii CPU.

PhysX is een middle ware en de klanten daarvan zijn Devstudio's voor die middleware kiezen. ipv zelf iets te brouwen. En dat zijn er veel.
Dat nV zwaar PhysX market naar de consument to is eigenlijk indirect van belang.

De consument weet daarmee dat PhysX games voor PC igv nV hardware meer Physics opties heefd.

Maar de dev's zijn doordat alleen nV GPU support wordt genoodzaak om een default gameplay Phsyics limiet voor mainstream CPU in te bakken. And extra zware Physics alleen optioneel mag zijn. En dus gelimiteerd is aan Effect Physics.

Dus gameplay Physics doet het er niet to. Voor de eyecandyjuist wel. Sommige dev's vinden dat wel waard om wat extra PhysX er optioneel bij te pleuren.

Mogelijk door aandringen van Twimtbp devisie die over de vloer komt.

[Tigran]

Ik vind het ook vreemd dat de physx engine niet volledig multithreaded is op de cpu. Als iets kan werken op een GPU, betekent het dat het erg multicore-friendly is.
Ze zouden toch gewoon wat threads toe kunnen voegen, dan kan de OS beslissen welke core die daarvoor inzet. (Dus bij single core cpus draaien alle threads op een core)

Ik vind het goed dat er eindelijk onderzoek naar is gedaan, want mensen beweerden van de enorme kracht van PhysX, terwijl havoc ongeveer hetzelfde kan op de CPU.

[Rexel]

Zo vreemd vind ik dat niet, want op die manier kun Nvidia mensen forcen een Nvidia kaart te kopen als ze PhysX te gebruiken, als iedereen het via zijn CPU zou laten draaien zou iedereen de goedkopere ATi kaarten kopen.

[Tigran]

Het geeft mij persoonlijk een negatiever beeld over nvidia.

Geen idee of het beeld klopt, maar het lijkt net of ATI (physics engines met) opencl meer ondersteunt (bijvoorbeeld opencl voor de bullet engine)

Als gpu physics ooit een belangrijke rol in games willen spelen, dan moeten ze met opencl (of directcompute) werken.

[sdk1985]

Met physics heb ik bij de game blur een aardige prestatie impact gemerkt (van 40-50 fps naar 50-60 fps).

[SG]

Ik zie het toch heel anders. Willen Games de GPPGU kracht ook voor Physics benutten dan moeten de markt leiders kwa Physics middleware. HArdware merk onafhankelijk zijn.

iNtel heeft Havok opgekocht en de GPU merk onafhankelijke Havok FX vermoord.
Dat is dus een kut streek. Niet alleen ATI(aMD) en nV zijn daarmee zwaar genaaid. Maar vooral de gamer. Omdat Havok CPU only blijft.
nV mede om deze reden Ageia PhysX heeft opgekocht. Toen met de Larrabee dreiging nog open stond voor AMD. Maar nu iNtel dreiging van LRB zowat weggevallen is. Spant nV de PhysX SDK voor hun GPU. OpenCL wordt gemeden.


D'r zijn weinig dev;s die zelf hun Physics engine inmekaar kloppen. MEestal doen dat licenceerbare game engine bouwers. Zoals Crytech. Maar deze kunnen ook gewoon een Middle ware engine pakken zoals UE3 PhysX gebruikt.

Ik zie dus totaal niks veranderen op korte termijn. De GPGPU Physics en vooral de gameplay Pjysics zal voornamelijk door CPU gedaan moeten worden.

Jammer.

Voor mij had nV al een negatief beeld gezien hoe ze zich in de markt gedragen maar de grote domper is toch wel intel.

HavokFX was GPU merk neutraal.

iNTel ziet GPGPU toch zeker als zware competitie.

[Flowmo]

Juist daarom is het een belachelijke beslissing. Ik snap dat je als fabrikant/ontwikkelaar mensen je eigen producten wilt laten kopen, maar om dan dit soort antieke ontwikkel beslissingen te nemen schiet bij mij in het verkeerde keelgat. Havok e.d. kunnen al jaaaaren op de cpu draaien, maar PhysX kan dat dan weer niet, erg raar imho. Als ze de code een beetje optimaliseren dan is de cpu echt niet de beperkende factor voor real-time physics berekeningen.

[sdk1985]

Het idee van physx (en het cuda gebeuren) is dat je gebruikt maakt van andere hardware dan de cpu.. Zo is het begonnen. Deze hardware was gebaseerd op een systeem met veel kleine reken eenheden. Dat is nu juist de vernieuwing... dan moet je juist NIET gaan optimaliseren voor de hardware met enkele krachtige kernen...

Juist de hardware met veel kleine kernen heeft potentieel en enorme rekencapciteit, als het eenmaal werkt kun je opschalen. Dat is nu goed te zijn de grafische kaarten waar ineens honderden shaders opzitten in plaats van tientallen.

Het is prachtig dat er GEEN aparte physx kaart meer nodig is (want die kon je een tijdje los kopen) en dan het gewoon op de gpu kan draaien... Optimaliseren voor cpu is echt weer een stap achteruit...

[Reactie gewijzigd door sdk1985 op 24 juli 2024 03:58]

[SG]

Het draaid op CPU , maar juist niet optimaal.

[barfieldmv]

Om vervolgens de game zelf qua performance weg te drukken die ervan uit ging dat de physx engine op een core bleef draaien zeker.

[StackMySwitchUp]

Gebeurt dat nu niet ook dan? een beetje slim programmeren kan dat tegengaan en als de user niet genoeg cores of CPU power heeft kan hij physx ook gewoon uitzetten...

[Ruud v A]

PhysX uitzetten? En hoe wil je dan de game spelen zonder physics?

[Torrentus]

PhysX is wat anders dan physics

PhysX is een technology van nVidia die (zoals hierboven al beschreven) wat 'extraatjes' toevoegd aan een game. Wapperende vlaggetjes en brekend glas. Je kan prima zonder spelen. Physics zorgt voor de natuurkundige kant van een game. Zwaartekracht is daar een voorbeeldje van.

[simen]

Fout.
PhysX is, net als Havoc, een physics "engine". Het voorziet het spel zowel van wapperende vlaggetjes als ragdolls en andere dingen die wel degelijk invloed hebben op het spelverloop en dus niet weggelaten kunnen worden. Wel heb je in veel spellen een optie om het physics "detail" te verlagen en op deze manier zonder een nvidia GPU of Ageia PhysX kaart je spelletje vloeiend te kunnen spelen op een ouder systeem.

[Niosus]

de cloth effecten van bijv vlaggen en kleren uitzetten, minder particles, de scherven van glas dat breekt zijn prebaked, windeffecten uitzetten.

Dat is waarvoor PhysX vooral gebruikt wordt. Voor een paar stenen die vallen en leuke ragdolls heb je echt geen zware spullen nodig hoor.

[mtsr]

Eens. Daarom kun je bij gebruik van PhysX inderdaad zelf instellen of dit een of meer cores moet gebruiker.

[Verwijderd]

Je kan niet zomaar hetzelfde op een CPU laten doen want dan je ga bottlenecks beginnen flooden. Een CPU is nog steeds volledig anders ontwikkelt dus je code zal ook wel goed kunnen werken maar je moet het volledig anders laten werken.

[SG]

Ja de PPU en GPU hebben vele reken eenheden. Vooral GPU. Dus Phsyics waarbij veel particles met elkaar interactie hebben is dat ideal voor GPPGU.
Heb je meer een branch probleem zoals complexe teammate AI dan kan dat CPU veel beter doen.

Daarnaast een CPU is geen dedicated PU een GPU met PhysX ook niet.
Dus voor beide geld je moet wat extra rekenpower marge hebben genoeg voor beide taken.

Omdat de meeste game onderdelen een dynamische load hebben.

In geval van een niet FPS gecapped game zie je vaak zeer grillige FPS.

De reden dat men niet Physics op een extra core wil draaien maar liever een game zodaning analiseerd en opsplits in kleine onafhankelijke subtaakjes, dat deze mini( AI. Physics, mplay, game mechanic ) taakjes door de multitreaden verwerkings engine gehaald wordt. Zodat als je eens een PhysX piek hebt. Zoals een destructieve explosie dat Physics load dan 90% van algehele zware game load is. Een piek belasting. Dat dan ook Physics taakjes vooral verwerkt worden. In een 1 : 9 verhouding.

Valve noemd dit fine grain multitreading en heeft goede ervaring met een hybride form daarvan. iNTel heeft een example tech demo dacht smoke genaamd als voorbeeld. Voor goede en efficiente manier met multitreaden van games te doen.

Dit is de toekomst. Want we gaan naar many core CPU's.

[Verwijderd]

"Ook zijn er volgens Nvidia nog steeds ontwikkelaars die liever geen gebruikmaken van de instructies, omdat ze mensen met oudere hardware niet buiten willen sluiten."
Wat een out-dated kul argument... Toont weer dat ze de developers / end-users weer serieus nemen.

Idem met Microsoft die nog steeds 32-bit OS'en uitbrengt terwijl iedereen (die een nieuw OS kan draaien) toch een 64-bit processer heeft.

[bigbadbull]

dat ligt eerder aan domme gebruikers dan aan MS.
hier mogen we geen 64 bit gebruiken omdat een of andere pipo er schrik van heeft dat er dan iets niet zou kunnen werken.

[LDenninger]

"Stick with what works" is voor bedrijven niet dom.

Jonge systeembeheerders die elk nieuw dingetje gelijk in het bedrijf willen introduceren en zo het risico nemen om het bedrijf plat te leggen - die zijn dom.

[Xthemes.us]

Zoals altijd is er ook een mogelijkheid tussen de twee extremen.
Inplaats van nooit of meteen naar x86_64 gaan kan je het ook even afwachten en alles grondig testen en dan implementeren. Zit je ook niet met het probleem dat zodra het simpelweg niet meer gesupport word je dan alles van de 1 op de andere dag moet omzetten.
Zelfde geld voor PhysX, waarom word ontwikkelaars dan niet gewoonweg beiden aangeboden zodat aan hen de keus is om wel of niet <PIII's te ondersteunen?

[artificial_sun]

Ik geloof niet dat ik dom ben.....

en op mijn oude p4 wil ik ook gewoon win7 draaien voor mijn media center en die ondersteunt geen (of niet goed iig) 64bit

[SCRAP]

Tot aan jouw post ging ik er volledig in mee. Maar mijn Samsung Intel Atom netbook draait geen 64bit OS, maar wel een nieuw besturingssysteem, namelijk Windows 7 Ultime.

Er zijn dus genoeg mensen -inclusief mezelf- die blij zijn dat Microsoft ook nog 32bit besturingssystemen uitbrengt. Wat Nvidia hier doet en beweert is natuurlijk iets heel anders. Er is niemand die moderne Physx software probeert te draaien op systemen ouder dan een Pentium 3. En dit is derhalve alleen maar gedaan om mensen aan te sporen een Nvidia GPU aan te schaffen, door de indruk te wekken dat je er één nodig hebt, terwijl dat dus niet zo is.

[gekko90]

Microsoft heeft al een tijdje geleden in het nieuws gebracht dat windows 7 de laatste windows is/was met een 32bit kernel.

sterker nog windows "9" moet zelfs beschikbaar komen in 128 bit volgens MS

Er zijn nu de dag nog maar een aantal cpu's die geen 64 bit set support hebben.
Die cpu's vinden we vaak terug in Netbooks.

[Wim-Bart]

Dit is zeker waar, kijk maar eens naar Windows Server Edities. Windows 2008 was de laatste 32-bit versie, Windows 2008 R2 is alleen nog 64-bit.

Bovendien zie ik op het moment dat veel bedrijven Windows 2K3 en 2K8 64-bit gebruiken en alleen voor legacy systemen nog 1 of 2 32-bit servers in de lucht houden. Helaas zijn er fabrikanten die hier nog niet zo lekker mee om gaan, maar dit wordt ook steeds beter.

Nog even en aan de server kant is 32-bit volledig weg en de client zal snel volgen.

[Reactie gewijzigd door Wim-Bart op 24 juli 2024 03:58]

[Verwijderd]

Is inderdaad onzin, GPU drivers gebruiken al sinds 10 jaar meerdere "code paths" afhankelijk van de beste aanwezige instructieset. Verder is SSE best wel als standaard aanwezig aan te nemen tegenwoordig.

Ze zijn trouwens wel bezig met een geoptimaliseerde CUDA voor multicore, dat zal de performance zeker verhogen.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 03:58]

[Amanoo]

Mensen met verouderde hardware niet uit willen sluiten?
SSE is al sinds de Pentium 3 in gebruik, je wil me toch niet vertellen dat mensen met een pre-P3 processor gaan proberen Crysis of UT3 te draaien?

Enige mensen die je misschien enigszins uitsluit zijn eigenaren van single core processors, maar tegenwoordig bestaan er dual cores, triple cores quad cores en er worden al steeds meer six cores op de markt geplaatst. Vandaag is flexibel zijn een must, dan kan single core echt nog wel tussen dit rijtje van verschillende soorten processoren.

Sterker nog, door PhysX op non-Nvidia systemen slecht te laten draaien sluit je JUIST mensen uit die geen Nvidia hebben.

[gbh]

allemaal heel leuk hoor maar waarom moet een bedrijf drivers uitbrengen voor hardware die niet van hun zelf is? dat doen intel en amd toch ook niet?

[Peran]

http://www.google.nl/search?q=nvidia%20buys%20ageia%20physx

Volgende keer eerst maar zelf Google..
Ik dacht ook wel dat de gemiddelde Tweaker het 'Physx' verhaal kende..?

Ik dacht dat Ageia de eerste was met stand alone PPU's.. Opgekocht door nVidia en vervolgens door zowel AMD als nVidia software matig in de videokaart in gebakken.

Verbeter me als ik het mis heb.

[Verwijderd]

Bij AMD niet want NVIDIA houdt het voor zichzelf. Iemand met AMD moet dus sowieso CPU gebruiken als er PhysX moet komen.

[gbh]

wat een crap, amd en intel houden licenties voor chipsets en de x86-instructieset ook voor hun zelf, nvidia krijgt daarvoor geen licentie ook al willen ze daar flink voor betalen

microsoft wordt al jaren van de ARM-instructieset afgehouden door intel en amd

intel en amd kunnen gewoon een licentie kopen voor physx en dan kunnen ze drivers optimaliseren wat ze willen, het is al heel wat dat nvidia physx drivers voor cpu's heeft gemaakt, hier is het nog altijd zo dat je een gegeven paard niet in de bek mag kijken

[Sinester]

En dan later er achter komen dat PhysX veel beter draaid op een nVidia dan op een AMD kaart, omdat nVidia daar op een of andere manier voor gezorgd heeft.

Nee het is niet zo simpel als jij doet overkomen, en AMD heeft dus ook een prima reden om geen PhysX licentie te nemen

het is al heel wat dat nvidia physx drivers voor cpu's heeft gemaakt, hier is het nog altijd zo dat je een gegeven paard niet in de bek mag kijken

Blijkbaar is het niet heel wat, want het is niet eens multithreaded en draait op antieke code

[Reactie gewijzigd door Sinester op 24 juli 2024 03:58]

[Peran]

Ondersteund AMD, Havok niet op de GPU?

Ik kan me moeilijk voorstellen dat AMD geen antwoord heeft gepresenteerd op nVidia.

[SG]

Nee. HavokFX zou dat doen voordat iNTel Havok overnam.
En

Cuda is opvolger van Cg
Cg wat tegen hanger is voor HSML
DX Compute shaders doorontwikkeling van HSML
OpenCL die daar mee ook concureerd.

Dus Cuda en OpenCL en Compute shaders zijn C taaltjes voor GPU reken eenheden. De shaders.

Middle ware maakt gebruik van deze taaltjes.

Dit houd in dat er geen PhysX unit in GPU aanwezig zijn.

PhysX vreet gewoon een zooi shaders weg die dan niet meer beschikbaar zijn voor shader effecten. Of de testalatie resultaat.

PhysX spreekt GPU aan met Cuda.

Havok FX zou HSML en Cuda gebruiken.

[Caelorum]

Omdat het geen drivers zijn, maar een stuk software welke wordt gebruikt in onder andere games om physics te berekenen.
Wat zij hier doen is ervoor zorgen dat mensen onnodig hun hardware moeten kopen als ze deze physics berekeningen snel willen hebben.

@Rizon: ze kunnnen ook altijd nog de physics berekeningen laten uitvoeren op de GPU dmv openCL of DirectCompute.

[Reactie gewijzigd door Caelorum op 24 juli 2024 03:58]

[cPT.cAPSLOCK]

Helemaal mee eens dat het kul is:
met oude hardware is physx uitzetten toch het eerste wat je doet. De rest moet natuurlijk soepel blijven, dus dan maar zonder eye-candy.

[roy-t]

Dat argument lijkt echter niet sterk, omdat cpu's sinds de Pentium 3 sse ondersteunen.

Ja maar ondertussen zijn we al bij SSE4. Ik weet nog wel dat een tijd geleden The Chronicles of Spellborn voor SSE3 gecompileerd werd en dat de Pentium D's het spel toen wel konden draaien maar de Athlon XP's niet.

Dat alle processoren van tegenwoordig wel SSE1 hebben snapt intel ook wel .

Ik neem aan dat nVidia niet de moeite gaat doen om eerst alleen SSE1 te implementeren maar dat het meteen door wil naar SSE4, echter zijn er nog zat games die ook op processoren met slechts SSE3 zouden kunnen draaien. Dit is dus een lastige afweging voor nVidia.

Verder is er zelfs in versie 4 nog verschil tussen Intel en AMD processoren, Intel heeft al SSE 4.1 (Penryn) en SSE 4.2 (alleen op de Nehalem i7).

Nogal een complex gebeuren dus .

[Reactie gewijzigd door roy-t op 24 juli 2024 03:58]

[Snoitkever]

SSE is backwards compatible. Elke CPU van dit moment heef SSE2 en SSE2 is meer dan voldoende om de x87 code te vervangen (waarschijnlijk SSE1 ook al wel).

Bovendien, zo moeilijk is het niet om wat verschillende codepaden te schrijven die van verschillende SSE instructiesets gebruik maken, mocht dat uberhaupt nodig zijn.

[Reactie gewijzigd door Snoitkever op 24 juli 2024 03:58]

[Countess]

is helemaal niet complex. dat regelde de compiler allemaal.
er is geen enkel excuus om nog alleen x87 te gebruiken. je compiler kan het automatische zo maken dat er SSE word gebruikt tenzij die niet aanwezig is. daar hoef je als ontwikkelaar (bijna) niks voor te doen.

[.oisyn]

dat regelde de compiler allemaal

Complete onzin. Ik heb het al meerdere keren gelezen hier, waar komt dat rare argument toch vandaan? De enige manier voor de compiler om dat te doen is je applicatie meerdere keren compilen voor verschillende architecturen, bij opstarten te detecteren op welke architectuur je draait en dan vervolgens de juiste codepath kiezen. Je compiler doet echter niets van zulks (aangezien dat je binary ook iets van 3 tot 5 keer zo groot maakt en de compiletijden, die al niet mis zijn bij grote projecten, ook nog eens toenemen), dat zul je geheel zelf moeten doen

[Reactie gewijzigd door .oisyn op 24 juli 2024 03:58]

[SPee]

Vraag je dan jezelf af: voor mensen die processoren hebben die dat niet ondersteunen: hoe oud zijn die processoren?
En vraag dan af: Kunnen ze op die processor het spel dat physx gebruikt wel draaien.

Zal in 100% van de gevallen 'nee' opleveren.
Dus nVidia mag dan wel zeggen 'voorzichtig te zijn' omdat oude processoren het niet aankunnen, maar de werkelijkheid is dat het daar nooit op zal gaan draaien en dat het een kul argument is.

[Seal64]

Ook zijn er volgens Nvidia nog steeds ontwikkelaars die liever geen gebruikmaken van de instructies, omdat ze mensen met oudere hardware niet buiten willen sluiten.

Uh-huh. Want games als Mirror's Edge, Batman - Arkham Asylum en Mass Effect draaien - als je PhysX uitschakelt uiteraard - fantastisch op een Pentium 3.

Ben ik nou gek of wordt Nvidia's zakenmodel steeds meer gebaseerd op het doelmatig en opzettelijk dwarszitten van concurrenten, en minder op gewoon zorgen dat je de beste producten op de markt zet?

[gravitone]

Dat klopt. Hetzelfde geld natuurlijk voor Nvidia, Ati, etc. De groote van de desbetreffende bedrijven en daaruit voortvloeiend het beschikbare capitaal (zowel fysiek als monetair) bepaald hoe effectief ze concurrentie kunnen bestreiden. Als de dominante positie eenmaal bereikt is de consument hier altijd de negatieve gevolgen van ondervinden door beperkingen in gebruik, aanschaf, en uiteraard prijs. De wet van vraag & aanbod vliegt op dit moment volledig uit de deur. Ook juridisch gezien vormen grotere bedrijven een steeds grotere oncontroleerbare entiteit waar misleiding aan de orde van de dag is en transparantie afgedwongen moet worden door een extreem traag reagerende politiek. Denken dat intel, nvidia, ati het beste met zijn klanten voor heeft is op zijn minst zeer naief te noemen. De enige reden dat ATI/AMD zich minder exploiterend opstelt is het gebrek van een dominante positie en de daaruit voortvloeiende macht.

Even terugkomend op het physix verhaal.. een open standaard zou zeer gewenst zijn boven de huidige implementatie. Nvidia houd developers waarschijnlijk in zijn greep door ze te verleiden met aantrekkelijke deals wat betreft hun hardware en software. Hopelijk staat er een partij op in de toekomst die third parties een alternatieve physics implementatie brengt die gebruik maakt van de direct compute interface. En hoewel dit weer een gesloten systeem is is het toch het mindere kwaad omdat dit universeel door het gros van de nieuwe hardware ondersteund word (intel daargelaten). Helaas heeft nvidia waarschijnlijk met de aquisitie van physix een hele berg software patenten (ja het is waanzin, maar ze bestaan echt) in handen gekregen die zo'n breed scala aan alghorithmes en implementaties dekt dat een alternatief er niet aan kan ontkomen om royalties af te dragen aan nvidia. Deze royalties zijn geheel arbitrair te bepalen door nvidia waardoor ze concurentie bij voorbaat uit kunnen sluiten. Gezien de hoge ontwikkelkosten van een complex stuk software zoals dit, en het extreem hoge risico zal er waarschijnlijk geen partij te vinden zijn die zich er aan waagt.

[Reactie gewijzigd door gravitone op 24 juli 2024 03:58]

[Verwijderd]

Er zijn genoeg alternatieven. Havok is de grootste. Je hebt ook ODE en Bullet als alternatieven.
Het probleem is dat je bij NVIDIA een dikke zak poen krijgt als je PhysX en enkel PhysX toevoegt aan je spel. En je mag natuurlijk "the way it's meant to be played" op je doosje en intro zetten. Echt walgelijk wanner ik die bs in intro's zie voorbij komen.

[elmuerte]

Uh-huh. Want games als Mirror's Edge, Batman - Arkham Asylum en Mass Effect draaien - als je PhysX uitschakelt uiteraard - fantastisch op een Pentium 3.

Je schakelt PhysX niet uit. PhysX wordt altijd gebruikt voor physics berekeningen. De "PhysX" optie in veel spellen doet niks anders dan meer dingen toevoegen waar physics berekeningen voor nodig zijn. Je kan in de PhysX control panel wel "hardware acceleratie" uitzetten, en dan gaan de berekeningen over de "CPU" ipv de GPU. Maar PhysX is er nog steeds.

Verder wordt PhysX om meer plekken gebruikt dan alleen in UnrealEngine3 games.

Ben ik nou gek of wordt Nvidia's zakenmodel steeds meer gebaseerd op het doelmatig en opzettelijk dwarszitten van concurrenten, en minder op gewoon zorgen dat je de beste producten op de markt zet?

Hetzelfde doen hun concurrenten, en bijna alle andere tech bedrijven, ook hoor, althans, als ze groot genoeg zijn.

[Sinester]

Nou hoe nVidia het de laatste tijd speelt is toch wel een verhaal opzich hoor.
Ik volg al lang het nVidia en AMD topic, en heb echt al veel vieze praktijken voor bij zien komen.

[Verwijderd]

Is er dan echt iemand die dacht dat NVIDIA niet zou proberen vals te spelen?
Das als de mensen die dachten dat er geen kindermisbruik is in de kerk. Als je 2000jaar je ogen sluit zal je het nog niet gemerkt hebben nee.

[Qreed]

Is er dan echt iemand die dacht dat NVIDIA niet zou proberen vals te spelen?
Das als de mensen die dachten dat er geen kindermisbruik is in de kerk. Als je 2000jaar je ogen sluit zal je het nog niet gemerkt hebben nee.

Wat ik me wel afvraag is hoe ze denken hiermee weg te kunnen komen. Als dit onderzoek echt klopt dan is dit inderdaad niet per ongeluk. Het zal me niet verbazen dat ze die hele code dus vol met #define en #if die een heel andere code flow heeft.

[bwerg]

Doordat 99% procent van de mensen hier helemaal geen weet van heeft en gewoon een pc aangesmeerd krijgt door de medewerkers van mediamarkt. Triest, maar het is wel zo. Op GoT merk ik al dat het merendeel van de tweakers die een beetje actief zijn op het videokaarten-forum zich soms behoorlijk (tot heel veel) ergeren aan dit soort praktijken. Waaronder ik, moet ik zeggen. Ik ben niet zo van fanboyisme maar hierdoor krijg ik toch wel een afkeer voor het kopen/aanraden van een NVidia.

[Reactie gewijzigd door bwerg op 24 juli 2024 03:58]

[ronny]

Ach ik heb eens bij de Dixon gehoord dat een laptop met een Pentium M processor dunner was omdat de processor dunner gemaakt werd
Hoe zout wil je het hebben?

[Yezpahr]

Wat niet weet, wat niet deert.
En ook al weten we het, dan kunnen we ze nog niets doen.
Let maar op, dit gaat ook een soort van doofpot in, want ze zullen hun niet bij de rechter hoeven te verantwoorden, want er is niemand die bewijzen kan dat ze het met voorbedachte rade hebben gedaan.

[Sinester]

Waarom zou dit naar de rechter moeten gaan.

Hoe vies het ook is, volgens mij hebben ze niks illegaal gedaan

[bigbadbull]

De compiler werkt die defines wel weg hoor, zeker als je compacting op zet.

Maar denk dat er minder defines zullen zijn en enkel
#if Nvid => optimized code
#else => buggy code. waar er anders nog wat checks bij zou moeten zitten
#endif
zoals
#if Nvid => optimized code
#elseif SSE_set
#elseif MMXset
#else printf("please buy a new pc instead of trying to run crysis on a P4");
#endif

[N11]

"Ook zijn er volgens Nvidia nog steeds ontwikkelaars die liever geen gebruikmaken van de instructies, omdat ze mensen met oudere hardware niet buiten willen sluiten."
Waarom maken ze dan niet gewoon verschillende versies? Lijkt me niet zo heel moeilijk aangezien de compilers van tegenwoordig goed kunnen optimaliseren voor verschillende instructiesets. Andere optie is natuurlijk om instructieset specifieke optimalisaties uit te voeren middels #ifndef.

[Countess]

sterker nog compiles bouwen tegenwoordig gewoon beide in.
het programma controleert wat de CPU ondersteunt en gebruiken het meest optimale 'path'. daar hoef je als ontwikkelaar niks voor te doen.

[johnbetonschaar]

Heb je daar een bron voor want dit is nieuw voor mij, en dan werk ik al heel wat jaren als software ontwikkelaar. Voor zover mij bekend moet je toch echt 2 binaries bouwen met verschillende compiler switches om verschillende code paden te genereren.

[MSalters]

Countess beschrijft de Intel compiler. MSVC doet dat niet.

[johnbetonschaar]

Ok, heb het even opgezocht (zie ook: http://software.intel.com...r-specific-optimizations/) en zo te zien kan de Intel compiler dit inderdaad, maar dan werkt het wel alleen maar op Intel CPU's, andere x86 CPU's kiezen dan standaard het default code pad. Voor zover mij bekend is dit ook de enige compiler die dit tructje kent, want ik ben het nog nooit ergens anders tegengekomen.

De stelling 'als ontwikkelaar hoef je niks te doen want de compiler doet alles voor je' is dus alleen maar waar als je ICC gebruikt en alleen Intel CPU's target, en de meeste software wordt volgens mij toch echt nog met een Microsoft compiler of een GCC variant gecompileerd en is uitvoerbaar op willekeurige x86 CPU's vanaf een van te voren door compiler switches bepaalde ondergrens.

[Reactie gewijzigd door johnbetonschaar op 24 juli 2024 03:58]

[Adion]

Is dat zo?
In Visual C++ 2010 staat SSE bij een nieuw project nog steeds standaard uit geloof ik, en als je het aan zet is werkt je code niet meer op oudere processors.
Je kan 2 versies maken en de geschikte kiezen, maar dat moet je voor zover ik weet wel zelf zo programmeren dan.

[kiang]

die meerdere versies worden vaak gebruikt hoor: bv bij je Windows installatie: daarbij wordt gekeken wat voor CPU je hebt en de installDVD bevat meerdere versies: de meest optimale wordt op jouw systeem geïnstalleerd

[Gammro]

Het zou wel eens mogen dat dit wordt gefixt, ik kan Mirrors edge met PhysX aan nog steeds niet goed spelen(lees: 3-10FPS) met deze high end hardware, wat je toch wel mag verwachten.

[SalimRMAF]

Dan is er iets goed mis!

Met mijn E3110 op 4 Ghz, en een 8800GT (inc Physx) haal ik ruim speelbare FPS op High @22inch.

[simplicidad]

Op mijn i7 (met een ATI 5770) moet ik physx afzetten of in het tweede level begint het level te stotteren en dropt het naar 5fps. En ik ben niet het enige met het probleem.

Had toen ook al het gevoel dat er iets niet pluis was want qua physics (shattered glass) was het nu niet te zeggen dat er zoveel gebeurde in dat level. Heb knappere physics voorstellingen gezien op mijn pc waar die niet eens verpinkte.

Ik geloof geen snars van wat Nvidia zegt. Hopelijk zet het ontwikkelaars te kijken naar alternatieven zoals bvb de bullet physics library. http://bulletphysics.org/wordpress/

[sharkwouter]

vergeet havok niet http://www.havok.com/

[Amanoo]

Zucht.
Een 8800GT is een NVIDIA!!!!
En zoals verteld werkt PhysX perfect op Nvidia.
Ik heb een ATi kaart waarbij vergeleken jouw 8800GT'tje een zielig namaakseltje is, en ook bij mij verandert Mirror's Edge in een diavoorstelling zodra ik het aanzet. Want het is ATi, die het perfect kan draaien maar het niet doen omdat het niet mag van PhysX-eigenaar Nvidia...

[sharkwouter]

Kom op, tuurlijk werkt het goed als je een physx kaar hebt, maar ik had toch meer verwacht van mijn 3,4ghz quad core in combinatie met physx. Ik ga straks ff het verschil testen van physx aan of uit, ik post het dan wel.

[Verwijderd]

Nvidia caught with her hand in the cookie jar...
Op zich wel logisch maar nu kleeft er toch een nare bijsmaak aan een "vereiste" Physx kaart voor bepaalde spellen, het zit Nvidia niet mee de laatste tijd.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 03:58]

[_Dune_]

Sorry, hoezo zit Nvida het niet mee de laatste tijd? Het is hun eigen bedijfsvoering (arrogantie) die hun in een dergelijke situatie brengt. Zie ook het hele debakel met de G84, G86 en G92 gabasseerde IGP en GPU's. Willens en wetens ruim twee jaar defecte chips verkopen aan de oem industrie, daarmee zowel partners als consumenten benadelen en uiteindelijk geheel geen oplossing bieden.

Nu ook dit weer boven water komt, kun je zien dat dit gewoon de standaard bedrijfsvoering is van Nvidia welke geheel op arrogantie is gebasseerd. Persoonlijk ben ik helemaal niet van het fanboy gebeuren, maar sinds zeker een jaar heb ik Nvidia geschrapt uit mijn hardware assortiment voor het uitbrengen van advies naar klanten, vrienden of familie.

Als het niet nodig is gebruik ik absoluut geen Nvidia produkten, dat is de enige manier om dergelijk bedrijf te laten voelen dat zij op de verkeerde weg bezig zijn. Gelukkig bied AMD/ATi tegenwoordig uitstekende alternatieven.

[Reactie gewijzigd door _Dune_ op 24 juli 2024 03:58]

[computerjunky]

sinds zeker een jaar heb ik Nvidia geschrapt uit mijn hardware assortiment voor het uitbrengen van advies naar klanten, vrienden of familie.

dus jij geefd advies om een ati kaart te kopen omdat nvidia de nummer 1 op de videokaart markt wil zijn en de prestaties doen er niet meer toe ?
nvidia is op het moment gewoon beter voor physx het is hun ontwerp hun inverstering waarom zouden ze een cpu er even goed in moeten maken zodat mensen hun producten niet meer zouden hoeven kopen ?

Gelukkig bied AMD/ATi tegenwoordig uitstekende alternatieven

tenzij je cuda of physx wil hebben

[Solid_Aapie]

Een grafische kaart aanschaffen voor alleen physx lijkt mij overdreven. Dan trap je juist in de ''val'' die Nvidia voor je zet want laten we het even op een rijtje zetten:

Nvidia deelt zijn software niet met anderen(of legt hier belachelijke voorwaarden aan vast)
Physx draait even snel op een Ati kaart
Physx draait even snel(of sneller) op je cpu

Ze halen alleen een trucje uit(die vaak te omzeilen is) zodat het alleen op hun kaarten draait. Hoe je het ook went of keert een klant die daarom een Nvidia kaart koopt loopt gewoon in de val.

Daarnaast heeft Nvidia momenteel GEEN goede prijs/prestatie kaarten, en ik vind het dan ook een heel normaal om te zeggen dat je mensen deze kaarten niet aanraad.

(Ik ben GEEN fanboy btw ik heb zelf ook een nvidia kaart maar zou er nu echt geen kopen)

[computerjunky]

Physx draait even snel(of sneller) op je cpu

als je cpu berekeningen aan het doen is die je gpu efficienten en beter kan doen kost dat cpu tijd waardoor je gpu minder effectief werkt wat je opoveral preformance nekt.

ik heb sinds de radeon 9800 tijd nvidia omdat ze simpelweg beter in prijs preformance zijn op de momenten dat ik ze koop (6800GT, 8800GT, GTX 285 ) alle 3 kaarten die geen gelijken hadden op het moment van aanchaf.
de huidige 400 serie en 5000 serie laat ik links liggen omdat mijn gtx 285 nog steeds alles full draait.
ik zou de nvidia 400 serie nooit kopen omdat ie energie vreet en niet echt supersnel is voor alles maaar alleen bepaalde bewerkingen goed doet (dit had ati in het verleden).

en ati heefd jaren nvidia belachelijk gemaakt vanwege hun release prijzen maar bij de release van de 5800 serie deed ati exact hetzelfde omdat er simpelweg geen antwoord van nvidia was de 5800 serie was bij de release dan ook enorm duur en nog steeds niet echt goedkoop.

kijk hier :http://www.alternate.nl/html/product/Grafische_kaarten_ATI_Radeon_HD5000/XFX/HD5870_Alien_vs_Predator/409199/?tn=HARDWARE&l1=Grafische+kaarten&l2=PCIe+kaarten+ATI&l3=Radeon+HD5000

dit is nog steeds 15 euro duurder dan dat ik destijds betaals heb voor mijn kaart die in dezelfde prijsklassen lag.

[Solid_Aapie]

als je cpu berekeningen aan het doen is die je gpu efficienten en beter kan doen kost dat cpu tijd waardoor je gpu minder effectief werkt wat je opoveral preformance nekt.

De test bewijst dat dit niet zo is

k heb sinds de radeon 9800 tijd nvidia omdat ze simpelweg beter in prijs preformance zijn op de momenten dat ik ze koop (6800GT, 8800GT, GTX 285 ) alle 3 kaarten die geen gelijken hadden op het moment van aanchaf.
de huidige 400 serie en 5000 serie laat ik links liggen omdat mijn gtx 285 nog steeds alles full draait.
ik zou de nvidia 400 serie nooit kopen omdat ie energie vreet en niet echt supersnel is voor alles maaar alleen bepaalde bewerkingen goed doet (dit had ati in het verleden).

Ik kan mij ten eerste herinneren dat de 850XT altijd sneller was dan de 6800GT en veel eerder te koop was EN goedkoper(had alleen geen ps3.0 maar was ook ouder).

en ati heefd jaren nvidia belachelijk gemaakt vanwege hun release prijzen maar bij de release van de 5800 serie deed ati exact hetzelfde omdat er simpelweg geen antwoord van nvidia was de 5800 serie was bij de release dan ook enorm duur en nog steeds niet echt goedkoop.

Sorry, maar dan ben je niet zo up to date in computerland als je dit zegt. Ten eerste heeft Ati bijna altijd een lagere release prijs. Ten tweede is Nvidia nu bezig om productie capaciteit van Ati weg te snoepen zodat hun minder kaarten kunnen maken(Nvidia heeft kennelijk voorrang in hun contract en gebruiken dit door Ati te dwarsbomen). Er is namelijk nu maar 1 fabriek waar allebei de dx11 kaarten gebakken worden. Door de hoge vraag en de lagere productie capaciteit(door Nvidia) neemt de prijs van Ati kaarten toe. Want ja als een product schaars is word de prijs hoger das logisch.

Daarnaast heeft Nvidia momenteel geen goed tegen aanbod dus Ati hoeft niet te concurreren door de prijs te verlagen(zoals bij de 400 serie).

[_Dune_]

Je leest niet goed of hebt de laatste alinea van mijn bericht overgeslagen. Op het moment dat er geen "must" is zal ik inderdaad absoluut geen Nvidia aanraden, aangezien Nvidia er een handje van heeft partners en cosument regelmatig in de koude te laten staan.

Daarbij zoals opgemerkt kun je prima zonder de physx van Nvidia, dus dat is geen must, koop je een dergelijke kaart wel voor physx in games, dan vind ik dat persoonlijk zonde van het geld, aangezien Nvidia op het moment geheel geen interessante kaarten heeft op het prijs/prestatie gebied en al helemaal niet als we naar het opgenomenvermogen gaan kijken.

Daarnaast is er meer dan alleen Game PC's...

Naast dat de huidige produkten van Nvidia nauwelijks mee kunnen komen met d concurrentie houden zij er ook nog dergelijke praktijken op na zoals deze hier worden besproken, meerekend het gehele GPU debakel welke al in Novmeber 2006 is begonnen en pas half 2008 door Nvidia erkent is, om vervolgens gewoon op het luie achterste blijven zitten.. of wel geen oplossing bieden. Doet mij het vertrouwen in een fabrikant en zijn produkten erg dalen en daarom zal ik het dan ook niet aanraden als et niet strikt nodig is.

[Reactie gewijzigd door _Dune_ op 24 juli 2024 03:58]