Gå til innhold

Asus lanserer PhysX P1


Anbefalte innlegg

Videoannonse
Annonse
Alt er vel egentlig software, det som er forskjellen er vel hvor den kjøres?

6080928[/snapback]

 

Ja...det er sant. Men etter disse spesialkortene kom på banen (3D grafikk kort og sånt) har folk begynt å kalle det hardware basert ettersom mye av "koden" ligger låst i selve kortet. Det er funksjoner som blir kalt fra softwaren, og leverer tilbake et resultat uten at CPU'en har noe kontroll på hva som skjer inne i funksjonen. Riktignok kan denne "koden" som ligger i kortet bli forandret på ved driver-oppdateringer (som igjen er software) så... :D

 

Jeje.

 

Syns at GFX kort produsentene skal bruke kreftene på å forbedre selve grafikken og ikke fysikkutregninger. Fysikken kan bli brukt i mange andre deler av et spill (som lyd f.ex) og at GFX kortet skal regne dette ut internt høres ikke bra ut for min del.

Lenke til kommentar

Approksimasjoner, forhåndsprogrammerte, er vel ikke så vanskelig å få til med fysikkortet, men det blir vel litt unødvendig å ta det helt ut,, eller umulig for den saks skyld. Turbulente strømningner etc krever jo lass me regnekraft bare for approksimasjoner for Navier-Stokes ligninger.

Endret av [^..^]Christian
Lenke til kommentar
ja, konsoller er prakteksempler på hva en kan utrette med spesialisert prosesering.

 

jeg synes det nesten er pereverst med grafikk av det kaliberet med tanke på specs ps3\xbox360 kontra en veldimensjonert pc.

6070862[/snapback]

 

Nå er det et faktum at konsoller selges med tap. Tapet tar de igjen på lisens for utvikling av spill for hver enkelt konsoll. Jeg tror nok, dersom konsoller hadde blitt solgt med gevinst, en Xbox eller P3 kjapt hadde klatret opp mot 7-8000kr. Husk at konsoll spill er en del dyrere en PC-versjoner. I det lange løp får man nok mer igjen for pengene på en PC.

6073532[/snapback]

 

Jeg tenkte på specs, ikke pris :)

Lenke til kommentar

Ikke bare det, men på en konsoll er vel også enkeltkomponentene optimalisert for å funke meget godt sammen. I en pc skal alt mulig være kompatibelt med alt mulig annet og man får en rekke flaskehalser en konsoll slipper unna. Det kommer ganske tydelig frem når man sammenligner hw vs ytelse i en pc/konsoll.

Lenke til kommentar
Ikke bare det, men på en konsoll er vel også enkeltkomponentene optimalisert for å funke meget godt sammen. I en pc skal alt mulig være kompatibelt med alt mulig annet og man får en rekke flaskehalser en konsoll slipper unna. Det kommer ganske tydelig frem når man sammenligner hw vs ytelse i en pc/konsoll.

6082411[/snapback]

 

Er det så veldig mange flaskehalser som spiller mye inn? De fleste konsoller har jo også en flaskehals eller to, og man pleier jo å komme seg rundt de. Se feks på x360, synes den er ganske på nivå med en PC med tilsvarende skjermkort.

 

AtW

Lenke til kommentar

Tråden tok seg voldsomt opp på slutten. Christian, du har et meget godt poeng med Navier-Stokes, den legger ikke bare grunnen for turbulens slik som beskrevet for sigarettrøyk, men for den saks skyld også en vannsprut. Selv approksimasjoner av Navier-Stokes leder gjerne til partielle diff-likninger. Hvis dette skal kunne håndteres av en massivt parallell fysikkmotor på en god måte, må man i det minste bruke en eksplisitt formulering. Kan bli mye rar røyk og vannsprut av slikt. Tilsvarende problem for varmeledning, selv om den i sin enkleste form kan løses ved separasjon av variable.

 

Jeg tipper at bruk av fysikkmotoren tar utgangspunkt i enklest tenkelig problem: a(t)=g med initialverdier v(0)=a og r(0)=b, m.a.o. integrasjon i hver himmelretning gir analytisk uttrykk, hvor man neglisjerer friksjon. Med tillegg for vridning av objektet gitt ved proposjonalt forhold mellom tid og to vinkler (typisk kulekoordinater). Dette vil gjøre synkronisering meget enkel siden alt er uttrykt mhp. tid, så lenge fysikkmotoren makter å ligge foran spilleren i tid. Kollisjoner ser jeg for meg som mer krevende å få til p.g.a. kommunikasjonsbehov.

 

Ellers stiller jeg meg skeptisk til at CPU skal være hjelpeløs her, det er bra mye fysikk en ekstra CPU-kjerne kan regne ut, men noen har kanskje klart for seg hvorfor noen få GFLOPS ikke er tilstrekkelig? Skulle gjerne også sett god argumentasjon på hva som gjør en GPU dårlig egnet til fysikk, utover "jeg har laget en software pipeline, og derfor vet jeg det".

Lenke til kommentar
Ellers stiller jeg meg skeptisk til at CPU skal være hjelpeløs her, det er bra mye fysikk en ekstra CPU-kjerne kan regne ut, men noen har kanskje klart for seg hvorfor noen få GFLOPS ikke er tilstrekkelig? Skulle gjerne også sett god argumentasjon på hva som gjør en GPU dårlig egnet til fysikk, utover "jeg har laget en software pipeline, og derfor vet jeg det".

6089241[/snapback]

 

leste noe om det for en stund siden. har noe med verdier som skal forandres og skrives tilbake til minnet uten å gå om ram'en.

men skal jeg være ærlig vet jeg veldig lite om temaet. husker ikke helt hvor jeg har lest det.

Lenke til kommentar
Ellers stiller jeg meg skeptisk til at CPU skal være hjelpeløs her, det er bra mye fysikk en ekstra CPU-kjerne kan regne ut, men noen har kanskje klart for seg hvorfor noen få GFLOPS ikke er tilstrekkelig?

6089241[/snapback]

Det kommer helt an på hva en definerer som "tilstrekkelig". Mer regnekraft gir større muligheter, akkurat som raskere skjermkort gir mulighet for bedre grafikk.

 

Tenk f.eks. at omtrent alt i et helt spill kan deformeres eller knuses i biter. Det blir fort mange tusen fragmenter som må simuleres. Eller tenk på løse klær som former seg etter kroppen og påvirkes av tyngdekraft og vind.

Lenke til kommentar
Tenk f.eks. at omtrent alt i et helt spill kan deformeres eller knuses i biter. Det blir fort mange tusen fragmenter som må simuleres.

Tror skjermoppløsningen din fort får problemer med mange tusen biter, den demo'en Ageia la ut hadde ikke så veldig mange biter.

Eller tenk på løse klær som former seg etter kroppen og påvirkes av tyngdekraft og vind.

6090069[/snapback]

Et slikt klesplagg vil gi deg et koblet system, vet du hvor krevende det kan være å parallellisere massivt?

Lenke til kommentar

så i dokumentaren om "the incredibles" angående håret til jenta i familien. det er visst sinnsykt hardt å få til hår skikkelig da det er så mange hårstrå. tror de brukte noe nye greier da, og når de viste frem en demo til folk som jobber med slike animasjons ting gikk de visst helt amok!

 

lurer på om en "proff" versjon(eller 100) av aeiga brikken kunne gjort underverker for animasjons bransjen?

Lenke til kommentar
Jeg mener å ha lest at denne tidlige demoen inneholder bokstavelig talt flere tusen elementer (steiner) men klarer ikke å finne tilbake til kilden nå.

Det hørtes veldig mye ut, men en skjerm har jo plass til en million pixler, så hvorfor ikke. I såfall må i det minste Physx gi beskjed om posisjon og rotasjon for hver av dem for hver frame. Hvis vi antar single precision for hver koordinat og hver vinkel, gir det 5x8=40byte, i tillegg må man vite hvilken stein det er, og da er vi oppe i ca. 50byte, og da har vi enda ikke begynt å tenke på kollisjoner (som det antagelig er rimelig mange av her). Ved 100fps og ett tusen objekter, så gir det minimum 5MB per. sekund som skal gå gjennom PCI porten (i en retning), det er jo forsåvidt godt innenfor båndbredden på ca. 100MB/s. Men hvordan skal man løse kollisjoner, da må jo nesten formen på hvert objekt være kjent, og det er en betydelig større mengde data (men som forsåvidt ikke trenger å bli sendt frem og tilbake). Er det noen som vet om det er Physx som skal ta seg av kollisjonsberegningen, eller er det CPU? Denne Physx saken har tross alt kun 128MB minne, så vi kan fort nærme oss en begrensning.

 

så i dokumentaren om "the incredibles" angående håret til jenta i familien. det er visst sinnsykt hardt å få til hår skikkelig da det er så mange hårstrå. tror de brukte noe nye greier da, og når de viste frem en demo til folk som jobber med slike animasjons ting gikk de visst helt amok!

Hår hørtes ikke så dumt ut, men der også blir det en del data som må håndteres, hvor mange byte trenger man for å angi posisjonen til et helt hårstrå?
Lenke til kommentar
Tror skjermoppløsningen din fort får problemer med mange tusen biter, den demo'en Ageia la ut hadde ikke så veldig mange biter.

Det har da nær sagt ingenting med skjermoppløsning å gjøre. Og Ageia har jo alt vist en demo med tusenvis av objekter.

 

Et slikt klesplagg vil gi deg et koblet system, vet du hvor krevende det kan være å parallellisere massivt?

6090279[/snapback]

Vel, mangelen på en demo sier nok sitt, men rykter har indikert at denne type problemer skal fungere bra med PhysX.

 

Men hvordan skal man løse kollisjoner, da må jo nesten formen på hvert objekt være kjent, og det er en betydelig større mengde data (men som forsåvidt ikke trenger å bli sendt frem og tilbake). Er det noen som vet om det er Physx som skal ta seg av kollisjonsberegningen, eller er det CPU? Denne Physx saken har tross alt kun 128MB minne, så vi kan fort nærme oss en begrensning.

Kollisjonene er den tunge jobben (når de trengs). PhysX tar seg av de. Hvis ikke hadde et slikt kort bare vært brukbart for effekter som ikke trenger kollisjoner.

Endret av EasyRaider
Lenke til kommentar
Det har da nær sagt ingenting med skjermoppløsning å gjøre. Og Ageia har jo alt vist en demo med tusenvis av objekter.

Hvor mange objekter det er hensiktsmessig å visualisere har ingenting med skjermoppløsning å gjøre, er det det du prøver å si? Tusenvis er fortsatt et tall litt i luften all den tid vi ikke har noe bekreftelse på dette, men min tillit til Simens hukommelse er veldig god, så jeg tok han på ordet.

 

Et slikt klesplagg vil gi deg et koblet system, vet du hvor krevende det kan være å parallellisere massivt?

6090279[/snapback]

Vel, mangelen på en demo sier nok sitt, men rykter har indikert at denne type problemer skal fungere bra med PhysX.

Hvilke rykter? Snakker vi om en anonym person på et forum, eller noe litt mer seriøst? Slike utsagn har minimal verdi for meg i denne sammenhengen.

 

Men hvordan skal man løse kollisjoner, da må jo nesten formen på hvert objekt være kjent, og det er en betydelig større mengde data (men som forsåvidt ikke trenger å bli sendt frem og tilbake). Er det noen som vet om det er Physx som skal ta seg av kollisjonsberegningen, eller er det CPU? Denne Physx saken har tross alt kun 128MB minne, så vi kan fort nærme oss en begrensning.

Kollisjonene er den tunge jobben (når de trengs). PhysX tar seg av de. Hvis ikke hadde et slikt kort bare vært brukbart for effekter som ikke trenger kollisjoner.

6091516[/snapback]

Nok en ubegrunnet påstand. Men jeg tror du har rett, og det gir noen ganske store utfordringer. Det enkleste er å løse kollisjoner mot et fast underlag, og det er kanskje kun det som gjøres nå, typisk uelastisk støt hvor vinkel på underlaget avgjør retningen den spretter opp i (tenk på billiardkuler). Hvis man skal ta hensyn til et ekte steinras, må man ta med kollisjoner mellom steiner, og hvis det virkelig er tusenvis av dem snakker vi om en del kollisjoner. Selv om dette er et svært begrenset problem, legger det likevel føringer på arkitekturen til Physx utover antall ALU'er de har smekket på. Er det noen som har tatt en nærmere titt på arkitekturen til Physx?

Endret av Del
Lenke til kommentar
  • 3 måneder senere...

Jeg har lest hele tråden...

Det om fysikk, Flight Simulator X har mye fysikk på fly, spesielt AI flyene, de har nok godt av den PhysX kortet, f.eks skyene, regn, rullebane, værsimulering osv.

 

Men teamet vil ikke bruke physx.

Tror dere det blir bedre hvis kvitter med CPU og kun bruke 4 pipeline på gpu av 24 på G7900 kortet ? high-end cpu'er yter jo bare 5-10 gflop, men skjermkort over 500 gflops.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...