• Hallo Gast,

    du hast Fragen zum PCGH-Abo oder zur Bestellung eines (Sonder)hefts von PC Games Hardware? Dann wirf einen Blick auf unser PCGH Abo-FAQ mit Antworten zu den wichtigsten Fragen. Hilfreich bei der Suche nach dem nächstgelegenen Händler, bei dem die aktuelle PC Games Hardware ausliegt, ist die Website Mykiosk. Gib dort deine Postleitzahl und PC Games Hardware (Magazin/DVD/Spezial/Sonderheft) in die Suchfelder ein und dir werden die Verkaufsstellen in deiner Nähe aufgezeigt. Wenn du PCGH digital (über App, Tablet, Smartphone oder im Webbrowser) lesen willst, haben wir eine entsprechende Anleitung für dich zusammengestellt.

Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Wenn ich als PhysX-Anwender schreibe: "Simuliere mir Vorfall X mit Genauigkeit Y", und eine API in etwa der Form erwarte ich von einer Middleware, dann sollte mir doch egal sein was da jetzt dahinter an Algo und HW gewählt wird.
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Siehst du, und genau da liegt das Problem ;)

Durch die Latenz des PCI-E busses und dem starten von einem Task auf der GPU, musst du schon so große Tasks haben, dass du gar keine Chance mehr hast, das vernünftig auf ner CPU laufen zu lassen. Das ist ja das große Problem von dGPUs. Bis die überhaupt mal schneller sind durch den ganzen Overhead, brauchste schon ziemlich große Tasks.
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

aber eigentlich dachte ich, alles würde auf allen Clients laufen und sich beliebig zwischen z.B. x86 und CUDA verlagern lassen, wenn einer überlastet ist. (Was in den meisten Systemen natürlich eher die Grafikkarte ist - aber eben nicht in allen.)

Jupp, das funktioniert leider nicht. Wäre schön, wenn man die Berechnung einfach auf die GPU verlegen (bzw. zwingen) könnte. Ich könnte mir vorstellen, dass es trotz eher anspruchsloser Effekte einen relativ deutlichen Geschwindigkeitsboost bringen könnte.
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Wahrscheinlicher ist, dass das ganze sogar langsamer werden würde.

Wie gesagt, Berechnungen auf der dGPU überhaupt schneller zu machen, als Sie einfach auf der CPU laufen zu lassen ist gar nicht sooo einfach!
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Ihr könntet bei Nvidia mal nachhaken, warum die mit Physix werben, welches teilweise extremst Computing Leistung braucht, ihre Karten aber alle um diese beschneiden, teils massiv (GK104).
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Die beschneiden DP, GPU-PhysX wird aber sehr sehr sicher nur mit SP laufen.
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Beim GK104 haben die aber Computing fast komplett über Bord geworfen
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Naja, ich glaube das liegt daran, das eben am Anfang es nur mit den Ageia Karten lief, nVidia dann die GPUs gebracht hat, weil das aber nicht gut akzeptiert wurde, dann halt immer mehr auf die CPU gebracht hat...

PhysX lief von Anfang an auf der CPU. (Wenn man bis Novodecs zurückgeht, lief es sogar zuerst auf der CPU)
Das war Ageias Geschäftskonzept:
Wir vergeben eine recht gute Physikengine für nahezu lau, mit der Entwickler leicht und auf jeder Plattform und ohne auf exotische Hardware angewiesen zu sein, tolle Spiele kreeiren können. Und dann verkaufen wir für gutes Geld Beschleunigerkarten, damit die Leute mehr davon haben.

Wenn ich als PhysX-Anwender schreibe: "Simuliere mir Vorfall X mit Genauigkeit Y", und eine API in etwa der Form erwarte ich von einer Middleware, dann sollte mir doch egal sein was da jetzt dahinter an Algo und HW gewählt wird.

/sign.
Das ist der Sinn einer API: Verschiedene Implementierungen mögen unterschiedlich effizient sein, aber es sollte auf jeder kompatiblen Hardware laufen. Deswegen kann eine DirectX-Engine auch mit dem Referenzrenderer auf einer CPU laufen (naja. Mit einem Läufer hat es wenig gemein. Sagen wir: gletschern). Oder auf einer GCN-GPU. Oder einer Kepler-GPU. Obwohl die alle sehr unterschiedlich aufgebaut sind.


Jupp, das funktioniert leider nicht. Wäre schön, wenn man die Berechnung einfach auf die GPU verlegen (bzw. zwingen) könnte. Ich könnte mir vorstellen, dass es trotz eher anspruchsloser Effekte einen relativ deutlichen Geschwindigkeitsboost bringen könnte.

:(
Wäre trotzdem nett, wenn wir in einem entsprechenden Artikel einen Benchmark unterschieben könnt. Die Befehle, die bei PhysX-Effektorgien eingesetzt werden, sind ja auf alle Fälle die gleichen, die zum Teil auch in normalen Szenarien genutzt werden - nur dass es halt z.B. extrem viel mehr Partikel sind. Aber z.B. eben Partikelberechnungen sollten sich dann ja immer auslagern lassen, auch wenn sie nur einen kleinen Teil ausmachen. Und irgend eine Auswirkung muss der Schalter im Treiber ja haben.
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

:(
Wäre trotzdem nett, wenn wir in einem entsprechenden Artikel einen Benchmark unterschieben könnt. Die Befehle, die bei PhysX-Effektorgien eingesetzt werden, sind ja auf alle Fälle die gleichen, die zum Teil auch in normalen Szenarien genutzt werden - nur dass es halt z.B. extrem viel mehr Partikel sind. Aber z.B. eben Partikelberechnungen sollten sich dann ja immer auslagern lassen, auch wenn sie nur einen kleinen Teil ausmachen. Und irgend eine Auswirkung muss der Schalter im Treiber ja haben.
Verstehe ich das jetzt richtig: Du möchtest, dass wir in einem Spiel ohne explizite GPU-Physx-Unterstützung einen Test machen und dabei den Treiber auf "Geforce für Physx nutzen" stellen?
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

So, wie ich das bislang verstanden habe, gibt es keine PhysX-"x86-CPU-Physik". Genausowenig, wie es "GPU-PhysX"-Physik gibt. Sondern es gibt PhysX-Physik. Und die wird auf einem x-beliebigen PhysX-Client bereichnet - egal ob x86/Windows, CUDA oder einer der Konsolen-Clients (oder, früher, PPU). Je nach Aufwand hat halt nur der CUDA-Client ausreichend starke Hardware zu seiner Verfügung, um es schnell genug zu berechnen - aber eigentlich dachte ich, alles würde auf allen Clients laufen und sich beliebig zwischen z.B. x86 und CUDA verlagern lassen, wenn einer überlastet ist. (Was in den meisten Systemen natürlich eher die Grafikkarte ist - aber eben nicht in allen.)
Die Entlastung der CPU war ja auch mal das Ziel von Ageia.
Das hast du dann falsch verstanden. Es gibt zwei Pfade: Einmal x86 per CPU und einmal die CUDA-Variante per GPU, die sich mit alten Treibern und Gefrickel teils noch per PPU berechnen lässt. Die CUDA-Variante kann man auf die CPU kippen, nicht aber umgekehrt. Auf den Konsolen wird der x86-Pfad genutzt, daher "nur" Low-Level-Physik und keine Effekte wie extra Partikel etc.

Und irgend eine Auswirkung muss der Schalter im Treiber ja haben.
Im Falle von Low-Level-Physik? Keine Auswirkung. Da ist kein Code den die GPU beschleunigt.

Beim GK104 haben die aber Computing fast komplett über Bord geworfen
V hat nur DP beschnitten. SP wie es für PhysX von Relevanz ist, läuft nach wie vor ganz passabel. Compute in Spielen, etwa bei BF4 oder TressFX in Tomb Raider, berechnet GK104 ähnlich flott wie Tahiti. Den Luxmark mögen die Dinger wie offenbar generell OpenCL nicht sonderlich, andere Compute-Benches (SDK FluidCS11 oder auch CS Raytracing) sehen recht gut aus.
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Verstehe ich das jetzt richtig: Du möchtest, dass wir in einem Spiel ohne explizite GPU-Physx-Unterstützung aber mit PhysX-Engine einen Test machen und dabei den Treiber auf "Geforce für Physx nutzen" stellen?

Das war der Hintergedanke, ja. Aber nach der Beschreibung von Mark macht das wohl keinen Sinn mehr.
Dann wünsche ich mir alternativ mal einen Artikel, der in die technischen Details von PhysX geht :)
Irgendwie ist für mich nämlich unverständlich, dass z.B. die Berechnung von Millionen von Partikeln (oder hunderte von Objekten mit Kollisionsabfrage, wie in den alten Techdemos) komplett auf der GPU durchgeführt werden kann, die Berechnung von ein paar tausend Partikeln (/dutzend Objekte) aber ausschließlich auf der CPU. Als Laie würde ich ja annehmen, dass es da von der Art der Aufgaben gar keine Unterschiede gibt, die einen bestimmten Client erzwingen.
Warum das nicht so ist, sollte einen interessanten Technikartikel ergeben :)
(Wenn auch ggf. einen sehr aufwendigen - je nachdem, wie viel Nvidia von sich aus erzählt)
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Ich mach mal nen kleines Beispiel, dann sollte es sehr leicht klar werden ;)

CPU schafft 10k Partikel je "Tick", und die GPU 40k Partikel je "Tick", damit Sie aber anfangen kann, müssen die Daten erstmal kopiert, werden, und nen kernel angeworfen werden. Das dauert 20 Ticks.

. := Berechnungstick
: := Overhead für GPU

Bsp:
100k Partikel
CPU: . . . . . . . . . . <- 10 Ticks
GPU: : : : : : : : : : : : : : : : : : : : . . . <-23 Ticks

Wie du siehst, ist die GPU zwar VIEL schneller als die CPU bei der Berechnung, Sie braucht ja nur 3 statt 10 ticks, aber der Overhead killt dich.

1Mio Partikel
CPU: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . <- 100 Ticks
GPU: : : : : : : : : : : : : : : : : : : : . . . . . . . . . . . . . . . . . . . . . . . . . <- 45 Ticks

Jetzt klar?
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Wenn das System durch die CPU-Leistung limitiert ist (auch nicht durch PCIe-Bandbreite, was aber ohnehin extrem selten ist), dann ist die (bekannte und keiner Erklärung bedürftige) Transferverzögerung im Spieleeinsatz egal. Im Gegensatz zu anderen Computinganwendungen muss das Ergebnis erst dann vorliegen, wenn der nächste Frame ansteht - und das hängt bei CPU-Limitierung eben davon ab, wann die CPU mit allen ihren Aufgaben fertig ist. Wenn eine Auslagerung dort Zeit spart, darf die Auslagerung selbst ruhig etwas dauern, denn sie findet zeitgleich zu nicht verlagerbaren Prozessen statt.
Und das ein basaler PCIe-Transfer sonderlich Rechenoverhead auf der CPU verursacht, wäre mir nicht bekannt.

Ein weiterer großer Unterschied zu der für dich typischen Cluster-Perspektive kommt hinzu, falls Nvidia die Rechenergebnisse, insbesondere von Effekten, direkt an den Renderer übergeben kann (ein weitere Frage, die man beantworten könnte). Denn es ist so oder so eine Übertragung zur GPU nötig - entweder vor der Phyikberechnung oder danach. Die Ausgabe erfolgt beim Spielen schließlich nicht über Ethernet...
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Ruyven, ich muss jetzt los, ansonsten würde ich dir mal nen paar Sachen zeigen, wie lang so manches dauert, da schlackert man ziemlich mit den Ohren ;)
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Ich würde mir gerne mal einen ausführlichen Artikel zu dem Thema Bitcoin und litecoin wünschen. Ich möchte gerne aufgeschlüsselt haben was das konkret ist, aus welchen Werten/ Gegenwerten heraus diese Kryptowährung entsteht und warum man mit synthetisch generierten Inhalten/ Blöcken quasi Geld verdienen kann.

MfG
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Sodele also, ich hab mal VS2010 angeschmissen. AMD hat dafür nen richtig geiles Plugin, mit dem man Performanceanalysen machen kann :daumen::hail:

SetKernelArg_OpenCL.png
Hier sieht man den Overhead, den man fürs kopieren, von gerade einmal 128 Byte an Daten hat! Das sind 141,877 µs also 0,141877 ms. Das sind bei ner 3GHz CPU 425.631 Takte! Da kannste aber holla die Waldfee eine Menge rechnen in der Zeit :ugly:

Write-Overhead_OpenCL.png
Und nen simples umsetzen einer Kernelvariablen dauert ca. 617ns also 0,617µs oder eben 0,000617ms. Das sind bei 3GHz aber halt auch schon wieder 1851 CPU takte.

Hier nochmal in ner Zusammenfassung für den 128Byte write.

Gesamtoverhead_OpenCL_PinnedWrite.png
Und jetzt BITTE!!! beachten, dass das schon mit gepinntem Speicher ist! Also die massiv schnellere Version...
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Nur kann ja die CPU mit den 1851Takten auch was anderes machen, man hat ja keinen Stall während eines DMA-Kopiervorgangs. Und eben deswegen kann es, auch wenn es absolut betrachtet weniger Effektiv ist, trotzdem sinnvoll sein auf der GPU zu rechnen.
 
AW: Offenes Ohr - welche Themen wünscht ihr euch für die nächste PCGH-Ausgabe?

Äh doch genau das sollte da aber passieren. Die CPU stalled. Bei so kleinen Packetgrößen wird das auch nicht zwingend über DMA gemacht, sondern über PIO. [stride]128 Byte sind jetzt zumindest nicht soo viel. Zumal das Ding ja auch noch in gepinnten Memory rein schreibt.[stride] Äh... das ist ein 64 Bit Wert, oder sollte es zumindest sein. Das läuft ziemlich sicher über PIO.

Und btw das ist gar nicht so wenig ;)

Da ist halt einiges an Overhead durch OS usw dabei. Das ist sehr fraglich, ob da parallel noch was anderes zu laufen kann. Ich würde rein aus Erfahrung/Gefühl eher nein sagen.

Hab die Woche memcpy und ne eigene implementierung gegeneinander gebencht. 64 Bit schreiben dauert mit memcpy mit -Os ~160 Takte und mit -O3 dauert es so um die 20.000 Takte!

Son ollen Wert schreiben in den Speicher dauert echt lange.

EDIT:
Ansonsten müsstest du ja auch die ganzen Register auf den Stack pushen, um den Zustand zu sichern. Ich seh da wenig Sinn dahinter, da was anderes rein quetschen zu wollen.
 
Zuletzt bearbeitet:
Zurück