Unterschied zwischen Compute Shader und PhysX

[mksu]

Nachdem ich die SuFu angeschmissen und keinen passenden Thread dazu gefunden habe, mache ich mal einen auf:

Was ist eigentlich genau der Unterschied zwischen den Compute Shadern, welche mit DX11 eingeführt wurden, und Nvidias PhysX?

Nachdem der fehlende DX11-Support für Crysis 2 in der Community für so ein heftiges Aufsehen gesorgt hat, hab ich mir nochmal die wesentlichen Neuerungen angeschaut, welche mit DX11 gekommen sind. Da hätten wir zum einem die Tesselation, welche dafür sorgt, dass Objekte mit wesentlich mehr Polygonen dargestellt werden können und somit plastischer aussehen, ohne dass dabei zusätzliche Ressourcen verbraucht werden, denn dafür gibt es die Tesselator-Einheiten in den DX11-Karten. Zudem ist Multithreaded Rendering hinzugekommen, sodass die Rechenkraft effizienter auf die einzelnen CPU-Kerne verteilt werden kann. Soweit, so verständlich.

Der dritte Punkt sind Compute Shader. Diese sind angeblich nun auch für Berechnungsprozesse verfügbar, welche nicht primär im GPU-Bereich anzusiedeln sind. So kann z.B. (wenn ich den Artikel bei Wikipedia richtig verstehe) Physikbeschleunigung durch die Shader der Grafikkarte übernommen werden, obwohl diese sonst ja dazu da sind, Pixel zu berechnen.

Soweit ich Nvidias PhysX richtig verstehe, ist der Sinn ja ebenfalls dahinter Physikberechnungen nicht auf der CPU, sondern auf den Shadern der Grafikkarte durchzuführen, da diese massiv parallelisiert sind und somit viel effektiver arbeiten können.

Stehen nun diese beiden Technologien nicht in direkter Konkurrenz zueinander? Ich mein wenn ich das doch richtig verstehe, verfolgen beide dasselbe Ziel, oder? Ich mein für uns Gamer wäre es doch toll, wenn es einen einheitlichen Standard in Sachen Physikbeschleunigung gäbe, und da sich DirectX nunmal als Einheits-API durchgesetzt hat und OpneGL wohl doch nur eine Nischenlösung bleibt, könnten sich die Entwickler darauf einigen, Physikberechnungen auf diesen Compute Shadern durchzuführen.

Hoffe dass ihr da mehr Licht ins Dunkle bringen könnt. Bisher ist nämlich bei Spielen mit DX11-Unterstützung in erster Linie von Tesselation die Rede gewesen, auf Screenshots hat man die Unterschiede meist nur an plastischeren Oberflächen erkannt. Gibt es denn Spiele, die auf diese Compute Shader setzen?

Vielen Dank schonmal für eure Beiträge!

 

[OctoCore]

Compute Shader ist keine Konkurrenz zu PhysX im eigentlichen Sinn, würde aber PhysX seiner Alleinstellungsmerkmale berauben, weil damit jede DX11-Karte umgehen kann. Außerdem könnte nVidia PhysX nicht mehr als Marketingkeule schwingen. Ich könnte mir vorstellen, dass die Verwendung von Compute Shadern für Berechnungen in Spielen effektiver ist als PhysX, weil sie in Direct3D integriert sind und dadurch direkter auf Daten zugreifen können, während PhysX eine externe Zusatzbibliothek ist.
Was jetzt Spiele angeht, die das verwenden: Die Frage habe ich mir auch schon gestellt.
War mir aber noch nicht die Mühe wert, Tante Google damit zu füttern.

Nachtrag:
Ach ja ... Der größte Nachteil der Compute Shader ist eben der, dass man dafür DX11 braucht.
PhysX ist davon unabhängig, das funktioniert auch unter XP. Und da die Spielepublisher eine möglichst breite Zielgruppe erreichen wollen, werden sie sich tunlichst überlegen, XP auszuschließen. Obwohl es langsam an der Zeit wird, da einen Schnitt zu machen, wie damals, als Win 9X nicht mehr unterstützt wurde.

 

[ruyven_macaran]

Der bessere Vergleich zu Compute Shader wären CUDA, Firestream und openCL. Alles vier sind Schnittstellen, mit denen man die GPU für beliebige Berechnungen nutzen kann (wobei Compute Shader afaik den beschränktes Funktionsumfang haben). Ein Nutzer dieser Technik ist der PhysX-GPU-Client, das als CUDA-Client daherkommt. Ein ähnliches Beispiel wäre -wenn sie denn genutzt werden würde- die Bullet-Physik-Engine, die iirc direkt openCL nutzt.
Für Compute Shader existiert afaik bislang keine Anwendung, die sich in Spiele integrieren ließe (um ehrlich zu sein: Mir fällt auch keine nicht-Spiele Anwendung ein). Falls jemand dafür eine Physik-Engine bringen würde, würde die in direkter Konkurrenz zur Kombination aus PhysX Engine und PhysX-GPU-Client stehen. (und vermutlich scheitern, da der Vorteil von PhysX ja in der Verfügbarkeit der CPU-Clients liegt)

 

[OctoCore]

Finde ich nicht, dass CUDA der bessere Vergleich ist, darum habe ich CUDA auch daraus gelassen, obwohl es mir durch den Kopf ging.
Es ist zwar etwas gewagt, die Absichten von MS deuten zu wollen, aber die Intention für die Benutzung der Compute Shader liegt (nach meinem eigenen subjektivem Verständnis) NICHT im Numbercrunching außerhalb von 3D-Anwendungen.
Was die Anwendung der Compute Shader in Spielen angeht, werden sie wohl schon benutzt, soweit ich das noch im Kopf habe. Allerdings für das Postprocessing der Grafik und nicht für Physikberechnungen.
Konkrete Spiele? Keine Ahnung. Spielemäßig bin ich im Moment nicht so ganz auf dem Laufenden. Lässt sich bestimmt ergooglen.
Und was heißt hier Engine?
Die gibt es doch: HLSL.
Okay, ist nicht ernst gemeint. Dafür ist sie zu allgemein.
Immerhin existieren die Compute Shader als Shader-Typ in HLSL und es liegt an MS, den Programmierern mit Programmierbeispielen und Biliotheken im DX-SDK für Compute Shader im Allgemeinen und Physikberechnungen im Speziellen zu unterstützen.
Der Unterschied zwischen MS und NVidia ist wohl in erster Linie der, dass nVidia bei einem hoffnungsvollen Projekt für den Spielemassenmarkt auch gerne vorbeischaut, um den Leuten ein wenig auf die Sprünge zu helfen, damit es wieder ein Vorzeigeprogramm für PhysX gibt. So ähnlich, wie es Intel z.B. mit Adobe macht, um denen ihre jeweiliges Befehlserweiterungspaket nahe zu bringen.

 

[ruyven_macaran]

HLSL wäre endgültig 1:1 das gleiche wie CUDA: Ein Sprache (nur ohne Projekt drum rum, das CUDA hat) und mehr gibt es von Mircosoft eben nicht. Man hat ein paar Shader, vielleicht noch ein paar Beispiele, dass man sie für z.B. Physik nutzen sollte.
PhysX dagegen ist eine komplette Engine, Bibliothek und API. Fix und fertig, muss man nur noch ein Spiel zu haben.

 

[mksu]

Was ist denn mit Intels Havoc? Könnte man die nicht soweit programmieren, dass sämtliche Physikeffekte auf den Compute Shadern berechnet werden?

 

[OctoCore]

Wer weiß? Auf jeden Fall will Intel die integrierte GPU ihrer Sandy Bridges auch rechnen lassen. Das Knowhow, dass sie unter anderem mit Havoc angesammelt haben, wird da sicherlich mit einfließen. Aber nur für ihre eigenen GPUs.
So nebenbei: Compute Shader sind keine Hardware, deshalb kann man darauf nichts laufen lassen.
Umgekehrt wird ein Schuh draus. Compute Shader laufen auf der GPU.
Das sind Programmkonstrukte, um die Shadereinheiten der GPU allgemeine Rechenoperationen ausführen zu lassen, so wie Pixel Shader als Programme die GPU-Shader zur Pixelmanipulation nutzen.

... und mehr gibt es von Mircosoft eben nicht. Man hat ein paar Shader, vielleicht noch ein paar Beispiele, dass man sie für z.B. Physik nutzen sollte. PhysX dagegen ist eine komplette Engine, Bibliothek und API. Fix und fertig, muss man nur noch ein Spiel zu haben.

So sieht's aus. Aber warten wir einfach ab. DX11 gibt es nicht erst seit gestern und SDKs für Entwickler sind wie üblich schon lange vorher verteilt worden. Genutzt werden die CS schon mal, wenn auch nicht für Physik.
Die aktuelle Situation ist eigentlich die ideale Marktlücke für fitte Programmierstudios, um eine hardwareunabhängige Physikengine zu schaffen, analog zu den 3D-Game-Engines der bekannten Anbieter.

Ansonsten: Ob PhysX oder Bullet oder über D3D mittels CS, alles ist nur oberflächliches Eyecandy, unerheblich für den Spielverlauf. Echte InGame-Physik, die auch Auswirkungen auf den Spielverlauf hat, wird wohl noch ein paar Jahre auf sich warten lassen. Vielleicht mit PCIe 6.0, damit die Kommunikation zwischen CPU und GPU nicht so stark gebremst wird wie heute noch.

 

[ruyven_macaran]

Wenn man will, kann man alles "soweit programieren".

 

[OctoCore]

Eben. "Entdecke die Möglichkeiten!"