Das Physik Chip Dilemma oder ...

[Demirug]

... warum ein Sportwagen im Stau auch nicht schneller ist.

Nach dem man nahezu ein Jahr lang immer wieder den Hype genähert hatte kam die Ernüchterung. Die Physik war zwar nun endlich da aber die Frameraten rutschten im Keller. Zur Ehrenrettung darf natürlich nicht verschweigen werden das mit der CPU alleine die gleichen Effekten sich noch vernichtender auswirken. Doch was nützen die schönsten Effekten wenn alles ruckelt auch wenn gerade kein Erdbeben simuliert wird? Scheinbar gibt es bei der Verwendung einer PPU ein Problem das hohe Frameraten unmöglich macht. Begeben wir uns also auf die Suche.

Betrachten wir dazu zuerst einmal ein Spiel ohne PPU Unterstützung das absolut CPU limitiert ist aber mit konstanten 50 FPS läuft. Das gibt uns 20 ms pro Frame. Nehmen wir nun weiterhin an das 20% der Zeit für die Physik und weitere 20% für die Ansteuerung der GPU benötigt werden. Das wären jeweils 4 ms. Die verbleiben 12 ms werden anderweitig genutzt.

Schritt 1: Outsourcing

Als ersten Schritt in unserem Gedankenspiel bauen wir nun eine PPU in das System und lagern die gesamte Physik auf diese aus. Wenn wir nun großzügig davon ausgehen das die Ansteuerung der PPU keine Rechenzeit auf der CPU braucht, was natürlich unrealistisch ist, brauchen wir nach dem Verlagern nur noch 16 ms pro Frame. Unsere Framerate ist also durch die PPU gerade auf 62,5 FPS gestiegen. Allerdings sehen wir nicht mehr als bisher auch.

Schritt 2: Mehr Physik

Nun haben wir die PPU aber eigentlich eingebaut um mehr Physik ins Spiel zu bringen. Da wir alle mal gerne etwas kaputt machen erlauben wir dem Spieler einfach mal das er die herum stehenden Gebäuden in Einzelteile zerlegen kann. Damit das auch nach etwas aussieht sollen es für den Anfang 250 Trümmerstücke sein. Kein Problem für die PPU und da wir ja CPU limitiert sind hat auch die GPU noch Luft. Zudem sind die einzelnen Trümer ja auch kleiner als das ganze Haus. Aber die Grafikkarte braucht trotzdem für jedes einzelne Stück eine Positionsangabe. Gehen wir nun davon aus das sich das Spiel vor dem Einbau der PPU an die Richtline nicht mehr als 500 Objekte pro Frame zu rendern gehalten hat wären wir nun bei 750. Da der CPU Aufwand für Grafik relativ linear mit der Anzahl der Objekte steigt können wir nun von 6 ms für die Grafik ausgehen. Das wären immerhin noch etwa 55,5 Frames. Leider zeigen Messungen am echten Spiel das die Anzahl der Objekte die an die GPU übertragen werden nicht um 50% steigt sondern auf das 3 bis Vierfache. Unser Aufwand für die Grafik steigt also eher auf 12 bis 16 ms. Da die Trümmer aber weitgehend jeweils mit den gleichen Setup der Pipeline gerendert werden ist es nicht ganz so schlimm. Trotzdem treiben die zusätzlichen Objekte den Aufwand nach oben und selbst wenn es nur 10 ms währen wir nur noch bei 45 FPS. Nutzt man nun die Leistungsreserve der PPU noch mehr entstehen ebenso mehr Objekte und die Framerate sinkt weiter.

Schritt 4: Zwischenfazit:

Unabhängig davon wie viel Leistung ein Physikchip hat wir können nur so viel davon nutzen wie CPU Leistung frei wird. Den wir brauchen diese Leistung um die zusätzlichen Objekte von der GPU rendern zu lassen.

Schritt 5: Die Suche nach Lösungswegen.

Zusammen mit dem Shadermodel 3.0 kam bei den GPUs auch die Unterstützung für Instancing. Damit lassen sich viele Objekte mit einem viel geringeren CPU Aufwand. Das Problem dabei ist aber das diese Erweiterung dazu gedacht ist viele gleichartige Objekte zu rendern. Wenn unsere Welt nicht gerade in baugleiche Lego Bausteine zerfallen soll ist Instancing keine Lösung.

Aber schauen wir etwas weiter zurück sehen wir das Direct3D schon lange eine als „Indexed Vertex Blending„ bezeichnete Technik unterstützt. Ursprünglich für Hardware T&L vorgesehen läßt sich diese Technik auch ganz leicht in einem Vertexshader implementieren. Dabei wird anstelle einer Transformationsmatrix für alle Vertices in einem Objekt eine Vielzahl bereitgestellt. In den Objekt Daten selbst kodiert man dann für jeden Eckpunkt welche Matrix benutzt werden soll. Damit wird es möglich ein Objekt in Einzelteile zu zerlegen aber es trotzdem als ganzen zu rendern. Limitiert wird die Anzahl der Teile dabei nur durch die Größe des Konstantenspeichers. Mit den 256 Werten die vom Shader Model 2 gefordert werden sind etwa 60 Teile möglich. Für ein Gebäude mit 250 Trümmern Teile wären so 5 entsprechende Objekte notwendig. Das sind zwar immer noch mehr als das Haus als ganzes aber wesentlich weniger als die 250 die man bisher gebraucht hätte.

Schauen wir in die Zukunft sehen wir dort Windows Vista. Microsoft und auch die IHV versprechen das die CPU kosten pro Objekt reduziert werden. In der gesparten Physikzeit ließen sich also dort mehr Objekte übertragen.

Noch weiter in der Zukunft haben wir Direct3D 10. Neben dem nochmal reduzierten Overhead erlauben die größeren Puffer Objekte auch dann noch als Ganzes zu betrachten wenn sie in sehr viele Einzelteile zerlegt werden.

Fazit:

Jede Physiklösung welche die Berechnungen von der primären CPU auslagert wird am Ende nur soviel zusätzliche Physik bieten können wie es die restlichen Flaschenhälse im System erlauben. Dabei ist gerade die gesteigerte Anzahl von Objekten ein großes Problem für die Grafik-APIs (mehr bei D3D als bei OpenGL) das mit entsprechenden Maßnahmen (Shader, Geometriedaten) entschärft werden muß. Wird eine Physiklösung dagegen schlecht ins Gesamtsystem integriert wird sie am Ende mehr CPU Zeit kosten als sie einspart.

Gerade für AGEIA könnte sich hier ein Problem ergeben. Da sie auf Physik spezialisiert sind ist fraglich in wie weit sie die Entwickler bei den nötigen GPU Implementierungen helfen können. ATI und nVidia dürften an diesem Punkt nicht sonderlich bereitwillig Support leisten da sie lieber ihre eigenen Physiklösungen pushen.

[Monger]

Danke für den Beitrag.

Sprich: die ziemlich miese Performance in Cellfactor war kein Treiberproblem, sondern ein systematisches Problem !?! Wir werden da erst Verbesserungen sehen, wenn sich auf Grafikschnittstellen /Grafikkartenseite was tut?

Hört sich nicht rosig an...

[TheGoD]

Demirug[/POST]']
Gerade für AGEIA könnte sich hier ein Problem ergeben. Da sie auf Physik spezialisiert sind ist fraglich in wie weit sie die Entwickler bei den nötigen GPU Implementierungen helfen können. ATI und nVidia dürften an diesem Punkt nicht sonderlich bereitwillig Support leisten da sie lieber ihre eigenen Physiklösungen pushen.

Deine Argumentation wäre, falls richtig, auch allgemein für ATI/NVidia sehr vorteilhaft, da mann dem Kunden mit einer im Vergleich zu Ageia leichtungswachen Lösung (z. B. eine Karte für Grafik und Physik oder eine x1300 aufwärts) bereits die gleiche Performance wie eine spezialisierte Hardware bieten könnte, da die CPU bei einer zu starken Mehrbelastung ohnehin limitiert.

[Gast]

eigentlich waere das das perfekte einsatzgebiet fuer dualcore, einfach die grafikkarten- und physikkartenansteuerung auf den 2. kern auslagern und gut is

[tombman]

ALso die NEUE Cellfactor demo (beta R36) rennt schon um einiges besser ;)
Man kann sogar MIT bots herumrennen und haufenweise Sachen in die Luft jagen.
Die Minimum-fps bei meinem 7sec Spezialbenchmark sind von 6fps auf 16fps gestiegen ;)

Und ich stimme dem Gast über mir zu. Einfach den zweiten core dafür benutzen und gut is ;) (in einem halben Jahr hat man dann per Kentsfield eh schon 4 cores, da wirds noch besser)

[Gast]

Hallo,

was du dir da ausgedacht hast ist echt an den Haaren herbeigezogen!

Wenn dem so wäre frage ich mich warum qualifizierte Entwickler, wie z.B. von Unreal, um nur einen NAMENHAFTEN Entwickler zu nennen, sich überhaupt die Zeit nehmen, einen Effekt für Ageia PhysX zu implementieren!

Eigentlich hätten sie ja, wenn deine Meinung der Realität entspricht, sofort lächelnd abwinken müssen!

Tut mir sehr leid Demirug, aber dein Beitrag gehört auf die Spielwiese!

:) Grüsse

[Gast]

Publishers, die dann keine Ahnung haben und PhysX integrieren! ;)

Akella
Atari
Aspyr Media
Buka Entertainment
Game Factory Interactive
HD Publishing B.V.
Microsoft Game Studios - XNA Studio, Xbox 360
Midway Home Entertainment
NCSoft Corporation
Noviy Disk
SEGA
Sony Computer Entertainment - PlayStation 3
Take-Two Interactive Software
Ubisoft Entertainment

[Gast]

Developers & Games - > die besser mal hier lesen sollten! ;)

Akella - Captain Blood
Airtight Games
Abyss Lights Studio - Abyss Lights: Frozen Systems
Artificial Studios / Immersion Games - CellFactor: Combat Training
- PhysX hardware support, LAN-only multiplayer, demo bundled with PhysX cards
- Click here to download the CellFactor demo
Artificial Studios / Immersion Games - CellFactor: Revolution
- Preliminary information about the game
Artificial Studios - Monster Madness
ASCARON Entertainment - Sacred II (and other next-generation titles)
Atari - Dragonshard
Atomic Elbow - Switchball
Big Huge Games - Rise Of Nations: Rise Of Legends
- Click here for demo
Black Element Software - Alpha Prime
Boanerges Studios
Bongfish Interactive Entertainment - Stoked Rider featuring Tommy Brunner
- Click here for demo mirrors
ChessBase - FRITZ 9 (and other upcoming titles)
Composite Studios - Ancient Galaxy
Crazy House - Tank Killer
Cryptic Studios - City Of Villains (and other next-generation titles)
- PhysX hardware support in a patch
Cyanide Studios - Loki
Destineer Studios
DiezelPower Studios - Dogtag
DIOsoft - Pirates of the XXI Century
EGN Interactive
Epic Games - Unreal Tournament 2007
- Will have PhysX hardware support (supposedly some levels require PhysX hardware)
FAKT Software - Crazy Machines II
FAKT Software - Gunship Apocalypse
Frantic Games - 1944: D-Day
Frogwares Game Development Studio
Futuremark Corporation - 3DMark06
Gaijin Entertainment
Game Consulting - Arena Online
GRIN - Tom Clancy's Ghost Recon: Advanced Warfighter
- Click here for demo mirrors
GungHo Online Entertainment - Rondo Projects
Icarus Studios - Fallen Earth
IceHill - Empire Above All
Illusion Softworks
Kuju Entertainment - Rail Simulator
Kylotonn - Bet On Soldier: Blood Sport & Blood Of Sahara expansion pack
- PhysX hardware support in a patch
Larian Studios
Legendo Entertainment
Meridian 93
Metropolis Software - INFERNAL (Diabolique)
MiST Land
Most Wanted Entertainment - Joint Task Force
Mythic Entertainment - Warhammer Online: Age Of Reckoning
Naked Sky Entertainment - RoboBlitz
NetDevil
Obsidian Entertainment
PerfectPlay Entertainment - Metathrone Project
Piranha Bytes - Gothic 3
- PhysX hardware support in a patch
Real Time Worlds
Shiny Entertainment Studio
Quantic Dream - KARMA & Heavy Rain
Ritual Entertainment
Secret Level
SEGA - GE2 Project (and other next-generation titles)
Sigil Games Online - Vanguard: Saga Of Heroes
Signature Devices
Spark Unlimited - New Pandora game *
Treehouse (Games Academy) - Fragfist
Widescreen Games
XL Games
YAGER Development - Eye Of The Storm

[Gast]

Game Engines, die alle NUTZLOS auf PhysX wären!

Artificial Studios - Reality Engine
Emergent Game Technologies - Gamebryo Element (Emergent Elements)
Epic Games - Unreal Engine 3
Dagor Game Engine
The Game Creators

[MuLuNGuS]

http://img96.imageshack.us/img96/2388/real7xv.jpg

[Demirug]

Schöne Copy und Paste Orgie bei der ich mich langsam frage ob AGEIA auch im deutschsprachigen Raum Leute für das Hypen in den Foren bezahlt.

Es dürfte aufgefallen sein das ich bis auf den letzten Absatz AGEIA nicht erwähnt habe und PhysX überhaupt nicht. Das angesprochene Problem haben nämlich alle Physiklösungen die versuchen die Detaildichte zu erhöhen. Den Begriff der PPU hat AGEIA auch nicht gepachtet ist gibt ältere Dokumente von nVidia in denen sie auch von einer PPU zur Beschleunigung der Physik sprechen.

Monger[/POST]']Danke für den Beitrag.

Sprich: die ziemlich miese Performance in Cellfactor war kein Treiberproblem, sondern ein systematisches Problem !?! Wir werden da erst Verbesserungen sehen, wenn sich auf Grafikschnittstellen /Grafikkartenseite was tut?

Hört sich nicht rosig an...
Es ist insofern systematisch dafür was passiert wenn man einfach die Anzahl der Objekte auf dem Bildschirm erhöht. Im gewissen Umfang kann man aber auch schon mit den aktuellen Grafik-APIs etwas tun. Mit D3D10 wird es aber einfacher werden.

Gast[/POST]']eigentlich waere das das perfekte einsatzgebiet fuer dualcore, einfach die grafikkarten- und physikkartenansteuerung auf den 2. kern auslagern und gut is
In diese Richtung geht es ja bei Vista. Der Grafik Treiber soll soweit wie möglich auf einem zweiten Core laufen.

Gast[/POST]']Hallo,
was du dir da ausgedacht hast ist echt an den Haaren herbeigezogen!
Mit denken hat das schon etwas zu tun. Schließlich mußte ich dazu die Ergebnisse der Analysen auswerten. Unabhängig von mir kam auch noch jemand anders zum gleichen Ergebnis.

Gast[/POST]']Wenn dem so wäre frage ich mich warum qualifizierte Entwickler, wie z.B. von Unreal, um nur einen NAMENHAFTEN Entwickler zu nennen, sich überhaupt die Zeit nehmen, einen Effekt für Ageia PhysX zu implementieren!
Eigentlich hätten sie ja, wenn deine Meinung der Realität entspricht, sofort lächelnd abwinken müssen!
Warum sollten sie abwinken? Wenn sie wissen das sie am Ende CPU limitiert sein werden können sie sich durch den Einsatz einer PPU ohne zusätzliche Effekt etwas CPU zeit erkaufen. Ein Argument das für viele schon ausreicht. Zudem kann auch namehaften Entwicklern der Fehler unterlaufen die Konsequenzen einer Veränderung in einem Teil der Engine (Physik) auf einen anderen (Graphik) nicht richtig vorherzusehen. Den Grafikentwicklern ist das 500 Objekt Limit so sehr in Fleisch und Blut übergegangen das sie darüber überhaupt nicht mehr reden. Die Leute die am Physikteil arbeiten haben davon vielleicht noch nie etwas gehört. Da sie bisher nie die Ressourcen hatten um so viele Objekte zu berechnen nicht verwunderlich.

Zeit ist ein gutes Stichwort den die brauchen die Entwickler um die anderen Teile der Engine entsprechend vorzubereiten. Zum Glück werden diese Änderungen am Ende jeder Physiklösung zu gute kommen.

Gast[/POST]']Tut mir sehr leid Demirug, aber dein Beitrag gehört auf die Spielwiese!
Das soll die Moderation entscheiden.

[Monger]

Gast[/POST]']Game Engines, die alle NUTZLOS auf PhysX wären!

Artificial Studios - Reality Engine
Emergent Game Technologies - Gamebryo Element (Emergent Elements)
Epic Games - Unreal Engine 3
Dagor Game Engine
The Game Creators

Ja Moment mal...
Nur weil jemand die Ageia Engine verwendet, heißt das noch lange nicht dass er voll auf die PhysX Hardware aufbaut!

Die Unreal Engine verwendet Ageia's Physik Engine, weil man Ersatz für Karma brauchte, und Havok wohl aus den einen oder anderen Gründen nicht so sympathisch war. Dass die Unreal Engine aber auf den PhysX Chip voll aufsetzt oder zumindest optimiert wäre, halte ich für unwahrscheinlich.

Die Physik-Engine von Ageia ist ja offenbar gar nicht übel. Nur ob sie mit Hardwarebeschleunigung signifikant schneller läuft, steht in den Sternen, und dürfte Epic & Co. wohl auch kaum interessieren! ;)

[Gast]

Demirug[/POST]']Schöne Copy und Paste Orgie bei der ich mich langsam frage ob AGEIA auch im deutschsprachigen Raum Leute für das Hypen in den Foren bezahlt.



Demirug,

eine "Ober-Peinliche" Unterstellung!

So etwas hätte ich von dir nicht erwartet!

Grüsse

[Aquaschaf]

Gast[/POST]']eine "Ober-Peinliche" Unterstellung!

Don't feed the troll, aber trotzdem: was soll man denn zu Copy&Past-Postings die nicht zum Thema passen sonst sagen?

[MegaManX4]

Alles schon und gut, aber "unterstützen" und "mehr Content durch PhysX" ist was anderes.

Was nützt mir das Fall wenn die PhysX Karte nur beschleunigt ohne mir etwas neues/besseres zu bieten?

[Gast]

Aquaschaf[/POST]']Don't feed the troll, aber trotzdem: was soll man denn zu Copy&Past-Postings die nicht zum Thema passen sonst sagen?

:) LOL

Dann sind 90% der Forumsschreiber vom Hersteller bezahlt!

Das Thema wird ja immer spannender, ich brauche nur ein bissel hier zu suchen um einige Beiträge von Usern zu zeigen, die eine Produkteigenschaft hypen und Links einfügen. Die Links die ich verwendet habe sind alle von dieser Seite, stand schonmal irgendwo sogar hier drin.

http://personal.inet.fi/atk/kjh2348fs/ageia_physx.html

Die ganzen Links stehen dort schön untereinander aufgereit!

Dort habe ich copy und past ausgeführt um Demirugs Meinung zu wiederlegen!

Grüsse

[Demirug]

Gast[/POST]']Demirug,

eine "Ober-Peinliche" Unterstellung!

So etwas hätte ich von dir nicht erwartet!

Grüsse

Scheinbar stecke auch ich noch voller Überraschungen wenn ich in der Lage bin Dinge zu tun die man nicht von mir erwartet. Allerdings mag dem geneigten Leser auffallen das ich niemandem persönlich den Vorwurf gemacht habe sich bezahlen zu lassen. Denn dann hätte ich etwas anderes geschrieben wie zum Beispiel: „Schöne Copy und Paste Orgie. Wie viel bezahlt AGEIA dafür das du das hier postest?“

Das wäre denn eine Unterstellung gewesen. So war es allerdings nur eine allgemeine in den Raum geworfene Frage die mir eben in den Sinn kam als ich wieder einmal diese Listen sah

Wenn sich jemand deswegen persönlich angegriffen fühlt so war das nicht meine Absicht. Aber im Zweifelsfall soll die Moderation das klären.

[Gast]

Ich empfehle das Demirug seine Anschuldigung löscht und ein Admin dann meine Beiträge löscht! Dann kann ich mich auch auf seine Argumentation einlassen, so bin ich jetzt nur "pissed off" darüber!

[derMeister]

In der Unrealengine kam bis jetzt auch immer eine sehr gute Physikengine zum Einsatz. Man könnte die Figuren und Fahrzeuginteraktion schon als vorbildlich ansehen :rolleyes: .
Die Engine in FEAR finde ich ebenfalls sehr gut ( an die Wand nageln :biggrin: )
Also ich weiß nicht wie es euch geht, aber wenn ich nen Shooter zog, brauch ich keine einstürzenden Gebäude, jedenfalls noch nicht :biggrin:
*EDIT*
Bleibt doch mal topic, auch als gast.

[Gast]

derMeister[/POST]']
Die Engine in FEAR finde ich ebenfalls sehr gut ( an die Wand nageln :biggrin: )Konnte man schon auch in Nolf1.

[Demirug]

Gast[/POST]']Dort habe ich copy und past ausgeführt um Demirugs Meinung zu wiederlegen!

Ich bin verwirrt. Welche meiner Meinungen zu diesem Thema kann durch eine Liste die im Wesentlichen angekündigte Spiele enthält wiederlegen?

Ich habe hier auch eine schöne Liste von nVidia mit angeblichen Shader Model 3 Spielen. Die Realität sah leider anders aus. Aber ich gehe in diesem Fall aus guten Gründen einfach mal davon aus all die aufgeführten Spiele am Ende wirklich eine vorhanden PhysX Karte nutzen können. Da ein Großteil davon aber noch gar nicht käuflich zu erwerben ist kann man sie schlecht als Beweis heran ziehen das dort der von mir Beschriebene Effekt nicht auftritt. Wenn er das am Ende dann nicht tut werte ich das als sicheres Zeichen dafür das bei dem entsprechenden Spiel auch die Grafikengine angepaßt wurde. Man darf mich dann mit entsprechendem Beweismaterial natürlich widerlegen.

Zudem sollte doch auch aufgefallen sein das ich mit keinem Wort gesagt habe die PhysX Karte wäre nicht in der Lage Daten für mehr Frames pro Sekunden zu liefern. Ich behaupte und bin dabei wie gesagt nicht der einzige das die CPU aufgrund der momentanen Treiberarchitektur für GPUs nicht in der Lage ist die Datenmenge (bzw. Objektmenge) zum Grafikchip zu übertragen.
Desweiteren sollte durch mein zugebener Maßen technisch etwas anspruchsvolleres Beispiel das ich wohl noch ausführlicher hätte darlegen sollen verständlich sein das ich die Lage keineswegs als Hoffungsloss darstellen wollte. Man darf allerdings auch nicht den Fehler machen zu erwarten dass nur durch den Einbau einer PhysX Karten und die Verwendung der PhysX Engine plötzlich schöne neue Welten entstehen. Wird es von den Entwicklern nur lieblos reingepfutsch um etwas von dem Hype abzubekommen wird es Katastrophal enden. Das gilt natürlich auch für jede andere Art von Physiklösung die sich zusätzliche Rechenleistung zu nutze macht.

Den einzigen Vorwurf den ich AGEIA mache ist das sie eben diese Problematik verschweigen. Da sie aber Ihre Chips verkaufen wollen und dafür Entwickler gewinnen müssen ist es nur zu verständlich das sie lieber nichts sagen. Aber gut heißen muß ich das deswegen trotzdem nicht.

[StefanV]

Wie schauts mit Dual Core aus??

Könnte man das ganze nicht durch die Verwendung von mehreren CPUs entschärfen?

[Demirug]

StefanV[/POST]']Wie schauts mit Dual Core aus??

Könnte man das ganze nicht durch die Verwendung von mehreren CPUs entschärfen?

Das Problem bleibt das gleiche. Was immer eine Physiklösung berechnet sobald man etwas davon sehen will muß es zur Grafikkarte. Dummerweise ist das übertragen von Kommandos an die GPU aus mehr als einem Thread sehr problematisch. Man läßt besser die Finger davon. Zudem stammen die meisten Engines auch noch aus der der Singel core Zeit sind also so programmiert das sie nur einen Gameloop haben. Dadurch laufen die Spiellogik und die Grafiksteuerung leider zusammen in einem Thread und damit auch nur auf einem Core.

Wie gesagt will Microsoft bei Vista zu mindestens den Treiber transparent auf einen anderen Core auslagern.

[StefanV]

Ich meinte auch nicht das man diese Aktionen Multithreaded schreibt sondern gleich einem anderen Core zuordnet (ergo: einen für Berechnungen, einen für I/O shit).

[Demirug]

StefanV[/POST]']Ich meinte auch nicht das man diese Aktionen Multithreaded schreibt sondern gleich einem anderen Core zuordnet (ergo: einen für Berechnungen, einen für I/O shit).

Die einzige Möglichkeit Arbeiten auf einen anderen Core verlagert zu bekommen ist der Einsatz von Multithreading.

[Jesus]

Demirug[/POST]']Das Problem bleibt das gleiche. Was immer eine Physiklösung berechnet sobald man etwas davon sehen will muß es zur Grafikkarte. Dummerweise ist das übertragen von Kommandos an die GPU aus mehr als einem Thread sehr problematisch. Man läßt besser die Finger davon. Zudem stammen die meisten Engines auch noch aus der der Singel core Zeit sind also so programmiert das sie nur einen Gameloop haben. Dadurch laufen die Spiellogik und die Grafiksteuerung leider zusammen in einem Thread und damit auch nur auf einem Core.

Ist das Problem bei den neuen Konsolen ähnlich, oder hat man da mehr freiheiten was die Kommunikation CPU/GPU angeht? Rein von der Bandbreite her müssten sich doch Konsolen da deutlich leichter tun...

[Demirug]

Jesus[/POST]']Ist das Problem bei den neuen Konsolen ähnlich, oder hat man da mehr freiheiten was die Kommunikation CPU/GPU angeht? Rein von der Bandbreite her müssten sich doch Konsolen da deutlich leichter tun...

Auch von der API her. Auf einer Konsole entfallen ja solche Sachen wie Treiber.

[Ronny G.]

Das ist doch bloß wieder Abzocke, oder es steckt noch viel zu sehr in den Kinderschuhen.

Ghost Recons neuer Titel läuft mit angewander PhisikKarte/engine langsamer als ohne!Und nicht nur 1%! Also, was soll das?

Gruß Ronny G.

[deekey777]

Ronny G.[/POST]']Das ist doch bloß wieder Abzocke, oder es steckt noch viel zu sehr in den Kinderschuhen.

Ghost Recons neuer Titel läuft mit angewander PhisikKarte/engine langsamer als ohne!Und nicht nur 1%! Also, was soll das?

Gruß Ronny G.
Läuft GRAW generell mit der PPU langsamer oder nur bei dem PPU-Einsatz? Eher das zweite: nur wenn die PPU zum Einsatz kommt.

[Monger]

DK777[/POST]']Läuft GRAW generell mit der PPU langsamer oder nur bei dem PPU-Einsatz? Eher das zweite: nur wenn die PPU zum Einsatz kommt.

Es sieht ja auch besser aus. Aber imho sehr, SEHR marginal.

[Android]

Demirug[/POST]']Die einzige Möglichkeit Arbeiten auf einen anderen Core verlagert zu bekommen ist der Einsatz von Multithreading.

Innerhalb einer Anwendung kann man auch auf einzelne Kerne komplett auslagern, wenn eine spätere Synchronisierung erfolgt. Hier kann zwar ein kleiner Overhead enstehen, aber möglich ist es.
Immer wieder ein schönes Beispiel ist hier Nuendo.

Zur Physik:
Die Implementierung von PhysX ist weitaus einfacher als man vielleicht glaubt. Von daher ist es ein nutzbares Feature, welches von Spieleherstellern logischerweise dann auch bei der jetzigen undurchsichtigen Marktlage "sicherheitshalber" eingebaut wird. Und das schöne: PhysX wird immer deaktiviert sein, wenn man es nicht hat. Dem Spiel fehlt dann schlicht ein Feature (vergleicht hierzu heutige Grafikeinstellungen bei Spielen).
Falls es mit der Marktdurchsetzung von PhysX dann nicht klappt, sind AGEIA die einzigen, die daraus einen erheblich finanziellen Nachteil ziehen werden ("gute" Übernahme mal ausgeschlossen).

Meine Vermutung:
Microsoft wird durch ihre marktbeherrschende Position einen Standard durchsetzen. Dieser wird dann sowohl von Grafikherstellern als auch von Spieleentwicklern unterstützt werden und das wars dann auch.
AGEIA hat bis zum Ende diesen Jahres noch Zeit etwas zu reissen. Wenn sie das verpassen ist Schluss mit der Eigenständigkeit. Dann gehen wieder die grossen Übernahmen los und es stellt sich nur noch die Frage: Wer übernimmt AGEIA ? ;)

[Demirug]

Android[/POST]']Innerhalb einer Anwendung kann man auch auf einzelne Kerne komplett auslagern, wenn eine spätere Synchronisierung erfolgt. Hier kann zwar ein kleiner Overhead enstehen, aber möglich ist es.
Immer wieder ein schönes Beispiel ist hier Nuendo.

Wenn du funktionen auf andere Kerne auslagern willst musst du Multithreading nutzen. Anders geht es gar nicht. Welche Funktion dann wo läuft und wann und wie syncronisert wird ist dann ja wieder ein anderes Thema.

Android[/POST]']Zur Physik:
Die Implementierung von PhysX ist weitaus einfacher als man vielleicht glaubt. Von daher ist es ein nutzbares Feature, welches von Spieleherstellern logischerweise dann auch bei der jetzigen undurchsichtigen Marktlage "sicherheitshalber" eingebaut wird. Und das schöne: PhysX wird immer deaktiviert sein, wenn man es nicht hat. Dem Spiel fehlt dann schlicht ein Feature (vergleicht hierzu heutige Grafikeinstellungen bei Spielen).
Falls es mit der Marktdurchsetzung von PhysX dann nicht klappt, sind AGEIA die einzigen, die daraus einen erheblich finanziellen Nachteil ziehen werden ("gute" Übernahme mal ausgeschlossen).

Ich behaupte ja nichts anderes (solange es sich nur um Effeckt Physik handelt) aber damit nur mal schnell die Physikengine einzubauen ist es eben nicht getan.

[Gast]

Android[/POST]']Innerhalb einer Anwendung kann man auch auf einzelne Kerne komplett auslagern, wenn eine spätere Synchronisierung erfolgt. Hier kann zwar ein kleiner Overhead enstehen, aber möglich ist es.


Das geht aber nur durch Multithreading!

[Android]

Wenn du funktionen auf andere Kerne auslagern willst musst du Multithreading nutzen. Anders geht es gar nicht. Welche Funktion dann wo läuft und wann und wie syncronisert wird ist dann ja wieder ein anderes Thema.

Das eine sollte ja auch nicht das andere ausschliessen. Meinte nur, dass es auch andere Möglichkeiten beim Multithreading gibt. Missverständnis.

Ich behaupte ja nichts anderes (solange es sich nur um Effeckt Physik handelt) aber damit nur mal schnell die Physikengine einzubauen ist es eben nicht getan.

Ich habe ja auch nicht behauptet, dass du das Gegenteil behauptest.
Ich meinte nur, dass die PhysX API an sich eine gut programmierbare Schnittstelle ist (mal abgesehen von den schon bekannten Schwachstellen).
Die Problematik, die von dir beschrieben wird ist mir schon klar. Das wussten die Entwickler aber auch schon, da man es aufgrund der Gesamtberechnung sehr einfach nachvollziehen kann. Das Produkt kam einfach zu früh und stützt sich auf dafür nicht ausgelegte Nebenkomponenten. Daher glaube ich ja auch, dass AGEIA ernsthafte Probleme bekommen wird. Denn genau eben diese Nebenkomponenten die den Flaschenhals erzeugen kommen teilweise von Herstellern, die Interesse an einem eigenen Standard mitbringen.
Was das bedeutet sollte ja jedem klar sein ? ;)

[Gast]

Gast[/POST]']Hallo,

was du dir da ausgedacht hast ist echt an den Haaren herbeigezogen!

Wenn dem so wäre frage ich mich warum qualifizierte Entwickler, wie z.B. von Unreal, um nur einen NAMENHAFTEN Entwickler zu nennen, sich überhaupt die Zeit nehmen, einen Effekt für Ageia PhysX zu implementieren!

Eigentlich hätten sie ja, wenn deine Meinung der Realität entspricht, sofort lächelnd abwinken müssen!

Tut mir sehr leid Demirug, aber dein Beitrag gehört auf die Spielwiese!

:) GrüsseDu solltest dich schämen. Demi macht sich die Mühe seine Erkenntnisse für uns aufzubereiten und du verfasst hier einen Schwachsinns-Post nach dem anderen. Da du bisher keinerlei (technische) Argumente gebracht hast, die Demirugs Aussage widerlegen, nehme ich mal an, dass du nur trollen willst. Das bedeutet, dass ich deine Postings von nun an ignoriere.

@Demi: Sehr interessanter Text. Ob die Devs dieses Problem bewältigen können, wird nur die Zukunft zeigen. Da du aber schon diverse Lösungsansätze gepostet hast, halte ich es für durchaus möglich, dass bei Physikbeschleunigung auch irgendwann die Vorteile überwiegen.

[Android]

Gast[/POST]']Du solltest dich schämen. Demi macht sich die Mühe seine Erkenntnisse für uns aufzubereiten und du verfasst hier einen Schwachsinns-Post nach dem anderen. Da du bisher keinerlei (technische) Argumente gebracht hast, die Demirugs Aussage widerlegen, nehme ich mal an, dass du nur trollen willst. Das bedeutet, dass ich deine Postings von nun an ignoriere.

Am besten man kommentiert es überhaupt nicht, sonst glaubt "der" Gast man würde den Schwachsinn auch noch Ernst nehmen.
Also am besten solche Posts einfach überlesen dann hat derjenige auch keine Lust mehr rumzutrollen, wenn er merkt, dass ihn niemand beachtet. ;)

[Monger]

Gast[/POST]']
@Demi: Sehr interessanter Text. Ob die Devs dieses Problem bewältigen können, wird nur die Zukunft zeigen. Da du aber schon diverse Lösungsansätze gepostet hast, halte ich es für durchaus möglich, dass bei Physikbeschleunigung auch irgendwann die Vorteile überwiegen.

Demirug hat sich ja wiederholt sehr positiv über Direct3D 10 geäußert. Man kann ja MS einiges vorwerfen, aber dass sie Zeit und Geld in eine Schnittstelle stecken mit der man nichts anfangen kann, halte ich für unwahrscheinlich. Deshalb: mit Vista (und erst dann) wird sich wohl in dem Bereich was tun.


@Demirug: jetzt mal so extrem laienhaft gefragt - passt nicht der Geometry Shader gut in das Konzept? Wenn ich das richtig irgendwo bei Ageia gelesen habe, stellen sie ja als wichtiges Merkmal heraus, dass Grafikkarten bis jetzt eben nur Polygone als Einheit begreifen können, aber nicht geschlossene Objekte an sich. Fällt nicht genau diese Limitierung mit dem Geometry Shader?

[Android]

Monger[/POST]']Demirug hat sich ja wiederholt sehr positiv über Direct3D 10 geäußert. Man kann ja MS einiges vorwerfen, aber dass sie Zeit und Geld in eine Schnittstelle stecken mit der man nichts anfangen kann, halte ich für unwahrscheinlich. Deshalb: mit Vista (und erst dann) wird sich wohl in dem Bereich was tun.


Absolute Zustimmung. Microsoft ist nicht irgendein Garagenunternehmen, das mal eben irgendwas auf den Markt wirft. Und das jedes Unternehmen irgendwo seine Probleme hat erübrigt sich von selbst. Manchmal würde ich gerne den ganzen Mega-Kritikern auf ihrer Arbeit mal über die Schulter schauen und bei jedem noch so kleinen Fehler eine Standpauke halten. Mal gucken wie lange die das dann noch lustig finden. Die meisten Leute wissen gar nicht was für ein Druck bei Microsoft auf die Programmierer ausgeübt wird, damit alles schnellstmöglich fertig ist. Daher Respekt jedem Programmierer bei Microsoft und nicht nur da.
Microsoft bietet mit der DirectX-Reihe einen Standard, der nicht ganz unverantwortlich ist, dass die Grafikindustrie und Spieleindustrie immer bessere Produkte liefert. Direct3D10 wird da keine Ausnahme sein.

So jetzt aber Schluss mit dem Lob, sonst heisst es noch ich werde von Microsoft gesponsert. ;)

[Gast]

Gibt es eigentlich unter den Spielen, die mit PhysX-Unterstützung geplant/erhältlich sind auch welche, die unter OpenGL laufen? Die sollten dann ja, wie auch die D3D10-Spiele, von diesen Problemen frei sein.

[Gast]

Gast[/POST]']Gibt es eigentlich unter den Spielen, die mit PhysX-Unterstützung geplant/erhältlich sind auch welche, die unter OpenGL laufen? Die sollten dann ja, wie auch die D3D10-Spiele, von diesen Problemen frei sein.

frei nicht, aber weniger stark als D3D9-spiele sollten diese betroffen sein.

[tombman]

Hmm, die Frage ist, ob 500 Objekte wirklich so wenig sind?

Bei Physik Spielereien in games braucht man die PPU doch meistens um "blow shit up".
Dh hauptsächlich Trümmerteile. Und die sehen eh alle gleich aus. Dh man könnte vielleicht für den gesamten Level 50 bis 100 verschiedenen TrümmerOBJEKTE definieren und hätte immer noch 400 Objekte für den Rest frei. Die reine ANZAHL der Trümmer kann man ja dann per instancing auf beliebige Größe aufblasen, denn, so wie ich es verstanden habe, schadet instancing ja dem "500 Objekt Limit" nicht...

Oder check ich da was ned?

[Blackland]

Demi hat schon recht, ich empfehle dazu mal ganz uneigennützig folgende, nicht so ganz ernst gemeinte - aber zutreffende - Abhandlung ;) :

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3523884#post3523884

[Gast]

Blackland[/POST]']Demi hat schon recht, ich empfehle dazu mal ganz uneigennützig folgende, nicht so ganz ernst gemeinte - aber zutreffende - Abhandlung ;) :

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3523884#post3523884

Dann poste auch die Antworten zu deiner Abhandlung ;)
Das hatten wir doch schon, aber vorsichtig! Sonst behauptet jemand noch dein Thread wäre per Cash enstanden, immerhin ist das eine klasse Argumentation für jeden VGA-Hersteller!

Feel the beat @Sunshine-Live!

[Gast]

tombman[/POST]']...

Oder check ich da was ned?

Nein! Das Thema wird erst klarer werden wenn wir 2007 haben! Immerhin paßt das ja zu Unreal 2007 ;)

[MuLuNGuS]

es gibt ja nicht nur trümmerteile...was ist mit flüssigkeiten, gerade da sollte eine ppu ihr potential ausspielen können. ist halt nur die frage wie stark die GPU durch fluids belastet wird.

Demirug?

[Demirug]

Flüssigkeiten sind auch übel. Da berechnet ein Physikchip ja nicht nur die Position und Lage des Körpers als ganzes sondern die gesamte Oberflächen Struktur. Diese muß dann bei jedem Frame vom Speicher der Physik Lösung zur GPU übertragen werden. Wenn sie dann noch Tropfen bilden bekommt man zusätzlich wieder leicht das Problem mit den vielen Objekten. Wobei es hier das man sowieso die ganze Polygonen suppe übertragen muß einfacher zu lösen ist. Flüssigkeiten sind also mehr ein Problem für die Bandbreite als für die CPU die aber immer noch zum umkopieren benötigt wird. Da haben die GPU Lösungen den Vorteil das sie die Daten leichter ohne die Mithilfe der CPU kopieren können.

[Mr.Soapdown]

Das Wort "Bandbreite" (Flaschenhals?) ist ja schon gefallen. Könntet ihr nicht mal eine Rechnung auf stellen, wo wir aktuell stehen? Wie sieht´s mit der Bandbreite in einem Jahr aus, sind CPU´s dann so stark entsprechend mehr zu liefern?

Wieso kommt nur Demirug auf solche Gedanken und Berechnungen? Haben die Hersteller keine schlauen Köpfchen?

[Demirug]

Mr.Soapdown[/POST]']Wieso kommt nur Demirug auf solche Gedanken und Berechnungen? Haben die Hersteller keine schlauen Köpfchen?

Die GPU Hersteller wissen schon an was es hängt aber da sie es ja schon seit Jahren predigen und selbst ein Interesse am Physikmarkt haben werden sie die Entwickler wohl kaum mit Lösungen für eine PhysX Integration überhäufen.

[Mave@Work]

Demirug[/POST]']Wenn du funktionen auf andere Kerne auslagern willst musst du Multithreading nutzen. Anders geht es gar nicht. Welche Funktion dann wo läuft und wann und wie syncronisert wird ist dann ja wieder ein anderes Thema.


ich hätte hier noch mal eine Verständnissfrage: Ich kann doch auch einen Process für I/O und einen für den Rest schreiben (Die sich dann noch irgendwie syncronisieren müssen über eine inter process Schnittstelle).
Die Processes kann ich dann ja unterschiedlichen Kernen fest zuordnen.
Das ist aber dann doch nicht das gleiche wie Multithreading oder eben doch ?

[Demirug]

Mave@Work[/POST]']ich hätte hier noch mal eine Verständnissfrage: Ich kann doch auch einen Process für I/O und einen für den Rest schreiben (Die sich dann noch irgendwie syncronisieren müssen über eine inter process Schnittstelle).
Die Processes kann ich dann ja unterschiedlichen Kernen fest zuordnen.
Das ist aber dann doch nicht das gleiche wie Multithreading oder eben doch ?

Das gleiche ist es nicht aber es gibt da schon einen Zusammenhang. Jeder Prozeß enthält ja mindestens ein Thread. Dadurch ergibt sich das wenn man die Arbeit auf zwei Prozesse verteilt man sie wiederum auf zwei Threads verteilt hat. Allerdings ist das Erzeugen und verwalten von Prozessen viel aufwendiger. Entsprechend macht man sowas eigentlich nicht. Diese Technik sollte lediglich eingesetzt werden wenn.

a) Das OS kein Multithreading unterstützt
b) Geplant ist die einzelnen Teile nicht nur auf mehren Cores/CPUs in einem Rechner sondern auf mehreren Rechnern verteilt laufen zu lassen.
c) Man sehr spezielle Anforderungen an die Betriebssicherheit hat.

Ansonsten ist es immer besser die Arbeit direkt auf Threads zu verteilen.

[Gast]

Irgendwie so in der Richtung hatte ich mir das schon gedacht...ein Flaschenhals...GPU/CPU kommen mit dem "mehr" (berechnen) an Objekten nicht klar und die FPS gehen in die Knie.
Guter Ansatz Demirug.

Die Treiber (v2.4.9Cellfactor bzw. 2.4.3) nutzen aber schon Dualcore...die Softwaredemo (hab keine PhysX Karte) läuft mit 2 Kernen ~10fps schneller...bei 1 Kern sinds ~95fps / 2 Kerne ~116fps...im Startbild...ohne Motion.
X2 3800+ @2500

MfG The Unknown

[Gast]

Das Thema PPU ist nun mal sehr jung. Tombman sagt ja, daß schon mit der neuen Version der Demo zu Cellfactor (beta R36) dies um einiges besser rennt. Glaube nicht, daß sich so viele Entwickler, die momentan an Ihren Spielen arbeiten, so verschossen haben. Hier sitzen Profis (Unreal-Engine 3) und Hut ab vor so Leuten.

Denke, daß wir alle, wenn eine Game mit der Unreal-Engine 3 kommt, die Kinnlade auf Durchzug halten werden. Da bin ich mir ziemlich sicher.

Vielleicht wird Nvidia oder ATI nicht auf die Wünsche von Ageia allein reagieren, aber wenn eine gewisse Anzahl Spiele da ist mit Ageia, dann nimmt das Gewicht/Druck zu und einer von beiden wird zuerst reagieren.

[Gast]

bei ghost-recon sind ja mit physX in erster linie mehr partikel vorhanden, diese belasten die gpu bestimmt auch nicht wenig.

[Blackland]

Gast[/POST]']bei ghost-recon sind ja mit physX in erster linie mehr partikel vorhanden, diese belasten die gpu bestimmt auch nicht wenig.
Richtig. Leider haben eben diese Mehrpartikel ÜBERHAUPT KEINE Auswirkung auf das Spiel und erhöhen "nur" die Grafikpracht. Das kostet trotzdem Prozessorleistung ;)

Was ist also an einer physikalischen Besserung sinnvoll, die nur die Grafik verändert, aber keine Auswirkung auf das Spiel hat? Das erinnert mich irgwendwie an einen aufgeklebten Pappspoiler auf einen Porsche.

[Gast]

Die heutige Havok-Engine wird bereits bei der Entwicklung eines Games mit Havok-Support in das Spiel integriert. Ghost Recon hinterläßt bei mir den Eindruck, als ob man Ageia "drübergestölpt" hat, also Ageia später dazu gekommen ist. Denke wenn man von vornherein mit dem SDK von Ageia die Physik direkt ins Spiel integriert, dann geht es eben richtig ab. Gut das Problem mit D3D ist immer noch nicht gelöst, aber hier können sicherlich Nvidia und ATI mit ihren Treibern ggf. aushelfen. Bei D3D10 passiert sicherlich auch was. Wenn Ageia eine gewisse Marktmacht erlangt, davon ist auszugehen, wenn man sich die Ankündigungen ansieht, dann wird entweder ATI oder Nvidia reagieren. Irgendwann machen die es beide, allein aus Konkurrentdruck. Glaube Ageia hat eine echte Chance sich zu etablieren.

[Gouvernator]

Falscher Ansatz. Ich hab bisher nur sehr schlechte
Physik speziell in Cell Demo gesehen. Ich finde man soll nicht Objektzahl erhöhen sondern die Qualität wie sich Objekte verhalten. Ich habe mehr Spass ein einzelnes Objekt durch die Gegend zu werfen das WIRKLICH wie echt berechnet wird , statt mehrere Hundert Lüftballons ala Kisten in Cell , oder Streichhölzer ala Balken in HL².

[Gast]

tombman[/POST]']Hmm, die Frage ist, ob 500 Objekte wirklich so wenig sind?
schnipp
instancing ja dem "500 Objekt Limit" nicht...

Oder check ich da was ned?

Einfaches Beispiel

Ein Beispiel
Multiplayer mit inzwischen 64 Spielern = 64 Objekte
Waffen =64 Objekte
Schüsse = wohlwollend betrachtet 64 Objekte
Gebäude = x Objekte
und noch so ein bisschen weiterer schmonsens, da kommst du blitzschnell über das limit

[Gast]

Blackland[/POST]']Demi hat schon recht, ich empfehle dazu mal ganz uneigennützig folgende, nicht so ganz ernst gemeinte - aber zutreffende - Abhandlung ;) :

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3523884#post3523884

:) Jo, das merke ich auch, Demi hat mal wieder recht!

Warum erinnert mich das ganze hier an dieses Thema?
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=277144

Bin mal auf Demis Reaktion gespannt!

[Blackland]

Gast[/POST]']:Warum erinnert mich das ganze hier an dieses Thema?
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=277144
Also ich bekomme nix von NVIDIA, ergreife keine Partei und meine persönliche Meinung ist trotzdem, dass momentan eine Physikbeschleunigerkarte Blödsinn ist. Warum, habe ich weiter oben gepostet ;) .

[Gast]

Blackland[/POST]']Also ich bekomme nix von NVIDIA, ergreife keine Partei und meine persönliche Meinung ist trotzdem, dass momentan eine Physikbeschleunigerkarte Blödsinn ist. Warum, habe ich weiter oben gepostet ;) .

So war das ja auch gar nicht gemeint, ich hatte was anderes im Auge ;)
Immerhin wurde hier ja schon vermutet das AGEIA Leute zum posten zahlt.
:) Da sich aber alle Anschuldigungen meistens auf das Glashaus-Prinzip projezieren lassen meinte ich eine andere Konstalation.

Wie sagte noch Jesus, wer ohne Schuld ist soll den ersten Stein werfen!

[Gast]

Gast[/POST]']Einfaches Beispiel

Ein Beispiel
Multiplayer mit inzwischen 64 Spielern = 64 Objekte
Waffen =64 Objekte
Schüsse = wohlwollend betrachtet 64 Objekte
Gebäude = x Objekte
und noch so ein bisschen weiterer schmonsens, da kommst du blitzschnell über das limit


haben die spieler wirklich alle ein anderes modell? falls ja sind es wirklich 64 modelle, andernfalls lässt sich hier schon einsparen (wenn beispielsweise nur der skin unterschiedlich ist)

waffen üblicherweise ~10-15 modelle, von denen in einer szene wahrscheinlich auch nur ein bruchteil zum einsatz kommen, lässt sich schon einiges einsparen.
schüsse: oft alles die selben modelle, aber maximal pro waffe 1 modell.

[Monger]

Gast[/POST]']haben die spieler wirklich alle ein anderes modell? falls ja sind es wirklich 64 modelle, andernfalls lässt sich hier schon einsparen (wenn beispielsweise nur der skin unterschiedlich ist)

Na, also ein modernes Spiel muss schon unterschiedliche Modelle bieten können. Das ist aber auch gar nicht so sehr das Problem, weil wann wird ein Spieler schonmal der Physik ausgesetzt? Doch eigentlich nur während den ersten 5 Sekunden nach dem Tod...


waffen üblicherweise ~10-15 modelle, von denen in einer szene wahrscheinlich auch nur ein bruchteil zum einsatz kommen, lässt sich schon einiges einsparen.
schüsse: oft alles die selben modelle, aber maximal pro waffe 1 modell.
Das selbe hier: welche Waffen brauchen schon eine Flugbahnberechnung? Auch die aller-allermeisten Projektile fliegen nur eine gerade Linie, und stören sich an Wind o.ä. überhaupt nicht.

Ich denke, es geht hier ja ohnehin nur um Clientseitige Effekte. Und da werden vorallem Partikeleffekte Leistung fressen.

Wenn ich so drüber nachdenke, kann ich mir auch nicht so recht vorstellen, wie man an die Grenze von 500 UNTERSCHIEDLICHEN physikalischen Objekten stoßen soll.

[Funky Bob]

Monger[/POST]']
Wenn ich so drüber nachdenke, kann ich mir auch nicht so recht vorstellen, wie man an die Grenze von 500 UNTERSCHIEDLICHEN physikalischen Objekten stoßen soll.

Spiel Garrys mod bspw.

Ne, aber mal ernsthaft, wenn man die Möglichkeiten auf der Hardwareseite hat, wird man sie auch nutzen... Konnte/Kann man halt bisher noch nicht.

[Gast]

Was ist eigentlich aus den Geometry Shadern geworden ?
Würden diese evtl. Vorteile bringen ?

noch eine Verständnisfrage :
warum werden nur Modelle die Physik ausgesetzt sind zum Problem ?
Die Koordinaten aller Objekte müssen ja an die GPU gesendet werden ?

[Monger]

Funky Bob[/POST]']Spiel Garrys mod bspw.

Ne, aber mal ernsthaft, wenn man die Möglichkeiten auf der Hardwareseite hat, wird man sie auch nutzen... Konnte/Kann man halt bisher noch nicht.

Ja, aber irgendwer muss die ganzen Objekte ja auch designen. Es ist ja nicht so dass die sich selbst machen würden... es sei denn man verwendet generische Inhalte, aber für die meisten Genres sind die noch in weiter Zukunft...

[Demirug]

Gast[/POST]']Was ist eigentlich aus den Geometry Shadern geworden ?
Würden diese evtl. Vorteile bringen ?

Gibt es ab D3D10. Er bringt aber nur etwas wenn man die Physik komplett auf die GPU verlagert.

Gast[/POST]']noch eine Verständnisfrage :
warum werden nur Modelle die Physik ausgesetzt sind zum Problem ?
Die Koordinaten aller Objekte müssen ja an die GPU gesendet werden ?

Das Problem ist nicht die Physik an sich sondern die dadurch zusätzlich entstehenden Objekte.

[Demirug]

Monger[/POST]']Ja, aber irgendwer muss die ganzen Objekte ja auch designen. Es ist ja nicht so dass die sich selbst machen würden... es sei denn man verwendet generische Inhalte, aber für die meisten Genres sind die noch in weiter Zukunft...

Gerade bei Organischen Objekte könnte man viel Automatisch erzeugen lassen. Das Problem dabei ist aber das die Entsprechenden Verfahren tendeziel noch zu viele Details und GPU feindliche Daten erzuegen.

[Gast]

Das selbe hier: welche Waffen brauchen schon eine Flugbahnberechnung? Auch die aller-allermeisten Projektile fliegen nur eine gerade Linie, und stören sich an Wind o.ä. überhaupt nicht.

Aber das wäre ja dann egal ob die Flugbahn eines Geschosses extra berechnet werden muss oder nicht ?
In die GPU muss es ja so und so ?

[Monger]

Demirug[/POST]']Gerade bei Organischen Objekte könnte man viel Automatisch erzeugen lassen. Das Problem dabei ist aber das die Entsprechenden Verfahren tendeziel noch zu viele Details und GPU feindliche Daten erzuegen.
Ja, ich weiß. Spore zum Beispiel. Oder SpeedTree und so Geschichten.

(Verdammt, da haben wir ja unseren Pferdefuß: Vegetation à la Far Cry/Crysis erfordern nicht nur viele, sondern auch möglichst generische Inhalte! Wenn man da Animationen o.ä. nicht rein GPU-seitig berechnet, gerät man sicher schnell ans Ende der Fahnenstange. Richtig, Demi?)

Gast[/POST]']Aber das wäre ja dann egal ob die Flugbahn eines Geschosses extra berechnet werden muss oder nicht ?
In die GPU muss es ja so und so ?
Ich glaube, das habe ich auch noch nicht wirklich verstanden: es geht darum, ob ein Objekt noch durch die CPU muss oder nicht, oder?
Nicht die GPU limitiert, sondern die Schnittstelle zwischen CPU und GPU. Alles was die Grafikkarte alleine macht, geht rasend schnell. Momentan ist das kein Thema, weil man Gewehrkugeln ohnehin nicht sieht, und der Rest ist nicht so wahnsinnig viel.

[Gast]

ob ein Objekt noch durch die CPU muss
Naja ob es in der CPU "entsteht" oder durchgeschickt wird dürfte ja egal sein ?
Aber warte wir mal bis demirug wieder was dazu sagt :-)

[Gast]

Hallo,

ich fasse die ganze Sache also mal so zusammen:

Ein echter Physikbeschleuniger wie von Ageia berechnet mir zwar sehr schnell viele Objekte, aber diese müssen ja auch angezeigt, also von der Grafikkarte gerendert werden. Die Koordinationsaufgaben der CPU steigen somit auch noch weiter an.

Alles in allem ist also gerade DURCH eine Physik-Beschleunigerkarte eine leistungsfähige CPU und ein leistungsfähiges Grafiksystem nötig!


- Quadcore mit zwei CPU-Sockeln auf dem Mainboard
- SLI mit zwei onboard-SLI-Karten
- Physikbeschleunigerkarte
- Ausgabe auf einem 16:10 24" LCD mit 1920x1200 Pixel
- zig-fach AAF und FSAA

Es macht eben doch alles Sinn auf dem Weg zum Realismus!

[Demirug]

Gast[/POST]']Naja ob es in der CPU "entsteht" oder durchgeschickt wird dürfte ja egal sein ?

Wo das Objekt herkommt ist dabei erst mal egal. Nur solange die Physik nur eine relativ geringen Anteil von der Rechenleistung bekam konnte man gar nicht genügend Objekte berechnen um die CPU/GPU Kommunikation zu überlasten. Wer sich nun aber eine Physikkarte kauft erwartet eben einfach mehr Physik und das ist dann zu viel für die CPU/GPU Kommunikation.

[Gast]

Monger[/POST]']Na, also ein modernes Spiel muss schon unterschiedliche Modelle bieten können. Das ist aber auch gar nicht so sehr das Problem, weil wann wird ein Spieler schonmal der Physik ausgesetzt? Doch eigentlich nur während den ersten 5 Sekunden nach dem Tod...


es geht doch nicht um die physikberechnung ansich, diese braucht ja (noch) relativ wenig rechenzeit.

ob ein modell nun der physik ausgesetzt ist oder nicht ist ja egal, die cpu muss der gpu auf jeden fall den befehl zum rendern geben, egal ob mit oder ohne physik.

[Mave@Work]

Demirug[/POST]']Das gleiche ist es nicht aber es gibt da schon einen Zusammenhang. Jeder Prozeß enthält ja mindestens ein Thread. Dadurch ergibt sich das wenn man die Arbeit auf zwei Prozesse verteilt man sie wiederum auf zwei Threads verteilt hat. Allerdings ist das Erzeugen und verwalten von Prozessen viel aufwendiger. Entsprechend macht man sowas eigentlich nicht. Diese Technik sollte lediglich eingesetzt werden wenn.

a) Das OS kein Multithreading unterstützt
b) Geplant ist die einzelnen Teile nicht nur auf mehren Cores/CPUs in einem Rechner sondern auf mehreren Rechnern verteilt laufen zu lassen.
c) Man sehr spezielle Anforderungen an die Betriebssicherheit hat.

Ansonsten ist es immer besser die Arbeit direkt auf Threads zu verteilen.

Vielen Dank für die Antwort.
Bei der Software die wir benutzen sind dann wohl die kriterien b) und c) erfüllt :biggrin:

[Gast]

Monger[/POST]']Na, also ein modernes Spiel muss schon unterschiedliche Modelle bieten können. Das ist aber auch gar nicht so
schnipp
, wie man an die Grenze von 500 UNTERSCHIEDLICHEN physikalischen Objekten stoßen soll.

Hier gehts ja auch nicht darum, ob die Ageiakarte zuviel Physik berechenen muss, sondern um einen anderen Flaschenhals, Objekzahl ;-)

[Datenschleuder]

Demirug[/POST]']Aber schauen wir etwas weiter zurück sehen wir das Direct3D schon lange eine als „Indexed Vertex Blending„ bezeichnete Technik unterstützt.Das ist aber wirklich was uraltes was auch nur teilweise unterstützt wurde soweit ich weiß.
Währe interessant zu wissen wie die Leistung davon ist und ob es nun problemlos von allen derzeitigen Treibern unterstützt wird.

Ursprünglich für Hardware T&L vorgesehen läßt sich diese Technik auch ganz leicht in einem Vertexshader implementieren. Dabei wird anstelle einer Transformationsmatrix für alle Vertices in einem Objekt eine Vielzahl bereitgestellt. In den Objekt Daten selbst kodiert man dann für jeden Eckpunkt welche Matrix benutzt werden soll. Damit wird es möglich ein Objekt in Einzelteile zu zerlegen aber es trotzdem als ganzen zu rendern. Limitiert wird die Anzahl der Teile dabei nur durch die Größe des Konstantenspeichers. Mit den 256 Werten die vom Shader Model 2 gefordert werden sind etwa 60 Teile möglich.Wie soll das funktionieren?
Ich wüsste jetzt nicht wie man im Vertex Programm herausfinden kann zu welcher Translationsmatrix der bearbeitete Eckpunkt gehört.

[Demirug]

Datenschleuder[/POST]']Das ist aber wirklich was uraltes was auch nur teilweise unterstützt wurde soweit ich weiß.
Währe interessant zu wissen wie die Leistung davon ist und ob es nun problemlos von allen derzeitigen Treibern unterstützt wird.

Das war nur zum Vergleich bestimmt. Unterstützt wird es auch heute noch nicht besonders gut.

Datenschleuder[/POST]']Wie soll das funktionieren?
Ich wüsste jetzt nicht wie man im Vertex Programm herausfinden kann zu welcher Translationsmatrix der bearbeitete Eckpunkt gehört.

Diese Information wird genau wie beim "Indexed Vertex Blending" als Teil der Vertexdaten übertragen.

[Gast]

Demirug[/POST]']Diese Information wird genau wie beim "Indexed Vertex Blending" als Teil der Vertexdaten übertragen.Also z.B. über Texturkoordinatendaten?
Na toll. Dann komme ich über die 32 Byte Grenze (float3 position, float3 normal float2 texCoord) hinaus und büße erheblich Leistung ein. :(

[Demirug]

Gast[/POST]']Also z.B. über Texturkoordinatendaten?
Na toll. Dann komme ich über die 32 Byte Grenze (float3 position, float3 normal float2 texCoord) hinaus und büße erheblich Leistung ein. :(

Weitaus weniger als durch die DrawCalls. Im Zweifel falls das Mesh wirklich dermassen schlecht optimiert ist kann man ja auch noch aufpaden. Alternativ könnte man auch einen zweiten Vertexstream nehmen. Müsste man natürlich in Einzelen durchmessen aber schneller als mit der Unmenge von Drawcalls wird es auf jeden Fall solange man CPU limitiert ist.

[Datenschleuder]

Da müsste es doch so aussehen:

VS 1.0: max. 32 Subobjekte
VS 2.0: max. 85 Subobjekte

Denn die Translation kommt doch mit 3*3 Matrizen (bzw. 3*4) aus.

[Neomi]

Datenschleuder[/POST]']VS 1.0: max. 32 Subobjekte
VS 2.0: max. 85 Subobjekte

Denn die Translation kommt doch mit 3*3 Matrizen (bzw. 3*4) aus.

Die Pose (Translation, Rotation und Skalierung) braucht eine 3x4-Matrix (bzw. 4x3, je nach Sichtweise), mit nur 3x3 fällt die Translation weg. Du solltest aber nicht sämtliche Konstanten dafür opfern, ein paar andere Dinge wollen auch noch was haben. Eine IMHO gute Mischung bei VS 2.0 (und drüber) wären 64 komplette Posen und 64 Vec4-Konstanten für alle anderen Dinge.

Mit D3D10 kann man dann bis zu 1365 Posen in einen Konstantenbuffer packen. Da muß auch kein Platz für andere Sachen übrig bleiben, da man 16 davon gleichzeitig an eine Shaderstage binden kann. Mehrere Buffer zu verwenden, um das Limit weiter zu erhöhen, ist reichlich unpraktisch, da die Indizierung dann unpraktikabel wird.

[ScottManDeath]

Wenn man nur Rotation, bzw keine Skalierungen/Scherungen oder nur uniforme Skalierungen hat,kommt man mit 9 floats weg, d.h. float3 Translation, float3 der X Vektor, float3 der Y Vektor; den Z Vektor der Matrix kreuzt man sich zusammen ;)

Oder man nimmt 4 Float für Quaternion und 3 Float für Translation und baut sich die Matrix im Shader zusammen.

[Neomi]

ScottManDeath[/POST]']Oder man nimmt 4 Float für Quaternion und 3 Float für Translation und baut sich die Matrix im Shader zusammen.

Einmal pro Objekt per CPU ist das ja gut, aber im Vertexshader? Und dann noch bis zu 4x im Falle von Skinning und das pro Vertex? Aua, das kann sich nicht wirklich lohnen. Eine einzelne 4x3-Matrix ist universell einsetzbar und mit 3x dp4 abgefrühstückt, die Umwandlung eines Quaternions in eine Matrix ist da doch ein ganz anderes Kaliber. Machbar natürlich, mit der unlimitierten Shaderlänge von SM4 erst recht, aber der Performance ist das doch nicht gerade zuträglich. Da beschränke ich mich lieber auf die maximal "nur" 1365 4x3-Matrizen in einem einzelnen Constantbuffer.

[Gast]

Neomi[/POST]']Einmal pro Objekt per CPU ist das ja gut, aber im Vertexshader? Und dann noch bis zu 4x im Falle von Skinning und das pro Vertex? Aua, das kann sich nicht wirklich lohnen. Eine einzelne 4x3-Matrix ist universell einsetzbar und mit 3x dp4 abgefrühstückt, die Umwandlung eines Quaternions in eine Matrix ist da doch ein ganz anderes Kaliber. Machbar natürlich, mit der unlimitierten Shaderlänge von SM4 erst recht, aber der Performance ist das doch nicht gerade zuträglich. Da beschränke ich mich lieber auf die maximal "nur" 1365 4x3-Matrizen in einem einzelnen Constantbuffer.

Ganz genau ;)

[DavChrFen]

Ich kapier nicht ganz, wieso diese 500 Objekt-Grenze. Ist ds CPU-limitiert? An der Graka kann es ja nicht liegen, da die Anzahl der Objekte nichts mit der Anzahl an Polygonen zu tun hat. Und wieso soll die Übertragung der von der PPU berechneten Objekte an die GPU ein Flaschenhals sein? Ich dachte immer, die Maximale Übertragungsgeschindigkeit durch den PCIe-Bus an die GraKa ist sehr viel höher, als heute gebraucht wird(außer man will auf den Arbeitsspeicher was auslagern)? Und kann der PPU nicht direkt über DMA an die Graka Daten übertragen. Da brauche ich doch gar keine bremsende CPU?
Fragen über Frage...

[Neomi]

Der eigentliche Flaschenhals hier ist die Anzahl der Drawcalls, jeder einzelne zieht eine Menge Overhead nach sich (z.B. Kontextwechsel, da der Treiber im Kernelmode arbeitet, mit Vista wandert er in den Usermode).

Die PPU kann nicht direkt an die GPU senden, weil sie nicht wissen kann, wie die jeweilige GPU anzusteuern ist, das weiß nur der Treiber. Und würde die PPU direkt an die GPU senden können, die GPU könnte mit den Daten nichts anfangen. Mit einer Pose (Position, Rotation, Skalierung) alleine wüßte die GPU nicht, was sie dort zeichnen sollte. Welche Geometrie, welche Texturen und welche Shader (grob vereinfacht) zum Einsatz kommen, weiß nur die Engine, die kann man da nicht einfach umgehen.

[Gast]

Neomi[/POST]']Der eigentliche Flaschenhals hier ist die Anzahl der Drawcalls, jeder einzelne zieht eine Menge Overhead nach sich (z.B. Kontextwechsel, da der Treiber im Kernelmode arbeitet, mit Vista wandert er in den Usermode).

Die PPU kann nicht direkt an die GPU senden, weil sie nicht wissen kann, wie die jeweilige GPU anzusteuern ist, das weiß nur der Treiber. Und würde die PPU direkt an die GPU senden können, die GPU könnte mit den Daten nichts anfangen. Mit einer Pose (Position, Rotation, Skalierung) alleine wüßte die GPU nicht, was sie dort zeichnen sollte. Welche Geometrie, welche Texturen und welche Shader (grob vereinfacht) zum Einsatz kommen, weiß nur die Engine, die kann man da nicht einfach umgehen.

Hey,

die VGA Anbindung im Spiel/ in der Entwicklung basiert ja auf Standarts, deswegen sehe ich auch keine Möglichkeit, seitens ATI oder NVIDIA, Physx-Berechnung mit der PPU zu verhindern.

Es kann auch keinen Flaschenhals geben, weil die PPU die Brechnung für Physx übernimt und die GPU & die CPU alleine für die Darstellung von bereits von der PPU fertig berechneten Objekten verantwortlich sind.

Thats fact!

[Gast]

Hey,

kurzer Nachtrag!

Kein Entwickler würde auch nur einen Tag mehr Arbeit investieren, wenn er diese Probleme festsstellen würde.

Deswegen sollten einige "Theologen" ;) hier Ihre Meinung auch mit Fakten unterlegen und Fakten erreicht man da nur, wenn man selbst eine Anbindung im Game mit der PPU realisiert!

Die Theorie war schon immer der Feind von Innovationen und die Phyxs PPU ist eine INNOVATION!

Sicherlich sind die ersten Games mit Physx - Unterstützung eher unbrauchbar für einen Vergleich, aber die Zukunft (max. 3 Monate) wird meine Theorie ;) untermauern!

[Demirug]

Gast[/POST]']Hey,

die VGA Anbindung im Spiel/ in der Entwicklung basiert ja auf Standarts, deswegen sehe ich auch keine Möglichkeit, seitens ATI oder NVIDIA, Physx-Berechnung mit der PPU zu verhindern.

Das können sie auch nicht und das wurde ja auch nicht behauptet.

Gast[/POST]']Es kann auch keinen Flaschenhals geben, weil die PPU die Brechnung für Physx übernimt und die GPU & die CPU alleine für die Darstellung von bereits von der PPU fertig berechneten Objekten verantwortlich sind.

Thats fact!

Und wie kommen die fertig berechneten Objekte von der PPU zur GPU? Nur über die CPU weil es zwischen PPU und GPU keine gemeinsame Schnittstelle gibt. Zum Zugriff auf die GPU durch die CPU nutzt man nun wiederum die besagten Standards und der Standard Direct3D hat einen Flaschenhals der nur etwa 500 DrawCalls pro Frame aushält.

Und das ist keine Theorie sondern ein Wert aus der täglichen Praxis den jeder der sich ernsthaft mit dem Thema Direct3D auseinander gesetzt hat kennt.

[saddevil]

war es bisher nicht so das benches immer im vergleich standen ..

ohne PPU ( max details )
mit PPU ( max details --- dazu die PPU effekte ) ???


um zu sehen wie weitdie PPU die CPU entlastet
sollte man nicht so benchen das die effekte die die CPU bisher gerechnet hat von der PPU übernommen werden ??
aber überall sehe ich nur einfach mehr effekte und teile die fliegen was natürlich auch wieder GPU und CPU mitsichzieht

um einen vergleich zu schaffen was die PPU alleine ausmacht sollte man mal nur die effekte von der PPU berechnen lassen die sonst auch da wären ...
mehr nicht
und ich glaube dann sieht die sache anders aus

[Gast]

Demirug[/POST]']Das können sie auch nicht und das wurde ja auch nicht behauptet.



Und wie kommen die fertig berechneten Objekte von der PPU zur GPU? Nur über die CPU weil es zwischen PPU und GPU keine gemeinsame Schnittstelle gibt. Zum Zugriff auf die GPU durch die CPU nutzt man nun wiederum die besagten Standards und der Standard Direct3D hat einen Flaschenhals der nur etwa 500 DrawCalls pro Frame aushält.

Und das ist keine Theorie sondern ein Wert aus der täglichen Praxis den jeder der sich ernsthaft mit dem Thema Direct3D auseinander gesetzt hat kennt.

Hey,

das ist ja nicht falsch, aber das Limit hat nichts mit dynamischen Daten an zu tun. Weiterhin lässt sich mit einem perfekten Batching ein Limit auch verhindern!

Aber das sind auch nur Theorien ;) , Fakt ist, das sich führende Entwickler mit dem Thema auseinandersetzen und man nicht pauschal jedes Limit direkt als gegeben ansehen muß!

[Demirug]

Ich glaube wir drehen uns hier im Kreis denn entweder hast du meinen Eingangspost nicht gelesen oder nicht verstanden.

Alles was ich im Endeffekt behauptet habe ist das der Einsatz einer PPU kontraproduktiv ist wenn man nicht gleichzeitig die Grafikengine dahingehend anpasst das sie mit der durch die zusätzliche Physik entstehende Datenlast zurecht kommt.

[Gast]

Demirug[/POST]']Ich glaube wir drehen uns hier im Kreis denn entweder hast du meinen Eingangspost nicht gelesen oder nicht verstanden.

Alles was ich im Endeffekt behauptet habe ist das der Einsatz einer PPU kontraproduktiv ist wenn man nicht gleichzeitig die Grafikengine dahingehend anpasst das sie mit der durch die zusätzliche Physik entstehende Datenlast zurecht kommt.

Hey,

das habe ich auch so verstanden, aus diesem Grund, meinte ich ja, das man mit einem vernüftigem Bacthing diesen Flaschenhals (Drawcalls) umgehen kann.

Ganz davon wird mit Dx10 sich einiges dort auch optimieren, somit ist der Aufwand nicht mehr so hoch.

[Gast]

...oder verwechsele ich jetzt etwas Demirug?

[Demirug]

Gast[/POST]']Hey,

das habe ich auch so verstanden, aus diesem Grund, meinte ich ja, das man mit einem vernüftigem Bacthing diesen Flaschenhals (Drawcalls) umgehen kann.

Natürlich nur ist eben "vernüpftiges" Batching nicht immer ganz einfach und kann unter Umständen große Veränderungen an einer vorhanden Engine nach sich ziehen. Aus diesem Grund erwarte ich eben auch das es bei einigen die auf PhysX nur wegen dem Hype aufgesprungen sind eben nicht vernüpftig gemacht werden wird.

Gast[/POST]']Ganz davon wird mit Dx10 sich einiges dort auch optimieren, somit ist der Aufwand nicht mehr so hoch.

D3D10 Bitte. Ja der Overhead wird geringer ich wage jetzt mal zu behaupten das man sogar unter den Overhead von OpenGL kommt. Dummerweiße ist im Punkt D3D10 und PPU im Moment nicht nur D3D10 aufgrund fehlender Hardwrae die Bremse. Es gibt ja auch keine Vista Treiber für PhysX.

[Gast]

Demirug[/POST]']Natürlich nur ist eben "vernüpftiges" Batching nicht immer ganz einfach und kann unter Umständen große Veränderungen an einer vorhanden Engine nach sich ziehen. Aus diesem Grund erwarte ich eben auch das es bei einigen die auf PhysX nur wegen dem Hype aufgesprungen sind eben nicht vernüpftig gemacht werden wird.



D3D10 Bitte. Ja der Overhead wird geringer ich wage jetzt mal zu behaupten das man sogar unter den Overhead von OpenGL kommt. Dummerweiße ist im Punkt D3D10 und PPU im Moment nicht nur D3D10 aufgrund fehlender Hardwrae die Bremse. Es gibt ja auch keine Vista Treiber für PhysX.

Hey.

damit hast du den Nagel auf dem Kopf getroffen, das habe ich auch vermutet, deswegen wird für mich das Bild um die Performance erst mit Unreal 2007 oder vieleicht erst noch später klarer.

Sicherlich ist es zwingend NOTWENDIG für die PPU einen Vista-Treiber bereit zu stellen, davon gehe ich auch 100%-Zig aus, da Dell und andere OEMs dies bereits in Ihrer aktuellen Planung drinhaben und bekanntlich AGEIA mit Dell als OEM Partner arbeitet.

Ich finde deinen Artikel in keinster Weise negativ, nur eröffnent er uns nach dieser Diskussion auch die möglichen Gründe, warum die Perormance am Launchtag so miserabel war.

1. Kein vernüftiges Batching
2. "Hopla-hop" -Implementierung von Physx in die eigene Geme -Engine
"PR-Sonne" ;)

[Gast]

Gast[/POST]']Einfaches Beispiel

Ein Beispiel
Multiplayer mit inzwischen 64 Spielern = 64 Objekte
Waffen =64 Objekte
Schüsse = wohlwollend betrachtet 64 Objekte
Gebäude = x Objekte
und noch so ein bisschen weiterer schmonsens, da kommst du blitzschnell über das limit
keine tolle rechnung schliesslich wird nur das berechnet was man auch sieht und wie oft sieht man wirklich alle 64 Spieler welche dann auch alle anders aussehen.

[Gast]

Hi, gibt es nun bzw. wird es eine 256MB-Version der Karte geben?

[Blutmaul]

Die Zeichen deuten an, es wird keine 256MB-Variante geben.

Aber wer kann schon in die Zukunft sehen...

[TheGamer]

Gast[/POST]']Die heutige Havok-Engine wird bereits bei der Entwicklung eines Games mit Havok-Support in das Spiel integriert. Ghost Recon hinterläßt bei mir den Eindruck, als ob man Ageia "drübergestölpt" hat, also Ageia später dazu gekommen ist.


das ist auch so, Ghost Recon verwendet von Natur aus Havok FX, Ageia wurde drübergestuelpt

[Gast]

Naja ich denke das die Ageia Hardwarelösung einfach noch bischen Zeit benötigt um zu reifen, das kann sie ja eigentlich nur wenn sie verwendet wird und genug feedback bekommt.

Was haben anfangs alle über SLI/Crossfire gewettert: zu wenig Mehrleistung, Spieleunterstützung etc. Wenn man heute in den Foren mal rumschaut was für Rechner die User haben, sind solche Systeme schon weit verbreitet.

Aus Dualcore zieht man doch derzeit auch (noch) nur begrenzt einen nutzen in Games?! So rosig ist die Unterstützung da auch noch nicht oder?! Wir werden ja sehen wie sich die Sache entwickelt :)

Frage: Ihr schreibt, die normal Anzahl der Physikobjekten sei max 500 in Games derzeit, richtig? Ich glaube gelesen zu haben das der PhysX Chip 30.000 berechnen kann?! Wieviel werden den derzeit in einem PhysX unterstützten Spiel verwendet?

[Gast]

Gast[/POST]']

Frage: Ihr schreibt, die normal Anzahl der Physikobjekten sei max 500 in Games derzeit, richtig? Ich glaube gelesen zu haben das der PhysX Chip 30.000 berechnen kann?! Wieviel werden den derzeit in einem PhysX unterstützten Spiel verwendet?

das ist ja nicht das problem, der physikchip kann es auch locker, nur braucht es einiges an mehrleistung auf cpu- und gpu-seite um diese mengen an objekten überhaupt zeichnen zu können.

die jetztigen physX-spiele haben ja auch in erster linie deutlich mehr partikeleffekte, die mit alpha-blending gezeichnet werden und damit den overdraw um einiges erhöhen.

[Gast]

Hey,

zu diesem Thema haben sich einige "profis" hier jetzt aber völlig überschätzt und wie immer den PR-Nasen von ATI geglaubt!

Siehe NEWS von heute!

Mehr sage ich nicht, ich follfe der 3D Guru ergänzt seinen Artikel HIER!

[Monger]

Gast[/POST]']Hey,

zu diesem Thema haben sich einige "profis" hier jetzt aber völlig überschätzt und wie immer den PR-Nasen von ATI geglaubt!

Siehe NEWS von heute!

Mehr sage ich nicht, ich follfe der 3D Guru ergänzt seinen Artikel HIER!

Klar, weil eine anonyme Quelle beim Inquirer ja auch viel vertrauenswürdiger ist als die Experten hier! :rolleyes:

[TheGamer]

Gast[/POST]']Hey,

zu diesem Thema haben sich einige "profis" hier jetzt aber völlig überschätzt und wie immer den PR-Nasen von ATI geglaubt!

Siehe NEWS von heute!

Mehr sage ich nicht, ich follfe der 3D Guru ergänzt seinen Artikel HIER!

Welche News?

[Demirug]

Fuad Abazovic und ein anonymer Entwickler. Eine interessante Kombination allerdings sehe ich ehrlich gesagt den genauen Zusammenhang nicht.

Das aufgeführte „Dilemma“ ist doch vollkommen unabhängig davon ob die Physik jetzt von einer GPU oder PPU berechnet wird. Die Daten müssen vom einem Chip zum anderen und genau da ist der Flaschenhals.

Theoretisch und das ist jetzt bitte auch so zu verstehen könnten bei GPUs von gleichen Hersteller im Treiber oder Hardware (SLI-Bridge) vorhanden Dinge genutzt werden um die Querkommunikation zwischen dem Physik und dem Grafikteil zu verbessern. Aber am Grundproblem wird sich bei Windows XP und D3D9 nichts ändern.

[Bokill]

Demirug[/POST]'] ... Und wie kommen die fertig berechneten Objekte von der PPU zur GPU? Nur über die CPU weil es zwischen PPU und GPU keine gemeinsame Schnittstelle gibt. Zum Zugriff auf die GPU durch die CPU nutzt man nun wiederum die besagten Standards und der Standard Direct3D hat einen Flaschenhals der nur etwa 500 DrawCalls pro Frame aushält. ... Nochmal zum Mitschreiben.

1. Das softwaretechnische Limit bei Direct3D 9 ist derzeit bei ca. 500 Objekten?

1.b. Da taugen die Ageia Angaben von 30.000 Objekten nur noch für Hochglanzbroschüren?

2. Alles Andere mehr säuft ab, da dann die Schnittstelle Direct3D 9 dicht macht?

3. Anders gesagt, selbst ein Monsterchip wie der Clearspeed 600 könnte kaum Mehrleistung bringen, auch dann nicht, wenn sogar eine angepasste Sockel 939/940/AM2-Lösung* auf dem Markt käme?

* = AMD lässt seit April 2006 auch andere Hersteller Chips auf den eigenen CPU Sockeln zu. Der Vorteil besteht darin, dass es keine direktere Chip-Chip Kommunikation bei derartig kurzen Latenzen gibt. PCI, AGP, PCI-Express sind dagegen sehr indirekte Chip-Chip-Verbindungen.

MFG Bobo(2006)

[TheGamer]

Bokill[/POST]']Nochmal zum Mitschreiben.

1. Das softwaretechnische Limit bei DirectX 9 ist derzeit bei ca. 500 Objekten?




Nein :D das hat er auch nicht gesagt, nicht 500 Objekte wie du es wahrschienlich meinst

[Bokill]

500 DrawCalls pro Frame Wie kann man das denn vereinfachen, wenn nicht mit "500 Objekten", die die Grenze zu bilden scheinen?

Ich nehme bezug zur Ageia Chip - CPU - GPU Kommunikation Bezug, NICHT zur Gesamtheit aller bewegten Objekte, die eine GPU fröhlich für sich selbst hinpinselt!

TheGamer[/POST]']Nein :D das hat er auch nicht gesagt, nicht 500 Objekte wie du es wahrschienlich meinst Wie meine ich es denn nach deiner Meinung? Erzähl mal ... ;)

MFG Bobo(2006)

[Neomi]

Bokill[/POST]']Wie kann man das denn vereinfachen, wenn nicht mit "500 Objekten", die die Grenze zu bilden scheinen?

Einen Drawcall kann man nicht mit irgendwas anderem ersetzen, ohne daß es falsch wird. 1 Drawcall pro Objekt gilt nur dann, wenn man nur ein Objekt pro Drawcall rendert (klingt seltsam, ich weiß), und genau das führ ja zu dem angesprochenen Dilemma. Und deshalb gibt es ein paar Möglichkeiten, gleich etliche Objekte in einem einzigen Drawcall zu rendern, jede Möglichkeit mit ihren eigenen Nachteilen. Die Möglichkeiten hat Demirug aber auch genannt, sogar direkt im Eröffnungsposting.

[TheGamer]

Neomi[/POST]']Einen Drawcall kann man nicht mit irgendwas anderem ersetzen, ohne daß es falsch wird. 1 Drawcall pro Objekt gilt nur dann, wenn man nur ein Objekt pro Drawcall rendert (klingt seltsam, ich weiß), und genau das führ ja zu dem angesprochenen Dilemma. Und deshalb gibt es ein paar Möglichkeiten, gleich etliche Objekte in einem einzigen Drawcall zu rendern, jede Möglichkeit mit ihren eigenen Nachteilen. Die Möglichkeiten hat Demirug aber auch genannt, sogar direkt im Eröffnungsposting.

Instancing wäre nur eine Möglichkeit ab SM3.0