Nvidia: Adaptive Physics EXtensions (APEX)

[AnarchX]

NVIDIA APEX for Developers
http://developer.download.nvidia.com/pix/physx/nv_subpage_feature_apexe.jpg

Available In Early 2008

NVIDIA APEX (Adaptive Physics EXtensions) provides game designers and developers with a streamlined method for implementing best-in-class physical interactions. This new offering saves considerable engineering time and increases efficiencies throughout the development of cutting-edge titles, regardless of the platform and enables designers to more directly utilize NVIDIA’s powerful physics engine with minimal technical assistance.
[...]
http://developer.nvidia.com/object/apex_dev.html

Hmmm...
When will the next engine use APEX?
Currently NVIDIA APEX is for use exclusively with Unreal Engine 3.0. While bringing the technology to new game engines is planned, nothing has been announced yet and NVIDIA’s focus with NVIDIA APEX is on Unreal Engine 3.0.

[deekey777]

Eins muss man NV lassen: Die Firma hält ihr Wort, denn es wurde ja bis Ende Mai versprochen, dass sie in diesem Bereich was tut.

[Bokill]

Ageias APEX-Entwicklerplattform (http://www.orthy.de/index.php?option=com_content&task=view&id=5256&Itemid=86) ... die haben sich nicht mal die Mühe gemacht den Namen von Ageia zu ändern ...

Ageia brachte "APEX" am 16 November 2007 heraus ...

MFG Bobo(2008 )

[Winter[Raven]]

Ageia wurde von NV komplett aufgekauft, alle Namen und Patante... also warum sollte man den Namen ändern wenn dieser so oder einem gehört?

[Bokill]

;6515669']Ageia wurde von NV komplett aufgekauft, alle Namen und Patante... also warum sollte man den Namen ändern wenn dieser so oder einem gehört? Für Eigenwerbung mit neuen nichts sagenden eigenen Akronymen war sich Nvidia nie zu schade ...

Neben nahezu pünktlichen regelmässigen Produkt-Refreshs und Neueinführungen war das sicherlich eines DER Gründe für Nvidias Markterfolg/Popularität.

Ich persönlich finde es aber gut, dass Nvidia offensichtlich die Physik-API offenbar mit Stumpf und Stiel weitgehend von Ageia so übernommen hat, dass es NICHT in der Schublade verschwindet ... ja womöglich der Konkurrenz als API zur Verfügung stellt (Nvidia hat dann immer noch den Finger auf die API und hat den Zeitvorteil gegenüber der Konkurrenz).

MFG Bobo(2008 )

[Moralelastix]

Die Frage is nur ob es einen wirklichen Vorteil gegenüber der CPU Berechnung gibt und was für NV Hardware man dafür brauch. Bis zum Schluss war Ageia Hardware einfach nur überflüssig.

Selbst dass es die kommende GTX 280 einfach so nebenher für umme berechnet ist ja wohl auch auszuschliessen.

Also brauch man eine zusätzliche kleine CUDA fähige Graka dafür.
Reicht schon eine 9600 oder is die zu langsam oder wie?

Wann gehts endlich los?

[MEDIC-on-DUTY]

Ageias APEX-Entwicklerplattform (http://www.orthy.de/index.php?option=com_content&task=view&id=5256&Itemid=86) ... die haben sich nicht mal die Mühe gemacht den Namen von Ageia zu ändern ...

Ageia brachte "APEX" am 16 November 2007 heraus ...

MFG Bobo(2008 )

Die werden die Marke nach und nach reduzieren. War bei den Siemenshandys nicht anders. Erst war das Siemens-Logo noch ganz groß, dann kam das BenQ immer deutlicher zum Vorschein. So gewöhnt man die Kunden langsam daran.

[Bokill]

Die werden die Marke nach und nach reduzieren. ... Ich persönlich hatte damit gerechnet, dass das alles unter Nvidias "CUDA" subsummiert wird.

In so fern ist das schon bemerkenswert, dass die Systemumgebung "APEX" noch ein "Eigenleben" bei Nvidia führt.

MFG Bobo(2008 )

[robbitop@work]

Also brauch man eine zusätzliche kleine CUDA fähige Graka dafür.


Das müßte auch mit einer Karte gehen. Der GPU ist es ziemlich egal, was sie gerade rechnet.
Wenn es eine zweite Karte benötigen würde, sähen die Verbreitungschancen dieses Konzeptes gleich deutlich schlechter aus.

[The_Silent_One]

seh ich auch so @robbitop

aber selbst wenn man eine zweite kleine nv karte braucht, sind die verbreitungschancen doch noch besser als bei den physx karten. allein schon vom preis her.

physx >= 80€
GeForce 8400 GS >=30€

[BAGZZlash]

Das müßte auch mit einer Karte gehen. Der GPU ist es ziemlich egal, was sie gerade rechnet.
Wenn es eine zweite Karte benötigen würde, sähen die Verbreitungschancen dieses Konzeptes gleich deutlich schlechter aus.

Ja, aber zwei Fragen dazu:

1.) Falls das mit einer Karte fluppen soll, dann braucht's zumindest 'nen Scheduler; mal muss den Physikberechnungen (GPU-)Rechenzeit zugeteilt werden und mal den Grafikberechnungen. Am Besten noch skalierbar, damit auf langsameren Karten mehr Rechenzeit für Grafikberechnungen zur Verfügung steht unter 'runterschrauben der Physikdetails bzw. umgekehrt. Darüberhinaus ist der GraKa dann aber nicht mehr ganz egal, was sie rechnet, Grafik oder Physik. Würde man nur physikalische Berechnungen auf der GraKa ausführen, um das Ganze per (CPU-)Code weiterzuverwenden (sozusagen die GPU nur als numbercruncher verwendet, wie bei GPGPU-Anwendungen), so wäre nämlich durch Busoverhead und Verwaltungsaufwand viel vom Vorteil dahin. Das ist eines der wesentlichen Probleme, die die dedizierte PhysX-Hardware hatte. Sinn macht das Ganze also nur, wenn die Physikberechnung (also alles: Der Code, die eigentliche Berechnung, die Ergebnisse und deren Weiterverwendung) komplett auf der GraKa stattfinden. Das soll wohl so gemacht werden, deswegen wird die Engine ja auch in CUDA geschrieben/portiert. Dann aber muss schon unterschieden werden zwischen Physikdaten und -ergebnissen und Grafikdaten und -ergebnissen. In diesem Fall muss die GraKa das schon "wissen", es ist ihr nicht egal.

2.) Will nVidia aus Marketinggründen, dass alles auf einer Karte läuft? Ich könnte mir gut vorstellen, dass nVidia einfach sagt "Nee, geht nicht auf einer Karte, eine Zweite ist zwingend erforderlich". Klar geht dann die Verbreitung nicht so schnell, aber das ist für nVidia auch nicht wichtig. Geld ist wichtig. Er geht um Profit. Und wenn das System überzeugen kann, dann ist genug Leuten egal, dass dafür Extrahardware erforderlich ist. Die kaufen.

[Moralelastix]

Niemals lässt sich NV das Verkaufen von zusätzlicher Hardware durch die Lappen gehen.

Is ja auch gut so:Ich will ja auch dass es im Gesicht zieht wenn ich auf'n Bildschirm glotz.
Und net so ne lauwarme Kacke wie noch zu Ägeiäs Zeiten wo man die starke Lupe gebraucht hat um was zu sehen.

[Coda]

Ich persönlich hatte damit gerechnet, dass das alles unter Nvidias "CUDA" subsummiert wird.
Ergibt doch gar keinen Sinn. CUDA steht für eine GPU Programmiersprache, nicht für Physik.

Man nennt Havok ja auch nicht C++.

[robbitop@work]

Ja, aber zwei Fragen dazu:

1.) Falls das mit einer Karte fluppen soll, dann braucht's zumindest 'nen Scheduler; mal muss den Physikberechnungen (GPU-)Rechenzeit zugeteilt werden und mal den Grafikberechnungen.
Es sind ja simultan zich Threads auf einer GPU vorhanden. Einen Sheduler und einen Dispatcher nutzt man dafür natürlich schon seit langem.

Am Besten noch skalierbar, damit auf langsameren Karten mehr Rechenzeit für Grafikberechnungen zur Verfügung steht unter 'runterschrauben der Physikdetails bzw. umgekehrt.
Bevor gerendert werden kann, muss die GP-Berechnung durch sein. Mit einem skalierbaren Sheduler würde man zusätzliche Flaschenhälse einbauen.


Darüberhinaus ist der GraKa dann aber nicht mehr ganz egal, was sie rechnet, Grafik oder Physik.
Der GPU ist das egal.


Würde man nur physikalische Berechnungen auf der GraKa ausführen, um das Ganze per (CPU-)Code weiterzuverwenden (sozusagen die GPU nur als numbercruncher verwendet, wie bei GPGPU-Anwendungen), so wäre nämlich durch Busoverhead und Verwaltungsaufwand viel vom Vorteil dahin. Das ist eines der wesentlichen Probleme, die die dedizierte PhysX-Hardware hatte. Sinn macht das Ganze also nur, wenn die Physikberechnung (also alles: Der Code, die eigentliche Berechnung, die Ergebnisse und deren Weiterverwendung) komplett auf der GraKa stattfinden. Das soll wohl so gemacht werden, deswegen wird die Engine ja auch in CUDA geschrieben/portiert. Dann aber muss schon unterschieden werden zwischen Physikdaten und -ergebnissen und Grafikdaten und -ergebnissen. In diesem Fall muss die GraKa das schon "wissen", es ist ihr nicht egal.

Ich gehe davon aus, dass ersteinmal nur Effektphysik zu sehen sein wird. Das hat auch Gründe in der Laufzeit. (Buslaufzeit, Pipelinetiefe ect)
Wenn du aber Gamerelevante Physik machen möchtest, müssen die Ergebnisse so oder so zurück zur CPU. Und das ergibt dann Laufzeitprobleme. Bei Effektphysik ist das nicht der Fall.


2.) Will nVidia aus Marketinggründen, dass alles auf einer Karte läuft? Ich könnte mir gut vorstellen, dass nVidia einfach sagt "Nee, geht nicht auf einer Karte, eine Zweite ist zwingend erforderlich". Klar geht dann die Verbreitung nicht so schnell, aber das ist für nVidia auch nicht wichtig. Geld ist wichtig. Er geht um Profit. Und wenn das System überzeugen kann, dann ist genug Leuten egal, dass dafür Extrahardware erforderlich ist. Die kaufen.
Wenn NV eine 2. Karte notwendig macht, wird das gleiche passieren, wie mit PhysX. Verbreitung ist einfach alles. Für ein paar wenige Enthusiasten wird kein großartiger Kontent entwickelt sondern für die Massen.

[tombman]

Sicher ist das der GPU egal, die weiß ja nicht was sie da rechnet, ob ein Teil eines Pixel shaders oder Physikberechnungen.
Die bekommt einfach Daten angeliefert und soll damit was rumrechnen, eben was der shader/Programm verlangt.
Die ist ein dummer Rechensklave/Number Crunsher, und sonst gar nix :)

[Gast]

Selbst dass es die kommende GTX 280 einfach so nebenher für umme berechnet ist ja wohl auch auszuschliessen.



es ist stark davon auszugehen, dass die GTX280 deutlich mehr rechenleistung als die aktuelle 9800GTX+PhysX zusammen besitzt.

sicherlich wird es leistung kosten, aber nur einen bruchteil von dem was die GPU hat.

andererseits haben wir natürlich weiter das übliche henne-ei-problem.
beim gaming limitiert in >90% der fälle immer die grafikkarte, während auf der cpu insbesondere bei quadcores in der regel noch jede menge frei ist.

die physik von der GPU berechnen zu lassen macht nur sinn wenn sie dermaßen aufwändig ist, dass die CPU sie garnicht bewältigen könnte. wenn sie dermaßen aufwändig ist, wird sie allerdings auch auf der GPU nennenswert leistung kosten.

damit haben wir natürlich vor allem marketingmäßig ein problem, physik auf der GPU wird leistung kosten, und einen leistungsverlust kann man immer schlecht verkaufen, vor allem wenn man das resultat schlecht illustrieren kann.

[Gast]

J

1.) Falls das mit einer Karte fluppen soll, dann braucht's zumindest 'nen Scheduler; mal muss den Physikberechnungen (GPU-)Rechenzeit zugeteilt werden und mal den Grafikberechnungen. Am Besten noch skalierbar, damit auf langsameren Karten mehr Rechenzeit für Grafikberechnungen zur Verfügung steht unter 'runterschrauben der Physikdetails bzw. umgekehrt.


einen scheduler braucht es immer, auf einer GPU sind ständig 1000e threads vorhanden die den ausführungseinheiten zugeordnet werden müssen, ob da jetzt noch ein paar physik-threads dazukommen ist dem scheduler ziemlich egal.

zweiteres wirst du dagegen nicht realisieren können. du kannst nicht mittendrin die physikberechnung abbrechen, weil du plötzlich mehr rechenleistung anderswo brauchst, da würde ein ziemliches chaos herauskommen. wenn du die physik berechnen willst, musst du sie gesamt berechnen.
zusätzlich wäre das schon eindeutig im bereich des cheatings einzuordnen, wenn man einfach von der anwendung geforderte berechnungen nicht macht.

eine schwache GPU schaltet ja auch nicht einfach FSAA/AF aus, wenn die awendung es will, nur weil die leistung nicht ausreicht.

[BAGZZlash]

Es sind ja simultan zich Threads auf einer GPU vorhanden. Einen Sheduler und einen Dispatcher nutzt man dafür natürlich schon seit langem.

Stimmt natürlich. Früher war der ja sogar in Hardware, fest verdrahtet.


Ich gehe davon aus, dass ersteinmal nur Effektphysik zu sehen sein wird. Das hat auch Gründe in der Laufzeit. (Buslaufzeit, Pipelinetiefe ect)
Wenn du aber Gamerelevante Physik machen möchtest, müssen die Ergebnisse so oder so zurück zur CPU. Und das ergibt dann Laufzeitprobleme. Bei Effektphysik ist das nicht der Fall.

Mit Effektphysik - nur um den Begriff zu definieren - ist alles gemeint, was die Geometrie nicht beeinflusst. Kann man das so sagen?


Wenn NV eine 2. Karte notwendig macht, wird das gleiche passieren, wie mit PhysX. Verbreitung ist einfach alles. Für ein paar wenige Enthusiasten wird kein großartiger Kontent entwickelt sondern für die Massen.

Du magst recht haben. Trotzdem: Ich sehe das das anders. Der Punkt jedoch ist: Das ist nicht nur eine technische, sondern auch und vor allem eine Marketingentscheidung. Wir werden sehen, wer recht behält. Vermutlich ist man sich selbst in Kalifornien noch nicht wirklich im Einen darüber. Höchstwahrscheinlich wird es so kommen: Grundsätzlich möglich wird es zwar auf einer einzigen Karte sein (sozusagen als Futter für die Massen), die Performance aber wird mies sein. Für überproportional mehr Performance (und auch Qualität/Details?) braucht man dann die Zusatzkarte. Außerdem ist gut vorstellbar, dass selbst die billigste CUDA-fähige Karte die nötigen Berechnungen als dedizierter Physikberechner spielend erledigen kann. Dennoch wird wohl kaum die weiter oben erwähnte 8400 GS für 30 € reichen. Damit lässt sich ja kein Geld verdienen... :wink:


Sicher ist das der GPU egal, die weiß ja nicht was sie da rechnet, ob ein Teil eines Pixel shaders oder Physikberechnungen.
Die bekommt einfach Daten angeliefert und soll damit was rumrechnen, eben was der shader/Programm verlangt.
Die ist ein dummer Rechensklave/Number Crunsher, und sonst gar nix :)

Könntest Du mir eventuell bei weiteren informationstechnischen Fragen helfen? :tongue:


zweiteres wirst du dagegen nicht realisieren können. du kannst nicht mittendrin die physikberechnung abbrechen, weil du plötzlich mehr rechenleistung anderswo brauchst, da würde ein ziemliches chaos herauskommen. wenn du die physik berechnen willst, musst du sie gesamt berechnen.

Selbstverständlich. Was meinst Du, wie Multitasking realisiert wird? Das wirft aber noch eine weitere Frage auf: Wenn man auf einer einzigen Graka rendert und Physik rechnet, wird man wohl nicht umhin kommen, dedizierte Shaderprozessoren für die Berechnung der Physik abzustellen. Eine CPU wirft ja beim Taskswitch einfach alle Register auf den Stack. Sowas hat 'ne GraKa ja gar nicht (statt dessen evtl. auf den Speicher, wenn der schnell genug ist?). Selbst wenn der Shaderprozessor zunächst die ganze (für eine Grafikberechnung vorgesehene) Matrix zuende rechnen würde (die Physik für den nächsten Frame also solange warten muss und somit nicht schon für den nächsten Frame vorberechnet werden kann, was ohnehin schon viel Performance ziehen würde), um dann eine (für Physik gedachte) Rechnung beginnen würde, wäre der Verschnitt im Pipelining der anstehenden Daten wohl riesig. Dedizierte Einheiten wären besser, denke ich (ein Eingriff in den Scheduler ist aber spätestens dann unabdingbar). Darüber könnte man dann auch skalieren, wie ich es vorhin schon beschrieben hatte. Gemeinerweise könnte man auch hier ansetzen, um die Performance bei Berechnungen von Physik und Grafik auf einer einzelnen Karte künstlich zu senken: Man lässt einfach einige Einheiten nichts tun. Das wäre nVidia nie zu beweisen und würde genau das erreichen, was nVidia braucht: Massives Einbrechen der Performance bei "shared calculating" und volle Performance bei dedizierter Hardware.


eine schwache GPU schaltet ja auch nicht einfach FSAA/AF aus, wenn die awendung es will, nur weil die leistung nicht ausreicht.

Der Vergleich hinkt wie sonstwas.

[Coda]

Stimmt natürlich. Früher war der ja sogar in Hardware, fest verdrahtet.
Das ist er immer noch.

Mit Effektphysik - nur um den Begriff zu definieren - ist alles gemeint, was die Geometrie nicht beeinflusst. Kann man das so sagen?
Ja kann man.

..., die Performance aber wird mies sein.
Warum? Es gibt keinen guten Grund dazu.

Selbstverständlich. Was meinst Du, wie Multitasking realisiert wird?
Offenbar hast du jedenfalls eine falsche Vorstellung davon.

Das wirft aber noch eine weitere Frage auf: Wenn man auf einer einzigen Graka rendert und Physik rechnet, wird man wohl nicht umhin kommen, dedizierte Shaderprozessoren für die Berechnung der Physik abzustellen.
Wieso das denn?

Eine CPU wirft ja beim Taskswitch einfach alle Register auf den Stack.
Erstens nicht auf den Stack, sondern ins RAM bzw. in den Cache und zweitens macht das nicht die CPU sondern das Betriebssystem.

Sowas hat 'ne GraKa ja gar nicht (statt dessen evtl. auf den Speicher, wenn der schnell genug ist?).
In der Tat nicht. Deshalb ist die maximale Anzahl an Threads auch dadurch limitiert wieviel Register man pro Programm braucht bei G80.

Selbst wenn der Shaderprozessor zunächst die ganze (für eine Grafikberechnung vorgesehene) Matrix zuende rechnen würde
Was für eine "Matrix"? Du weißt doch gar nicht von was du redest.

(die Physik für den nächsten Frame also solange warten muss und somit nicht schon für den nächsten Frame vorberechnet werden kann, was ohnehin schon viel Performance ziehen würde), um dann eine (für Physik gedachte) Rechnung beginnen würde, wäre der Verschnitt im Pipelining der anstehenden Daten wohl riesig.
Es ist natürlich immer nur ein Streamkernel pro Prozessor aktiv.

Dedizierte Einheiten wären besser, denke ich
Dann solltest du darüber nochmal ganz gewaltig nachdenken. Das ergibt überhaupt gar keinen Sinn bei der Richtung in die wir uns bewegen bei GPUs. Da drückt's mir echt Fragezeichen aus dem Kopf wie man so einen pseudotechnischen Text formulieren kann und dazu noch so komische Vorstellung hat.

Wir haben unified shader. Das heißt die GPU ist um einen riesigen Vektorprozessor aufgebaut der sich natürlich auch wunderbar für Physik eignet. Es ergibt überhaupt keinen Sinn ALUs einzubauen die nur für Physik arbeiten können und sonst rumidlen. Das wär eine völlig Resourcenverschwendung.

Der Vergleich hinkt wie sonstwas.
Nein tut er nicht.

[Simon]

Selbstverständlich. Was meinst Du, wie Multitasking realisiert wird? Das wirft aber noch eine weitere Frage auf: Wenn man auf einer einzigen Graka rendert und Physik rechnet, wird man wohl nicht umhin kommen, dedizierte Shaderprozessoren für die Berechnung der Physik abzustellen. Eine CPU wirft ja beim Taskswitch einfach alle Register auf den Stack. Sowas hat 'ne GraKa ja gar nicht (statt dessen evtl. auf den Speicher, wenn der schnell genug ist?). Selbst wenn der Shaderprozessor zunächst die ganze (für eine Grafikberechnung vorgesehene) Matrix zuende rechnen würde (die Physik für den nächsten Frame also solange warten muss und somit nicht schon für den nächsten Frame vorberechnet werden kann, was ohnehin schon viel Performance ziehen würde), um dann eine (für Physik gedachte) Rechnung beginnen würde, wäre der Verschnitt im Pipelining der anstehenden Daten wohl riesig. Dedizierte Einheiten wären besser, denke ich (ein Eingriff in den Scheduler ist aber spätestens dann unabdingbar). Darüber könnte man dann auch skalieren, wie ich es vorhin schon beschrieben hatte. Gemeinerweise könnte man auch hier ansetzen, um die Performance bei Berechnungen von Physik und Grafik auf einer einzelnen Karte künstlich zu senken: Man lässt einfach einige Einheiten nichts tun. Das wäre nVidia nie zu beweisen und würde genau das erreichen, was nVidia braucht: Massives Einbrechen der Performance bei "shared calculating" und volle Performance bei dedizierter Hardware.
Das wird nie und nimmer darauf hinauslaufen, dass extra Einheiten auf der Grafikkarte für die Physik zuständig sind.
Im nv-Forum heißt es seitens Nvidia, dass ein Switch zwischen CUDA und OpenGL/D3D ausreichend schnell ist, um das pro Frame zu machen. Die Lösung von Nvidia wird also in etwa so aussehen (wobei das immer noch keine gute Lösung für die Kommunikation zwischen Physik-API und Render-API gibt):

Frame n:
Context Switch
Berechne Physik mit CUDA
Context Switch
Rendern
Frame n+1:
Context Switch
Berechne Physik mit CUDA
Context Switch
Rendern
...

Was du vorschlägst ist Präemptives Multitasking und dazu müßte die GPU für jeden Wechsel die komplette Pipeline leeren und dann wirds wirklich langsam ;D


eine schwache GPU schaltet ja auch nicht einfach FSAA/AF aus, wenn die awendung es will, nur weil die leistung nicht ausreicht.
Wobei das gar keine schlechte Idee wäre, wenn das funktioniert (find ich). AF lässt sich zwar zur Laufzeit ändern, FSAA aber weniger...

[Gast]

Mit Effektphysik - nur um den Begriff zu definieren - ist alles gemeint, was die Geometrie nicht beeinflusst. Kann man das so sagen?

alles was das spielgeschehen nicht beeinflusst, mit D3D10 wäre es auch möglich die geometrie zu beeinflussen, ob man damit auch die spielwelt konsistent halten kann ist natürlich eine andere frage ;)
die cascades-demo nutzt ja beispielsweise die GPU um den wasserfluss zu berechnen und kann dabei auch die geometrie verändern.



Selbstverständlich. Was meinst Du, wie Multitasking realisiert wird? Das wirft aber noch eine weitere Frage auf: Wenn man auf einer einzigen Graka rendert und Physik rechnet, wird man wohl nicht umhin kommen, dedizierte Shaderprozessoren für die Berechnung der Physik abzustellen. Eine CPU wirft ja beim Taskswitch einfach alle Register auf den Stack. Sowas hat 'ne GraKa ja gar nicht (statt dessen evtl. auf den Speicher, wenn der schnell genug ist?).

auch auf der cpu wird beim context-switch register- und stackinhalt in den speicher (bzw. cache) geschrieben, was allerdings das betriebssystem und nicht die hardware macht.

bei der GPU schwirrt dagegen der ganze inhalt eines threads immer irgendwo in der GPU herum. möglicherweise wäre es sogar denkbar diese auch in den RAM auszulagern, allerdings wäre das viel zu lahm.
in den meisten fällen wird es eh notwendig sein, dass die physikberechnungen vor dem rendering fertig sind, womit sich renderthreads und physikthreads kaum in die quere kommen sollten.
eigene einheiten für die physik wären ziemlich dämlich, wir haben gerade (ok ist schon ein paar jährchen her) den sprung zu unified shader geschafft, und nun sollen wird das für die physik wieder aufbrechen? für was, um transistoren zu verschwenden?

[Gast]

Wobei das gar keine schlechte Idee wäre, wenn das funktioniert (find ich). AF lässt sich zwar zur Laufzeit ändern, FSAA aber weniger...

nicht wenn es das programm anfordert, dann soll auch das gerechnet werden.

auch FSAA würde sich zur laufzeit ändern lassen, nur den speicher wird man kaum vernünftig dynamisch alloziieren können, weshalb der speicherverbrauch immer der maximalen FSAA-stufe entsprechen würde.
AF ist eh per definition adaptiv, da wird nichts zu viel gerechnet.

[Gast]

Mit Effektphysik - nur um den Begriff zu definieren - ist alles gemeint, was die Geometrie nicht beeinflusst. Kann man das so sagen?
Effektphysik ist alles was das eigentliche Spiel nicht beeinflusst. Da weder KI, Gamelogik oä. davon betroffen sind, ist keine Synchronisation notwendig.

[BAGZZlash]

Das ist er immer noch.

Wusste ich nicht. Ich dachte, mit der unified Architektur ist der programmierbar geworden. War allerdings nur 'ne Vermutung. Wieder was gelernt! (y)


Warum? Es gibt keinen guten Grund dazu.

Doch. Spätestens Marketinggründe, wie bereits erwähnt.


Offenbar hast du jedenfalls eine falsche Vorstellung davon.

Nein, hab' ich nicht, glaub' mir. :smile:


Wieso das denn?

Das war vielleicht etwas blöd formuliert. Ich meine nicht, dass es extra Physik-Prozessoren auf Grafikhardware geben soll. Ich meine folgendes: Nehmen wir z.B. G80. Dort gibt es 128 Shaderprozessoren (die Zählweise ist streitig, ich weiss, aber nehmen wir's mal so). Dann sollte von diesen 128 eine feste Anzahl von Prozessoren, z.B. 16, für Physikberechnungen abgestellt werden. Per Programmanweisung. Also wieder auflösbar. Der Scheduler leitet Grafikdaten an die übrigen Prozessoren. Somit wäre gewährleistet, dass die in diesem Moment für Physik eingesetzten Prozessoren auch nur Daten hierfür bekommen, was Verschnitt an verworfenen Daten reduzieren würde.


Erstens nicht auf den Stack, sondern ins RAM bzw. in den Cache und zweitens macht das nicht die CPU sondern das Betriebssystem.

Natürlich macht das das Betriebsystem. Es löst ja schließlich den switch auch aus. Ist im Prinzip ja nix anderes als 'ne Exception, die 'nen Handler auslöst. Deswegen hängt es auch vom Betriebsystem ab, wohin die Register letztlich geschrieben werden. Mir geht's nicht darum, in diesem Punkt unbedingt recht haben zu wollen. Mein Buch, das ich darüber mal gelesen habe, war hier wohl nur etwas zu theoretisch oder veraltet.


Was für eine "Matrix"? Du weißt doch gar nicht von was du redest.

Hmm. Zunächst einmal finde ich Deine Art, sowas von oben herab einfach hinzuknallen, ziemlich zum Kotzen. Bist ziemlich selbstgerecht (http://de.wikipedia.org/wiki/Selbstgerechtigkeit), findest Du nicht? Zum Anderen verstehe ich nicht, warum Du das nicht verstehst. Hast Du schonmal 'ne Renderingengine geschrieben? Ich schon, mehrere sogar: Direct3D und auch Softwarerendering mit komplettem Code "from scratch". Ich suche Dir gern mal den Thread hier im Forum dazu 'raus. Also was soll das: Weißt Du nicht, was 'ne Matrix ist? Weißt Du, was für Berechnungen zum Darstellen der schönen bunten 3D-Bilder nötig sind? Ist Dir klar, dass Translation, Rotation und Projektion von Vertices im dreidimensionalen Raum elementare lineare Algebra erfordern? Texturierung ebenfalls?
Um ehrlich zu sein: Ja, ich glaube, dass Du das weisst. Also warum verstehst Du mein kleines Sätzchen nicht? Ehrlich gemeinte Frage, ich will nicht, dass das hier ein Bashthread wird.
Meine Vermutung ist: Du beziehst Dich wohl darauf, dass klassische Shaderprogramme natürlich nicht für die eben erwähnten Aufgaben herangezogen werden. Dennoch: Eine GPU ist nichts anderes als ein massiver Numbercruncher für MUL und MADD. Zum Matrizenmultiplizieren werden die Dinger gebaut, das ist nun mal so.


Dann solltest du darüber nochmal ganz gewaltig nachdenken. Das ergibt überhaupt gar keinen Sinn bei der Richtung in die wir uns bewegen bei GPUs. Da drückt's mir echt Fragezeichen aus dem Kopf wie man so einen pseudotechnischen Text formulieren kann und dazu noch so komische Vorstellung hat.

Siehe oben. Hab' nicht genau genug beschrieben, was ich meinte, deswegen hast Du's nicht begriffen. Sorry.


Wir haben unified shader. Das heißt die GPU ist um einen riesigen Vektorprozessor aufgebaut der sich natürlich auch wunderbar für Physik eignet. Es ergibt überhaupt keinen Sinn ALUs einzubauen die nur für Physik arbeiten können und sonst rumidlen. Das wär eine völlig Resourcenverschwendung.

Hamwa's jetzt? :rolleyes:


Nein tut er nicht.

Doch, tut er.

[Simon]

Das war vielleicht etwas blöd formuliert. Ich meine nicht, dass es extra Physik-Prozessoren auf Grafikhardware geben soll. Ich meine folgendes: Nehmen wir z.B. G80. Dort gibt es 128 Shaderprozessoren (die Zählweise ist streitig, ich weiss, aber nehmen wir's mal so). Dann sollte von diesen 128 eine feste Anzahl von Prozessoren, z.B. 16, für Physikberechnungen abgestellt werden. Per Programmanweisung. Also wieder auflösbar. Der Scheduler leitet Grafikdaten an die übrigen Prozessoren. Somit wäre gewährleistet, dass die in diesem Moment für Physik eingesetzten Prozessoren auch nur Daten hierfür bekommen, was Verschnitt an verworfenen Daten reduzieren würde.
Ok, dann nochmal: Das funktioniert so nicht. Du kannst nicht ein paar Shader-Prozessoren A rechnen lassen, während der Rest in einem anderen Context B rechnet.

Hmm. Zunächst einmal finde ich Deine Art, sowas von oben herab einfach hinzuknallen, ziemlich zum Kotzen. ...
Sorry, aber an der Stelle hat Coda recht, auch wenn die Formulierung vielleicht etwas unglücklich war... Was für eine "Matrix" berechnen denn die Stream-Prozessoren deiner Meinung nach?

Du solltest etwas vorsichtig sein, du kannst nicht einfach die OS-Konzepte aus dem Tanenbaum (gedacht für CPUs) auf GPUs übertragen. Soweit ähneln sich GPU und CPU dann doch nicht...

[BAGZZlash]

Ok, dann nochmal: Das funktioniert so nicht. Du kannst nicht ein paar Shader-Prozessoren A rechnen lassen, während der Rest in einem anderen Context B rechnet.

Ich seh's ja ein. Allerdings ist es keineswegs so, dass das per se "nicht geht". Ich habe auch nur gesagt, dass man es aus verschiedenen Gründen theoretisch so machen sollte (Effizienz etc., sie oben). Robbitop hat das schnell verstanden, sagt aber, dass dies zu anderen Flaschenhälsen führt. Da mag er recht haben. Aber er ist zumindest bereit, über den Tellerrand hinaus zu sehen.
Derzeit ist es in der Tat nicht möglich, einzelnen Shaderprozessoren bestimmte Aufgaben exklusiv zuzuweisen. Wenn dies aber sinnvoll wäre, so müsste man halt den Scheduler anpassen, damit das möglich wird. Deswegen reite ich so darauf 'rum. Das und nur das war mein Vorschlag.


Sorry, aber an der Stelle hat Coda recht, auch wenn die Formulierung vielleicht etwas unglücklich war... Was für eine "Matrix" berechnen denn die Stream-Prozessoren deiner Meinung nach?

Allein schon die Tatsache, dass Ihr das Wort Matrix in Anführungszeichen schreibt... *Weiche, unbekanntes Wesen* :smile: Gelesen, was ich oben geschrieben habe? Schonmal ein Shaderprogramm angeschaut? Ein Pixelshader multipliziert beispielsweise zwei Farbvektoren miteinander. Oder einen Lichtvektor mit einem Normalenvektor. Ein Vertexshader multipliziert einen Vertex mit einer Rotationsmatrix oder World-, Projektions- und Viewmatrix miteinander. Wer sich wundert, dass Grafikkarten Matrizen berechnen, hat elementare Dinge der 3D-Programmierung nicht verstanden.

[Gast]

Wer sich wundert, dass Grafikkarten Matrizen berechnen, hat elementare Dinge der 3D-Programmierung nicht verstanden.

Du hast doch eben gerade erläutert, dass Grafikkarten KEINE Matrizen berechnen, sondern die Matrizen nur die Input-Daten für den Chip sind.

[Coda]

Hast Du schonmal 'ne Renderingengine geschrieben?
Ja.

Soll das "Matrix berechnen" nur ein Beispiel sein oder wie? Eine GPU berechnet wenn dann einen Shader, aber keine "Matrix". Deshalb das ganze in Anführungszeichen. Es passt einfach nicht in den Kontext. Spätestens mit SM2 weiß die GPU doch allein schon gar nicht mehr dass Daten überhaupt eine Matrix sind auf denen sie grad rumrechnet.

Das klang doch sehr laienhaft.

[BAGZZlash]

Du hast doch eben gerade erläutert, dass Grafikkarten KEINE Matrizen berechnen, sondern die Matrizen nur die Input-Daten für den Chip sind.

Fritzchen berechnet keine Zahlen. Zahlen sind nur seine Inputdaten. Hmm, ist dasselbe, oder? Auch die Ergebnisse von Matrizenoperationen sind i.d.R. Matrizen: A(3x2) x B(2x4) = AB(3x4).


Ja.

Soll das "Matrix berechnen" nur ein Beispiel sein oder wie?

Ja. Ich will auch da gar nicht so drauf 'rumreiten. Wollte nur sagen, dass der Prozessor eben seine aktuelle Aufgabe beenden sollte.

[Gast]

Fritzchen berechnet keine Zahlen. Zahlen sind nur seine Inputdaten. Hmm, ist dasselbe, oder? Auch die Ergebnisse von Matrizenoperationen sind i.d.R. Matrizen: A(3x2) x B(2x4) = AB(3x4).


Nein, die Ergebnisse sind Vektoren!

[del_4901]

@BAGZZlash: Eine NCC1701 darzustellen, wuerde ich nicht als Renderengine bezeichnen wollen. Sei mal ein bissel nett zu Coda, dann ist er auch zuvorkommend.

@Coda: Sei doch nicht immer so kurz angebunden.

[Coda]

Nein, die Ergebnisse sind Vektoren!
Vektoren sind auch nur Matrizen mit einer Spalte wenn man jetzt pingelig wäre.

[Gast]

Vektoren sind auch nur Matrizen mit einer Spalte wenn man jetzt pingelig wäre.

Was du ja aber nicht bist.;) Ich wollte nur klar machen, dass das Ergebnis einer Rechenoperation ein Pixel oder ein Vertex ist. Und beides sind Vektoren (aka einspaltige Matrizen).

[BAGZZlash]

@BAGZZlash: Eine NCC1701 darzustellen, wuerde ich nicht als Renderengine bezeichnen wollen.

Schön,dass Du Dich noch daran erinnerst. :smile: Auch wenn das sicherlich kein hochprofessionelles Werk war, reicht es aber, um zu wissen, wovon ich rede. Vor allem aber reicht's, um von Coda nicht wie der letzte Vollhorst hingestellt zu werden. :rolleyes:


Sei mal ein bissel nett zu Coda, dann ist er auch zuvorkommend.

Eigentlich kann man erwarten, dass er höflich ist, auch ohne dass man vorher nett zu ihm gewesen sein muss, meinst Du nicht auch? Aber bitte - wenn er sich entschuldigt, gerne! :cool:

[del_4901]

Schön,dass Du Dich noch daran erinnerst. :smile: Auch wenn das sicherlich kein hochprofessionelles Werk war, reicht es aber, um zu wissen, wovon ich rede. Vor allem aber reicht's, um von Coda nicht wie der letzte Vollhorst hingestellt zu werden. :rolleyes:
Man darf sich in der Branche keine Fehler erlauben. Lieber einmal mehr nachgefragt, als Müll gebaut. Das was du da gemacht hast, reicht definitiv nicht aus, um deine Aussagen stützen zu können. Das ist inzwischen so ein komplexes Thema geworden, das kann nichtmal ich (Ego Ego Ego ;) ) allein überblicken.

Eigentlich kann man erwarten, dass er höflich ist, auch ohne dass man vorher nett zu ihm gewesen sein muss, meinst Du nicht auch? Aber bitte - wenn er sich entschuldigt, gerne! :cool:

Wenn Coda kurz angebunden ist, heißt das noch nicht, dass er unhöflich war. Anfangs wollte Coda nur deine Fehler korrigiern, dabei hat er das sehr auf den Punkt gebracht. Aber ihr habt euch da so reingesteigert, dann kommen natürlich solche Züge durch. Wir Profis klugscheissen alle gerne, man hört sich einfach gerne selber reden. Das ist natürlich auch schwer diese Marotte zu überwinden, da muss man ein klein wenig Tolleranz zeigen, schließlich willst du ja was lernen.

[Liszca]

Nach den SLI Microrucklern kriegen wir noch zusätzlich sporadisch auftretende APEx Ruckler.

Ach wie schön waren doch die glide zeiten:rolleyes:.

[ScottManDeath]

Ok, dann nochmal: Das funktioniert so nicht. Du kannst nicht ein paar Shader-Prozessoren A rechnen lassen, während der Rest in einem anderen Context B rechnet.



Doch, das geht. Es laufen ja parallel Vertex Shader und Pixel Shader Threads.

Unter CUDA ist es eine API Limitiering das nur 1 Kernel gleichzeitig ausgefuehrt werden kann.

[tombman]

Nach den SLI Microrucklern kriegen wir noch zusätzlich sporadisch auftretende APEx Ruckler.

Ach wie schön waren doch die glide zeiten:rolleyes:.
Rofl, Depression total :D

Aber ein paar Ruckler nehme ich bzgl APEX gerne hin, wenn ich dafür ingame alles zerstören kann :)

[Liszca]

Doch, das geht. Es laufen ja parallel Vertex Shader und Pixel Shader Threads.

Unter CUDA ist es eine API Limitiering das nur 1 Kernel gleichzeitig ausgefuehrt werden kann.

Diese Unified shader sind doch immer zu einem "rudel" zusammen geschloßen, kann da nicht ein "rudel" für die grafik rechnen und eines für die physik? warum sollte das nicht gehen :confused:

[Simon]

Doch, das geht. Es laufen ja parallel Vertex Shader und Pixel Shader Threads.

Unter CUDA ist es eine API Limitiering das nur 1 Kernel gleichzeitig ausgefuehrt werden kann.

Dann missversteh ich diesen Satz:
Is it possible to run multiple CUDA applications and graphics applications at the same time?

CUDA is a client of the GPU in the same way as the OpenGL and Direct3D drivers are - it shares the GPU via time slicing. It is possible to run multiple graphics and CUDA applications at the same time, although currently CUDA only switches at the boundaries between kernel executions.

The cost of context switching between CUDA and the graphics API is roughly the same as switching graphics contexts. This isn't something you'd want to do more than a few times a frame, but is certainly fast enough to make it practical for use in games.
Dort ist explizit von Time Slicing die Rede, es wird also jeweils die ganze Grafikkarte für CUDA,D3D,OpenGL,CTM oder was auch immer genutzt. Die Vertex und Pixel Shader (für CUDA die Kernel) sind dann jeweils Clients der GPU.

[ScottManDeath]

Time slicing zwischen verschiedenen Prozessen, klar.

Aber wenn Du dir Grafik anguckst, laufen da innerhalb eines (CPU) Prozesses bzw. Grafixkontextes {Vertex, Geometry, Pixel} Shader Threads parallel.

Das Zusammenspiel von Grafik und CUDA ist ne andere Sache, da gibts durchaus die von Dir benannten Limitierungen die wohl ein Tradeoff sind, anstelle einer konzeptuellen Limitierung.

[Coda]

Doch, das geht. Es laufen ja parallel Vertex Shader und Pixel Shader Threads.

Unter CUDA ist es eine API Limitiering das nur 1 Kernel gleichzeitig ausgefuehrt werden kann.
Ist das nicht eher eine Hardware-Limitierung? Ich mein die Vertex- Und Pixelshader werden ja von der GPU-Logik erzeugt, CUDA-Threads ja eher nicht.

[dust]

auf http://www.openscenegraph.org/ habe ich vor längerer zeit http://www.realityprime.com/articles/scenegraphs-past-present-and-future#tomorrow gefunden
Scenegraph’s Tomorrow

Granted, it is probably impossible to find a single perfect organization for a scenegraph that simultaneously optimizes for spatial, state, semantic, and CPU considerations. Some people try to hand-design theirs to straddle the fence and make the best of what they have. But a better idea is to remove one of the fundamental constraints: that there need be a single scenegraph organization for a given visual database.

It is entirely possible that we can have a single set of objects, call it an object soup, but have two, three, four, or more hierarchies linking these objects into independent and complimentary organizations. It’s been on the wish of a number of scenegraph designers for years, though it’s never been a requirement before distributed databases came along.

But how to implement this is another matter. The solution, it seems, lies in the separation of concepts of scenegraph “nodes” from the “objects” they represent. By making shared objects live in a soup, we minimize the amount of waste and miscoordination we might see with four or more simultaneous object hierarchies. This way the “node” part of an object is just a few bytes – just enough to point to the object in the soup and to the parent/child/sibling relationships in this particular view. All of the real “meat” is kept once in the object, which ideally contains back pointers to each node in each graph, limited to a small number like four.

Is this rocket science? Not really. Relational databases have separated indices from data since the dawn of time. And scenegraphs are just one way of indexing into big visual databases. Once scenegraph designers come to grips with that, the rest is downhill.

The second problem is how to correlate among multiple database views (i.e., sets of indices). Since lightweight nodes in two views point back to the same object, it’s easy to see how given a node in one database view, we could find the corresponding node another view — just follow the back pointers. This lets us cull using the optimized spatial view and render using the hardware-optimized state view.

The heart of an efficient distributed database implementation, then, is using the spatial view to limit what happens in the other views (rendering, culling, physics, animation, and so on) and distributing changes in the spatial view among disparate systems. The state, semantic, and application views do not generally change, except for visibility and priority per time interval, so the real meat of the task is in synchronizing the spatial views.

http://www.opencascade.org/
so eine physik ingame wird zwar noch dauern, sehe aber keinen grund warum sie nicht kommen sollte.

viel wichtiger als cuda und das ati pendant wäre die gpu als coprozessor anzusprechen und direkt beim compilieren mit diversen standardtools einzubinden. mit gcc, mathematica und konsorten, neukompilieren und fertig. gpu mit den selben sockeln wie cpu und alles auf ein multiprozessor motherboard. noch besser wäre die motherboards abzuschaffen und karten zu nehmen und die per optischen kabel verbinden.

interessant wäre softwarerendering als zb. cuda mit "hardwarerendering" zu vergleichen. sollte gleich schnell sein aber bei softwarerendering verluste durch context switching verhindern.