Nvidia: omzetting Ageia's Physx-engine naar Cuda bijna voltooid

De omzetting van Physx-engine naar het Cuda-platform verloopt volgens Nvidia voorspoedig. Tijdens een demonstratie van de fabrikant bleek de technologie tien keer zo snel als Intels Nehalem bij natuurkundige berekeningen.

Half februari maakte Nvidia bekend dat de Physx-api geïntegreerd zou worden in zijn gpgpu-systeem Cuda. Aangezien Cuda door de Geforce 8- en 9-serie wordt ondersteund, zal het aantal gebruikers van Ageia's physics engine toenemen van 150.000 naar acht miljoen, schat TG Daily.

Om de rekenkracht op het gebied van physics bij zijn Geforce 8800- en 9800-kaarten te demonstreren, voerde Nvidia een demonstratie uit die Intel eerder hield om de kracht van zijn octocore Nehalem-platform te demonstreren. Intel liet zien dat het platform zonder gpu 50.000 tot 60.000 afzonderlijk bewegende deeltjes kan weergeven op 15 tot 20fps. De demonstratie lokte de uitspraak uit van een van de ontwikkelaars van Intel dat cpu's binnenkort zo krachtig zijn dat systemen geen gpu meer nodig hebben.

Nvidia's demonstratie moet dan ook gezien worden als een poging om aan te tonen dat het nog lang niet zover is. Op een Geforce 9800 voerde het bedrijf de test uit met 65.000 deeltjes op 300fps. Aangezien de kans groot is dat Nvidia het aantal shader units gaat verdubbelen bij zijn komende GT100/200-architectuur, zou het bedrijf nog dit jaar 600fps kunnen halen bij de demonstratie, zo is de verwachting.

Reacties (75)

[mvds]

Allemaal leuk, die wedstrijdjes verpissen. Maar het zal tijd worden dat physics een echte rol gaan spelen in spellen. Dus een volledig verwoestbare omgeving bijvoorbeeld, waarbij je het de tegenstander lastig kan maken door bepaalde routes onbegaanbaar te maken. Of dat je met een tank door muren heen kan schieten zoals in het echt ook kan. Ik noem maar wat voorbeelden.

Tot nu toe zijn ze nog niet erg ver gekomen met physics in spellen, en dat is erg jammer. Leuk dat ze laten zien hoeveer fps ze kunnen halen, maar ze moeten er ook een fatsoenlijke toepassing voor vinden.

@Tab0en & rickhave0
Dat is inderdaad het andere uiterste, als ze iets gaan maken puur om te laten zien wat ze kunnen met physics, maar dan is de gameplay weer ver te zoeken.

[Reactie gewijzigd door mvds op 23 juli 2024 16:45]

[t_captain]

Voordat de games industrie dit onderwerp echt gaat aanpakken, is er een installed base nodig van een flink aantal gamers dat beschikt over voldoende physics rekenkracht.

Wat dat betreft zijn CUDA en Nehalem niet alleen concurrenten maar ook twee wegen naar hetzelfde Rome. Beide technologieen gaan zorgen voor een toename van het aantal physics-accelerated gebruikers.
Als het goed is, wordt de technologie op DirectX niveau transparant, net zoals bijvoorbeeld 3D acceleratie nu. Dan hoeft de game developer geen twee keer hetzelfde wiel uit te vinden, dezelfde game moet gewoon draaien met Nehalem en CUDA systemen.

Persoonlijk vermoed ik dat CUDA de oplossing voor de high-end systemen gaat worden en Nehalem voor de budget markt; het afschaffen van gespecialiseerde chips t.b.v. een iets snellere processor belooft goedkopere systemen dan de nVidia aanpak.
En wat betreft de Ageia chip, ik denk dat er een generatie high-end videokaarten gaat komen die een GeForce en een PhysiX bevatten op een PCIe plank. Voor de verdere toekomst denk ik dat PhysX gaat worden geintegreerd in de GeForce GPU.

[BramT]

En wat betreft de Ageia chip, ik denk dat er een generatie high-end videokaarten gaat komen die een GeForce en een PhysiX bevatten op een PCIe plank. Voor de verdere toekomst denk ik dat PhysX gaat worden geintegreerd in de GeForce GPU.

Niet helemaal dus, de Ageia chip gaat helemaal verdwijnen. Ze gaan PhysX 'software' aandrijven mbv de geforce-chips (dmv dat Cuda-platform dus). De architectuur van GPU's leent zich vele malen beter voor dit soort dingen dan CPU's (zie bericht).

Wat ik eigenlijk mis in dit bericht is of straks inderdaad alle PhysX-titels door alle geforce 8 en 9 kaarten ondersteund gaat worden (UT3 engine!). Volgens deze uitspraak lijkt het er wel op. Wat dus erg goed nieuws is voor geforce-bezitters

Ik ben erg benieuwd wat voor performance-verschil het gaat opleveren in ieder geval. Minder GPU kracht voor puur het grafische werk versus veel snellere physics-berekeningen...

[SG]

Nou halfom.
De PPU is op 'n hostile manier gekort wiekt. Maar nV heeft de patenten en tech nu in portifolio. nVidia zal hun grote Unifiedshade coprocs daarvoor gebruiken.
Wat PhysX SDK is gewoon 'n vervanger voor HavokFX.
Later kunnen de GPU architekturen de Unified shader verder geoptimaliseerd worden voor alle vier de taken. Geo Vertex pixel én physX. Ageia technieken kunnen dus hun weg vinden naar unified shaders.

Dus zou in kunnen houden dat Unified shaders 'n kleine eigen Local mem krijgen zoals Cell en PPU hebben en 'n hoge interne banbreedte tussen de unit's dat is wat physics nodig heeft. Wat PPU wel heeft en CELL weer niet.

[Garma]

dit is zeker niet alleen handig voor games. Ik ken echt talloze toepassingen in de wetenschap waar snelle systemen voor het uitrekenen van deeltjesgedrag echt een uitkomst zou zijn.

CUDA is _de_ uitkomst voor dit soort berekeningen vanwegen de parallele natuur van de GPU's en de algoritmes. vroeger zaten we een beetje slim shaders te programmeren, met CUDA wordt het allemaal een stuk serieuzer om GPU's te gebruiken voor lange berekeningen.

edit: Overigens, over dat alles kapot kunnen maken, als je dat implementeerd moet je erg goed nadenken over de gameplay natuurlijk. Wat wou je doen, naar amsterdam lopen in-game ofzo?

[Reactie gewijzigd door Garma op 23 juli 2024 16:45]

[SG]

Cuda is niet meer dan 'n door ontwikkeling van Cg.
'n programmeer taal voor nV shaders.
zoals HSML de markt standaard is.
En wat low level Lib's. Om devs op gang te helpen.

Cuda is geen wonder middel. Maar shader in C styl coderen ipv nV shader assembler.

Zoals we nu met CPU nog hoger level programmeer talen gaan.
Is bij shader die trend ook.
'n Programmuer kan makkelijker met C 'n routine voor elkaar krijgen dan met ASm.
Sneller workflow vs mogelijk iets minder performance.
Men is dan meer bezig met de effect die men voorelkaar wil krijgen dan met nV hardware de shaders aan te spreken.

Ik zie liever dat 'n standaard API of compiler voor shaders word nagestreven.

Cuda zie ik meer als nV tegenhanger van iNtel C compiler plug in.

Liever had ik gezien dat de HavokFX ATI en nV neutrale GpGPU Physics SDK zou komen.
Nu wordt het dus wachten op Physics component in dX11

[Snoitkever]

Ik weet niet waar je je kennis op hebt gedaan, maar ik kan je aanraden toch weer eens de boeken in te duiken.

Cuda is niet meer dan 'n door ontwikkeling van Cg.
...
Cuda is geen wonder middel. Maar shader in C styl coderen ipv nV shader assembler.

Cg heeft niks met Cuda te maken. Cg is een high level shader language, voor korte vertex en pixel shaders. Het heeft een vaste set instructies op een gelimiteerde stroom informatie, waarbij het lezen uit het geheugen beperkt is tot het samplen van een texture, en het schrijven alleen kan door een of meerdere waardes weg te schrijven naar een pixel. Cg wordt bij het compileren omgezet naar OpenGL of DirectX shadercode, die op elke GPU kan worden uitgevoerd.
Cuda is een low-level taal voor high-performance computing. Het is een extensie van de C programmeertaal, en kan uit het geheugen lezen en er naar weg schrijven. Er is zelfs gedeeld geheugen tussen gelijk uitgevoerde threads. Cuda kan alleen worden uitgevoerd op NVIDIA's G80 en afgeleiden.

'n programmeer taal voor nV shaders.

CUDA heeft niks met shaders te maken, tenzij je de ALU's in een GPU shader wilt noemen, wat ze niet zijn. Shaders zijn korte programma's die de GPU uitvoert voor elke vertex, pixel en primitieve.

zoals HSML de markt standaard is.

Je bedoel HLSL neem ik aan?

Zoals we nu met CPU nog hoger level programmeer talen gaan.
Is bij shader die trend ook.

HLSL en Cg zijn high level talen, terwijl CUDA vrij low-level is. Shadertalen zijn vanaf de allereerste generatie assembler shaders al bijna direct overgestapt op high-level talen (Cg, HLSL, GLSL). Deze talen zijn amper aan verandering onderhevig, ze krijgen enkel wat extra features bij elke nieuwe shader model generatie.

'n Programmuer kan makkelijker met C 'n routine voor elkaar krijgen dan met ASm.
Sneller workflow vs mogelijk iets minder performance.

Er is geen enkele manier om assembler te programmeren voor NVIDIA GPUs.

Ik zie liever dat 'n standaard API of compiler voor shaders word nagestreven.

Gezien de gigantische verschillen tussen R600 en G80 denk ik dat je lang kan wachten. CUDA is juist zo snel omdat het vrij direct gelinkt is met de G80 architectuur.

[TheCapK]

Het voordeel van alles kapot maken in een game is dat je het de tegenstander moeilijker kan maken jou onverhoeds aan te vallen. Je zou ook een hinderlaag kunnen aanleggen door bv 3 van de 4 toegangswegen onbegaanbaar te maken en de laatste netjes onder vuur te leggen.
Mogelijkheden legio EN het sluit meer aan bij de werkelijkheid.
Zo zou je ook tegenstanders uit kunnen schakelen door een gebouw strategisch kapot te maken en de genadeklap te geven als de vijand erin zit.

[Verwijderd]

"Allemaal leuk, die wedstrijdjes verpissen. Maar het zal tijd worden dat physics een echte rol gaan spelen in spellen. Dus een volledig verwoestbare omgeving bijvoorbeeld, waarbij je het de tegenstander lastig kan maken door bepaalde routes onbegaanbaar te maken."

Het bestaat, en wel in UT3. In de speciale Physx-maps. Je kan alles stukmaken, dingen naar beneden laten komen.
En dit allemaal op een leuke 10 tot 20 fps, wat veel beter schijnt te zijn met Physx kaart, dus waarschijnlijk binnenkort ook met Nvidia kaart.

[Verwijderd]

Er Zijn al spellen waar je de omgeving volledig kan vernietigen,
Red faction 1 en 2 helaas zijn bijde spellen aan een still dood gestorven.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:45]

[SanderHG]

Echt volledig vernietigen zat er niet bij hoor, je kon wat gaten in de muur schieten en daar bleef het wel bij. behalve dat was het ook gewoon geen leuk spel, heeft er ook mee te maken dat het "aan een still dodo gestorven" is.

[Verwijderd]

Volgens mij waren de recensies voor red faction wel goed.
Speel het af en toe nog online het is gewoon heel leuk online te spelen.
Volgens mij is het gewoon aan een stille dood(dodo ) gestorven omdat het niet genoeg publicteit gekregen had.

[Verwijderd]

Toch zit er een derde deel aan te komen, dus laten we het een coma noemen

[Frituurman]

I.m.h.o. een vergelijking die kant noch wal raakt. Het vergelijken van de prestaties van een huidige CPU met dat van een high-end-GPU is per definitie oneerlijk, omdat er totaal verschillende belangen zijn. Feit is dat blijkt dat een CPU ook prima in staat is om GPU-taken uit te voeren op termijn. Natuurlijk staat de ontwikkeling v.w.b. GPU's ook niet stil, maar voor de casual gamer en de mensen die hun PC voor kantoor gebruiken, is het een grote winst als ze niet meer apart hoeven te shoppen naar een GPU die aan hun eisen voldoet. De markt lijkt me zo wel een stuk overzichtelijker te maken.

Dat gezegd hebbende, het maakt de markt ook weer wat voller. Weer een nieuw aanbod!

[MatthiasDS]

I.m.h.o. een vergelijking die kant noch wal raakt. Het vergelijken van de prestaties van een huidige CPU met dat van een high-end-GPU is per definitie oneerlijk, omdat er totaal verschillende belangen zijn.

Kant noch wal?
Eerst en vooral is Nehalem geen "huidige CPU". Ten tweede is het Intel dat die tests eerst heeft uitgevoerd om te tonen hoe snel hun CPU daarvoor is. Ten derde is op basis hiervan zelfs de uitspraak gekomen van Intel-ontwikkelaars dat de GPU overbodig zal worden.

Wel, dan vind ik dat Nvidia Intel toch maar even lik op stuk geeft door met een huidige GPU zomaar eventjes dik 15 keer sneller te zijn dan een toekomstige CPU en vind ik de vergelijking (gezien punt 2 en vooral punt 3) zeker opgaan.

[Yor]

Om even met een ander bijltje te hakken:

In mijn rig is simpelweg geen plek voor de physics kaart, alhoewel ik hem hier wel heb liggen.

8800 in sli, ertussen met moeite een XFI gevrot en dan houdt de ruimte op het mobo snel op. Voor mij dus reden om dat ene vrije pci slot te gebruiken voor de geluidskaart. Tenslotte haal ik meer plezier uit goed geluid dan dat ene spel waarvan de physics wel degelijk een meerwaarde bieden. Jammer maar helaas, ik zag liever dat Ageia die kaart op een pci-e 1 of 4 slot gemaakt had òf dat de mobo bouwers eens iets betere lay-outs produceerden.
Dan kon het wel eens zo zijn geweest dat meer gamers er 1 in hun rig hadden.

(tuurlijk kun je ook op singleslot watercooling overgaan, maar dat mag imho geen must zijn om én goede sound én sli met een physics kaart te draaien)

[SG]

Gebruik zelf onboard sound maar heb genoeg plaats voor beide. Maar heb aleen Asus P1 kaarten in elke PC.
De PPU is nu al bijna in mei 2 jaar oud. en dus zijn Produkt cycle zit er nagenoeg op.
tijd voor 'n andere PPU dat wordt dus 'n G92 chip iets met HDMI uitgangen?

Vraag me alleen af hoe AMDTI in het plaatje past.

[Shammah]

Is het misschien niet mogelijk om een deel van de physics te laten berkenen door the GPU, en het andere deel door de CPU? Hierdoor lijken mij de taken een beetje in balans wat voor meer stabiliteit zorgt. Helaas denk ik dat dit heel moeilijk is te programmeren?

[SG]

Nee. het beste is altijd om de veel beter chip voor de task de volledig task te laten doen. Met 'n performnace verschil van 10X is het veel efficenter om de GPU Physics volledig te doen.
Dit houd in dat de krachtige CPU zijn Game logic en mechanics task heel snel kan doen. zodat de GPU's voor renderen en Physics ook voldoende Time slice van elke frame beschikbaar hebben om 'n veel zwaardere taak te doen.

'n goede Physics game laat deze task volledig op de PPU doen.
'n snelle quadcore geeft het geheel ook 'nm boost in fPS.
Omdat de CPU computing tijd verkort wordt de PPU meer zijn ding kan doen zo ook 'n snelle GPU kanm renderen. En zo tot hoge FPS kan komen.

UnrealT3 PhysX benching van de PPU gaf dat al aan.

Bij 'n performance verhouding van 1:10 houd in dat je 10% ook op de CPU zou kunnen doen. Maar die 10 % is 'n hele zware load voor de CPU die dan 'n heel stuk langer doet over zijn CPU taken. En dat gaat af van de Physics en render computatie tijd per frame. Die 90% wordt dan 55% En De render task moet dan ook lichtere settings doen.

[Snoitkever]

Nee. het beste is altijd om de veel beter chip voor de task de volledig task te laten doen. Met 'n performnace verschil van 10X is het veel efficenter om de GPU Physics volledig te doen.
Dit houd in dat de krachtige CPU zijn Game logic en mechanics task heel snel kan doen. zodat de GPU's voor renderen en Physics ook voldoende Time slice van elke frame beschikbaar hebben om 'n veel zwaardere taak te doen.

Het ligt er maar aan waar de bottleneck van je game ligt. Als die bij je CPU ligt (wat niet vaak het geval is in moderne games) zul je inderdaad je CPU willen ontlasten door zoveel mogelijk op de GPU uit te voeren.
Als de bottleneck bij je GPU ligt is de sitatie complexer. Sowieso zijn er heel wat verschillende punten waar je game gelimiteerd kan zijn op de GPU (vertex, texture fetch, rasterizer, fillrate, etc). Afhankelijk van hoe de CUDA versie van PhysX werkt zou dit een groter of minder groot effect op je framerate hebben. In theorie zou je het verschil zelfs niet kunnen merken, maar die kans lijkt me heel klein.

Denk er wel aan dat de GPU en CPU parallel van elkaar werken. Dat betekent dat een hoge GPU load weinig tot niks zegt over de CPU tijd die beschikbaar is, en andersom. Het betekent ook dat het idee van Shammah helemaal niet zo slecht is.

[Snoitkever]

Is het misschien niet mogelijk om een deel van de physics te laten berkenen door the GPU, en het andere deel door de CPU? Hierdoor lijken mij de taken een beetje in balans wat voor meer stabiliteit zorgt. Helaas denk ik dat dit heel moeilijk is te programmeren?

Hoe lastig het wel of niet is hangt af van de flexibiliteit van het systeem. Als je een systeem wilt hebben dat afhankelijk van de huidige scene de inschatting kan maken of er op de GPU of CPU gerekend moet worden is dat inderdaad vrij lastig. Je moet dan constant data heen en weer schuiven tussen CPU en GPU om er voor te zorgen dat beiden op elk moment precies dezelfde gegevens hebben.
Als je een vooraf vastgelegd systeem wilt hebben wordt het een heel stuk haalbaarder. Dit was (volgens geruchten) ook wat Havoc's idee voor GPU physics was. Belangrijke effecten met gevolgen voor de gameplay worden op de CPU berekend, waardoor deze code direct geintegreerd kan worden met de gameplay code. Daarnaast worden enkel visuele effecten op de GPU berekend, waardoor je explosies, rook en vuur krijgt die er vele malen realistischer uit zien. De GPU kan deze effecten namelijk veel efficienter berekenen en weergeven, waardoor er veel meer particles op het scherm getoond kunnen worden.
Dit systeem heeft als bijkomend voordeel dat er geen tweerichtingsverkeer nodig is. De particle effects op de GPU hebben geen effect op de gameplay, dus is het alleen nodig om deze op te zetten, niet om er feedback van te krijgen. Dit is ideaal voor een GPU, want dit is analoog aan hoe graphics werken. Een GPU werkt asynchroon van de CPU, en feedback terug geven naar de CPU is bijzonder duur.

[FlowDesign]

Dus als ik het goed begrijp ondersteunen de GeForce 8- en 9-serie de Physx-api waardoor er geen aparte Physx-chip meer nodig is zoals deze eerst nog apart op een PCI(e) kaart in een systeem bijgestoken moesten worden?

Ja, dan is het wel matig dat game-ontwikkelaars nog maar weinig gebruik maken van deze mogelijkheden. Hoewel misschien is dat in zekere zin maar goed ook, want dan zouden niet veel mensen nog AMD kaarten kopen en krijgt nVidia haast een monopoly-positie.

[beany]

Veel spellen ondersteunen ook nog pre-8 kaarten. Call of Duty 4 bijvoorbeeld draait vanaf een 6600GT. Het is dus in het belang van de game ontwikkelaars om oudere kaarten ook nog te ondersteunen, dat maakt de verkoop verwachting wat hoger. Het is dus een kwestie van tijd denk ik. Als een 8 serie kaart de ondergrens is zullen physics op de GPU ook wat meer gemeengoed worden.

[Verwijderd]

Dit is echt een onzin conclusie om eerlijk te zijn, omdat Nvidia Physx geintegreerd heeft koopt niemand AMD meer.
1. De meeste consumenten weten helemaal niet wat Physx is.
2. AMD is natuurlijk ook met zijn eigen oplossing bezig.
3. AMD doet mee op 2 fronten, de GPGPU en de CPU

Intel gaat het alleen maar moeilijker krijgen (zelfde gaat voor AMD gelden) met de, langzaam maar zeker, onvermijdelijke toetreding van Nvidia tot de "CPU-markt" (en Intel in de "GPU-markt") Wat mij de afgelopen maanden echt opvat is dat de 3 "grote spelers" ieder een eigen benadering kiezen naar het zelfde punt, de "General Purpose Processor". Intel vanuit de CPU, Nvidia vanuit de GPU en AMD vanuit de combinatie.

Mijn conclusie: Heerlijk, meer concurrentie!

[Madrox]

Klopt. Uiteindelijk mondt het uit in een nieuw produkt. Een GPU die de de CPU overbodig maakt of andersom, een CPU die een GPU overbodig maakt is dat in mijn ogen.

Alles ertussen in zijn "extra features" op een bestaand concept.

[Verwijderd]

Snap niet dat Intel zo'n uitspraak zou doen. Het is de afgelopen paar jaren wel duidelijk geworden dat GPU's zo krachtig en veelzijdig zijn dat ze CPU's on-die kunnen ondersteunen en kwa rauwe rekenkracht zelfs sterker zijn dan CPU's.

[Madrox]

Zo veelzijdig zijn de GPU's niet, als je deze grafische programmeur mag geloven:

http://mainroach.blogspot...pu-vs-multi-core-cpu.html.

To be fully explicit about my opinion on this fact : GPGPU is nothing more than a hack. It appeared as a 'nifty trick' that one could use the GPU to help out with other processing requests, and snowballed into a catch-phrase that all APIs and IHVs are molesting as though it were their date at a drunken prom party.

Kon er wel om lachen, die vergelijking met een Marathon :-)

Die rauwe rekenkracht waar je over praat, is zeer specifieke rekenkracht; speciaal voor een handvol opdrachten bedoelt. De GPU is nooit bedoelt en daarom ook absoluut niet geschikt om de willekeurige, algemene taken van de CPU te doen.

Maar goed, cpu's en gpu's vergelijken is zoiets als appels met peren. Zodra je die twee combineert, heb je een nieuw produkt. Een Sinasappel.
Dat is precies waar bijv. AMD met Fusion op af stuurt. Niet echt revolutionair, maar meer een evolutie; beide core's worden verenigt op 1 Die, twee architecturen "naast elkaar geplakt" als het ware. Revolutionair is het als de hele CPU/GPU functionaliteit vanaf de grond af ontwerpt wordt in een enkele core. Wat nu niet het geval is met Fusion van AMD.

edit:
Dank je Shaidar ;-)

[Reactie gewijzigd door Madrox op 23 juli 2024 16:45]

[drahca]

Zo veelzijdig zijn de GPU's niet, als je deze grafische programmeur mag geloven:

Deze grafische programmeur is niet erg genuanceerd in zijn beweringen dat GPGPU een hack is. GPGPU is inderdaad ontstaan omdat veel mensen een enorm krachtige co-processor in hun systeem zagen zitten en ze de rekenkracht van dit ding ook eens wilden gaan gebruiken voor andere dingen dan games. Omdat GPU's alleen benaderd konden worden door een API als OpenGL en DirectX was het programmeren op deze chips wat gekunsteld. Nu zijn er betere alternatieven: NVidia heeft CUDA en AMD komt met Brook+ met CAL backend. Natuurlijk is een GPU voornamelijk een rasterizer, maar dat wil niet zeggen dat het concept van GPGPU een hack is.

Voor een medisch bedrijf heb ik bepaalde simulatiesoftware voor natuurkundige berekeningen omgezet naar zowel multicore processors (2 socket quad core Xeon) als een GPU (8800GTX) met behulp van CUDA. Een GPU was ruim 20 - 30 keer sneller in deze berekeningen dan 8 1.83Ghz Xeon (Core2) processoren! Vergelijk dit kostenplaatje eens en je zult tot de conclusie moeten komen dat een GPU toch wel een zeer gunstig geprijsde co-processor is. Bovendien biedt CUDA een zeer nette programmeer omgeving die ik toch echt niet zou willen typeren als hack.

Deze man beweert ook dat hij liever een aantal CPU's heeft met extra hardware voor grafische taken dan een GPU. Zodat je met de CPU's ook makkelijk andere nuttige dingen kan doen. Nou zo'n soort chip komt er en zijn naam is Larrabee. Wat deze man echter niet meeneemt in zijn verhaal is dat Larrabee ook een gespecialiseerde co-processor is. De single-thread performance van Larrabee zal niet kunnen tippen aan een Core2.

Naar mijn mening zal de GPU zich langzaam meer richting een algemeen toepasbare co-processor toebewegen dan nu het geval is, maar dat wil zeker niet zeggen dat GPGPU nu een hack is!

[Madrox]

Helemaal mee eens, maar nog steeds een CO-processor die alleen bepaalde, specifieke functies kan verwerken. Zeker geen Co-processor, die alle taken van een CPU aankan.

Maw: nog steeds niet zo veelzijdig als een echte central processing unit. Wat ook helemaal niet erg is, daarvoor is de GPU nooit bedoelt.

Het is idd geen HACK, het is een Feature !:+ (maar nog altijd geen volwaardig alternatief voor een CPU, wat sommigen denken)

[SG]

GPGPU in de toekomst zullen niet diezelfde beperkingen hebben als die van nu.

Zoals we ooit van Fix T&L naar PS1,4 gekomen zijn.
Ps2.0
PS3.0
En ergens GPGPU de kop opstak.

Nu op UNIFIED shaders 4,1 zitten.

Houd in dat Larrabree het tegen 'n hele andere generatie aan GpGPU unified shaders moet op nemen.

Die steeds meer true general purpouse zijn.

Ook mikt iNtel meer op Raytracing?
Rasteriser methode die nu gebruikt wordt kunnen door shader ook iets van ratracing doen. De GPU markt ziet meer in een hybride oplossing terwijl iNtel pure raytracing nastreefd.

De toekomst wordt iig heel interresant.

[Snoitkever]

Ook mikt iNtel meer op Raytracing?
Rasteriser methode die nu gebruikt wordt kunnen door shader ook iets van ratracing doen. De GPU markt ziet meer in een hybride oplossing terwijl iNtel pure raytracing nastreefd.

Ik weet niet waar je het idee vandaan haalt dat huidige GPU's raytracing kunnen, maar er klopt niks van. Verder kan Intel mooi hard roepen dat Raytracing de toekomst is, het slaat nog steeds nergens op. Raytracing biedt geen overtuigende voordelen ten opzichte van rasterizing en is vele malen langzamer. De enige reden dat Intel het graag noemt is dat het ontwetende consumenten mooi in de oren klinkt en het iets is dat de concurrentie (met name NVIDIA) niet kan. Desalniettemin zal Larrabee gewoon een rasterizing GPU worden.
Zelfs hybride oplossingen zullen de eerste paar jaar nog niet op de markt gezet worden, alleen al niet omdat het geen voordelen biedt.

[drahca]

Ik weet niet waar je het idee vandaan haalt dat huidige GPU's raytracing kunnen, maar er klopt niks van.

Ehm, misschien hier: [url]http://eric_rollins.home.mindspring.com/ray/cuda.html[/url]. Ok, het is nog niet praktisch of snel op dit moment vanwege de beperkingen van de G80 maar onmogelijk is het zeker niet.

Verder kan Intel mooi hard roepen dat Raytracing de toekomst is, het slaat nog steeds nergens op. Raytracing biedt geen overtuigende voordelen ten opzichte van rasterizing en is vele malen langzamer.

Ray-tracing is een veel natuurlijker manier om graphics te renderen dan rasterization aangezien het de werkelijkheid veel dichter benaderd. Kijk maar eens hier: http://www.openrt.de/gallery.php. De lichteffecten die je hier ziet zijn niet te doen met rasterization. Kijk vooral eens naar de Interactive Headlight Demo, dat ziet er toch prachtig uit. Verder schaalt raytracing lineair over meerdere conventionele processoren en kan je door het raytracen ook gebruik maken van de stralen voor realistische physics en collision detection en response.

Natuurlijk heeft raytracing nadelen en enkele problemen die opgelost moeten worden, maar het is slechts een kwestie van tijd voordat raytracing de standaard wordt, de vraag is alleen hoeveel tijd. Ik denk niet dat Larrabee daar tot in staat zal zijn, maar eventuele opvolgers van Larrabee kunnen dat misschien wel.

[Snoitkever]

Ehm, misschien hier: http://eric_rollins.home.mindspring.com/ray/cuda.html. Ok, het is nog niet praktisch of snel op dit moment vanwege de beperkingen van de G80 maar onmogelijk is het zeker niet.

Goed, misschien was mijn formulering overtrokken, maar huidige GPUs zijn niet gemaakt en amper geschikt voor raytracing. Raytracing is zelfs op een GPU nog ordes langzamer dan rasterizing.

Ray-tracing is een veel natuurlijker manier om graphics te renderen dan rasterization aangezien het de werkelijkheid veel dichter benaderd

Mee eens.

De lichteffecten die je hier ziet zijn niet te doen met rasterization.

Daar ben ik het dan weer niet mee eens. Kijk een wat voor geweldige belichting Geomeric's Enlighten geeft. Dat is real-time radiosity op zowel PC, PS3 als Xbox 360. En Geomeric is niet de enige.

Verder schaalt raytracing lineair over meerdere conventionele processoren

Daarmee doe je net alsof rasterizing niet goed schaalt. Vrijwel alle onderdelen uit de traditionele rasterizing pipeline zijn parallel uitvoerbaar, dus als je de hoeveelheid transistors verdubbelt zul je ook een verdubbeling van performance zien. Wat betreft bandbreedte voor onder andere textures ligt het verhaal misschien iets anders, maar bij raytracing is bandbreedte net zo goed een probleem, objecten moeten ook getextured worden.
Daarnaast zijn meerdere CPUs per systeem natuurlijk leuk voor Intel's demonstraties, het is niet iets wat je bij doorsnee consumenten zult zien.

kan je door het raytracen ook gebruik maken van de stralen voor realistische physics en collision detection en response.

Voor collision detection en physics wordt juist vrijwel altijd gebruik gemaakt van simpele modellen, om de hoeveelheid rekenwerk te verminderen. Nu zou je kunnen argumenteren dat een gespecialiseerde raytracing processor (zoals Larrabee) dit zou kunnen versnellen, maar dan zit je weer met synchronisatieproblemen en (nog erger) pipeline stalls. (Rendering zal waarschijnlijk altijd een asynchroon proces blijven, zelfs al draait het op dezelfde processor)

Natuurlijk heeft raytracing nadelen en enkele problemen die opgelost moeten worden, maar het is slechts een kwestie van tijd voordat raytracing de standaard wordt, de vraag is alleen hoeveel tijd.

Het probleem bij raytracing is tweevoudig. Ten eerste is er vrijwel niets in raytracing dat niet ook gewoon met rasterizing gedaan kan worden. Reflecties en lichtbreking zijn makkelijk en goedkoop te doen met losse (kleine) rendertargets, radiosity lighting is zeker te doen, soft en hard shadows zijn prima, op wat artifacts hier en daar na. Bij al deze effecten geldt dat ze enorm goed schalen, ten koste van artifacts en beeldkwaliteit.
Ten tweede is er het snelheidsprobleem. Hoe je het ook wendt of keert, raytracing is ordes langzamer dan rasterizing, zeker op gespecialiseerde hardware. Tegen de tijd dat Intel een chip heeft die real-time een scene met een paar miljoen polygonen kan weergeven kunnen NVIDIA en ATI al weer een veelvoud van die hoeveelheid polygonen tekenen. Er is gewoon geen enkel aspect van raytracing dat er voor zal zorgen dat het met de tijd rasterizing zal inhalen. Beiden zijn "embarrassingly parallel", beiden gebruiken een flinke hoeveelheid texturebandbreedte, beiden gebruiken shadercode voor complexe effecten (zonder shaders zouden alle geraytracede oppervlakken er hetzelfde uit zien, dus dat is net zo goed een vereiste voor raytracing. Bij rasterizing heb je hier het toegevoegde voordeel van betere caching en snellere operaties door interpolatie), en beiden schalen ze relatief lineair afhankelijk van de complexiteit van de scene. Intel en andere raytracing fans roepen al jaren dat raytracing komt, zo gauw pc's er krachtig genoeg voor zijn. Maar wanneer de pc dan eindelijk real time al die mooie graphics uit bijvoorbeeld Quake 4 kan laten zien is het al hopeloos verouderd. Crysis ziet er zo ontzettend veel mooier en realistischer uit dan wat dan ook op het gebied van realtime raytracing.

Misschien dat er over tien jaar, als iedereen 16nm chips heeft, als Intel geen flauw idee meer heeft wat ze met die miljarden transistors moeten en als consumenten geen flauw idee meer hebben wat ze met al die GFLOPS aan rekenkracht moeten, misschien dat dan real time raytracing een fatsoenlijk alternatief is. Misschien dat de eisen van de consument en de mogelijkheden van de CPU tegen die tijd elkaar ontmoeten, zoals al eerder gebeurd is met audio, raid en netwerkchips. Maar die tijd ligt nog een heel eind weg. En zelfs dan ben ik niet overtuigd, want zouden er niet tien jaar geleden ook mensen zijn geweest die zich dat hadden afgevraagd over nu? "Wat moeten ze in godsnaam met zoveel megaflops?". Het antwoord is Vista draaien, en misschien nog een beetje Crysis

[drahca]

Je spreekt over shader modellen, maar dat zijn OpenGL / DirectX termen. De G80 heeft dan wel zogenaamde 'unified shaders', maar dit zijn niks anders dan 16 processoren met 8 ALU's in een SIMD array (16x8 = 128 'stream processors'). Die 16 processoren zijn nogal speciaal en niet rechtstreeks te vergelijken met de simpele x86 processoren van de Larrabee, maar het zijn processoren die in staat zijn om veel verschillende soorten berekeningen op uit te voeren.

Zo is de G80 zoals hij er nu is niet erg geschikt om mee te ray-tracen. De geruchten over de eventuele opvolger duiden al op een hoger aantal processoren met een kleinere breedte ( 50 processoren x 4 breed SIMD ) wat al iets beter is voor ray-tracen maar nog steeds minder optimaal dan het ontwerp van Larrabee dat volwaardige In Order processors aanbiedt met SMT om de latency van cache misses, die veel optreden in ray tracing, tegen te gaan en de executie units bezig te houden.

De toekomst wordt dus zeker interessant!

[Punkie]

Dit lijkt alleen maar zo indien je blijft vasthouden aan een tegenstelling van GPU en CPU. Echter zowel intel (met larrabee) als nvidia (met CUDA) schijnen te denken dat beide soorten berekeningen/architecturen wel op 1 chipje kunnen. En daar komen intel en Nvidia met elkaar in aanvaring. Daarom de uitspraak van intel, hun cpu (met extra gpu mogelijkheden) moet domineren.

[oenboek]

Nu nog een driver die de GPU gebruikt om de effecten van VST of DirectX plugins te berekenen. Dat zou het aantal mogelijke effecten een pak kunnen opdrijven, en weer meer mogelijkheden geven. Nu moet de CPU alles doen, en met wat complexere effecten is het aantal dan sterk beperkt.
Wie is er kandidaat om die VSTs te schrijven?

[.oisyn]

Daar zat ik ook aan te denken ja, maar dat gaat denk ik niet echt lukken met het huidige systeem, zonder je latencies te verhogen. En dat is nou net funest bij muziekapplicaties . Het probleem is dat je als VST een callback krijgt om data te genereren. Op dat moment moet je de GPU aan het werk zetten, en tot ie klaar is staat de CPU in feite uit z'n neus te eten, omdat je niet eerder uit je callback terug kan keren voor de data klaar is. Als je dat per VST moet gaan zitten doen is je hele parallellisatie weg, en neemt het aansturen van de GPU al snel veel teveel overhead in beslag.

Je zou wel alvast de volgende serie samples kunnen klaarzetten om te laten renderen door de GPU, en dan het resultaat van het vorige "frame" gebruiken om terug te geven. Maar dat betekent wel een delay van X samples per VST, en dan ook alleen voor de VSTs die op een dergelijke manier zijn opgezet. Alles gaat dus enorm uit sync lopen.

[b0On]

Wel leuk om te zien hoe intel met nvidia in de clinch ligt over het overbodig maken van een GPU.

Wat ik mezelf nu afvraag, wat merken wij als thuisgebruiker hiervan? Krijg ik nu meer FPS bij mijn games met mijn 8600?

[HaterFrame]

Dat is een mogelijkheid, het ontlast je CPU. Maar belast je Graka wel weer meer.

[SG]

Gezien Games meestal met enkele uitzonderingen vooral gPU afhankelijk zijn.
Houd in dat je lowbudged tot midrange GPU al zwaar nodig hebt voor het renderen.
Physics shaders verhogen de renderbelasting ook meer door wat er door physics gegenereerd wordt aan effect Physics of objecten.

Dus 'n voldoende krachtige G-kaart is dan gewenst zodat er wat shaders over zijn voor de physics taak. omdat het unified is kan dit realtime gebalanceerd worden.
Nog beter is 'n extra dedicated kaart. Zodat je bestaande kaart zich kan fixeren op de zware render taak. Physics kan ook weer 'n zware taak zijn als je die Extra GPU goed wil benutten. En ook heel ver kan opschalen.

Daar naast je cPU ontlasten van 'n Physics taak die CPU al aankon heeft weinig zin.
De zin zit meer in 'n zeer zware Phsyics load die het spel met meer phsyics verrijkt.

Je moet dat zien als COD4MW nogal Physics arm vs Cryis physics rijk.
Bij COD4mw heeft CPU ontlasten geen zin.
Maar 'n game als warmonger wordt 'n Physics accelerator wel benut.
Dat is ontlasten net zo efficent 'n 1 liter pak melk met heftruck tillen.
en in geval van warmonger 'n full V12 6.0i blok met 'n heftruck tillen

[darthdrinker]

Nee niet direct, maar je kaart krijgt wel meer mogelijkheden. Zo kan het in de toekomst zo zijn dat er spellen komen die hier heel intensief gebruik van gaan maken. In dat geval heb jij een kaart die dit ondersteund.

[kozue]

Of het is zo dat je nu betaald voor mogelijkheden die toch niemand gebruikt, en over een jaar al weer dood zijn, zoals die losse physx kaarten nu. Daar heb ik al nooit heil in gezien en het verbaasd me niet dat ze gaan verdwijnen. 150.000 verkochte exemplaren vind ik aardig wat overigens, voor iets wat eigenlijk bijna niks doet (het voordeel in spellen lijkt me niet al te groot en behalve een paar op 1 hand te tellen spellen, kun je het eigenlijk nergens voor gebruiken).
Tenzij je niks geeft om je geld kun je beter wachten en pas zoiets kopen op een moment dat je er niet meer om heen kan.

[SG]

150.000. Als resultaat door 'n hele grote Anti PR van ATI en nV die hun Fanbase al bij de PPU solutie al weg trok. zelfs voordat de PPU uitrolde ATI al met hun demo kwam. iNtel met hun Quadcore fabeltjes die ook veel iNtel fans weg trok.
Quadcore zou voldoende zijn voor PhysX. tuurlijk voor wat voor Phsyics load er nu gemiddeld in games wordt toegepast wel ja.
Games zoals Warmonger en UT3 PhysX heavy mappen laten zien dat 'n PPU zelfs te weinig is. Om 'n grote mix van verschillende physics effecten op grote schaal in de game wereld toe te passen ook mer fijne granulatie.

3DFX met hun Voodoo1 had in het begin al helemaal geen anti PR en ook geen beloftes van zeer zware spelers uit twee ander Chip markten.

3dFX kwam op ene goed moment in een situatie dat de markt het makkelijk kan op pakken. Daarnaast is GFX tov Physics.
1 ) Makkelijker te marketen.
2 ) Gamplay Physx geeft Net load dilemma's en dynamic pathing voor destructable envoirments.
Dat heet 3DFX siewieso mee en Ageia tegen.
Ageia PhysX idee van hardware accelerated Physics heeft zeker wel de markt goed opgepakt. ATI en nV nemen het over en nV neemt de voortouw.
Ageia als PPU chip is de neck omgedraaid. Uieindelijk zag ik de toekomst zeker somber in. Aangezien veel hun tegen zat. van het begin.

'n paar goede games die PPU van af begin zwaar zouden pushen bleven uit.
UT3 de top titel bleef lang weg en bood niet veel bijzonders. Dat is jammer.

Het grootste probleem van Ageia PPU is dat ze te laat zijn met hun idee en in het GPGPU tijdperk eerder slapende honden wakker gemaakt hebben. En door ene zelfs opgevroten zijn geworden.

Ik vind ageia idee geweldig.
Bij crysis waardeer ik ook de Physics zeer zwaar. Met hun inhouse ook deels GPU benuttende engine. Het heeft zeker ook invloed op de spel beleving.
GRAW 2 Ageia island gaf ook 'n kick.
Als games doordat de target platform zeer vergoot is door kwart tot halve teraflops aan dedicated physX power wat G8x en G9x kan bieden en daar dus ook aan Honderden Gigaflops aan Phyisics in game gaan stoppen.

Zodat zeer interactieve Speel werelden op grotere schaal dan ageia island worden toegepast. En er meer keuze is in games als warmonger en cellfactor. En dat ook andere AAA titles naast geweldige GFX ook diepgande Physics implementeren.
Dat juich ik toe. Interactieve Spel werelden

[groene henk]

Natuurlijk zal Intel het altijd moeilijk hebben om grafisch meer te doen met een CPU dan Nvidia met een GPU. Echter als Intel straks met een 80-core uitkomt, dan zou het verschil veel kleiner worden.

Als je eindelijk een 3D-GPU goed zou kunnen nabootsen, dan zou je dmv desktopvirtualisatie alle 3D-workstations kunnen opruimen. Je gebruikt dan alleen maar een paar krachtige servers met een zooi multi-cores erin, een aantal thin-clients ervoor

Weg met al die zware workstations die onder de tafel lawaai staan te maken en erg veel hitte afgeven!

Ik verwacht dat Intel op deze lucratieve markt zit te azen.

[Snoitkever]

Echter als Intel straks met een 80-core uitkomt, dan zou het verschil veel kleiner worden.

Tegen de tijd dat Intel 80 (20 keer zoveel als nu) cores op dezelfde ruimte krijgt als een huidige Core 2 chip kan NVIDIA 2560 "stream processors" op een chip bakken.

[knirfie244]

Intel heeft al lang een 80 core demonstreerd, gewoon een kwestie van de cores veel kleiner maken dan nu. Dan kan je per core wel minder dan wat een huidge core kan, maar de totale snelheid is (mits de software ervoor geoptimaliseerd is) hoger.

[drahca]

Dat de snelheid zonder meer hoger is is niet waar. Voor branch-heavy code kan je optimaliseren tot je een ons weegt maar deze code zal niet vooruit te branden zijn op een 80 core processor. De efficiëntie van bepaalde parallelle algoritmen zal wel hoger liggen op een dergelijk ontwerp, hoewel er over de implementatie van dit prototype bar weinig bekend is. Een 'vette' Out of Order chip als de Core2 zal voor de x86 ISA altijd te prefereren zijn voor taken zoals een browser, tekstverwerker, etc. In order x86, wat is wat jij bedoelt met 'minder', kan nooit snel zijn vanwege de inherente onmogelijkheid om parallelle instructies te schedulen en de geweldige 8 GPR's (16 voor x86-64). Zonder Out of Order en register renaming valt geen snelle x86 chip te maken. (nee, de Atom zal niet erg snel zijn in integer code).

NVidia hoeft niet zonder meer buitenspel gezet te worden door Intel. Vergeet niet dat Intel een 80 core processor op basis van het x86 instructieset moet maken, terwijl NVidia gewoon zijn RISC achtige architectuur kan gebruiken en ATI zijn VLIW architectuur.

Het nadeel van x86 is dat iedere processor extra transistors nodig heeft om de extra decode stappen uit te voeren om x86 instructies om te zetten naar micro-ops. Ze proberen dit met hun voorsprong in procestechnologie op te heffen maar het zou in principe voor de wereld veel beter zijn als we een krachtige SIMD co-processor zouden hebben op basis van een schoon instructieset.

De huidige G80 is ook in feite een 16 core processor, waarvan iedere processor een SIMD array is van 8 ALUs. Het zijn alleen nog redelijk simpele processors en door hun SIMD karakter zijn ze slecht is branches. Maar hun floating point performance is indrukwekkend en de G80 scoort qua efficiëntie beter dan andere soortgelijke ontwerpen. (Zoals die van ATI).

[Snoitkever]

Als ik groene henk goed begrijp is zijn argument dat chips straks veel meer (even krachtige) cores hebben, waardoor ze meer processorkracht 'over' hebben, en dus tijd kunnen besteden aan grafisch rekenwerk.

Die 80 core prototype chip van Intel haalt misschien een theoretische 1.28 TFLOP, het is verder nergens bruikbaar voor, laat staan standaard CPU werk.

[Verwijderd]

Lekker belangrijk allemaal,
als je videokaart physics doet doet ie geen graphics.
Zolang mensen niet tevreden zijn met de look van spellen (en dat zijn ze de komende 15 jaar nog niet) denk ik niet dat er een grote fanbase komt van het idee "okee het spel ziet er minder uit maar heeft wel GPU-physics!".

De graphics kun je namelijk laten zien in een screenshot bij een review.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:45]

[beany]

Het zijn de mensen die kaarten van 500 euro kopen die de kwaliteit enorm belangrijk vinden. Het meerendeel van de gamers gaat meer voor de speelkwaliteit.

Physics voegen een element toe aan het speelplezier, daardoor zullen mensen het meer waarderen dan extra belichting of nog meer anti-alias kwaliteit.

Een videokaart staat overigens nooit 100% voluit te draaien. Er zijn altijd reken-units die niks staan te doen. Waarom deze niet inzetten voor physics?

[Verwijderd]

Het merendeel gaat voor spelkwaliteit ? Really ?
Voor zover ik zie geilt iedereen op graphics & screenshots.

En overige rekenkracht gebruiken voor physics is prima, maar naar mijn mening is er dus weinig overige rekenkracht.
Spellen zijn nu bijna altijd videocard-limited, niet CPU-limited.

En als je dan "overige" rekenkracht kunt gebruiken voor physics, is het weer alleen voor eyecandy-physics en niet voor physics die daadwerkelijk invloed heeft op de gameplay.
Want als het invloed heeft op de gameplay moet het overal gelijk zijn (Multiplayer waarbij een speler in het nadeel is omdat er op zijn pc meer physics berekend wordt die het hem lastig maakt is vrij naar), en dan is het dus geen kwestie meer van "overige rekenkracht" maar van "benodigde rekenkracht".