Test: EVGA Geforce GTS 450 FTW

[Syar-2003]

Raptor' date='29. september 2010 - 00:30' timestamp='1285713000' post='16268751']

Ikke bare har Nvidia sperret PhysX for AMD kort (uten cuda vel å merke), men også sabotert CPU ytelsen betraktelig. PhysX kunne kjørt mye bedre på CPU enn det gjør i dag og den dårlige ytelsen er ene og alene fordi Nvidia ikke ønsker bedre ytelse for PhysX via CPU.

Noen andre konspirasjonsteorier du vil komme med i samme slengen?

 

 

 

Konspirasjons teori ?

Når det gjelder disablingen av physx , er det iallefall klart uttalt fra nVidia

Here is a copy of the email I received from Nvidia support confirming what they have done.

 

"Hello JC,

 

Ill explain why this function was disabled.

 

Physx is an open software standard any company can freely develop hardware or software that supports it. Nvidia supports GPU accelerated Physx on NVIDIA GPUs while using NVIDIA GPUs for graphics. NVIDIA performs extensive Engineering, Development, and QA work that makes Physx a great experience for customers. For a variety of reasons - some development expense some quality assurance and some business reasons NVIDIA will not support GPU accelerated Physx with NVIDIA GPUs while GPU rendering is happening on non- NVIDIA GPUs. I'm sorry for any inconvenience caused but I hope you can understand.

 

Best Regards,

Troy

NVIDIA Customer Care"

 

 

Les: http://www.ngohq.com/graphic-cards/16223-nvidia-disables-physx-when-ati-card-is-present.html

Endret 29. september 2010 av syar2003

[vesleengen]

Meh... Not all that bad... Kunne vert litt billigere... GTX460 1GB må komme seg nedover og det MÅ HD5830 og 5850 snart også! De to sistnevnte burde blitt kuttet 500kr.. De har jo enda ikke gått ned nesten noe..

 

Håper seriøst på noen skikkelige drivere fra AMD snart, samt ny nettside og enklere installasjon av driverne... Nettopp her gjør Nvidia en MYE bedre jobb, samt at de har langt bedre støtte for lille Linux

 

Diskusjonen og PhysX er så som så... Er ikke mange spill som bruker det uansett, og de spillene jeg har prøvd med PhysX har jeg knapt lagt merke til forskjellene...

[HKS]

Det er noen måneder siden det ble linket til en god og utfyllende artikkel om hvor elendig PhysX implementasjonen mot CPU var og at de enkelt kunne gjort den betraktelig bedre.

Det er denne delen jeg kan snakke for. Husk at du deler CPU med andre applikasjoner. Hvis man skriver ett API som bruker for mye resurser så lager du problemer for de andre applikasjonene som kjører. PhysX er implementert på mange plattformer, og store deler av koden er delt mellom PC/360/PS3.

 

Jeg skulle tro at de opplyste i forumet som følger med i begge leire faktisk hadde fått med seg en så viktig post i HD5xxx tråden.

Det er dessverre begrenset hva jeg har av tid til å være på et forum...

 

 

OpenCL-spesifikasjonen er absolutt moden, det er AMDs implementasjon som ikke er moden. AMD har heller ikke klart å lage en ordentlig implementasjon av OpenGL.

 

nVidia bør jobbe med med PhysX implementert i OpenCL slik at det er stabilt og klart til lansering om cirka et års tid.

Helt riktig.

 

OpenCL kommer også med sine utfordringer, og man er ganske naiv hvis man tror at en ting skrevet i OpenCL magisk fungerer knallbra både på Nvidia og AMD. Hvis jeg skriver en applikasjon og optimerer den mot for eksempel Nvidia sin GF100-arkitektur så kommer den til å kjøre ganske elendig på AMD-kort (selv om de skulle klart å fikse OpenCL implementasjonen). Oppbyggingen av arkitekturene er rett og slett så forskjellig.

[007CD]

Vell Raptor, den der artikkelen kan det lønne seg å slå opp.

Det som var diskutert var SSE optimering av instruksene i PhysX.

Riktignok nå er jeg ikke noen ekspert men jeg har sett ett av disse klassiske forvokste uoptimerte rotapplikasjoner (Tenk dårlig koding, skrevet etter hundgammel hardware, men vokst opp til dagens størrelse uten optimeringer.) ha en variant med SSE2 og en uten.

 

Utviklerne hevdet det ikke var noen forskjell, men jeg testet samme applikasjonen med og uten SSE2 på flere maskiner, både moderne i7, Core 2, og en gammel Sempron på socket 754.

Jeg gikk såpass langt at jeg testet en nyere versjon av samme applikasjonen som var ryddet litt men uten SSE2 fra og enda da var gapet mellom optimeringen ganske stor.

 

En kort oppsumering var at i frames på Sempronen kunne jeg uten SSE2 måle ytelsen i seconds per frame, mens med SSE2 kunne jeg måle ytelsen i frames per second igjen.

Og når en slik elendig applikasjon klarer å se forbedringer og reduksjon i CPU bruk på rundt 40% så vil jeg nok tro at PhysX har like mye å hente på det hele, og enda enklere å få flertrådet, enn den enkeltrådete applikasjonen.

[Theo343]

PhysX CPU:

Jeg tror ikke man trenger være naiv eller andre ting man blir kalt her for å mene at CPU implementasjonen til PhysX kunne vært gjort betraktelig bedre uten å snu verden på hodet for å få det til.

 

Husk at du deler CPU med andre applikasjoner. Hvis man skriver ett API som bruker for mye resurser så lager du problemer for de andre applikasjonene som kjører.

Det vil jo også gjelde i spill hvor eks. PhysX kjører på GPU. PhysX kjøringen vil "stjele" ressurser fra andre GPU oppgaver i spillet. I eks. Mafia II synker FPS betraktelig om man enabler PhysX på sterkt Nvidia kort.

 

Så det er ingen "magi" involvert slik sett i det og det er nok de fleste klar over.

 

PhysX GPU:

Man oppfatter det som naturlig at det gjøres optimaliseringer mot Nvidias egen arkitektur. På en annen side kan man si at Nvidia villedet brukerne en periode og forsøkte å fremstille det som at det bare var opp til AMD å omfavne CUDA så ville alle ha PhysX omtrentlig like godt fungerende men med noe dårligere ytelse. Selvfølgelig er det nok aspekter jeg og andre ikke har oversikt over, men det ble snakket i generelle vendinger om at "CUDA var åpent, AMD kunne bare implementere det i driverne sine men ville ikke". Hvorpå de rir den andre hesten etterpå og sier at CUDA er så optimalisert mot Nvidia arkitekturer at man omtrent kunne glemme det osv.

 

Forøvrig blir man ikke spesielt naiv ift. slik som dette av å jobbe 15 år innen ikt teknisk, system, program etc.

 

Raptor:

Når det gjelder tid i forumet så forventet jeg ikke nødvendigvis at du hadde fått deg med deg her, men i ditt daglig virke som driver mye med slikt.

Endret 29. september 2010 av Theo343

[Theo343]

Du forstår tydeligvis ikke hvor stor overheaden blir pga. synkronisering. Det vil være en veldig stor oppgave å få det til å skalere brukbart på tre- fire kjerner og ulike prosessorer, dessuten vil det ikke skalere bra videre. Uansett så vil et GT 240-kort gjøre jobben mye bedre enn dagens CPUer.

Du mener at ikke hvem som helst forstår at det byr på utfordringer med parallellprosessering? Prøv igjen... Endret 29. september 2010 av Theo343

[HKS]

Vell Raptor, den der artikkelen kan det lønne seg å slå opp.

Det som var diskutert var SSE optimering av instruksene i PhysX.

Hmmm..

får legge det på todo-listen å finne den artikkelen dere snakker om.

Det lille jeg har sett av kode i PhysX brukte både SSE og AltiVec.

Uansett så tviler jeg på at de ønsker å optimere koden mer til x86. En OpenCL versjon vil fint kunne kjøre på CPU, så da slår de nok heller to fluer i en smekk på den måten.

 

Det vil jo også gjelde i spill hvor eks. PhysX kjører på GPU. PhysX kjøringen vil "stjele" ressurser fra andre GPU oppgaver i spillet. I eks. Mafia II synker FPS betraktelig om man enabler PhysX på sterkt Nvidia kort.

Forskjellen er at på GPU så har Nvidia sin lastbalanserer full kontroll. Det har de ikke på CPU.

 

Raptor:

Når det gjelder tid i forumet så forventet jeg ikke nødvendigvis at du hadde fått deg med deg her, men i ditt daglig virke som driver mye med slikt.

Jeg driver en del med GPGPU støtte i OS, ikke med grafikk eller fysikk i spill...

[Theo343]

Uansett så tviler jeg på at de ønsker å optimere koden mer til x86

Og da er vi vel tilbake på det Nvidia har fått kritikk for en god stund nå, uten at det er en konspirasjonsteori.

 

En OpenCL versjon vil fint kunne kjøre på CPU, så da slår de nok heller to fluer i en smekk på den måten.

Får man en god OpenCL implementasjon også mot CPU vi jeg, og sikkert mange andre, se saken i et annet lys. Endret 29. september 2010 av Theo343

[HKS]

Uansett så tviler jeg på at de ønsker å optimere koden mer til x86

Og da er vi vel tilbake på det Nvidia har fått kritikk for en god stund nå, uten at det er en konspirasjonsteori.

Ja, men jeg mener fremdeles at "sabotere" er feil ord å bruke. At de ikke prioriterer x86 optimering like mye som GPU optimering stemmer nok.

 

Det er veldig mange spill der ute som kun bruker PhysX sin CPU implementasjon, hadde koden til Nvidia vært så elendig så tviler jeg på at spillutviklere hadde brukt det...

[Theo343]

Jeg er ikke uvillig til å være enig i at jeg brukte sterke ord, men jeg er langt fra alene om det, og oppfatningen stammer fra vesentlig mer oppdaterte personer enn meg på området.

 

Implementasjonen har så åpenbare svakheter at man rett og slett lurer på hva motivasjonen med den var.

 

Men det blir uansett spennende med OpenCL/CPU.

Endret 29. september 2010 av Theo343

[efikkan]

Man oppfatter det som naturlig at det gjøres optimaliseringer mot Nvidias egen arkitektur. På en annen side kan man si at Nvidia villedet brukerne en periode og forsøkte å fremstille det som at det bare var opp til AMD å omfavne CUDA så ville alle ha PhysX omtrentlig like godt fungerende men med noe dårligere ytelse. Selvfølgelig er det nok aspekter jeg og andre ikke har oversikt over, men det ble snakket i generelle vendinger om at "CUDA var åpent, AMD kunne bare implementere det i driverne sine men ville ikke". Hvorpå de rir den andre hesten etterpå og sier at CUDA er så optimalisert mot Nvidia arkitekturer at man omtrent kunne glemme det osv.

Som sagt er CUDA designet for nVidias GPUer, og har vært tett integrert siden G80. AMDs arkitekturer er veldig ulike nVidias, så her vil det veldig sannsynlig være flaskehalser som vil kreve justeringer av arkitekturen for å få bort. Uansett vil det være en enorm oppgave å implementere et API som ikke er designet for andre arkitekturer. Men hvis AMD nå gjør en enorm innsats og justerer sin kommende arkitektur (HD 7000) så vil det i beste fall bli som OpenCL- og OpenGL-implementasjonene tim AMD, to åpne API som ikke er designet arkitekturspesifikt og AMD har vært med i hele designprosessen og likevel har AMD vansker med å implementere. En annen forutsetning for å implementere CUDA er at nVidia må være villig til å hjelpe hele veien.

 

Parallellprosessering er relativt greit når arbeidet bare skal gjennomføres så raskt som mulig og ikke trenger å være synkronisert. Så la meg prøve på en forklaring på hvorfor dette er vanskelig å få til uten stor overhead eller annet ytelsestap, hver sykel med fysikkberegninger må være synkronisert med en timer f.eks. på 1/60 sek, gjerne kortere intervall, men la oss ta det tallet som eksempel. Dvs. at PhysX må dimmensjonere en arbeidsmengde som den vet blir ferdig på 1/60 sek fordelt på x kjerner, og siden det kjører flere andre prosesser i bakgrunnen blir dette langt fra full utnyttelse. Det må beregnes god margin og andre threads må vente til den siste er ferdig og synkroniseres, i tillegg til forsinkelser pga. operativsystemet. En slik implementasjon av PhysX måtte vært optimalisert mot ulike CPUer og ulike operativsystemer, i tillegg til en god skaleringsalgoritme som både håndterer godt antall kjerner men også skalerer godt med hensyn på annen last på systemet, altså både resten av spillet og alle andre prosesser. En god implementasjon vil ha rundt 80% effektivitet av 2-3 kjerner(på dagens CPUer ~3 GHz), men effektiviteten vil sakte men sikkert minke ved flere kjerner og et sted mellom 4-8 kjerner vil effektiviteten synke til et punkt der det ikke er så stor gevinst av flere kjerner. Men uansett så ser ikke jeg poenget med dette når en halvgod implementasjon i OpenCL vil gjøre det mye mer effektivt på en relativt svak GPU. Jeg ser ikke gode nok argumenter til hvorfor nVidia skal bruke tid på dette.

[Theo343]

Jeg ser ikke gode nok argumenter til hvorfor nVidia skal bruke tid på dette

Jeg er ikke totalt uenig i det, men slik sett er jeg heller ikke overbevist om at PhysX bør være det som gir oss fysikk i spill. Ikke at det er dårlig, men dette at det favoriserer en produsent fremfor en annen, dog av flere årsaker.

Parallellprosessering er et aspekt, en annen ting er dette som 007CD snakker om som var kjernen i artikkelen vi tenkte tilbake på.

 

Men jeg ser lysere på saken med OpenCL og neste generasjon skjermkort (ikke SI/NI)

Endret 29. september 2010 av Theo343

[efikkan]

Det finnes da flere andre fysikkmotorer, og det er vel ikke lenge før noen av disse bruker OpenCL og er modne nok til produksjon.

[ArneJ.]

Tror dette er rett artikkel om Physx ytelse på cpu.

[Theo343]

Takk Onanias

 

Siden jeg leste det på hadde muligens en noe annen layout men jeg tror den var basert på samme kildestoffet.

Endret 29. september 2010 av Theo343