AMD's RD790-chipset krijgt drie- en viervoudige Crossfire-support

AMD zal zijn verouderde 580x-chipset later dit jaar gaan vervangen door het RD790-platform. De chipset beschikt in totaal over 41 pci-express 2.0-lanes, zodat CrossFire met drie of vier videokaarten mogelijk wordt.

Eerdere geruchten over de RD790 gingen nog uit van 52 pci-express lanes. Hardwarefabrikanten kunnen met de 41 pci-express-kanalen bijvoorbeeld tot vier pci-e x16-sloten op een moederbord plaatsen, waarbij elk slot toegang krijgt tot acht lanes. De RD790-chipset heeft een tdp van 10W. AMD heeft ook zijn CrossFire-technologie verbeterd, waardoor de chipset overweg kan met maximaal vier ATi Radeon HD 2900 XT-kaarten. In tegenstelling tot nVidia's sli-oplossing kan CrossFire ook drie kaarten aansturen. Volgens de chipmaker kan een pc die is voorzien van twee ATi-kaarten, zijn snelheid met tachtig procent verhogen ten opzichte van configuraties met een enkele videokaart; met drie kaarten in CrossFire-opstelling zouden de prestaties met een factor 2,6 toenemen. AMD heeft geen cijfers vrijgegeven over configuraties met Quad CrossFire. De eerste moederborden met de RD790-chipset, voorzien van één of twee AM2+-sockets, zullen vermoedelijk uitkomen op het moment dat de eerste Phenom-chips op het toneel verschijnen. Insiders verwachten deze lancering op zijn vroegst in november.

Reacties (102)

[Andros]

Ben ik nou de enige die zich verbaast over het stroomverbruik van die chipset? nVidia's bordjes hebben kilo's aan koper om die nForce's een beetje koel te houden, zoals gewoonlijk gaat AMD het met een simpel alu blokje af kunnen als ie maar 10W gebruikt. nVidia, kijk de kunst eens af, zuinige chipsets zijn goed mogelijk...

[PKN]

Offtopic: wat is het probleem met grote voedingen dan..? noem eens 1 probleem? denk je dat ze die 1500watt opnemen ofzo? dat geven ze ook alleen maar af als je hardware daarom zou vragen, en dat doet het dus gewoonweg nooit.

(we hebben een tijdje terug een quadcore samengesteld met 24" flatscreen en X1900XTX + 5HDD's, totaal verbruik via de stabilisator was slechts 350watt voor het hele systeem, inclusief overclock)

Ten tweede zijn die voedingen bij een gelijke afname zuiniger dan een kleinere soortgenoot, het rendement ligt vaak hoger.

Ten derde geven ze een enorm hoog amperage over de 12v lijnen, en is het een prima toekomst perspectief voor verdere uitbreidingen (ze komen o.a met 4 powerconnectors voor grafische kaarten)

Vooral voor de grote jongens gaan dus.

[Soze]

Het probleem met grote voedingen is dat een voeding altijd minder efficient is bij lagere load. Het optimum van de efficiency wordt vaak pas bereikt bij hogere loads op de voeding, dus een grote voeding is relatief erg inefficient wanneer hij niet ten volle - of althans voor een redelijk percentage - belast wordt.

Zie b.v. pagina 8 van http://www.efficientpower...iciency_Testing_Intel.pdf

[Verwijderd]

Het rendement van een voeding meestal het beste wanneer je op 80% van maximaal vermogen zit. Een enorm zware voeding slecht licht belasten is i.h.a. juist een verschrikkelijk slecht idee wat betreft rendement.

[Verwijderd]

Het ligt er maar aan. De betere PC-voedingen kunnen vaak een efficiency van over de 80% halen bij een belasting van 30%-80%.
Aan 30% belasting zit je zomaar, zelfs bij een 1500w-voeding.
Kleinere voedingen zijn vaak over het geheel minder efficient, omdat ze ook goedkoper geproduceerd worden (uitzonderingen als EnerMax daargelaten).
Zie bv deze voeding: http://www.corsair.com/products/hx.aspx
Tussen 30% en 100% boven de 82% efficiency, met de hoogste efficiency rond de 50% belasting.
In dit geval is het dus het efficientst om een voeding te kopen die twee keer zoveel vermogen heeft als jouw PC gemiddeld verbruikt.

[Verwijderd]

Ik weet niet hoe jij "zomaar" aan 30% x 1500W = 450W komt, maar ik zit daar in idle (waar de meeste PC's het meest op draaien) toch ruim 350W onder.

[Verwijderd]

Ik weet niet hoe jij "zomaar" aan 30% x 1500W = 450W komt, maar ik zit daar in idle (waar de meeste PC's het meest op draaien) toch ruim 350W onder.

Ik heb toch nergens gezegd dat ik het over idle verbruik had?
Tsja, em zo'n 1500w-voeding koop je natuurlijk niet voor een simpel PCtje met 1 CPU, onboard graphics en 1 harddiskje ofzo. 'De meeste PCs' zijn dus ook niet van toepassing.
Ik ben dan ook benieuwd wat voor systeem jij hebt... als je idle nog niet eens aan de 100w zit. Vast niet het type systeem waarbij je uberhaupt na gaat denken over het aanschaffen van een voeding van meer dan 500w, laat staan 1500w.
Deze systemen hier hebben toch al flink wat meer nodig: http://www.pcper.com/arti...id=317&type=expert&pid=14
En dat zijn nog 'lichte' systemen (1 high-end CPU, 1 harddisk, en 1 high-end videokaart)... De chipset uit het nieuwsbericht biedt dus support voor 4 videokaarten, en dan klimt het idle-verbruik hard. Zeker als je ook nog eens voor twee quadcore-processors gaat ipv 1 (4x4?).

Desondanks, als we uitgaan van de grofweg 150w die deze systemen idle gebruiken, en dat als 30% nemen, dan komen we al op de 500w uit, vast meer dan je had ingeschat op basis van het maximumverbruik van zo'n 240-250w.
Zouden we de 80% op de 250w loslaten, dan komen we op 312w, en dat is wel erg krap, denk je niet? Ik heb zelf een nog lichter systeem (E6600 met GeForce 7600GT), en als ik voel hoe heet mijn Antec TruePower 550w (toch een kwaliteitsvoeding) al wordt, als ik een zwaar spel als FEAR speel, dan moet ik er niet aan denken om een voeding van 300-350w te gebruiken.

Wat ook heel belangrijk is, is beseffen dat het vermogen van een voeding het totaal is van de 3.3v, 5v en 12v-lijnen. Doorgaans worden de 3.3v en 5v niet zwaar belast. De CPU en videokaart (verreweg de zwaarste componenten in een systeem) worden via de 12v gevoed. Het vermogen op de 12v is dus bij een '500w'-voeding een stuk minder dan 500w (vooral bij goedkope voedingen wordt er vaak bezuinigd op 12v, en 3.3v en 5v ter compensatie heel hoog opgevoerd), terwijl het meeste van het verbruik van je PC *wel* van de 12v afhankelijk is.

Mijn TruePower van 550w is daarom ook een hele normale voeding voor een mid-end tot high-end game-systeem, en als je bv kijkt bij de specs van een GeForce 8800GTS of GTX-kaart, zie je ook dat meestal voedingen worden aangeraden van 500w of meer:
http://www.club3d.nl/index.php/download/pdf/CGNX_X8868.pdf
850w wordt aangeraden voor SLI (met 2 kaarten).
Het is dan niet zo vreemd om bij 3 of 4 kaarten een voeding in de categorie 1200-1500w te nemen, dat is niet eens zo veel overbodige luxe.

[masterant]

Owkeej, nou dat wilt nog wel eens wat beloven in gameprestaties, dan moeten ze er wel eerst voor zorgen dat drivers optimaal werken ...ennuh.. gaan ze nu dan ook 1500W+ crossfire-ready voedingen verkopen??

@ddbruijn: lol... dacht alleen 1000W te hebben gezien.. scherp

[Reactie gewijzigd door masterant op 25 juli 2024 00:28]

[Verwijderd]

Ja: http://www.thermaltake.co...oughPower/w0171/w0171.asp

[chrisO]

Dat soort voedingen zouden per wet verboden moeten zijn/worden complete energie verspilling.

[LCP]

Ik zou m'n elektronika kennis maar eens bijschaven Een voeding waarvan op de doos staat '1000 Watt' verbruikt per definitie geen 1000 Watt hoor. Een voeding levert stroom aan de componenten in een systeem. De voeding levert dus de hoeveelheid stroom die de componenten samen vragen. De voeding kan alleen maximaal 1000 Watt aan stroom leveren, wat betekend dat ie geschikt is voor monstersystemen (of systemen met een Intel Prescott mini-bakplaatje ) En die 1000 Watt is ook nog eens het secundaire maximale vermogen wat geleverd wordt. Het vermogen wat primair, dus uit je stopcontact getrokken wordt, is heel anders en dat is ook wat je wil weten. P = U x I

[Madrox]

Het klopt allemaal wat je zegt. Alleen is het natuurlijk wel zo dat diegene die zo'n 1000watter koopt, er ook wel het nodige "uit" gaat trekken. Anders koop je zo'n ding niet.

En ja, in een tijd van mileuvervuiling en het versnelt opwarmen van de aarde word het hoog tijd dat we, wij allemaal, eens goed gaan nadenken wat we aan het doen zijn.
Of zijn we nou werkelijk zo "oost-indisch doof" en/of blind ? Geven we zo weinig om de toekomst? Onze aarde, de kinderen ?

Zolang "ik" het maar goed heb, en alles kan doen wat ik maar wil, is het goed ?
Excuses zijn er genoeg te vinden, dat is makkelijk. Maar zeker niet verstandig.

[Maestro.mosjuh]

Ik ben het eens dat je zo wel erg veel stroom ge-/ver-bruikt, echter om het dan te verbieden vind ik ook zo wat(t). Immers, dan zou je dat ook kunnen doen bij andere producten; auto's bijvoorbeeld. Waarom een 1.8 liter toelaten, als je af kan met (in theorie) een 0.8 liter motor.

En waar leg je de grens?

[Verwijderd]

Je verbruikt niet meer dan wat je eraan hangt.
Verder gaat het om de efficientie van de voeding. Die is bij dit model juist uitzonderlijk hoog (tot 87%). Een 'gewone' voeding heeft het al moeilijk om de 80% te halen.
De kans is dus groot dat deze voeding in de meeste systemen minder energie zal verspillen dan de veel minder krachtige voeding die erin zit.

Net als bij auto's zegt de motorinhoud of het maximumvermogen ook weinig over het verbruik. Er bestaan krachtige motoren die heel zuinig zijn, en er bestaan kleine motoren met een hoog verbruik. Verder hangt het natuurlijk ook van de rijstijl af, en de rest van de auto (massa, aerodynamica etc).

[HKS-Skyline]

klopt, je verbruikt alleen wat er gevraagd word, en dus geen 1500 watt, daarnaast is het wel zo dat veel hoog vermogen voedingen wel een minimum vereisen voor ze werken.
maar het rendament is van geavanceerdere voedingen idd ook beter.
zodra een voeding zwaar word belast komt er veel warmte vrij, die warmte is ook energie, en die gaat in dat geval verloren, dus als de voeding minder warm word gaat er dus minder energie verloren, als er maar 500 van de 1500 word gevraagd zal de voeding niet enorm warm worden en dus een veel beter rendament hebben dan een 600 watt voeding.

en daarnaast, iemand die milieubewust wil gamen koopt een wii en geen dikke pc, simpel.....

[humbug]

Iemand die milieubewust wil gamen koopt "mens erger je niet".

[Verwijderd]

Ja maar laat je niet lekker maken door zulke verkoopverhalen.

Een efficientie tot 87% kan ook betekenen dat bij een belasting van maar 400W
(waarbij de weerstand en dus warmteproductie laag is en dus de efficientie hoog)
deze waarde gehaald word.

Tenslotte is het bij alle voedingen zo dat de efficientie bij volle belasting, in dit geval als de voeding 1500W levert, vaak het slechtst is. Zeggen en bewijzen ze nu dat bij een volle belasting dit 87% is dan kun je spreken van een hele goede voeding.

Voor zover we nu weten kan het best zijn dat bij een volledige belasting de efficientie maar 70% is wat een werkelijk gebruik oplevert van 2150W.

[Verwijderd]

Een efficientie tot 87% kan ook betekenen dat bij een belasting van maar 400W
(waarbij de weerstand en dus warmteproductie laag is en dus de efficientie hoog)
deze waarde gehaald word.

Statistisch gezien zijn de meeste PSUs het meest efficient in het bereik van 50-80% van hun vermogen.
Kwaliteitsvoedingen hebben bovendien weinig verloop (minder dan 10% tussen minimum en maximum).
Zie onder andere deze metingen op pagina 8: http://www.efficientpower...iciency_Testing_Intel.pdf

Tenslotte is het bij alle voedingen zo dat de efficientie bij volle belasting, in dit geval als de voeding 1500W levert, vaak het slechtst is.

Zowel bij volle belasting als bij heel weinig belasting is de efficientie slecht (vandaar dat ik 30-80% noem, daarin zijn goede voedingen efficent, doorgaans 80% en hoger, met deze voeding blijkbaar een piek van 87%). Maar zeker in het geval van een 1500w-voeding zal volle belasting bijna niet voorkomen. Het is aan de gebruiker om te zorgen dat hij een voeding koopt die nooit meer dan 80% belast wordt, om in het efficiente bereik van de voeding te blijven.

Voor zover we nu weten kan het best zijn dat bij een volledige belasting de efficientie maar 70% is wat een werkelijk gebruik oplevert van 2150W.

Dat is niet heel realistisch. Aangezien het een kwaliteitsvoeding is met een opgegeven piek-efficientie van 87% is het wel erg negatief om aan te nemen dat hij helemaal terugzakt naar 70% (en sowieso is het dom om een voeding volledig te belasten. Nooit verder gaan dan 80%... Niet alleen vanwege de efficientie op zich, maar ook vanwege de kans op overbelasting, en de sterk verkorte levensduur van de componenten). Statistisch gezien blijven kwaliteitsvoedingen tussen de 30 en 80% allemaal boven de 80% efficientie, sommigen komen zelfs niet onder de 83% (terwijl ze een piek van minder dan 87% hebben).
Daarom lijkt het me aannemelijk dat deze voeding ook een vergelijkbare karakteristiek heeft, en dus een redelijk vlak efficientieverloop heeft, in ieder geval binnen de grenzen van 30-80% belasting.

[Verwijderd]

Nog even en we moeten onze pc's op een aparte plon aansluiten, of via zo'n dikke kabel als een elektrisch fornuis... Pure waanzin als je het mij vraagt.

Maar verbieden vind ik eigenlijk ook ver gaan. In sommige - professionele - situaties kan ik mij voorstellen dat je een beest van een pc nodig hebt.

Daarom: leg er een accijns op! Doe dat op Europese schaal bijvoorbeeld, leg in eerste instantie vast wat een "normale" voeding is en wees daarin genereus. Men zou dat ook met auto's kunnen doen bijvoorbeeld, waarbij een motor ook wel ietsje meer hebben dan 1200cc.

Laat dit accijnzensysteem progressief toenemen.

En wie kan aantonen een geldige reden te hebben kan zijn accijns terugkrijgen. Er bestaat al een kanaal dat daarvoor geschikt is: de belastingsbrief. Als je bijvoorbeeld je pc toch al kan indragen wegens beroepskost, kan je bijvoorbeeld ook je accijns langs die weg (deels) in mindering brengen. Dat zou men kunnen laten variëren van het soort beroep dat je doet, en uiteraard weet de overheid dat.

Met de wagens geldt hetzelfde. Als iemand met 6 kinderen een negenzitter koopt (met zware motor) zal de overheid hen dat niet kwalijk nemen. De gezinssituatie is bij de overheid uiteraard ook bekend.

[Verwijderd]

dij accijncen bestaan al... dat heet belasting die je betaald op je afgenomen energie. zo heb je ook accijns op benzine

[j005t]

die voeding is net zoveel energie verspilling als een 500W voeding als je computer er maar 400W van verbruikt. De voeding is er niet de schuld van. Voornamelijk de cpu en videokaarten.

[Verwijderd]

Ik vraag me af waarvoor je dit nodig denkt te hebben, voor grafische pracht is dit echt totale overkill. Leuk dat je 200 fps haalt ipv 100 maar je ogen zien het verschil toch niet.

[Verwijderd]

vaak is het ook als buffer.

Soms heb je extreme FPS loss in spellen (als het ineens heel druk wordt etc.) dan kan een hogere basis FPS beter zijn.

Voorbeeld: 60FPS max op je huidige kaart
Heel druk stuk: 20FPS

Met 100FPS kan je dat dus makkelijk opvangen
100 - 40 = 60FPS dat merk je niet

[Rey Nemaattori]

Als je framerate halveert op een bepaald stuk, zal hij bij een 2x zo snelle kaart ook halveren...'t netto effect is dan 40 fps, da's tenminste nog speelbaar

[mjtdevries]

Die redenatie klinkt heel aannemelijk, maar in de praktijk blijkt het vaak niet zo te werken.

Ik heb spellen gezien waarbij een kaart 80fps max haalde en 30 fps min. Terwijl een concurerende kaart 100 fps max haalde en 15 fps min.

Het mag duidelijk zijn dat je dan beter de kaart kan hebben die minimaal 30fps haalt.
Echter laten veel benchmarks alleen gemiddeldes zien, waardoor je bij dat spel bij de verkeerde kaart uit zou komen.

[SRI]

Het kan ook van nut zijn met de opkomst van de GPU als secundaire rekeneenheid voor een computer. Het gebruik van GPU's in plaats van CPU's kan in een aantal gevallen zeer lonend zijn.

[leploep]

Soms is zelfs 100 fps niet genoeg.

How many frames per second can the human eye see?

http://www.100fps.com/how_many_frames_can_humans_see.htm

[Countess]

100FPS is eigenlijk altijd genoeg omdat je monitor er toch niet meer kan weergeven.

[mjtdevries]

Onbegrijpelijk dat je dat zegt, terwijl je verwijst naar een link die juist duidelijk maakt dat 100fps wel genoeg is.

De situaties waarin het niet genoeg is, hebben namelijk geen betrekking op beeldschermen en spellen. Lees die pagina zelf nog eens goed door!

[Heezy]

Hij reageert dan ook op dit...

Leuk dat je 200 fps haalt ipv 100 maar je ogen zien het verschil toch niet.

Beter lezen .

[Rey Nemaattori]

Tot je een spel tegen komt volgend jaar dat zo zwaar is dat je maar net 25 frames haalt..dan is het wel fijn dat je voor ruwweg 70% van de huidige nieuw prijzen je renderpresaties zowat kan verdubbelen, ipv een compleet nieuwe pc te moeten aanshaffen....

[Verwijderd]

En dan waarschijnlijk een dank u wel kaartje van de electriciteits boer erbij.

[poepkop]

Ok dan mag crossfire misschien wel veel gebruiken, maar de chipset verbruikt maar 10watt!
Ik vind het raar dat niemand daar wat over zegt... de 690 gebruikt ook al zo weinig met ook nog eens een igp erop! Ik wil eigenlijk niet weten wat mijn p35 slurpt

[PASware]

AMD/ATI staat er wel beetje om bekend dat hun chipset maar weinig energie verbruiken. nVidia verbruikt een heel stuk meer. De Intel chipset liggen er een beetje tussenin.

[Verwijderd]

Intel is al over NVIDIA gesprongen hoor.
zowel P35 als X38 gebruiken meer dan nividia's C55 & C55XE chipset

[Verwijderd]

en de 680i verbruikt nog meer

http://tweakers.net/ext/i/1173787853.png
(60 watt idle, 20watt load)

[Jut]

Precies dat mag zeker gezegd worden. Dat zie ik Intel of nVidia niet nadoen: 41 lanes op een chipie met een tdp van 10watt.

De vorige chip (RD580) verbruikte maar 7,5 watt in werkelijkheid. Als deze tdp ruim genomen is zal hij wss ongeveer hetzelfde slurpen.

Dit chipie kan af met een simpel koelblokje net zoals zijn voorganger. Hopelijk is ook deze chip in staat tot zeer hoge htt's.

[Fonzie27]

Wordt dit niet een beetje overkill? Ik bedoel, de huidige en teokomstige games zullen volgens mij bij lange na niet de volledige capaciteit benutten van alles. Daarnaast is natuurlijk ook het stroomverbruik, Nuon zal blij zijn hier. Mij lijkt het een betere optie om daar eerst eens naar te kijken alvorens weer nieuwere platforms te ontwikkelem die 4 videokaarten ondersteunen.

[Hieronymus]

Niet het volledige? Ik gok dat Crysis al het volledige van zo'n set-up zal vragen.

Het stroomverbruik tja, waar ik me meer zorgen om maak is de koeling! Zelfs met waterkoeling heb je dan al extreme onderdelen nodig om het zaakje koel te houden.

[SG]

Dat is voor 'n paar zieltjes op de wereld die graag op hun 30" TFT in native resolutie alles op high willen spelen.

Dus HDR vol
AA de meest exotische
AF 16x of de meest excotische optie daarvan.
end at met 'n minimum FPS van 60

En budged powerdraw boeid dan niet dit volk bestaat maar wel zeldzaam.
Hebben ook het geld ervoor.

[skelleniels]

Hmm, op mijn geforce 8800 gtx heb ik ook 2 SLI connectoren. Ik kan er toch ook 3 dan in SLI zetten of ben ik nu mis?

[Verwijderd]

volgens mij heeft SLI altijd een even getal aan kaarten nodig. Bij Ati werkt dat anders.

[HKS-Skyline]

De 2e SLI connector op de 8800 kaarten is om een 3e kaart aan te sluiten voor physics enz, helaas word dit nog niet ondersteund, maar dit was in ieder geval het idee achter de extra connector.

[Verwijderd]

Een hele kaart toewijden aan physics is bullshit. Ten eerste gebruikt physics zoveel rekenkracht niet. Ten tweede is een moderne grafische kaart perfect in staat om verschillende shaders tegelijk te draaien. Je wil dus de taken balanceren, en dat lukt met één of meerdere kaarten. Zeker geen nood aan SLI om physics op de GPU te laten draaien.

Maar er is nog een reden waarom het bullshit is. Multi-core CPU's zijn meer dan krachtig genoeg om physics te draaien. Bovendien heb je dan geen vertraging zoals bij de GPU waar alle data over de bus moet en terug.

Last but not least, alle spellen waar ik weet van heb die 'zware' physics zullen gebruiken doen alle berekeningen op de CPU. Dat is de enige logische keuze want men gaat z'n spel niet beperken tot de systemen met SLI of een PhysX kaart. Wil je toch hoge prestaties halen dan ben je dus beter af met een stevige multi-core CPU dan 'dedicated' physics hardware.

Da's zowiezo een slimmere investering aangezien je CPU nu eenmaal voor nog veel meer dingen instaat...

[Verwijderd]

Ten eerste gebruikt physics zoveel rekenkracht niet.

Dat ligt er maar aan hoeveel physics je wilt berekenen, nietwaar?
Momenteel kost het niet zo veel rekenkracht, omdat het nog toegespitst is op CPUs, die niet veel rekenkracht over hebben voor physics.
Ik zie een parallel met de overgang van software-rendering naar hardware-rendering.
De graphics waren lage resolutie en hadden weinig detail, en waren vaak weinig realistisch, omdat de CPUs niet beter konden. Maar toen de hardware het overnam, kwam de ontwikkeling van de graphics in een stroomversnelling, en het is nu ook niet denkbaar meer dat een moderne game met al z'n detail op een CPU gerenderd wordt.
De kans is groot dat ook physics deze sprong gaan maken zodra GPUs danwel PPUs dit mogelijk maken. De komende generatie (oa Crysis en UE3) geeft in ieder geval de indruk dat physics zich flink gaan ontwikkelen en veel meer deel worden van het spel.

Multi-core CPU's zijn meer dan krachtig genoeg om physics te draaien.

Wederom omdat de spellen dusdanig ontworpen zijn, PPU en physics op GPU staan immers nog in de kinderschoenen. De eerste spellen met 3d-acceleratie waren ook slechts aangepaste software-engines met de bijbehorende content.
Het verschil is dat de 3d-accelerators dingen als texture-filtering en hogere resoluties/framerates konden bieden, waar je physics vrij lastig op kunt schalen naar krachtiger hardware zonder de content aan te passen.

Da's zowiezo een slimmere investering aangezien je CPU nu eenmaal voor nog veel meer dingen instaat...

Dat argument ging ook op voor CPUs vs 3d-accelerators. Desondanks is de 3d-accelerator nu ingeburgerd, en zijn games niet meer zonder te spelen.
Ik zie dan ook wel de mogelijkheid dat er een 'hybride'-generatie van games komt, waarbij de CPU-routines minder gedetailleerde physics hebben dan een PPU/GPU-versie. En uiteindelijk zullen de CPU-routines compleet verdwijnen, als PPU/GPU-physics voldoende ingeburgerd zijn.
Het is dus aan de game-industrie om deze technologie te pushen. Ik denk wel dat dat gaat gebeuren, want HalfLife2 heeft toch wel een nieuwe trend gezet. Sindsdien zie je steeds realistischer physics in alle nieuwe spellen. Omgevingen worden steeds interactiever. Het lijkt haast onvermijdelijk dat de physics de CPU gaan ontgroeien, net zoals dit met graphics gebeurd is, nog niet al te lang geleden.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 00:28]

[Verwijderd]

Dat ligt er maar aan hoeveel physics je wilt berekenen, nietwaar?

Physics schaalt niet zoals graphics. Als je een scène hebt waarbij de speler tien kratten moet opeenstapelen dan ga je met tien keer meer rekenkracht daar niet plots honderd kratten plaatsen. Graphics is continu nodig, terwijl physics slechts periodiek aanwezig is. Meer rekenkracht voor graphics is dus steeds welkom, terwijl er voor physics een plafond is afhankelijk van wat er in de scène moet gebeuren.

De kans is groot dat ook physics deze sprong gaan maken zodra GPUs danwel PPUs dit mogelijk maken.

Een Core 2 Quad is even krachtig als een GeForce 8600 GTS qua GFLOPS, en krachtiger dan de PhysX P1. Zou stom zijn om die cores onbenut te laten en je GPU zwaarder te gaan belasten (twee maal, want meer physics zorgt vaak voor meer graphics).

Het lijkt haast onvermijdelijk dat de physics de CPU gaan ontgroeien...

Bijlange niet. Met multi-core CPU's schalen de prestaties minimaal even snel. Binnen twee à drie jaar zitten we al aan octa-cores op 4 GHz. Da's meer dan voldoende rekenkracht voor elk physics-effect dat je maar kan bedenken, waar de GPU nog kan volgen. GPU's en PPU's zitten nu ook vast aan de fysische wetten qua warmteproductie dus die gaan niet verder vooroplopen. CPU's zijn nog maar net begonnen met het parallisme uit te buiten, en gaan dus relatief eerder een inhaalbeweging maken.

Physics is serieus overhyped. Extra interactiviteit in spellen is heel leuk maar ik kan me niet voorstellen dat de physics in Crysis of Unreal 3 echt veel zwaarder zullen zijn dan die in Half-Life 2. Elke game-developer wil bovendien dat z'n spel vlot draait op een doorsnee systeem. En daar zie je al gauw dat de CPU relatief krachtig is tegenover de GPU in floating-point.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 00:28]

[SG]

@c0d1f1ed


Ten eerste Phsyics is meer dan kratten?
Zo'n dozijn aan Phsyics features kunnen gelijktijdig toegepast worden

Die kratten wat 'n 386 ook kan
Die deformable vaten
Destructable objecten kraten potten stoelen ramen
Dustructable structures muren gebouwen
Gedetaileerd vloeistoffen blood. gevulde vazen. etc aquariums die je kapot kan schieten
Kleding gordijnen tenten flaggen
interactieve volumetrische Rook
Ragdoll
Paricles, dust
Haar
Etc.

Dit alles kan elk feature van compleet weg laten tot 'n groffe methode to een heel fijn en of complexe methode allemaal gedaan worden om realisme van Phyiscs nog verder te verhogen tot in de fijnste detail.
Er worden in games 'n mix toegepast van 3 tot 10+ van die in gevarieerd detail en complexiteid. dus 7GFlops tot 500Gflops kan gebruikt worden.
Will je alles of een aanzienlijk deel of een kwart dan voldoet 'n CPU niet

Will je dit goed doen dan heb je PPU2 in SLI of zeker zo'n 500Gflop 8800Ulra dedicated voor Physics nodig. En dan nog kan er opgeschaald worden in detail en complexiteit.

'n Deel van 'n CPU kan alleen gebruikt worden dus als die dezelfde Gflops heeft als de PPU is de PPU nog steed 4x zo krachtig omdat die dedicated is en 'n CPU niet. dus 1 core van de vier. Die moet bijvoorbeeld ook AI doen die bij die features past

En uiteraard zorgt meer Physics ook belasting op andere fronten zoals meer te renderen objects of particles. meer debri waar AI ook rekening moet houden. AI belastend.

Physics kan de CPU ongroeien. PPU staat niet alleen het is een van de kampen die Hardware accelerated Physics bied het andere kamp. HavokFX met nV en ATI bieden dus ook 'n breede solution voor hardware accelerated Physics.

Games kunnen dus 'n 2+1 oplossing ondersteunen dat is
1Tflop voor rendering en 'n half Tera Flops voor Phsyics.
Al zal dit 500Gflops voor effects Physics door toepassing van HavokFX en gameplay Physics Havok Hydracore kan dan de Mulitcore daarvoor gebruiken.
PPU is dan 'n middel solutie gelijk waardig aan 'n midrange GPU maar Gameplay en effect is niet appart PPU SDK PhhysX ondersteund dat openlijk integraal.

Games dev's hebben dus de optie om heel veel Phsycis toe te passen en dat kan want Phsyics is ook een heel ver schalende task naar 'n foto realistische game world die ook realistisch gedraagd ipv statisch. en dit dan ook op hoog detail

ALs je de laaste CPU pakt 50Gflops en de laaste top GPU half Tera flops.
zie je dat HAdrware accelerated Physics 10voud bied wat ook nog eens dedicated kan zijn. Waarbij CPU dus met maar 1/10 deel dit ook nog moet splitsen over alle task.
Kan dus 'n 40x schelen.

nV bied met HAvokFX dus de optie om 'n deel van de shaders van één kaart voor Phsyics te gebruiken. als één 8800Ultra/GTX/2900XT ongeveer 500Gflops bied dan zal 'n kwart van zijn shaders nog altijd de CPU overtreffen en zelf met 3/4 deel nog sub high-end performance bieden.

Uiteraard kan er ook gekozen worden voor 'n 8600GT of PPU dedicated voor respectievelijk HavokFX en PhysX games.

Physics is niet overhyped het is wat de dev's ervan gaan maken.
De een kiest CPU is dus gelimiteerd aan 'n limiet wat 'n deeltje is van +/- 50Glops wat een topmodel bied.
De ander kiest 'n leuk middleware SDK die PPU support en heeft dus de optie om Physics op te schalen door gebruikt te maken van de GFlops die de PPU bied. Heeft dus CPU en PPU Gflops beschikbaar. andere kiest voor ander middleware module die GPU ondersteund HavokFX dus.

Dan is natuurlijk van belang dat dev's al dat Phsycis geweld ook meerwaarde bied in een game. iig zal het veel gebruikt worden als eyecandy effectPhsyics.

Foldinghome laat zien dat GPU de CPU al wegblaasd.
Shader based Video encoding ook.

PPU laat ook zien dat het krachtiger is dan CPU. Uiteraard komt er ook 'n nieuwe generatie of refresh van PPU produkten.

[Reactie gewijzigd door SG op 25 juli 2024 00:28]

[Verwijderd]

Ten eerste Phsyics is meer dan kratten?

Heb ik iets anders gezegd? Je mist m'n punt. Physics schaalt niet zoals graphics.

Die deformable vaten
Destructable objecten kraten potten stoelen ramen
Dustructable structures muren gebouwen

Wat ga je doen met extra rekenkracht? Meer vaten, kraten, potten, stoelen, ramen? Neen da's gameplay-gebonden. Meer polygonen/splinters dan? Goed, maar daarmee belast je ook de graphics verder. Dus terwijl je GPU staat te zweten heeft je multi-core CPU niks te doen... Beter dus de CPU de physics laten doen en de GPU waar hij best in is.

Gedetaileerd vloeistoffen blood. gevulde vazen. etc aquariums die je kapot kan schieten
Kleding gordijnen tenten flaggen
interactieve volumetrische Rook
Ragdoll
Paricles, dust
Haar

Veel van die dingen bestaan uit kleine, afhankelijke berekeningen. De GPU heeft juist graag grote, onafhankelijke berekeningen. Hoewel de CPU dus vaak minder brute rekenkracht heeft is hij veel beter geschikt voor complexe berekeningen. En ook hier kan je het niet zomaar laten schalen. Je zit vast aan een bepaalde hoeveelheid stoffen, ragdolls, particles.

Will je dit goed doen dan heb je PPU2 in SLI of zeker zo'n 500Gflop 8800Ulra dedicated voor Physics nodig.

Oh ik twijfel er niet aan dat een imbeciele programmeur 500 GFLOPS kan verbranden. Da's geen kunst. Maar wil je echt een spel dat op 0,1% van alle gamersystemen kan draaien?

Ik heb het hier over praktische games. En daar is het meest realistische scenario dat de physics op de CPU uitgevoerd worden, zowel in de nabije als de verre toekomst. Superrealistische physics is trouwens geen must. Vloestoffen die zich lijken te gedragen als vloeistoffen, stoffen die zich lijken te gedragen als stoffen, haar dat zich lijkt te gedragen als haar, etc. is meer dan voldoende. En dat vergt echt niet zoveel rekenkracht. De speler merkt er al gauw niks meer van als je het precieser maakt of meer detail geeft.

ALs je de laaste CPU pakt 50Gflops en de laaste top GPU half Tera flops.
zie je dat HAdrware accelerated Physics 10voud bied wat ook nog eens dedicated kan zijn.

Een Core 2 Quad 3 GHz haalt 96 GFLOPS. Zou zonde zijn die niet te gebruiken en je graphics een vijfde trager te maken (extra werk voor de graphics niet meegerekend). Soit, je mag niet zomaar die getallen vergelijken. Zoals ik al eerder zei kan een GPU niet overweg met kleine taken met veel afhankelijkheden. Kijk ook even naar het matige (of onbestaande) succes dat GPGPU-toepassingen hebben met complexere taken die moeilijk parallelliseren. Voorbeeldje: een handgeschreven routine voor Gaussiaanse blur die gebruik maakt van SSE draait sneller op mijn Core 2 Duo dan op mijn GeForce 8800. Op de CPU is het geen probleem om een FIR-filter te implementeren (met afhankelijkheden tussen de samples), op de GPU moet je meerdere malen dezelfde samples nemen. En dit is een grafische taak waar de GPU verliest van de CPU! Voor physics zijn hun beperkingen nog zwaarder.

Foldinghome laat zien dat GPU de CPU al wegblaasd.

Da's dan ook extreem parallelliseerbaar. Zodanig zelfs dat het gedistribueerd berekend wordt... Game physics is heel wat anders en kan je daar onmogelijk mee vergelijken (tenzij een spel om moleculen te vouwen dan).

PPU laat ook zien dat het krachtiger is dan CPU.

Waar? Kan je me een benchmark tonen die niet van AGEIA komt?

[Verwijderd]

Goed, maar daarmee belast je ook de graphics verder. Dus terwijl je GPU staat te zweten heeft je multi-core CPU niks te doen...

Hieraan kloppen 2 dingen niet:
1) Het detail van de physics hoeft niet gelijk te zijn aan het detail van rendering.
Momenteel is de physics-geometrie vaak minder gedetailleerd dan de graphics.
In de toekomst zou dit ook omgekeerd kunnen zijn (denk bv aan objecten die in de verte staan... de physics moeten wel 100% kloppen, maar de grafische representatie kan versimpeld).

2) De top-GPUs zijn momenteel 'te snel' voor de processors, in de meeste gevallen. Er is een hoop kracht over, zeker voor geometrie, met de nieuwe unified shaders.
De trend van de laatste jaren is dat GPUs sneller doorontwikkelen dan CPUs, waardoor de huidige situatie ontstaan is. Er is geen reden om aan te nemen dat deze trend niet doorzet in de nabije toekomst. DX10 maakt het renderen van vele objecten ook nog eens een stuk efficienter, waardoor de GPU nog een sprong vooruit maakt.

[Verwijderd]

Het detail van de physics hoeft niet gelijk te zijn aan het detail van rendering.
Momenteel is de physics-geometrie vaak minder gedetailleerd dan de graphics.
In de toekomst zou dit ook omgekeerd kunnen zijn...

Maakt niet uit of het gelijkloopt met de graphics of niet, je wil het niet op inefficiënte wijze door de GPU laten verwerken als je cores op je CPU hebt die het wel efficiënt kunnen en anders niks of weinig te doen hebben.

DX10 maakt het renderen van vele objecten ook nog eens een stuk efficienter, waardoor de GPU nog een sprong vooruit maakt.

Direct3D 10 ontlast de CPU waardoor meer rekenkracht ter beschikking komt voor de applicatie in plaats van dat een groot deel door de driver opgeslokt wordt. Geen sprong voorwaarts voor de GPU dus maar voor de CPU.

[Verwijderd]

Maakt niet uit of het gelijkloopt met de graphics of niet, je wil het niet op inefficiënte wijze door de GPU laten verwerken als je cores op je CPU hebt die het wel efficiënt kunnen en anders niks of weinig te doen hebben.

Dat ligt er maar net aan.
Soms is een inefficiente oplossing toch sneller omdat je er veel meer processorkracht tegenaan kunt gooien.
Zo ook met de GPU-based skinning en shadowvolumes. De oplossing is niet heel efficient, maar toch een stuk sneller dan een CPU (die wel met een efficiente oplossing werkt).
Je denkt dus te simpel.

Direct3D 10 ontlast de CPU waardoor meer rekenkracht ter beschikking komt voor de applicatie in plaats van dat een groot deel door de driver opgeslokt wordt. Geen sprong voorwaarts voor de GPU dus maar voor de CPU.

Nee, dat is niet zo. De rekenkracht werd beperkt door de scenes simpel te houden, en het aantal calls te minimaliseren, en de workload in die calls te maximaliseren.
De CPU was dus al ontlast. Je kunt nu bij dezelfde belasting alleen meer doen. Je kunt echter niet de CPU nog significant verder ontlasten (zie je ook bij de huidige DX9-spellen die naar DX10 zijn overgezet. Ze zijn niet of nauwelijks sneller omdat ze gewoon niet de situaties uitbuiten waar DX10 beter in is dan DX9).

[Verwijderd]

Soms is een inefficiente oplossing toch sneller omdat je er veel meer processorkracht tegenaan kunt gooien.
Zo ook met de GPU-based skinning en shadowvolumes.

De GPU is reeds voltijds bezig met graphics, terwijl de cores van de CPU geheel of voor het grootste deel vrij zijn. Je analyse van skinning en shadow volumes is leuk maar je noemde enkel single-core CPU's. Daar waar je op een single-core misschien 25% rekenkracht beschikbaar hebt voor physics/skinning/shadow heb je met dual-core plots 100% daarvoor. En het betert nog in de toekomst met op z'n minst quad-core en octa-core.

[Verwijderd]

Je analyse van skinning en shadow volumes is leuk maar je noemde enkel single-core CPU's.

Er was niets anders destijds.
We zijn allebei op de hoogte van Amdahl's law, dus we verwachten geen wonderen van een paar cores meer, toch?

Daar waar je op een single-core misschien 25% rekenkracht beschikbaar hebt voor physics/skinning/shadow heb je met dual-core plots 100% daarvoor.

Het was een testcase waar verder niets gedaan werd in de applicatie. Het was dus skinnen en renderen. In totaal had je een stuk of 10 rendercalls voor de hele scene misschien, en de scene was in een klein windowtje, dus niet fillrate-limited). De CPU kon dus voor bijna 100% aan de skinning en shadowvolumes rekenen.
Helaas pindakaas dus.

Je kunt er wel meer cores tegenaan smijten, maar dat zou nergens op slaan.
Waarom zou je een hele dualcore of quadcore op gaan branden aan skinning+shadowvolumes als de GPU het al net zo snel, of zelfs sneller kan (zonder daarbij dus in te boeten aan rendersnelheid, want het gaat gewoon 'on the fly'. De extra processing wordt min of meer gecamoufleerd door de overhead van de rest van de triangle setup etc)?
Die CPU heeft ook nog zat andere dingen te doen, en itt de GPU gaat het bij de CPU ten koste van andere dingen.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 00:28]

[Verwijderd]

We zijn allebei op de hoogte van Amdahl's law, dus we verwachten geen wonderen van een paar cores meer, toch?

Dus een PPU met acht cores vind je fantastisch maar een CPU met vier cores wordt neergeslagen door Amdahl's law?

[Verwijderd]

Physics schaalt niet zoals graphics.

Zoals SG ook al uitlegt, je hebt echt een totaal gebrek aan visie. Jij ziet alleen de physics zoals ze nu zijn (of eigenlijk, zoals ze een paar jaar geleden waren, Crysis en UE laten al heel wat destructable/deformable spul zien, wat aanzienlijk meer rekenkracht vergt dan een paar kratjes).

Graphics is continu nodig, terwijl physics slechts periodiek aanwezig is. Meer rekenkracht voor graphics is dus steeds welkom, terwijl er voor physics een plafond is afhankelijk van wat er in de scène moet gebeuren.

In de echte wereld zijn physics continu nodig. In een zo realistisch mogelijk spel ook. Als ik in de echte wereld ga schieten, dan kan praktisch alles kapot of in ieder geval beschadigd en gedeformeerd raken.

Een Core 2 Quad is even krachtig als een GeForce 6800 GTS qua GFLOPS, en krachtiger dan de PhysX P1. Zou stom zijn om die cores onbenut te laten en je GPU zwaarder te gaan belasten (twee maal, want meer physics zorgt vaak voor meer graphics).

Dit is appels en peren vergelijken. Gflops zeggen absoluut niets over de toepassing, die bij alle drie de typen processors compleet anders zijn.
Dedicated processors hebben vaak relatief weinig rauwe processorkracht vergeleken bij een CPU, maar ze zijn toch veel sneller, omdat ze geoptimaliseerd zijn voor de taak die ze moeten doen. Veel efficienter dus.

Afgezien daarvan zijn er genoeg dingen naast physics te bedenken waar je die cores mee bezig kunt houden.
Je redeneert gewoon compleet achterstevoren. Wat je zou moeten doen is denken "Hoe kan ik iedere taak zo efficient mogelijk uitvoeren, zodat ik zo veel mogelijk detail in het spel kan inbouwen?". En niet "Hoe kan ik zo veel mogelijk op m'n CPU doen", zoals jij kennelijk denkt.

Bijlange niet. Met multi-core CPU's schalen de prestaties minimaal even snel. Binnen twee à drie jaar zitten we al aan octa-cores op 4 GHz.

Nee, want CPUs zijn niet de ideale architectuur voor physics-processing. Het schalen gaat dus vele malen langzamer dan met dedicated processors... zoals we bv ook hebben gezien met graphics. De huidige CPUs kunnen net in software renderen wat de videokaarten van bijna 10 jaar geleden al in hardware konden. En de huidige GPUs worden misschien pas over 20 of 30 jaar bijgehaald door de CPU.
Software-rendering schaalt namelijk bijzonder slecht over CPUs omdat voornamelijk het geheugen de bottleneck is. Het geheugen schaalt veel minder snel op dan de rest van de CPU (zeker met die multicore-fratsen, waar je ineens 4 cores zet op een memory-controller waar eerst 1 core op zat).
Bij physics heb je veel afhankelijkheden van data (veel scatter/gather operaties). De PPU is ongeveer ontworpen als een packet-switching systeem, zoals bv een netwerkrouter ook is.
Een CPU is veel zwakker in dit soort bewerkingen (moet je maar kijken wat voor CPU je nodig hebt om een gigabit-netwerkje softwarematig te routeren, en wat een eenvoudig goedkoop processortje een hardware-router heeft).

GPU's en PPU's zitten nu ook vast aan de fysische wetten qua warmteproductie dus die gaan niet verder vooroplopen.

GPUs lopen zelfs nog achter op de technologie van CPUs (90 nm, waar Intel al bijna op de 45 nm zit), maar toch zijn de Tesla-kaarten van nVidia absoluut niet te benaderen met een paar quadcores als het gaat om bv het doorrekenen van lineaire stelsels.
Over PPUs nog maar te zwijgen... Deze wordt nog op 130 nm gemaakt, en bevat slechts 125m transistors. GPUs en vooral PPUs hebben dus nog wat goed te maken op de CPUs.

GPUs hebben zich vooral ontwikkeld omdat de architectuur steeds beter werd. CPUs hebben deze ontwikkeling al in de jaren 70 en 80 doorgemaakt, en de laatste 20 jaar is er eigenlijk weinig spectaculairs geweest in de ontwikkeling van de CPU-architectuur. Zeker in het x86-kamp... Itanium en Crusoe maakten dan nog uitstapjes naar EPIC/VLIW, maar ook dat mocht niet heel veel baten tot dusverre.
Intussen zijn GPUs gigantisch doorgegroeid, iedere twee jaar een compleet nieuwe generatie die vele malen krachtiger was dan zijn voorganger. Bij CPUs is dit absoluut niet het geval. Zeker met de huidige trend van multicore, want multithreading schaalt sowieso al niet zo heel denderend voor de meeste applicaties... en een hoop applicaties zijn sowieso nog niet multithreaded, dus een single-core is net zo snel als een quadcore. De efficientie van CPUs ligt gewoon veel te laag, en gaat steeds lager komen te liggen naarmate er meer cores toegevoegd worden. Ik denk eerder dat de ontwikkeling trager zal gaan dan voorheen, toen men vooral probeerde de kloksnelheid zo hoog mogelijk te maken. Nu zal men de cores simpeler moeten houden om er maar meer op 1 CPU te kunnen zetten.
Ik denk ook niet dat je die kant op moet willen met CPUs. Naarmate je parallelisme belangrijker maakt, zul je meer toegeven op de seriele performance (zie ook de Cell, die voor het draaien van een OS als linux gewoon erg traag is). Het lijkt mij beter om te blijven focussen op de seriele performance (zoals Intel ook doet), en het 'overschot' aan transistors vanwege de moderne productietechnologie om te zetten in meer cores. Maar het maximaliseren van het aantal cores moet nooit het uitgangspunt worden. Ik zie dat op m'n werk al met een Sun systeem. Daarin zitten quadcore-processors met SMT-support. Ze zijn ideaal voor parallele taken zoals webservers/databases met veel onafhankelijke requests tegelijkertijd. Maar voor het compileren van code zijn ze juist weer erg zwak.
Als je geen CPUs meer hebt die snel code kunnen compileren, wat moet je dan?

Extra interactiviteit in spellen is heel leuk maar ik kan me niet voorstellen dat de physics in Crysis of Unreal 3 echt veel zwaarder zullen zijn dan die in Half-Life 2.

Nou, ik wel.

Elke game-developer wil bovendien dat z'n spel vlot draait op een doorsnee systeem. En daar zie je al gauw dat de CPU relatief krachtig is tegenover de GPU in floating-point.

Niet bepaald. De CPU is bijzonder zwak in veel floating-point berekeningen. Zo kun je bv skinning en shadowvolumes vele malen sneller doen op de GPU dan op de CPU.
Wat ontwikkelaars doen met graphics is gewoon meerdere detail-levels maken. Zo kan het ook op simpelere GPUs en CPUs draaien. Ik zie niet in waarom dit niet met physics kan. Mensen met een krachtiger systeem kunnen dan bv wel allerlei objecten beschadigen/deformeren, waar de tragere systemen alleen de objecten kunnen laten botsen. Ik noem maar wat, zie verder ook de post van SG voor nog meer voorbeelden.
Natuurlijk moet je altijd uitkijken dat het detail de spelbeleving niet (te veel) verandert... Ik kan me Test Drive 3 nog herinneren... Op laag detail werden er geen bomen langs de weg getekend. Dit betekende dat je veel minder kans op ongelukken had als je van de weg raakte... Je kon ook op veel plekken stukken afsnijden, en zo tijden realiseren die op hoger detail onmogelijk waren.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 00:28]

[Verwijderd]

Crysis en UE laten al heel wat destructable/deformable spul zien, wat aanzienlijk meer rekenkracht vergt dan een paar kratjes.

Een paar blaadjes van de bomen schieten of een deuk in een wagen slaan kost echt geen GFLOPS hoor.

In de echte wereld zijn physics continu nodig. In een zo realistisch mogelijk spel ook. Als ik in de echte wereld ga schieten, dan kan praktisch alles kapot of in ieder geval beschadigd en gedeformeerd raken.

Alleen een idoot doet fysische berekeningen wanneer ze niet nodig zijn. Als ik in een lege kamer sta en ik schiet niet hoeft er niks fysisch berekend te worden, graphics vullen echter continu je scherm. Eens je de nodige fysische effecten hebt is het afgelopen, meer grafische rekenkracht kan echter steeds -nuttig- aangewend worden.

Gflops zeggen absoluut niets over de toepassing, die bij alle drie de typen processors compleet anders zijn.

Daarom ook dat een GPU niet ideaal is voor physics. Anderzijds is een CPU er perfect voor uitgerust. Vectorinstructies, check. Random geheugentoegang, check. Efficiënte controlestructuren, check. Ontbreekt er iets? En voor de zoveelste keer: een GPU is zo goed in graphics omdat hij texture sampling units heeft en dergelijke terwijl een CPU dit niet heeft. Er is echter niks dat een PPU heeft dat hem beter maakt in physics dan een CPU.

Wat je zou moeten doen is denken "Hoe kan ik iedere taak zo efficient mogelijk uitvoeren, zodat ik zo veel mogelijk detail in het spel kan inbouwen?". En niet "Hoe kan ik zo veel mogelijk op m'n CPU doen", zoals jij kennelijk denkt.

Helemaal niet. Ik kijk naar de beschikbare rekenkracht van het gemiddelde systeem in de nabije toekomst en dan zie ik een multi-core CPU die zeer geschikt is voor fysische berekeningen en niet zoveel anders te doen heeft, en een mid-end GPU die al last heeft met de graphics en die we dus niet gaan storen door er op onefficiente wijze physics op uit te rekenen. Zo zijn CPU en GPU goed gebruikt en goed geïnvesteerd. Geld voor een PPU heeft 99% van de gamers niet en zou toch maar voor 1% van z'n tijd effectief de CPU ontlasten. Stomste investering ooit dus.

Het schalen gaat dus vele malen langzamer dan met dedicated processors... zoals we bv ook hebben gezien met graphics.

Nonsense. GPU's schaalden sneller doordat een toename van het transistorbudget in de eerste plaats gebruikt werd voor extra parallellisme, terwijl voor de CPU dit naar het ondersteunen van hogere kloksnelheden ging. Met multi-core CPU's gebruikt men echter ook een verdubbeling van het aantal transistors voor een verdubbeling van het parallellisme. Beter zelfs, Intel heeft CPU's in de planning die de cores vereenvoudigd om er meer op een chip te krijgen. En hun Tera-Scale experimenten tonen reeds aan dat ze geen moeite hebben om met de technologie van vandaag een TFLOP te halen. Hoewel het nog even duurt eer dat praktische resultaten zal opleveren in de vorm van commerciële CPU's is het meer dan duidelijk dat CPU's een inhaalbeweging maken qua perf/watt en perf/area en GPU's het daar juist lastig mee krijgen.

Software-rendering schaalt namelijk bijzonder slecht over CPUs omdat voornamelijk het geheugen de bottleneck is.

Merk ik niks van. Een 16-bit frame buffer of depth buffer is trager dan 32-bit omdat het extra instructies vergt voor de 'compressie'. Ik zit dus nog steeds gelimiteerd door de rekenkracht.

Het geheugen schaalt veel minder snel op dan de rest van de CPU...

RAM wel ja. Maar de cache schaalt zeer goed mee. Met enkele megabytes L2 kan je héél wat data verwerken voor je terug naar RAM moet. Als je goede tijdelijke en temporele localiteit nastreeft is geheugenbandbreedte echt geen probleem. Laat je inspireren door tile-based rendering. Maar we wijken af...

GPUs lopen zelfs nog achter op de technologie van CPUs... Over PPUs nog maar te zwijgen...

En dat zal altijd zo blijven. Wanneer AGEIA het kapitaal bijeen heeft voor de productie van een 65 nm chip zit Intel aan 32 nm en 8 cores. Jammer voor hen maar het is nu eenmaal de werkelijkheid. Een game-developer kan dus maar beter z'n physics op de CPU afstemmen in plaats van te wachten op een doorbraak van PPU's die er nooit komt.

Ik denk ook niet dat je die kant op moet willen met CPUs. Naarmate je parallelisme belangrijker maakt, zul je meer toegeven op de seriele performance...

Toegeven op de seriële snelheid zal men niet doen, maar ik zie het wel een beetje stagneren. Dat is niet zo erg, want minder parallelle software is doorgaans ook minder rekenintensief (je zal niet rap een quad-core nodig hebben voor bijvoorbeeld Word, terwijl bijvoorbeeld een videocodec zowel rekenintensief als parallelliseerbaar is). Men verhoogd dus de rekenkracht daar waar ze het meest nodig is.

Anderzijds is er nog een grote ommezwaai nodig in de manier van programmeren. We zijn het doorgaans zo gewoon om serieel te programmeren dat multithreading voor velen grote verwarring en frustratie veroorzaakt. Maar eerst zullen de game-studios's er goed gebruik van leren maken, en dan volgt de applicatie-ontwikkeling wanneer er meer tools voorhanden zijn en vooral de opleiding verbetert. Een kwestie van tijd, en geen reden om de multi-core revolutie tegen te houden. Je hebt zowiezo eerst de hardware nodig voor de software kan volgen... Ik zie geen reden waarom men niet tot honderd cores en duizend threads zou gaan. Alle software bevat zeer veel parallellisme, en met de geschikte tools en nieuwe programmeertalen (denk HDL of Oz) kan men dat eruithalen. Da's nog niet voor morgen uiteraard, maar is de enige manier om de prestaties van CPU's verder te schalen. En ergens halverwege die evolutie moet AGEIA beslist de boeken sluiten of zich concenteren op softwarematige physics.

Het lijkt mij beter om te blijven focussen op de seriele performance...

Hoe dan wel? De klokfrequentie schaalt maar zeer traag en de complexiteit neemt kwadratisch toe met de IPC (versus lineair wanneer men multi-core gaat).

Als je geen CPUs meer hebt die snel code kunnen compileren, wat moet je dan?

Is je compiler multi-threaded? Compileren is vrij goed te parallelliseren (bestand per bestand of functie per functie). Zal niet te lang duren eer dat sneller is dan op een single-core met gelijk aantal transistors.

De CPU is bijzonder zwak in veel floating-point berekeningen. Zo kun je bv skinning en shadowvolumes vele malen sneller doen op de GPU dan op de CPU.

Tja, ik zie maar al te vaak op forums mensen klagen over hoe traag hun skinning of shadow volumes zijn op de CPU, en dan schrijven ze liever een shader dan SSE code. "Want assembler is moeilijk en gevaarlijk". Trouwens, Doom 3 gebruikt CPU skinning en shadow volumes (mét SSE).

Bovendien neemt dit op een single-core zowiezo een hap uit je FPS indien je reeds CPU-bound bent, terwijl op een multi-core er maar al te vaak een core niks staat te doen. Als je het wél multi-threaded doet is er rekenkracht te over (ettelijke miljoenen vertices/polygonen) en belast je de GPU niet met een bijkomende taak. Misschien dat je met een GeForce 8800 nog steeds CPU-limited bent maar een mid-end kaartje heeft echt wel z'n grenzen. Een Core 2 Duo heeft al gauw half zoveel GFLOPS als een GeForce 8600 GTS. "Bijzonder zwak" zou ik dit dus niet noemen, en het zou dus dom zijn om dat relatief klein aantal vertices/polygonen niet op de CPU te laten verwerken en de GPU zich te laten concentreren op de pixels.

'k Heb hier trouwens een laptop met Radeon X1300 waar software vertex processing meer dan dubbel zo snel is dan hardware. Ok da's een relatief zwakke GPU maar een heilig geloof in dedicated hardware zou voor problemen zorgen. De CPU kan dus ook best wat werk verzetten. Het is trouwens op dit soort systemen (en laptops worden steeds populairder) dat deze keuzes het verschil maakt tussen speelbaar of niet. Dat de physics nog net iets sneller hadden gekunnen op de GeForce 8800 interesseert 95% van de gamers niks. Een developer moet vooral de juiste keuzes maken zodat het ook goed loopt op die 95% andere systemen. En dan is physics op de CPU een heel logische keuze, waar je nog steeds bijzonder knappe dingen mee kan vertonen.

[Verwijderd]

Crysis en UE laten al heel wat destructable/deformable spul zien, wat aanzienlijk meer rekenkracht vergt dan een paar kratjes.
Een paar blaadjes van de bomen schieten of een deuk in een wagen slaan kost echt geen GFLOPS hoor.

Tsja, als jij dom blijft zeuren over gflops terwijl al meerdere keren is uitgelegd dat het om andere dingen gaat dan alleen rauwe rekenkracht...
Je spreekt ook jezelf hiermee tegen.

Alleen een idoot doet fysische berekeningen wanneer ze niet nodig zijn. Als ik in een lege kamer sta en ik schiet niet hoeft er niks fysisch berekend te worden,

En als je dan naar een volle kamer gaat waar je alles kapot gaat schieten?
Dan moet je toch ineens die physics kunnen berekenen. Ook bij graphics is niet iedere kamer even zwaar, maat het gaat vooral om de minimum framerates. Zo zijn spellen vaak lastig te spelen als er rook-effecten gebruikt worden.
Met physics hetzelfde... als je bv in een huis staat dat ineens instort wil je natuurlijk niet dat je nog maar 3 frames per minuut te zien krijgt.
Die rook-effecten kunnen trouwens ook veel realistischer gemaakt worden als physics in acht genomen worden. Dan kunnen rook en vuur ook echt om objecten heen gaan, en gevoelig worden voor luchtverplaatsing etc.

Daarom ook dat een GPU niet ideaal is voor physics.

Inderdaad, ik zou zelfs beweren dat een GPU er uitermate ongeschikt voor is. Maar de pure kracht van de huidige GPUs en het feit dat ze de CPU ontlasten, maken dat enigszins goed. Ik vind de PPU echter een verreweg superieure oplossing.

Anderzijds is een CPU er perfect voor uitgerust. Vectorinstructies, check. Random geheugentoegang, check. Efficiënte controlestructuren, check. Ontbreekt er iets? En voor de zoveelste keer: een GPU is zo goed in graphics omdat hij texture sampling units heeft en dergelijke terwijl een CPU dit niet heeft. Er is echter niks dat een PPU heeft dat hem beter maakt in physics dan een CPU.

Ja, er ontbreekt iets. Maar je leest mijn posts kennelijk niet.
Maar blijf maar volhouden hoor. Als je het maar vaak genoeg herhaalt, wordt het misschien nog eens waar.

Geld voor een PPU heeft 99% van de gamers niet en zou toch maar voor 1% van z'n tijd effectief de CPU ontlasten. Stomste investering ooit dus.

Zo werkt de game-wereld niet.
Games maken altijd al vroeg gebruik van de nieuwste hardware. Jouw argument is complete onzin. Binnen een paar maanden na de introductie van een nieuwe generatie hardware, zijn er al spellen die er gebruik van maken (bv SSE, hardware T&L, DX8/DX9/DX10). Dit terwijl er op dat moment ook maar heel weinig mensen zijn die daadwerkelijk die hardware in huis hebben.
Omdat ze meerdere detailniveaus ondersteunen, en meerdere codepaden kunnen gebruiken, kunnen ze dit doen zonder de anderen te duperen.
Maar het gemiddelde spel op maximaal detailniveau heeft gewoon absolute top-hardware nodig, en dat is niet de hardware waar de gemiddelde gamer op speelt.
PhysX past prima in dit plaatje, en kan voor een push zorgen, net zoals de andere technologie ook oa door games gepusht is. Als gamers zich bewust worden van de extra features die een PhysX-kaart levert in hun spellen, zullen ze eerder een PhysX-kaart kopen. Net zoals de eerste Voodoo-kaarten zeer succesvol waren met de eerste paar 3d-spellen, ook al kon je die spellen op een snelle CPU net zo goed spelen. Het was alleen wat minder mooi.

Nonsense. GPU's schaalden sneller doordat een toename van het transistorbudget in de eerste plaats gebruikt werd voor extra parallellisme, terwijl voor de CPU dit naar het ondersteunen van hogere kloksnelheden ging.

Maar begrijp je waarom dat zo is? Waarschijnlijk niet.
De GPU leent zich sowieso veel meer voor parallele implementaties dan een CPU, dus is het veel logischer dat men veel eerder die richting kiest. Voor CPUs is dat niet de meest directe weg naar betere prestaties, voor GPUs wel.
Afgezien daarvan is de architectuur van GPUs een aantal keren grondig veranderd om te kunnen zorgen dat ze efficient bleven bij grotere parallelisatie. Een paar 'key-technologies' hierin zijn bv hardware T&L (in het leven geroepen omdat de CPU de GPU niet meer bij kon benen), de hierarchische z-buffer en de unified shaders met dynamische allocatie.

Met multi-core CPU's gebruikt men echter ook een verdubbeling van het aantal transistors voor een verdubbeling van het parallellisme.

Wat tot veel minder prestatiewinst leidt dan bij de GPUs (en dat was mijn punt, waar jij eigenlijk niet op ingaat, maar langs loopt te redeneren. Je begrijpt het niet?).

Beter zelfs, Intel heeft CPU's in de planning die de cores vereenvoudigd om er meer op een chip te krijgen. En hun Tera-Scale experimenten tonen reeds aan dat ze geen moeite hebben om met de technologie van vandaag een TFLOP te halen. Hoewel het nog even duurt eer dat praktische resultaten zal opleveren in de vorm van commerciële CPU's is het meer dan duidelijk dat CPU's een inhaalbeweging maken qua perf/watt en perf/area en GPU's het daar juist lastig mee krijgen

We weten niet of de term 'CPU' van toepassing is voor deze processors.
Het is nog niet duidelijk wat Intel hiermee wil. Er gaan geruchten dat Intel er een grafische processor van wil maken met x86-achtige instructieset. Andere geruchten zeggen weer dat het een netwerkprocessor zou worden voor high-performance corporate switches/routers/firewalls etc.
Dat valt dus niet in de categorie CPU, maar gewoon een dedicated processor net als een GPU of PPU dat is.
Gezien de bijzonder slechte bruikbaarheid/efficientie van de huidige quadcore-processors is het me absoluut niet duidelijk wat ik met 80 cores zou willen binnen nu en een paar jaar.
TFLOPS en zo, allemaal indrukwekkend, maar een CPU moet gewone PC-software draaien, en daar zit hem het probleem.
Natuurlijk kan Intel makkelijk een systeem bedenken met 80 cores, maar dat wil niet zeggen dat dat in de praktijk ook veel sneller is. Het verschil met de GPUs, waar ik dus op doelde, is dat een 8800 ook daadwerkelijk een flinke verbetering is tov een 7800. Sterker nog, hij is ook sneller dan twee 7800s in SLI. En dat in vrijwel alle applicaties.
Dat is het verschil met een CPU. Parallelisatie werkt in sommige applicaties wel goed, maar in de meeste niet. Hogere kloksnelheid/IPC werkt echter wel altijd.

Merk ik niks van. Een 16-bit frame buffer of depth buffer is trager dan 32-bit omdat het extra instructies vergt voor de 'compressie'. Ik zit dus nog steeds gelimiteerd door de rekenkracht.

Ik heb het over schalen van dezelfde code op snellere hardware. Neem maar bv HalfLife 1, wat nog in software 3d te spelen is. Dat is op een CPU van een paar jaar geleden niet veel trager dan op een moderne CPU. Het verschil tussen een high-end Pentium D en een Core2 Duo is zeer klein.

RAM wel ja. Maar de cache schaalt zeer goed mee. Met enkele megabytes L2 kan je héél wat data verwerken voor je terug naar RAM moet.

Behalve dan dat alleen de Core2 Duo de L2-cache geshared heeft. De cores kunnen bij het sharen van data dus niet de snellere L1 gebruiken. Je kunt wel veel data verwerken, maar je kunt het niet zo heel snel verwerken.
Andere processors zijn nog slechter, want die hebben geen shared-cache en moeten via een trage bus de caches synchroon houden. Een PPU is hier vele malen sneller in.

En dat zal altijd zo blijven. Wanneer AGEIA het kapitaal bijeen heeft voor de productie van een 65 nm chip zit Intel aan 32 nm en 8 cores. Jammer voor hen maar het is nu eenmaal de werkelijkheid.

Dat geeft niet. nVidia en ATi lopen ook achter op Intel qua productie.
Ook Creative bv loopt aardig achter qua productietechniek.
Maar ze hebben weinig te vrezen van software-oplossingen, want die kunnen bij lange na niet tippen aan de prestaties van de hardware.

Een game-developer kan dus maar beter z'n physics op de CPU afstemmen in plaats van te wachten op een doorbraak van PPU's die er nooit komt.

Behalve dat ik een game-developer ben, en jij niet, en ik de doorbraak van PPU's juist actief push. Niet zoveel extra moeite op zich, hoor. Dus geen man overboord als het verspilde moeite blijkt.

Hoe dan wel? De klokfrequentie schaalt maar zeer traag en de complexiteit neemt kwadratisch toe met de IPC (versus lineair wanneer men multi-core gaat).

Lees m'n post nog eens door, ik had het al besproken, en heb daar niks aan toe te voegen.

s je compiler multi-threaded? Compileren is vrij goed te parallelliseren (bestand per bestand of functie per functie). Zal niet te lang duren eer dat sneller is dan op een single-core met gelijk aantal transistors.

Veel code is afhankelijk van elkaar.
Ik kan pas de subclasses compileren als de base-classes gecompileerd zijn. Zo moet ik ook eerst de basis-libraries compileren voordat ik de code kan compileren die er gebruik van maakt.
Compileren is dus redelijk slecht te paralleliseren. Zeker via een geautomatiseerd proces, want ik ken nog geen compiler die zelf uit kan zoeken in welke volgorde hij een willekeurig project moet compileren. Ik moet dat nog altijd zelf aangeven. Aangeven welke bestanden tegelijk gecompileerd kunnen worden is nog een stap verder, dan wordt het een hierarchisch verhaal.
Alleen totaal verschillende projecten zouden makkelijk parallel te compileren zijn. Maar ik werk doorgaans maar aan 1 project tegelijk, dus is dat geen interessante oplossing.

Tja, ik zie maar al te vaak op forums mensen klagen over hoe traag hun skinning of shadow volumes zijn op de CPU, en dan schrijven ze liever een shader dan SSE code. "Want assembler is moeilijk en gevaarlijk". Trouwens, Doom 3 gebruikt CPU skinning en shadow volumes (mét SSE).

Doom3 is dan ook mijn pet-peeve. Bijzonder zwaar voor de CPU, en zeer lage framerates. 3DMark03 heeft een vergelijkbare scene qua complexiteit (zelfs nog hogere polycount, en meer shadowcasters, Doom3 heeft bv geen self-shadows op skinned characters, 3DMark03 heeft dat wel), maar dan met GPU-based skinning en shadowvolumes, en haalt ook veel hogere framerates.
Programmeren in assembly en SSE is geen probleem. Maar na onderzoek en wat discussies met Mikko Kallinen kwamen we tot de conclusie dat GPUs gewoon sneller waren op dat moment, en alleen nog maar verder uitlopen. Destijds kwamen we met onze test-cases tot de conclusie dat een XP1800+ ongeveer even snel was als een Radeon 9600Pro (mid-end gaming systeem), en een Pentium 4 2.4 GHz was ruim twee keer zo traag als een 6800Ultra (high-end systeem). We hadden toen al ingeschat dat dit alleen nog maar verder zou uitlopen, en tot dusverre blijkt dat waar te zijn. Het is overigens niet meer relevant, want intussen hebben shadowmaps de shadowvolumes al opgevolgd.

Als je het wél multi-threaded doet is er rekenkracht te over (ettelijke miljoenen vertices/polygonen) en belast je de GPU niet met een bijkomende taak.

Het punt is dat het geen 'bijkomende taak' is. Het ging gewoon 'on the fly'. De shader werd alleen wat langer.
Als je het op de CPU doet, moet je weer met dynamische vertexbuffers gaan werken, die sowieso al veel minder efficient zijn, en kan de GPU niets renderen totdat je de vertexbuffer geupload hebt.
Het is zeer lastig om de CPU en GPU efficient parallel te laten lopen met een dergelijke constructie. Er tellen dus veel meer zaken mee dan alleen hoe snel een CPU in theorie de berekeningen kan uitvoeren.

Een Core 2 Duo heeft al gauw half zoveel GFLOPS als een GeForce 8600 GTS. "Bijzonder zwak" zou ik dit dus niet noemen, en het zou dus dom zijn om dat relatief klein aantal vertices/polygonen niet op de CPU te laten verwerken en de GPU zich te laten concentreren op de pixels.

Dit getuigt dus van een compleet gebrek aan inzicht en ervaring, zie mijn alinea hierboven.

'k Heb hier trouwens een laptop met Radeon X1300 waar software vertex processing meer dan dubbel zo snel is dan hardware.

Omdat het geen hardware is? Veel laptop-GPUs hebben gewoon software vertexprocessors, maar wegens software-compatibiliteit rapporteert de driver wel hardware-support. Het gaat dan wel via recompilatie van GPU-shaders, wat minder efficient is dan een geoptimaliseerde CPU-routine, zoals bv in de implementatie van Doom3.

Dat de physics nog net iets sneller hadden gekunnen op de GeForce 8800 interesseert 95% van de gamers niks. Een developer moet vooral de juiste keuzes maken zodat het ook goed loopt op die 95% andere systemen.

Nogmaals, developers kiezen niet, die delen.
Er worden gewoon meerdere implementaties gemaakt van verschillende delen (renderpad met/zonder schaduwen, HDR, etc... SSE of niet..), en bepaalde content wordt in verschillende detailniveaus meegeleverd (shaders, textures, meshes).
Waarom is die high-end interessant? Omdat spellen en engines op die manier langer mee kunnen gaan, en beter door kunnen schalen.
Je hele redenering is dus gebaseerd op foute aannamen.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 00:28]

[Verwijderd]

En als je dan naar een volle kamer gaat waar je alles kapot gaat schieten?

Dan gaan de physics van nul naar iets dat de multi-core CPU nog prima kan berekenen op een core die weinig of niks te doen had. Grafisch is het dan een factor twee/drie zwaarder en dat wil je niet verergeren door er nog eens physics bij te gooien waar het niet optimaal mee overweg kan.

Inderdaad, ik zou zelfs beweren dat een GPU er uitermate ongeschikt voor is. Maar de pure kracht van de huidige GPUs en het feit dat ze de CPU ontlasten, maken dat enigszins goed. Ik vind de PPU echter een verreweg superieure oplossing.

De krachtigste GPU telt slechts vijf maal meer GFLOPS dan de krachtigste CPU. Reken daarbij dat de CPU vlot overweg kan met physics en de GPU niet, en je ziet dat er snel heel wat van de framerate zou ingeleverd moeten worden wanneer je de zwaarste physics die de CPU aankan op de GPU zou gaan uitvoeren. Bovendien is de verhouding CPU/GPU hoger bij mid-end systemen en is het dus nog minder interessant om je GPU in te zetten voor physics.

Maar aangezien je niet zo gelooft in de rekenkracht van de CPU, laat het me zo stellen: wat als je de zwaarste physics die de PPU aankan op de GPU zou draaien? gegarandeerd dat je framerate klappen krijgt. Iedereen dan maar een PPU laten aanschaffen? 150 € voor iets dat enkel physics doet in een paar spellen daar ga je niet iedereen mee overtuigen (en wat met laptops)? Zeker niet als een multi-core CPU je dezelfde ervaring kan geven en nog voor zoveel meer nuttig is.

Binnen een paar maanden na de introductie van een nieuwe generatie hardware, zijn er al spellen die er gebruik van maken (bv SSE, hardware T&L, DX8/DX9/DX10). Dit terwijl er op dat moment ook maar heel weinig mensen zijn die daadwerkelijk die hardware in huis hebben.

Het verschil is dat die ontwikkelingen relatief kleine stappen zijn en gegarandeerd binnen enkele jaren bij iedereen beschikbaar zijn. Het is dus een goede investering van de developers om al vroeg met de nieuwe technologie vertrouwd te geraken, maar ze kunnen ook op iets oudere hardware nagenoeg hetzelfde doen. Het ontbreken van hardware met de allernieuwste features betekent niet dat je onmiddelijk uit de boot valt. De high-end bepaalt wat de volgende generatie mid-end zal zijn. Bij physics is daar totaal geen sprake van. Het schaalt niet zoals graphics en geraakt niet verder dan de early adopters. Ik zie nog niks dat aangeeft dat dit zou veranderen. Het is te duur en het voordeel te klein.

Het enige waar men nu op kan vertrouwen is dat toekomstige systemen met quad-cores uitgerust zullen worden. Logisch dus dat dit meer aandacht zal krijgen en uiteindelijk PhysX nutteloos zal maken.

Ik kan pas de subclasses compileren als de base-classes gecompileerd zijn.

Ik bedoelde natuurlijk parallel compileren per bronbestand he, niet per header. Ik heb rap een hondertal object-files, die allemaal in parallel gecompileerd kunnen worden. Visual Studio is trouwens multi-threaded...

Doom3 is dan ook mijn pet-peeve. Bijzonder zwaar voor de CPU, en zeer lage framerates.

Waarom toont elke review van nieuwe grafische kaarten dan een mooie groei in framerates (die in de honderden kan lopen)? Geen teken van CPU-limited te zijn hoor. Is ook logisch. In id's papers kan je lezen dat de verwerking slechts enkele tientallen of honderden klokcycli duurt per element. Met enkele duizenden elementen is je CPU dus helemaal niet zwaar belast.

Het is zeer lastig om de CPU en GPU efficient parallel te laten lopen met een dergelijke constructie.

En met een PPU is het eenvoudiger?

Omdat het geen hardware is? Veel laptop-GPUs hebben gewoon software vertexprocessors, maar wegens software-compatibiliteit rapporteert de driver wel hardware-support.

Dat geldt voor Intel IGP's, niet voor de Radeon X1300 waar ik het over heb. Vertex processing vertaalt zich bijzonder goed naar SSE en een dual-core 2+ GHz CPU heeft dan ook geen moeite om de twee vertex units van de X1300 op 500 MHz te verslaan. In game.

Nogmaals, developers kiezen niet, die delen.
Er worden gewoon meerdere implementaties gemaakt van verschillende delen (renderpad met/zonder schaduwen, HDR, etc... SSE of niet..),

Direct3D 10 is bedoeld om daar grotendeels korte metten mee te maken. Meerdere implementaties zorgt voor een grote ontwikkelingskost en supportproblemen. Die is een developer liever kwijt dan rijk, en ze beperken zich dan ook tot de nodige technologie in plaats van alle technologie. Voorbeeldje: jaren geleden had men al multi-CPU, en hoewel dit duidelijk de top-end systemen waren ging het nooit mid-end worden (niet in die vorm) en dus is het nooit doorgebroken in de gamewereld. Multi-core is intussen doorgebroken tot in de low-end. Een developer zou stom zijn om er geen gebruik van te maken.

AGEIA biedt zowel een software- als hardwareimplementatie omdat ze anders immers hun product niet verkocht krijgen. Dus zowiezo krijgt elke engine die gebruik maakt van PhysX twee 'physics-paths'. Dat geeft echter niks garantie dat PPU's ooit doorbreken. Ik zie het echt niet gebeuren. Quad-core is echter reeds een feit en wordt heel binnenkort betaalbaar. Plannen voor octa-cores liggen ook al klaar...

Waarom is die high-end interessant? Omdat spellen en engines op die manier langer mee kunnen gaan, en beter door kunnen schalen.

Vertaal dit nu even naar CPU's. Gamedevelopers weten reeds dat octa-core er aankomen. Dan moet men nu reeds weten wat men met zoveel rekenkracht zal aanvangen. Physics is één van de logische antwoorden. De toekomst van de PPU is veel twijfelachtiger, en ik heb je al veel redenen gegeven waarom het wellicht nooit de mid-end haalt.

Nog eentje: om door te breken moeten er spellen komen die enkel met hardware-physics kunnen draaien (net zoals spellen nu ook geen software renderer meer hebben). Dan moet het voordeel echt bijzonder duidelijk zijn en moet het ook in de toekomst blijven schalen (in plaats van ingelopen te worden door de CPU). Veel geluk om iemand daarvan te overtuigen. Als zo'n spel verschijnt eet ik m'n schoen op. Hou me er aan.

[Verwijderd]

Dan gaan de physics van nul naar iets dat de multi-core CPU nog prima kan berekenen op een core die weinig of niks te doen had.

Alleen als je de complexiteit bijzonder beperkt houdt. Start eens een paar samples op uit de PhysX SDK en zie hoe gauw een quadcore op z'n gat gaat.

Grafisch is het dan een factor twee/drie zwaarder en dat wil je niet verergeren door er nog eens physics bij te gooien waar het niet optimaal mee overweg kan.

Dat was vroeger zo (bottleneck zat vooral in de driver), maar DX10 brengt daar dus verandering in.

Maar aangezien je niet zo gelooft in de rekenkracht van de CPU, laat het me zo stellen: wat als je de zwaarste physics die de PPU aankan op de GPU zou draaien?

Dat moet je ook niet willen. Je gaat toch ook geen code voor een Core2 Duo op een 386 draaien? Ofwel je maakt een speciaal pad voor een bepaalde hardware-configuratie, of je accepteert dat die configuratie niet of niet goed werkt.
Onzinnige stelling dus.

Iedereen dan maar een PPU laten aanschaffen? 150 € voor iets dat enkel physics doet in een paar spellen daar ga je niet iedereen mee overtuigen (en wat met laptops)? Zeker niet als een multi-core CPU je dezelfde ervaring kan geven en nog voor zoveel meer nuttig is.

Zeur nou eens niet over geld. Ik ben niet geinteresseerd in geld, ik hou van technologie, geld boeit me niet.
Ik vind dat iedereen een PPU moet aanschaffen dan, ja. Dan gaat de prijs automatisch ook omlaag... net zoals je nu nog voor geen 50e een DX10-videokaart kunt kopen. Ga je nog steeds zeuren als PPUs straks ook 50e kosten?
Mensen met laptops moeten niet zeuren. Je weet van tevoren dat een laptop geen ideale game-PC wordt. Dus dat wordt minder detail in je physics, of wachten totdat ook de laptops een PPU aan boord krijgen (wat vast wel gebeurt als alle desktops een PPU aan boord hebben.... het is met GPUs ook gelukt, zelfde argument: iets dat alleen acceleratie doet in een paar spellen).
Verder slaat je redenering nergens op. Een quadcore is nog steeds duurder dan een PPU. Als ik betere physics in mijn spellen wil, ga ik dus geen quadcore kopen, maar een PPU. Waarom? Omdat die PPU de physics beter maakt dan een quadcore, en voor alles behalve spellen mijn dualcore toch al veel te snel is. Ik heb niks aan nog meer processorkracht.
Afgezien daarvan moet zelfs jij toegeven dat er momenteel meer spellen zijn met support voor PhysX dan dat er spellen zijn die geoptimaliseerd zijn voor quadcore of hoger.

Het verschil is dat die ontwikkelingen relatief kleine stappen zijn en gegarandeerd binnen enkele jaren bij iedereen beschikbaar zijn. Het is dus een goede investering van de developers om al vroeg met de nieuwe technologie vertrouwd te geraken, maar ze kunnen ook op iets oudere hardware nagenoeg hetzelfde doen.

Onzin. Ook het gebruik van HavokFX of de PhysX SDK is maar een kleine stap. Physics zijn immers al in alle grote game-engines nadrukkelijk aanwezig.
De PhysX-SDK is vooral op consoles erg populair, en het porten naar PC zou automatisch de PPU-support toevoegen.
Het argument van goede investering gaat ook bij physics op, want HavokFX werkt sowieso al op alle moderne videokaarten, en zal alleen maar beter worden, en ook voor PhysX is wel wat te zeggen, want de kaartjes zijn toch behoorlijk scherp geprijsd. Als een gamer 300e uitgeeft aan een quadcore processor en 500e voor een high-end CPU, dan kunnen daar ook nog wel die luttele 150e voor een PPU ergens bij, desnoods in een tussentijdse upgrade. De PPU zal ook een prima investering zijn, want voorlopig is de processor veel sneller dan wat de spellen vragen, en kan dus nog wel wat jaartjes doorschalen... Waar een videokaart van 500+e eigenlijk een wegwerp-artikel is, want over 6 maanden is er weer een snellere. Toch worden die kaarten veel verkocht.

Het enige waar men nu op kan vertrouwen is dat toekomstige systemen met quad-cores uitgerust zullen worden. Logisch dus dat dit meer aandacht zal krijgen en uiteindelijk PhysX nutteloos zal maken.

Niet als developers de PhysX pushen. Quadcores zijn overrated. Ik heb veel game-developers gesproken die het eigenlijk helemaal niet zien zitten. Het is enorm veel werk om je engine goed multithreaded te maken op een nuttige manier, en dan nog is de winst heel mager. Valve heeft tot dusverre de beste oplossing met hun hybrid threading, maar ook dat is eigenlijk slechts een experiment. De resultaten zijn nou niet heel denderend te noemen. Daarom zullen developers graag de physics van de CPU afhalen, zodat ze hun efficientie van de rest van de multithreaded code in ieder geval wat kunnen verbeteren.

Waarom toont elke review van nieuwe grafische kaarten dan een mooie groei in framerates (die in de honderden kan lopen)? Geen teken van CPU-limited te zijn hoor. Is ook logisch.

Ja, nu valt het wel mee ja. Tijdens de introductie was het wel even anders.
Sowieso testen zij doorgaans met timedemos waar voor een groot deel ook helemaal geen skinned meshes in beeld zijn, en alle statische shadowvolumes worden maar 1 keer berekend, dus dat vertekent de slechte performance van hun skinning-code nogal.

Desalniettemin is de polycount in Doom3 schrikbarend laag gehouden om te zorgen dat de CPU niet te zwaar belast wordt. Vergelijk het met tijdgenoot Battle of Proxycon uit 3DMark03 en zie dat je daar meer polys hebt, meer selfshadows, geavanceerdere belichting, meer geanimeerde karakters tegelijkertijd op het scherm, en TOCH haal je veel hogere framerates dan met Doom3.
Destijds was het heel extreem, met de Pentium 4 2.4 GHz met GeForce 6800XG.
In Doom3 haalde je gemiddeld zo'n 30-40 fps met mannetjes in beeld, waar je in Battle of Proxycon in de buurt van de 200 fps zat. Dat verschil is HEEL groot.
Het meest irritante is wel dat Doom3 bizar slecht schaalt. Met 1 of 2 mannetjes zit je nog rond de 30-40 fps, maar met 4 of 5 zit je rond de 10-12, en begint de speelbaarheid er sterk onder te lijden.
Bij de testscenes die wij draaiden hadden we een geanimeerde hand die in z'n eentje al 5000 geskinde polys had... Dat is meer dan een complete scene in Doom3, waar een compleet karakter gemiddeld zo'n 1500 polys bevat.

In id's papers kan je lezen dat de verwerking slechts enkele tientallen of honderden klokcycli duurt per element. Met enkele duizenden elementen is je CPU dus helemaal niet zwaar belast.

Ja, strooi maar weer met wat nutteloze theoretische getallen. Lees maar eens wat ik hierboven zeg. Ten eerste verknalt ID dus z'n spel omdat ze de polycount noodgedwongen zeer laag moeten houden. Ten tweede zitten ze de CPU zwaar te belasten, en laten ze de vertexshaders op de GPU onbelast. Dit hadden ze veel beter om kunnen draaien, zoals bij Battle of Proxycon. Ook spellen als Far Cry en Fear schakelen wel de GPU in voor hun shadowvolumes.

En met een PPU is het eenvoudiger?

Ja.

Dat geldt voor Intel IGP's, niet voor de Radeon X1300 waar ik het over heb.

Nee, dat geldt ook voor jouw mobile X1300.

Vertex processing vertaalt zich bijzonder goed naar SSE en een dual-core 2+ GHz CPU heeft dan ook geen moeite om de twee vertex units van de X1300 op 500 MHz te verslaan. In game.

Probeer het eens met een 'gewone' X1300 insteekkaart. Je zult zien dat die al stukken sneller is dan de X1300 in jouw laptop.
Mijn 7600GT is in ieder geval al stukken krachtiger dan mijn Core2 Duo E6600. Om over een 8800 maar te zwijgen.
In de tijd dat ik nog een GeForce2 GTS gebruikte, maakte ik ook vaak gebruik van de hardware T&L, omdat deze zo snel was in vergelijking met mijn 1800+ processor.
Ik schreef mijn CPU-routine dan dusdanig dat hij alles doorrekende totdat er 'gewone' vertices in object-space met de juiste normaalvectors, texcoords etc waren, welke ik door de GeForce2 liet belichten en transformeren naar worldspace. Vooral met de stap van de belichting was de GF2 een stuk sneller dan de CPU (dotproducts, wortels, machtsverheffen etc, dat doet een CPU zelfs met geoptimaliseerde SSE nog niet zo heel efficient, omdat je gewoon niet de instructies hebt die die dingen in 1 instructie/cycle kunnen doen... en die zitten in een GPU wel).

Direct3D 10 is bedoeld om daar grotendeels korte metten mee te maken. Meerdere implementaties zorgt voor een grote ontwikkelingskost en supportproblemen.

Hoe kom je daarbij?
Het enige dat Direct3D elimineert is het systeem van 'caps'. Een DX10-kaart kan gewoon per definitie een gegeven set bewerkingen, en daarop zijn geen uitbreidingen.
Dit betekent echter natuurlijk niet dat alle DX10-kaarten even snel zijn, dus zullen er nog steeds meerdere niveaus van detail moeten zijn in het spel, om het toch op de tragere kaarten goed speelbaar te houden. Dat is niet iets waar een API ooit verandering in kan brengen. Dergelijke detail-niveaus moet je op engine/game-niveau implementeren (welke grafische effecten gaan aan/uit... hoe krachtig stellen we de LOD in etc).

Voorbeeldje: jaren geleden had men al multi-CPU, en hoewel dit duidelijk de top-end systemen waren ging het nooit mid-end worden (niet in die vorm) en dus is het nooit doorgebroken in de gamewereld. Multi-core is intussen doorgebroken tot in de low-end. Een developer zou stom zijn om er geen gebruik van te maken.

Bij dat voorbeeld hoort ook de opmerking van John Carmack dat het een leuk experiment was, maar dat het enorm veel extra werk was, en eigenlijk nauwelijks winst opleverde, en daarom in ieder geval voor Doom3 geen optie zou zijn.
Multi-core komt gewoon zeer belabberd uit de kosten-baten analyse. Heeft weinig te maken met hoe stom developers zijn.

AGEIA biedt zowel een software- als hardwareimplementatie omdat ze anders immers hun product niet verkocht krijgen. Dus zowiezo krijgt elke engine die gebruik maakt van PhysX twee 'physics-paths'.

Ik bedoelde natuurlijk op het niveau van het spel, niet de API.
Evident dat er een CPU-fallback is. Maar de CPU is ook nog eens veel trager (zeker als de rest van het spel ook erg zwaar is), dus zal het spel ook rekening moeten houden met meer of minder gedetaiieerde physics. Dit doen alle spellen die gebruikmaken van PhysX ook (en ook een aantal spellen heeft voor de CPU verschillende physics-niveaus, want ook niet alle CPUs zijn even snel natuurlijk). We zitten alleen nog in de fase dat PhysX doorgaans als 'afterthought' toegevoegd is aan een spel, en de content een beetje opgepoetst is voor de PPU. De workload is nog niet echt geoptimaliseerd voor het gebruik van een PPU, de grenzen zijn nog lang niet bereikt.
Op het moment dat er een nieuwere, snellere generatie PPUs komt, zal er nog een extra high-end pad toegevoegd kunnen worden.

Vertaal dit nu even naar CPU's. Gamedevelopers weten reeds dat octa-core er aankomen. Dan moet men nu reeds weten wat men met zoveel rekenkracht zal aanvangen.

Niet zo gek veel, want de infrastructuur legt die cores flinke beperkingen op, waardoor vele potentiele taken al afvallen voor het gebruik van multicore, of in ieder geval maar beperkt kunnen schalen. Je zult eerder zien dat er steeds grenzen blijven, waar je tegenaan loopt.
Momenteel is er de grens dat applicaties uberhaupt geen threads gebruiken... Applicaties die dat wel doen, hebben weer de grens dat niet alle threads even zwaar zijn, dus de cores worden niet genoeg benut. Vaak heb je ook niet eens genoeg aparte threads om uberhaupt alle cores iets te laten doen.
De volgende stap is dan om de verschillende 'jobs' op zich op te delen in meerdere threads. Maar dan kom je tegen flinke beperkingen aan omdat meerdere cores met dezelfde stukken geheugen moeten werken, en beperkt worden door het mechanisme dat de data synchroniseert, ipv dat ze gewoon direct in hun l1-cache kunnen werken. Verder zul je tegen de wet van Amdahl aanlopen. Je kunt er wel meer threads tegenaan smijten, maar dat geeft ook steeds meer overhead om de threads te managen, en uiteindelijk win je niets meer door nog meer threads/cores tegelijk te gebruiken. Twee cores is wel aardig, 4 cores kan nog net... 8 cores begint al wat twijfelachtig te worden... en zo'n CPU met 80 cores? Dat zul je waarschijnlijk nooit goed kunnen gaan benutten, niet met een game engine in ieder geval.

De toekomst van de PPU is veel twijfelachtiger, en ik heb je al veel redenen gegeven waarom het wellicht nooit de mid-end haalt.

Jij gelooft er gewoon niet in. Ik vind het een prima technologie, en ik vind dus dat alle game-developers die moeten pushen... en dan gaat het echt wel lukken.
Ik geloof dan weer minder in multi-core. Het belangrijkste in een game dat geparallelliseerd kan worden, is dat al: de graphics.
Van wat er overblijft is physics de beste kanshebber, maar dat past gewoon niet zo lekker op de architectuur van een standaard CPU. Je hebt heel veel kleine jobs, welke onderling weer afhankelijkheden hebben, waar een standaard CPU veel liever grote jobs heeft, en liefst zo onafhankelijk mogelijk. Zodra iets afhankelijk is, geef je sowieso je l1-cache al op, in feite. En dat hakt er in. Bij een andere CPU dan de Core2 Duo geef je eigenlijk ook je l2-cache al op, en bepaalt de bus tussen de onderlinge cores de snelheid van de datatoevoer.

Nog eentje: om door te breken moeten er spellen komen die enkel met hardware-physics kunnen draaien (net zoals spellen nu ook geen software renderer meer hebben).

Dat moet helemaal niet. Waarom zou dat moeten?
Software-renderers zijn ook nog redelijk lang gebleven, hoewel 3d-accelerators al aardig ingeburgerd waren.
Het lijkt wel of je de meest rare hersenspinsels verzint om maar tegen de PPU aan te kunnen schoppen. Jammer dat je het op technologische kennis niet redt.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 00:28]

[Verwijderd]

Start eens een paar samples op uit de PhysX SDK en zie hoe gauw een quadcore op z'n gat gaat.

AGEIA heeft er alle belang bij z'n software niet even snel te maken als z'n hardware. Ik wacht nog steeds op onafhankelijke benchmarks. Bij grafische kaarten was dit trouwens veel duidelijker omdat spellen zoals Quake een fantatisch geoptimaliseerde software renderer hadden maar hardware het toch versloeg en hogere kwaliteit leverde.

AGEIA: "Wij van WC-Eend..."

Zeur nou eens niet over geld. Ik ben niet geinteresseerd in geld, ik hou van technologie, geld boeit me niet.

733-0171654-91

Het meest fantastische technologische idee komt er echt niet door als het niet economisch is. Aan die realiteit ontsnap je niet.

...net zoals je nu nog voor geen 50e een DX10-videokaart kunt kopen. Ga je nog steeds zeuren als PPUs straks ook 50e kosten?

Je boedoelt voor 50 € een grafische kaart waarvan de vertex processing verslaan wordt door een CPU? Voor 50 € kunnen ze ook geen PPU produceren die een CPU kan bijhouden. En zoals ik al eerder zei tegen dat AGEIA een 65 nm chip kan presenteren zit Intel al op 32 nm octa-cores te produceren.

Nee, dat geldt ook voor jouw mobile X1300.

Nee, die heeft twee vertex units in hardware.

Probeer het eens met een 'gewone' X1300 insteekkaart. Je zult zien dat die al stukken sneller is dan de X1300 in jouw laptop.

Logisch, de klokfrequentie van het dektopmodel is bijna dubbel zo hoog.

Een quadcore is nog steeds duurder dan een PPU.

Dat zei je vorig jaar ook over dual-core. Nu kosten ze de helft van een PPU. Binnenkort wordt Barcelona gelanceerd en maakt Intel goedkope quad-cores op 45 nm.

Omdat die PPU de physics beter maakt dan een quadcore...

Daar ga je steeds maar vanuit, terwijl je nog geen enkele onderbouwde argumentatie gegeven hebt waarom die meer werk kan verzetten dan een moderne multi-core CPU. Feiten wil ik horen, marketingpraat of samples van AGEIA zijn niks waard. Wat maakt de PPU zo uniek voor physics als de GPU is voor graphics? GFLOPS en het interconnectienetwerk stellen niet veel voor, dus wat zijn de geheime ingrediënt zoals we die bij de GPU wel kunnen onderscheiden?

...en voor alles behalve spellen mijn dualcore toch al veel te snel is. Ik heb niks aan nog meer processorkracht.

Kijk even verder dan je persoonlijke interesses. Alles wat een beetje multimedia is heeft baat bij een multi-core CPU. En ook binnen spellen zijn er andere taken dan physics die verdeeld kunnen worden over de cores. Alle toekomstige engines zijn voorbereid op quad-core en verder. Een PPU is echter enkel en alleen van 'nut' in spellen met extreem veel physics (ik zou zelfs zeggen artificeel veel). Op dit moment is dat CellFactor en Warmonger, de rest doet nog steeds prima z'n physics op de CPU. Een lullig beetje extra brokstukken en rook gaat buiten de early adpoters niemand overtuigen om een extra kaart in hun systeem te proppen. En het is nog niet eens bewezen dat een moderne CPU niet die brokstukken en rook aankan.

Soit, ik heb nog werk, moet nog wat patentclaims vervoltooien.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 00:28]

[Madrox]

Ben het absoluut niet met je eens. Physics word zwaar onderschat, je vergelijk met multi-core cpu's slaat ook nergens op. De spellen die meer dan 1 CPU-Core gebruiken zijn tot nu op 1 hand te tellen. Dus ook al die phycisc worden op 1 core gedraait. Je hebt tot nu dus geen r**t aan multi-core voor je spellen, laat staan physics. Dat dit kan veranderen, is duidelijk. Het gaat alleen zeer traag.

Het gaat trouwens niet alleen om extra interactiviteit, het gaat vooral ook om path-finding, 'slimmere" tegenstanders die noy eens niet de meeste domme wegen bewandelen bijv. . Ver helpt physics in scenes waar veel objecten tegelijk door de lucht suisen en zo kan je nog wel een paar dingen noemen. Neem nou bijv. Oblivion, daar vertraagt de FPS van zwak tot enorm, afhankelijk van hoeveel NPC's enzo in de buurt zijn. Ook hier kan Physics enorm helpen.

[Verwijderd]

De spellen die meer dan 1 CPU-Core gebruiken zijn tot nu op 1 hand te tellen.

De spellen die van de GPU gebruik maken voor physics zijn er exact nul.

Het gaat mij over toekomstige spellen. Crysis en Unreal 3 en alle volgende spellen zullen zeer goed gebruik maken van multi-core.

Het gaat alleen zeer traag.

Je kan ook niet zomaar een PhysX P1 of een extra GPU in je systeem ploppen en al je spellen daar automatisch voor de physics gebruik van maken. Voor een 'doorbraak' van relatief rekenintensieve physics moet je zeker een jaar verder kijken. En dan zie ik multi-core CPU's een véél groter belang hebben dan GPU's of PPU's, en houden.

...het gaat vooral ook om path-finding, 'slimmere" tegenstanders die noy eens niet de meeste domme wegen bewandelen...

A.I. bedoel je dus. Daar zijn de GPU en PPU helemaal niet geschikt voor.

Soms hoor ik ook zaken over een 'dedicated' processor voor A.I. Da's al helemaal belachelijk. Zo'n processor zou zeer sterk lijken op een multi-core general-purpose CPU, zoals die van Intel en AMD...

In dezelfde zin zie ik de PPU geen lang leven beschoren. Het doet niks dat een CPU niet kan. De floating-point units van een PPU zijn geen haar beter dan die van een CPU. In tegendeel, ze draaien op tien keer lagere klokfrequentie. En met multi-core haalt de CPU nu ook zeer goed parallelisme.

Sommige mensen lijken te vergeten dat de CPU ook hardware is. En de CPU versus PPU vergelijken met de CPU versus GPU gaat niet op. De GPU beschikt namelijk over texture filter units die de CPU niet bezit, terwijl de PPU niks bezit dat de CPU niet heeft.

[Verwijderd]

A.I. bedoel je dus. Daar zijn de GPU en PPU helemaal niet geschikt voor.

Je ziet het voor de hand liggende weer eens over het hoofd.
Als de GPU en PPU niet geschikt zijn voor AI, dan ga je dat op de CPU doen.
Waardoor er dus minder tijd overblifjt voor physics op de CPU.
Laten de GPU en PPU dat nou juist WEL goed kunnen!
Kortom, door de physics van de CPU af te halen, kun de de AI krachtiger maken op de CPU.

De floating-point units van een PPU zijn geen haar beter dan die van een CPU. In tegendeel, ze draaien op tien keer lagere klokfrequentie. En met multi-core haalt de CPU nu ook zeer goed parallelisme.

Ja, de floating-point units zijn niet zo bijster snel. Toch is een PPU significant sneller dan de snelste CPU op dit moment. Dan moet er toch een lampje gaan branden bij je?
Er is blijkbaar iets waar de PPU veel beter in is dan de CPU, en dat is niet zozeer de rauwe floating-point rekenkracht op zich (ook GPUs waren lange tijd niet krachtiger dan CPUs, en ook veel lager geklokt, maar desondanks waren ze veel sneller met bepaalde taken, zoals het renderen van 3d-scenes).

terwijl de PPU niks bezit dat de CPU niet heeft.

Dit heb ik in eerdere discussies al uitgelegd.
Blijkbaar is je schedel dermate dik dat er onmogelijk toe doorgedrongen kan worden, maar ik zal nog eenmaal de link naar het artikel van digit-life geven, welke een diagram laat zien van de layout van de PPU:
http://www.digit-life.com...o/ageia_physx_review.html
De PPU bezit dus een netwerk om met hoge bandbreedte en lage latencies te communiceren tussen de 16 processors.
Ten eerste hebben we nog lang geen 16 cores op onze CPUs, we zitten nu net aan de 4. Ten tweede is de communicatie tussen die cores vele malen trager.
DAT is dus wat de PPU heeft, en de CPU niet.
Maargoed, dat heb ik je al vele malen verteld, en dat zal ik ook nog vele malen moeten gaan herhalen. Het wil er bij jou gewoon niet in.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 00:28]

[Verwijderd]

Als de GPU en PPU niet geschikt zijn voor AI, dan ga je dat op de CPU doen.
Waardoor er dus minder tijd overblifjt voor physics op de CPU..

Madrox zei: "Ook hier kan Physics enorm helpen". Het is daar dat ik op geantwoord heb aangezien hij A.I. lijkt te verwarren met physics.

Hoe dan ook, A.I. is traag als men er een geïnterpreteerde scriptingtaal voor gebruikt (wat steeds populairder lijkt te worden). De oplossing is niet om extra rekenkracht vrij te maken (door bijvoorbeeld physics te verhuizen naar de GPU), maar het zaakje deftig te compileren en optimaliseren zodat het slechts een minieme fractie van de tijd meer inneemt.

Ja, de floating-point units zijn niet zo bijster snel. Toch is een PPU significant sneller dan de snelste CPU op dit moment.

Ik wacht nog steeds op een onafhankelijke benchmark die dit bewijst. Mijn technisch gefundeerde schattingen tonen aan dat een multi-core CPU en goed geoptimaliseerde software geen probleem zou moeten hebben om hetzelfde te doen dan wat een PhysX P1 doet in games ontwikkeld voor en door AGEIA.

...maar ik zal nog eenmaal de link naar het artikel van digit-life geven, welke een diagram laat zien van de layout van de PPU: [...]. De PPU bezit dus een netwerk om met hoge bandbreedte en lage latencies te communiceren tussen de 16 processors.

Het was ik die jou het eerst naar het patent verwees hoor. En ik gebruikte het om aan te tonen dat het helemaal niet zo'n fabuleus netwerk bevat. In tegendeel, een Core 2 heeft hogere interne bandbreedtes, en hoewel de latentie hoger is in clocks is ze lager in absolute tijd.

[Verwijderd]

Madrox zei: "Ook hier kan Physics enorm helpen". Het is daar dat ik op geantwoord heb aangezien hij A.I. lijkt te verwarren met physics.

Ik denk dat hij het verband tussen physics en AI bedoelt, dat jij niet ziet.

Ik wacht nog steeds op een onafhankelijke benchmark die dit bewijst. Mijn technisch gefundeerde schattingen tonen aan dat een multi-core CPU en goed geoptimaliseerde software geen probleem zou moeten hebben om hetzelfde te doen dan wat een PhysX P1 doet in games ontwikkeld voor en door AGEIA.

Jouw 'technisch gefundeerde schattingen' *kuch* zijn compleet uit je duim gezogen aan de hand van een paar getalletjes, en nemen allerlei praktische zaken zoals overhead van driver-calls, het verplaatsen van data van A naar B, achtergrondtaken op de CPU etc compleet niet in acht.
Je probeert over te komen als een deskundige, maar je gebrek aan ervaring en inzicht is overduidelijk.

Het was ik die jou het eerst naar het patent verwees hoor. En ik gebruikte het om aan te tonen dat het helemaal niet zo'n fabuleus netwerk bevat. In tegendeel, een Core 2 heeft hogere interne bandbreedtes, en hoewel de latentie hoger is in clocks is ze lager in absolute tijd.

Knap dat jij weet hoe de latency in absolute tijd is, als zowel de kloksnelheid als de exacte cyclecount van de PhysX-PPU niet bekend zijn.
Je kletst uit je nek.

Afgezien daarvan blijft de PPU dedicated, waar de Core2 zijn bandbreedte, cache en processorkracht moet delen met de andere CPU-taken binnen de software. Dus effectief is de Core2 met physics veel zwakker dan in theorie.
Aangezien je sowieso een grafische component naast je physics-component moet hebben om uberhaupt wat te zien, kun je nooit de theoretische physics-prestaties van een Core2 benaderen.

[Verwijderd]

Jouw 'technisch gefundeerde schattingen' *kuch* zijn compleet uit je duim gezogen aan de hand van een paar getalletjes...

Ze zijn gebaseerd op de zeer summiere data die AGEIA zelf vrijgeeft over z'n PPU, en hun patent. 530 miljoen sphere collision tests per seconde versla je met gemak op één core van een Core 2. En 2 Tb/s (waarom spreken ze over bit) wordt verslagen door een Core 2 Quad die 384 GB/s bandbreedte biedt.

Waar blijven ze trouwens met meer details over de specificaties? Wat hebben ze te verbergen?

Knap dat jij weet hoe de latency in absolute tijd is, als zowel de kloksnelheid als de exacte cyclecount van de PhysX-PPU niet bekend zijn.

De snelste access is 1 klockcyclus, maar de PPU is veel trager geklokt dan de CPU.

Je kletst uit je nek.

[Verwijderd]

530 miljoen sphere collision tests per seconde versla je met gemak op één core van een Core 2.

Ten eerste, bewijs het maar. Met een werkend stukje code welteverstaan (inclusief visualisatie natuurlijk, want daar gaat het om). Aan theoretisch geleuter, op niets meer gebaseerd dan een vage theoretische schatting van het aantal gflops, heb ik niks. Zo dom en onervaren ben ik niet. Jij misschien wel.

Ten tweede, hoe weet je wat voor collisions het zijn? Als het 530 miljoen spheres zijn die allen tegen elkaar aan botsen, dan is dat voor een CPU een stuk lastiger dan 530 keer twee bollen berekenen.
En dat verschil is nou juist iets dat de PPU minimaliseert.

Waar blijven ze trouwens met meer details over de specificaties? Wat hebben ze te verbergen?

Waarom zou je het willen weten? Je kunt zo'n kaartje kopen, en zelf testen hoe snel ie is. Als hij 530 miljoen sphere collisions per seconde kan doen, dan kan ie dat. Boeit het dan nog of ie op 250 MHz loopt, of op 500? En of ie 64 bit is, of 128? Of wat dan ook?
Zolang zij de enigen zijn met een PPU, snap ik wel dat ze het zo lastig mogelijk maken om hem na te maken. Bij CPUs en GPUs ligt het anders. De meeste technologie ligt al jaren 'op straat', en wordt door vele bedrijven toegepast.

De snelste access is 1 klockcyclus, maar de PPU is veel trager geklokt dan de CPU.

De snelste access van l2-cache op ee Core2 is 14 cycles (l1 kunnen we in principe buiten beschouwing laten, want bij de PPU gaat het om het sharen van data, iets dat de CPU ook veelvuldig zal moeten doen bij physics).
De kloksnelheid van de PPU lijkt me dus wel interessant om te weten. Als ie minder dan 14 keer zo laag is dan een Core2, dan heeft hij dus minder latency bij het sharen van data tussen twee processing units.
Maar die weten we dus niet.

[Verwijderd]

Ten eerste, bewijs het maar. Met een werkend stukje code welteverstaan...

Heb ik al eens SSE-code voor getoond. Zoek het even op.

inclusief visualisatie natuurlijk, want daar gaat het om

Waarom? AGEIA heeft het daar over maximale prestaties.

Ten tweede, hoe weet je wat voor collisions het zijn?

Omdat ze spreken over sphere-sphere collisions.

Je kunt zo'n kaartje kopen, en zelf testen hoe snel ie is.

Klopt maar dat is niet het punt. AGEIA verzwijgt gegevens die blijkbaar gevoelig zijn. Waarom zouden ze gevoelig zijn? Omdat in AGEIA's marketing staat dat PPU's beter zijn dan CPU's, en het hun doodsteek zou zijn indien blijkt dat dit niet het geval is.

Als hij 530 miljoen sphere collisions per seconde kan doen, dan kan ie dat. Boeit het dan nog of ie op 250 MHz loopt, of op 500? En of ie 64 bit is, of 128? Of wat dan ook?

Neen, maar de CPU kan dat ook, dus ik had gehoopt dat de PPU misschien toch ergens in uitblinkt. Blijkbaar niet.

De snelste access van l2-cache op ee Core2 is 14 cycles (l1 kunnen we in principe buiten beschouwing laten, want bij de PPU gaat het om het sharen van data, iets dat de CPU ook veelvuldig zal moeten doen bij physics).

Maakt niet veel uit met out-of-order execution. De PPU moet trouwens ook meerdere niveaus doorlopen om data met een willekeurige core uit te wisselen. Bovendien heeft de PPU helemaal geen cache, en zit je dus vast aan de bandbreedte van de RAM voor effectieve dataverwerkingscapaciteit. Een Core 2 Duo heeft met 4 MB gedeelde L2 cache de belangrijkste data on-chip. En de volgende generatie Core 2 Quads zullen 12 MB hebben.

Maar die weten we dus niet.

Inderdaad, en het is verdacht dat AGEIA dit niet meedeelt.

[Heezy]

Je probeert over te komen als een deskundige, maar je gebrek aan ervaring en inzicht is overduidelijk.

Ja, hij heeft alleen maar voor NVIDIA gewerkt...

[Verwijderd]

Ja, hij heeft alleen maar voor NVIDIA gewerkt...

Dat wil niet zeggen dat je over deze onderwerpen kunt meepraten. nVidia ontwikkelt geen game-engines of PPUs, en er zijn sowieso maar heel weinig mensen binnen nVidia bezig met het schrijven van 3d-code (alleen het demo-team, en daar zat hij vast niet bij, als ik hem zo hoor praten).

[Verwijderd]

Dat wil niet zeggen dat je over deze onderwerpen kunt meepraten. nVidia ontwikkelt geen game-engines of PPUs, en er zijn sowieso maar heel weinig mensen binnen nVidia bezig met het schrijven van 3d-code (alleen het demo-team, en daar zat hij vast niet bij, als ik hem zo hoor praten).

Dus volgens jou kennen de personen die de drivers schrijven niks over het gedrag van de applicaties en het bijhorende prestatiepatroon? En verder praat ook niemand met elkaar en wordt geen kennis en ervaring uitgewisseld (formeel of informeel)? En iemand die GPUs en CPUs tot op het transistorniveau vertaat kan geen oordeel vellen over PPUs?

[Verwijderd]

Dus volgens jou kennen de personen die de drivers schrijven niks over het gedrag van de applicaties en het bijhorende prestatiepatroon?

Nee.
De mensen bij Microsoft weten toch ook niet hoe mijn Windows-applicaties werken? En ze hebben nog wel Windows gemaakt!

En verder praat ook niemand met elkaar en wordt geen kennis en ervaring uitgewisseld (formeel of informeel)?

Dat blijkt nergens uit, in ieder geval.

En iemand die GPUs en CPUs tot op het transistorniveau vertaat kan geen oordeel vellen over PPUs?

Misschien wel (ligt eraan wat hij van de PPU weet en begrijpt), maar jij bent blijkbaar niet zo iemand.
Maar eigenlijk is de kwestie vooral eentje van high-level code. Jij komt over als iemand die alleen lowlevel begrijpt, en nooit daadwerkelijk code voor dergelijke hardware hebt geschreven. Je lijkt absoluut geen inzicht te hebben in *hoe* een applicatie die hardware gebruikt. Anders zou je niet zo overdreven met allerlei specs, timings en theoretische maxima komen, die weinig zeggen over hoe de applicaties in de praktijk draaien.
Een mooi voorbeeld is de memorycontroller van de Athlon64. Deze heeft theoretisch meer bandbreedte dan de chipset+FSB van Intel.
In iedere benchmark die puur de maximum doorvoer in het ideale geval test, wint de Athlon64 ook makkelijk van de Core2 Duo.
Maar er is geen enkele, maar dan ook helemaal geen een applicatie waarin de Athlon64 beter presteert dan de Core2 Duo... ook al zijn dit behoorlijk geheugen-intensieve applicaties. Jij kijkt niet verder dan de specs, dus jij zou beweren dat de Athlon64 de snellere processor is. Ik kijk naar de applicaties en ik zeg "Nee, applicaties zijn van veel meer factoren afhankelijk dan alleen de maximum doorvoer van het geheugen".
Jij mist gewoon dat inzicht. Wat nog erger is, je ziet ook niet in dat je dat inzicht niet hebt, en je ratelt maar door.

Als je echt verstand van zaken had, zou het niet eens ter sprake hoeven komen of je ooit bij nVidia stage hebt gelopen of niet. Blijkbaar red je het niet op je kennis alleen.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 00:28]

[Verwijderd]

De mensen bij Microsoft weten toch ook niet hoe mijn Windows-applicaties werken? En ze hebben nog wel Windows gemaakt!

NVIDIA en ATI krijgen zo goed als alle games te zien voor die gereleased worden. Zo kan men dus problemen met de driver voorkomen, en optimalisaties voorzien die afgestemd zijn op de noden van de games. Denk ook aan TWIMTBP, een programma voor dichte samenwerking tussen NVIDIA en game developers. Bij een probleempje belt men al gauw naar de game studio om uitleg te vragen, en anderzijds helpen de IHV's de game developers om hun spellen goed te optimaliseren. Soms worden zelfs delen van de code van de engine naar de IHV's gestuurd. Dat is dus niet te vergelijken met Microsoft Windows.

Bovendien is het aantal grafische effecten nog steeds eindig. Bijvoorbeeld HDR wordt steeds vaker toegepast en is dus ook goed gekend binnen NVIDIA en ATI. Het is dus van extreem groot belang dat ze wel degelijk weten hoe de applicaties te werk gaan, en vooral wat de prestatiekarakteristieken zijn. Niet alleen de software (drivers) maar ook de hardware wordt erop afgestemd.

Dit is dan ook zeer goed door te trekken naar physics. Dat staat zelfs eerder in z'n kinderschoenen tegenover graphics.

Dat blijkt nergens uit, in ieder geval.

Grafische drivers zijn extreem complex, en zonder goede contacten tussen alle partijen zou men veel bugs tegenkomen en/of significant lagere prestaties halen. WHQL certificatie is echt niet genoeg, en dat bestaat letterlijk uit miljoenen tests.

[Verwijderd]

Physics cards zijn overbodig, aangezien de 8800 een onboard physics module heeft

[stewie]

het is geen physics module, het maakt gewoon gebruik van de unified shaders.

[HKS-Skyline]

klopt, de GPU van de 8800 kaarten is ook in te zetten voor andere berekeningen dan alleen de grafische, en is dankzij de unified shaders erg goed in physics berekenen.

[Proxy]

Klopt, maar met de 2e SLI-aansluiting kan alsnog een PPU-kaartje worden aangestuurd.

[aegis]

nee volgens mij kon het alleen maar 2 of 4 nvidias

[Sdu7cb]

De chipsets voor sli ondersteunen het dan nog altijd niet, is toch wel een must lijkt me

[DJMurtz]

Hoeveel procent boost krijg je eigenlijk met de huidige Crossifre(/Sli) chipsets? Ik krijg namelijk vaak te horen dat Crossfire bij lange na niet betekend dat je 2x zo snelle CPU krijgt, maar hoeveel is het dan wel?

80% is namelijk best redelijk, dan zijn twee H2900XT kaarten ipv één 8800GTX Ultra misschien wel veel leuker om aan te schaffen voor bijna dezelfde prijs.

[M2M]

uhhh 2x zo snelle cpu... echt niet

en dan daarbij, je processor, of je geheugen wordt dan de bottleneck van elke game.

dan zakt je framerate nog in omdat je cpu het niet kan trekken

[HugoBoss1985]

Ik heb ooit een setup met 2 kaarten gehad (SLI) en ik begin er niet meer aan, zonde van het geld... koop ik later liever een betere single kaart.
Wel ziek hoor, die 1500 watt voeding!