CPU-Limits und Spiele
- Ersteller unl34shed
- Erstellt am
Complicated
Grand Admiral Special
Nur damit wir mal klären worum es hier in diesem Thread geht:
Bitte von Anfang an lesen bevor man beurteilen will wer einer Diskussion fern bleiben soll. Das Thema habe ich angefragt und die Moderation hat dies dann so definiert. Es geht hier darum dass keine CPU-Limits in Spielen abgebildet werden können.
Casi030
Grand Admiral Special
- Mitglied seit
- 03.10.2012
- Beiträge
- 8.942
- Renomée
- 153
@Devastators
Lesen bildet,aber bitte doch nicht immer nur die Bild.
http://m.welt.de/motor/article1864525/Audis-schoenster-Tabubruch-heisst-R8-TDI.html
http://m.focus.de/auto/neuheiten/sp...t-verkauf-des-panamera-diesel_id_5009248.html
http://m.spiegel.de/auto/aktuell/a-906603.html
http://www.motorsport-total.com/meh...nft_im_Motorsport_heisst_Diesel_08020503.html
Dann frag ich mich noch wo liegt das Problem.......
Lebewesen = Vom Einzeller zum ........= Evolution
Warum schafft es manch ein Einzeller nicht seinen 50 Jahre alten Algorithmus über Bord zu werfen und seine eine Zelle an zu strengen?!
Will er den Fortschritt aufhalten?
Wenn alle Menschen so denken würden,dann würden wir uns jetzt noch mit Rauchzeichen verständigen.
Lesen bildet,aber bitte doch nicht immer nur die Bild.
http://m.welt.de/motor/article1864525/Audis-schoenster-Tabubruch-heisst-R8-TDI.html
http://m.focus.de/auto/neuheiten/sp...t-verkauf-des-panamera-diesel_id_5009248.html
http://m.spiegel.de/auto/aktuell/a-906603.html
http://www.motorsport-total.com/meh...nft_im_Motorsport_heisst_Diesel_08020503.html
Dann frag ich mich noch wo liegt das Problem.......
Lebewesen = Vom Einzeller zum ........= Evolution
Warum schafft es manch ein Einzeller nicht seinen 50 Jahre alten Algorithmus über Bord zu werfen und seine eine Zelle an zu strengen?!
Will er den Fortschritt aufhalten?
Wenn alle Menschen so denken würden,dann würden wir uns jetzt noch mit Rauchzeichen verständigen.
Zuletzt bearbeitet:
Devastators
Grand Admiral Special
Ich schrieb von "spontan" fällt mir nichts ein.
Mit dem Wissen der Welt im Nacken und einer Suchmaschine hätte ich auch ein paar Autos finden können.
ansonsten zu Deiner Einzeller-Theorie:
Auch hier hilft Google in 0,3s weiter.
https://de.wikipedia.org/wiki/Paralleler_Algorithmus
Mal von dem einzelnen Individuum abgesehen (in Form eines 0815 Programmierers) wird dort von Forschern gesprochen die noch nichts gefunden haben.
Es ist also etwas Überheblich mit einem Wisch eine ganze Wissenschaft zu denunzieren.
Dabei ist die Wirtschaftlichkeit möglicher Optimierungen noch gar nicht inbegriffen.
WindHund
Grand Admiral Special
Die Parallelisierung findet im Compiler statt und muss weniger vom Entwickler beachtet werden, es sei den er will es selbst Managen dann hat er natürlich auch die Möglichkeit.
Z.B. hier: http://www.planet3dnow.de/cms/20750...s-add-openacc-support-for-x86-multicore-cpus/
Single Thread ist was für Fred Feuerstein.
Z.B. hier: http://www.planet3dnow.de/cms/20750...s-add-openacc-support-for-x86-multicore-cpus/
Single Thread ist was für Fred Feuerstein.
Devastators
Grand Admiral Special
Die Parallelisierung findet im Compiler statt und muss weniger vom Entwickler beachtet werden, es sei den er will es selbst Managen dann hat er natürlich auch die Möglichkeit.
Z.B. hier: http://www.planet3dnow.de/cms/20750...s-add-openacc-support-for-x86-multicore-cpus/
Single Thread ist was für Fred Feuerstein.
Ich muss zugeben, die automatische Parallelisierung ist mir etwas suspekt, da ich mir kaum noch vorstellen kann, dass komplexe und umfangreiche Algorithmen vollständig automatisch auf Parallelisierbarkeit überprüft und optimiert werden können.
Soweit mir bekannt, bezieht sich diese Automatik lediglich auf das Suchen und Überprüfen von z.B. kleineren Schleifen ohne größere Komplexität.
Wenn bei einer größeren Schleife ein Durchgang das Ergebnis vom Vorgänger benötigt, war es das schon mit parallelisieren, das geht dann nur sequentiell.
Ob sich ein krampfhaftes Parallelisieren immer positiv auswirkt muss man auch individuell entscheiden, da dabei ein Overhead entsteht der sich erst Mal amortisieren muss.
Wenn ich mich jedoch für einen parallele Schleife bewusst entscheide, regelt dann zur Laufzeit tatsächlich der Rechner selber in wie viele Threads diese Schleife aufgeteilt werden kann und soll. Damit habe ich als Entwickler nichts mehr am Hut.
Ich denke die Parallelisierung liegt bei spielen eher im größeren Bereich als ein paar Schleifen zu verteilen.
Die KI könnte komplett getrennt von der Geometrieberechnung oder von möglicher Physik berechnet werden.
Solche Aufteilungen muss m.E. der Entwickler selber programmieren, da würde mich eine Vollautomatik doch sehr wundern.
Wenn das alles so easy gehen würde, wundert es mich wieso die meißten Programme noch Single Core laufen
Casi030
Grand Admiral Special
- Mitglied seit
- 03.10.2012
- Beiträge
- 8.942
- Renomée
- 153
Dann sollte man mit solchen Sachen nicht anfangen......Allein ein Zahnarztbesuch jedes Jahr reicht aus um von Jedem etwas ab zu bekommen.
Hmmmm wo kann ich das Spiel runter laden,würd ich mich gern mal selber von überzeugen?!
WindHund
Grand Admiral Special
Den Overhead denn du meinst ist aber nur vorhanden, wenn der Kernel nicht parallelisierbar ist, also nur auf einem Kern die Verwaltung läuft.Ich muss zugeben, die automatische Parallelisierung ist mir etwas suspekt, da ich mir kaum noch vorstellen kann, dass komplexe und umfangreiche Algorithmen vollständig automatisch auf Parallelisierbarkeit überprüft und optimiert werden können.
Soweit mir bekannt, bezieht sich diese Automatik lediglich auf das Suchen und Überprüfen von z.B. kleineren Schleifen ohne größere Komplexität.
Wenn bei einer größeren Schleife ein Durchgang das Ergebnis vom Vorgänger benötigt, war es das schon mit parallelisieren, das geht dann nur sequentiell.
Ob sich ein krampfhaftes Parallelisieren immer positiv auswirkt muss man auch individuell entscheiden, da dabei ein Overhead entsteht der sich erst Mal amortisieren muss.
Wenn ich mich jedoch für einen parallele Schleife bewusst entscheide, regelt dann zur Laufzeit tatsächlich der Rechner selber in wie viele Threads diese Schleife aufgeteilt werden kann und soll. Damit habe ich als Entwickler nichts mehr am Hut.
Ich denke die Parallelisierung liegt bei spielen eher im größeren Bereich als ein paar Schleifen zu verteilen.
Die KI könnte komplett getrennt von der Geometrieberechnung oder von möglicher Physik berechnet werden.
Solche Aufteilungen muss m.E. der Entwickler selber programmieren, da würde mich eine Vollautomatik doch sehr wundern.
Wenn das alles so easy gehen würde, wundert es mich wieso die meißten Programme noch Single Core laufen
Der Kernel ist inzwischen aber ebenfalls auf alle Kerne verteilt, somit vermindert man den Verwaltungs Overhead.
Single Thread ist eben der einfachste Weg der Programmierung.
Zudem kann man so die Konkurenz klein halten, da nur die Hardware mit mehr Leistung profitiert womit das Programm auch compiliert wurde z.B. mit dem Intel Compiler.
AMD hat noch nicht so lang einen eigenen Windows Compiler.
Zuletzt bearbeitet:
Hallo
In vielen Linuxdistributionen existiert ein "cpulimit"
http://manpages.ubuntu.com/manpages/natty/man1/cpulimit.1.html
Da hier auch die Begriffe wie "Parallelität" genannt werden, sollte u.a. der Task-Scheduler als
variable Größe in verschiedenen Betriebssystemen berücksichtigt werden
für die Auslastung der Ausführungseinheiten.
MfG
RedBaron
In vielen Linuxdistributionen existiert ein "cpulimit"
http://manpages.ubuntu.com/manpages/natty/man1/cpulimit.1.html
Da hier auch die Begriffe wie "Parallelität" genannt werden, sollte u.a. der Task-Scheduler als
variable Größe in verschiedenen Betriebssystemen berücksichtigt werden
für die Auslastung der Ausführungseinheiten.
MfG
RedBaron
WindHund
Grand Admiral Special
Habs gefunden via ToolTips: http://abload.de/img/vulkan_siv64_loadsgu5o.png
DPC und Interrupt Last wird als dunkel blau und Türkis dargestellt im CPU Diagramm.
Keine Ahnung was ich damit anfangen soll, könnte aber evt. nützlich für die Entwickler sein.
Devastators
Grand Admiral Special
Dann ist mir gar nicht klar wie die Compiler Option läuft.
Soweit mir bis jetzt bewusst, wird der Quellcode, der grundlegend erstmal immer sequenziell abgearbeitet wird, auf parallelisierbarkeit überprüft.
Findet sich dort z.B. eine Schleife, kann diese u.U. parallel abgearbeitet werden, der Compiler richtet die notwendigen Schritte selber ein.
Dafür müssen aber neue Threads erstellt werden die am Ende der Schleife wieder beendet werden.
Das Programm wird also nur temporär parallel verarbeitet, was eine menge Overhead produziert.
Du sprichst von kompletter Parallelisierung?
irgendwann und irgendwo müssen die Daten aber verteilt und wieder gesammelt werden.
Wenn das alles ach so einfach wäre, verstehe ich nicht wieso manche sehr gut parallelisierbare Codes (Encodieren von Videos) nicht mit einem Compiler-Mausklick alle Kerne auslasten.
AFAIK nutzt DivX erst bei den neueren Codecs mehr als 2 Kerne aus.
Und wenn das alles so einfach wäre, dürfte die Diskussion gar nicht existieren, dass ein Programmcode nur ein Kern auslasten kann.
--- Update ---
Meiner hat nur die Auto-Bild, die darf ich ja nicht lesen.
Kennst Du denn jetzt den Unterschied zwischen Nm und kW?
Nebelkerze?
Muss ich raten was Du mir jetzt mitteilen willst?
WindHund
Grand Admiral Special
Mir ebenfalls nicht, aber ich konnte noch keinen Single Thread mit 100% Auslastung loggen bei Spiele.
Schleifen sind eher für den Cache relevant.
ISt dir bewusst wie breit GPUs sind?
Eine NANO hat z.B. so viele shader wie meine beiden HD 7970 zusammen, das sind 4096 Unified shader oder 64 Threads mit CPU Code.
Andersherum kann man auch die GPU als FPU nutzen, wer hoch klettert, kann auch herunter klettern.
Devastators
Grand Admiral Special
Du redest jetzt von der Parallelisierung innerhalb der GPU.... das ist etwas vollständig anderes.
Du kannst direkt mit einem Vektor oder Parallelrechner anfangen, den haben wir hier aber nicht.
Eine x86/x64 Computer besteht i.d.R. noch immer aus einer CISC-CPU
http://www.bernd-leitenberger.de/cisc-risc.shtml
schön erklärt.
-
Wir reden von CPU Code und der CPU Auslastung.
Und eine 100% Auslastung eines Kernes wirst Du ziemlich leicht hinbekommen, musst Windows nur verbieten permanent den Kern wechseln zu lassen.
Wenn ein Programm auf einem 4-Kerner 25% Auslastung erzeugt, entspricht das bei einem Kern i.d.R. 100%.
Windows verteilt den Thread gleichmäßig auf die 4 Kerne, aber AFAIK nur um die thermische Belastung auf dem Die zu verteilen.
Mit Parallelisierung hat das gar nichts zu tun, die Kerne der CPU werden dabei nacheinander belastet, nicht gleichzeitig!
Du kannst direkt mit einem Vektor oder Parallelrechner anfangen, den haben wir hier aber nicht.
Eine x86/x64 Computer besteht i.d.R. noch immer aus einer CISC-CPU
http://www.bernd-leitenberger.de/cisc-risc.shtml
schön erklärt.
-
Wir reden von CPU Code und der CPU Auslastung.
Und eine 100% Auslastung eines Kernes wirst Du ziemlich leicht hinbekommen, musst Windows nur verbieten permanent den Kern wechseln zu lassen.
Wenn ein Programm auf einem 4-Kerner 25% Auslastung erzeugt, entspricht das bei einem Kern i.d.R. 100%.
Windows verteilt den Thread gleichmäßig auf die 4 Kerne, aber AFAIK nur um die thermische Belastung auf dem Die zu verteilen.
Mit Parallelisierung hat das gar nichts zu tun, die Kerne der CPU werden dabei nacheinander belastet, nicht gleichzeitig!
Zuletzt bearbeitet:
Auto-Parallelisierung kratzt im Allgemeinen nur an der Oberfläche. Häufig müssen die Algorithmen selbst angepasst werden oder sogar komplett ersetzt werden um Teile des Codes überhaupt effizient parallel abarbeiten zu können.
Overhead entsteht nicht nur durch das erzeugen der Threads, sondern auch durch die manchmal notwendige Synchronisation dergleichen. Deswegen muss immer erst eine größere Sequenz komplett parallelisierbar sein bevor es sich lohnt. Bei GPGPU Anwendungen ist das noch viel aufwendiger, obwohl Techniken wie HSA diesen Aufwand zu verringern versuchen.
Overhead entsteht nicht nur durch das erzeugen der Threads, sondern auch durch die manchmal notwendige Synchronisation dergleichen. Deswegen muss immer erst eine größere Sequenz komplett parallelisierbar sein bevor es sich lohnt. Bei GPGPU Anwendungen ist das noch viel aufwendiger, obwohl Techniken wie HSA diesen Aufwand zu verringern versuchen.
Devastators
Grand Admiral Special
Danke, das entspricht auch meinem Wissensstand.
Ich denke hier wird sehr vieles sehr wild durcheinander geworfen.
Die GPU, mit ihren tausenden Shadern, ist natürlich in der Lage diese Shader auch parallel arbeiten lassen zu können, aber dafür muss das Grundmodell (Ich nenne es mal Basis-Geometrie) weitegehend aufgebaut/vorberechnet sein, was dann CPU Arbeit wäre.
Wenn die Aufgabenstellung klar ist und nun auf die z.B. 100 Millionen Vertices angewendet werden muss, kann das die GPU relativ eigenständig auf die Shader verteilen.
Die GPU übernimmt dann die geometrischen Berechnungen, das Mapping, Licht und Schatten Effekte und was immer neuere DX-Versionen so alles hergeben.
Bei GPGPU-Anwendungen geht m.E. gar nix automatisiert, was ja grundlegend sehr Schade ist
Ich muss mich mit meinen Algorithmen innerhalb der Möglichkeiten der GPGPU-Schnittstelle bewegen, was u.U. eine komplett andere Programmierung bedeutet.
Man darf auch nicht den Fehler machen und glauben, so eine Grafikengine sei in ein paar Wochen neu aufgebaut.
Da stecken locker einige Zehn- bis Hundert-Tausend Mannstunden hinter.
Da fängt selten eine Spieleschmiede bei 0 an.
WindHund
Grand Admiral Special
Ich meine allgemein Parallelisierung.
Es ist ja z.B. auch möglich openCL zu nutzen, beim LuxMark Renderer rechnen CPU und GPU an der selben Aufgabe nur eben mit "working balance"
Demnach können beide ebenfalls die Berechnungen des anderen übernehmen oder ergänzen.
Das CPU und GPU unterschiedliche Stärken haben ist klar, aber es sind immer noch Integer oder Floating Berechnungen und diese sie eben bei beiden möglich (CPU & GPU)
http://abload.de/img/luxmarkv3_lobby_fx-95uaj79.jpg
Devastators
Grand Admiral Special
Worauf willst Du jetzt hinaus?
Rendern ist einer der Aufgabengebiete, die sich sehr gut parallelisieren läßt.
Und wenn Dein "LuxMark Renderer" das kann, dann nur weil es entsprechend vorab so programmiert wurde und nicht weil jemand im Compiler das Parallelisierungsflag gesetzt hat.
Um es mal ganz einfach runter zu brechen:
Matheklausur mit 8 Aufgaben.
Eine Klausur kannst Du mit 3 Kollegen zusammen beginnen.
Jeder nimmt sich eine der 8 Aufgaben und rechnet sie unabhängig vom Kollegen.
Insgesamt könnt ihr die Aufgaben parallel abarbeiten und seid im Idealfall 4x schneller fertig.
Jetzt kommt aber die Schwierigkeit hinzu, dass Aufgabe 2 mit dem Ergebnis von Aufgabe 1 weiter rechnet u.s.W.
Da sitzen nun 3 Leute auf Bereitschaft und warten bis Du mit Aufgabe 1 fertig bist.
Geschwindigkeitsvorteil = 0.
Und es macht auch keinen Sinn eine einzige Aufgabe mit 4 Leuten zu berechnen, denn schneller als der beste Matherechner wirst Du nicht werden.
Du kannst diese Aufgabe nicht weiter aufteilen.
So macht es keinen Sinn mehr, ob Du nun alleine, zu zweit, zu 6 oder 256 Leuten vor dieser Aufgabe sitzt, Du wirst keine Sekunde früher fertig mit der Aufgabe.
Es gibt nur einen Weg diese gegebene Aufgabe schneller zu lösen -> eine Person hinsetzen die schneller rechnen kann, denn weitere Parallelisierung bringt Dich hier nicht weiter.
Rendern ist einer der Aufgabengebiete, die sich sehr gut parallelisieren läßt.
Und wenn Dein "LuxMark Renderer" das kann, dann nur weil es entsprechend vorab so programmiert wurde und nicht weil jemand im Compiler das Parallelisierungsflag gesetzt hat.
Um es mal ganz einfach runter zu brechen:
Matheklausur mit 8 Aufgaben.
Eine Klausur kannst Du mit 3 Kollegen zusammen beginnen.
Jeder nimmt sich eine der 8 Aufgaben und rechnet sie unabhängig vom Kollegen.
Insgesamt könnt ihr die Aufgaben parallel abarbeiten und seid im Idealfall 4x schneller fertig.
Jetzt kommt aber die Schwierigkeit hinzu, dass Aufgabe 2 mit dem Ergebnis von Aufgabe 1 weiter rechnet u.s.W.
Da sitzen nun 3 Leute auf Bereitschaft und warten bis Du mit Aufgabe 1 fertig bist.
Geschwindigkeitsvorteil = 0.
Und es macht auch keinen Sinn eine einzige Aufgabe mit 4 Leuten zu berechnen, denn schneller als der beste Matherechner wirst Du nicht werden.
Du kannst diese Aufgabe nicht weiter aufteilen.
So macht es keinen Sinn mehr, ob Du nun alleine, zu zweit, zu 6 oder 256 Leuten vor dieser Aufgabe sitzt, Du wirst keine Sekunde früher fertig mit der Aufgabe.
Es gibt nur einen Weg diese gegebene Aufgabe schneller zu lösen -> eine Person hinsetzen die schneller rechnen kann, denn weitere Parallelisierung bringt Dich hier nicht weiter.
Casi030
Grand Admiral Special
- Mitglied seit
- 03.10.2012
- Beiträge
- 8.942
- Renomée
- 153
Ist mir als KFZ-Mechatroniker nicht bekannt,aber DU wirst es mir sicherlich erklären.
Ja,da ich deinen Text leider nicht zu Spielen parallelisieren kann,dauert es noch sehr lange bis ich auf das Ergebnis komme.
Devastators
Grand Admiral Special
Ist mir als KFZ-Mechatroniker nicht bekannt,aber DU wirst es mir sicherlich erklären.
Ja,da ich deinen Text leider nicht zu Spielen parallelisieren kann,dauert es noch sehr lange bis ich auf das Ergebnis komme.
Da Du scheinbar weder interessiert und/oder nicht in der Lage bist irgendwie Sachlich zu folgen, hat sich das für mich erledigt.
--- Update ---
wen meinst Du jetzt und worauf beziehst Du Dich?
Diejenigen die die Einzelkernleistung als Maß aller Dinge hervor heben wolle, da man ja sonst die Programmierart ändern müßte und nicht in allen Lebenslagen ein mehrfaches an Leistung raus bekommen kann.
Devastators
Grand Admiral Special
k.A., ist mir hier niemand aufgefallen.
mir persönlich ging es nur um die kindliche Vorstellung, mit "mal eben" gemachter Parallelisierung (am besten auf Knopfdruck) alle Probleme lösen zu können.
Es gibt eben immer solche und solche extreme.
Oft genug wurde ja auch bei diversen Diskussionen bei der lausigen CPU Unterstützung von Physx damit argumentiert das eben nicht alles parallelisierbar wäre, nur warum läuft die beschleunigte Variante dann auf extrem parallelisierten Architekturen wie den GPUs, war aber nicht in der Lage alle Kerne der CPU zu verwenden?
Das wird mir einfach viel zu oft als Totschlagargument für fehlende Weiterentwicklung verwendet.
Oft genug wurde ja auch bei diversen Diskussionen bei der lausigen CPU Unterstützung von Physx damit argumentiert das eben nicht alles parallelisierbar wäre, nur warum läuft die beschleunigte Variante dann auf extrem parallelisierten Architekturen wie den GPUs, war aber nicht in der Lage alle Kerne der CPU zu verwenden?
Das wird mir einfach viel zu oft als Totschlagargument für fehlende Weiterentwicklung verwendet.
Devastators
Grand Admiral Special
genau... Es sind Einzelfälle und müssen individuell entschieden werden.
Wie bereits schon angedeutet, entscheidet letztendlich auch die Wirtschaftlichkeit wie viel Manpower in die Codeoptimierung gesteckt werden kann und soll.
Deine Beispiele bzgl. Physx kenne ich nicht und ich muss auch zugeben, dass ich im Bereich GPGPU Programmierung nicht wirklich praktische Erfahrung habe.
Ich habe mich aber die letzten Jahre durchaus bemüht, meinen zu verwalteten Programmcode, u.A. auch älterer Programme, stellenweise Multi-Thread tauglich zu bekommen.
Das ist eine ziemliche Schweinskramsarbeit altes Zeugs zu durchwühlen und Optimieren und steht oft in keinem Verhältnis zur Möglichen Leistungssteigerung.
Alten Krempel umstellen bedeutet auch oft, die gesamte Debug-Phase zu wiederholen.
Bei einer kompletten Neuentwicklung, mit Berücksichtigung möglicher Parallelisierung von der ersten Zeile an, sieht das ganz anders aus.
Wie bereits schon angedeutet, entscheidet letztendlich auch die Wirtschaftlichkeit wie viel Manpower in die Codeoptimierung gesteckt werden kann und soll.
Deine Beispiele bzgl. Physx kenne ich nicht und ich muss auch zugeben, dass ich im Bereich GPGPU Programmierung nicht wirklich praktische Erfahrung habe.
Ich habe mich aber die letzten Jahre durchaus bemüht, meinen zu verwalteten Programmcode, u.A. auch älterer Programme, stellenweise Multi-Thread tauglich zu bekommen.
Das ist eine ziemliche Schweinskramsarbeit altes Zeugs zu durchwühlen und Optimieren und steht oft in keinem Verhältnis zur Möglichen Leistungssteigerung.
Alten Krempel umstellen bedeutet auch oft, die gesamte Debug-Phase zu wiederholen.
Bei einer kompletten Neuentwicklung, mit Berücksichtigung möglicher Parallelisierung von der ersten Zeile an, sieht das ganz anders aus.
WindHund
Grand Admiral Special
Dann probier mal den LuxMark Bench aus und schau ob deine CPU die selben % Arbeitseinteilung bekommt wie bei meinem Bild.
Working balance überprüft während der Laufzeit wie stark die CPU und GPU ist und Teilt die Arbeit in Echtzeit auf.
Wenn die GPU z.B. doppelt so schnell ist wird es zu 25%/75% (CPU/GPU) aufgeteilt.
Mir ist die sequntielle Abarbeitung schon bewusst und dem möchte ich auch nicht wiedersprechen.
Allerdings bestehen Spiele nicht nur aus einfachen Rechenaufgaben (verschiedene Ansichten im 3D Koordinaten System) sonst könnte man auch auf einem Taschenrechner spielen.
Alten Code Multi-threading bei bringen ist gewiss mit Arbeit verbunden, wenn es so viel Arbeit ist, dann lohnt es sich individuell komplett neu zu schreiben.
Allein schon wegen den neuen Befehlssätze, die ganze Seiten alten Code ersetzen können.
HSA kommt ja auch nicht von ungefähr etwa könnte...
@Devastators
Das Ding mit physx ist relativ einfach.
Kann die Grafikkarte die erweiterte Form nicht berechnen wird es von der CPU erledig. Bis physx 3.0 mit der wohl lausigsten CPU Unterstützung die es gab (kein multithreading, FPU Code), das ging mitte 2010 durch die Presse.
Man könnte meinen das dies inzwischen Geschichte ist aber als ich neulich mal dem Benchmark von "Metro: Last Light" rumspielte zeigte sich trotz aktuellem Physx genau das Gegenteil. Mit der erweiterten Physik fiel die Framerate ins bodenlose und die CPU wurde dabei entlastet, kein Wunder denn in der Physx System Software ist auch nur von einer Unterstützung bis zur SDK Version 2.8.4 die Rede.
Stolze Leistung dafür das die Aussage vor 5-6 Jahren getroffen wurde.
Das hat wohl kaum etwas mit technischen Gründen sondern vielmehr mit fehlenden Interesse an einer deutlichen Verbesserung der Leistung beim Einsatz auf einer CPU zu tuen.
Mich würde es nicht wundern wenn solche produktpolitischen Entscheidungen in vielen Fällen deutlich entscheidener für mangelhaften Multicore Support sind als technische Gründe.
Seitens Spiele Hersteller will man sich einfach die Kosten sparen. Frei nach dem Motte für die meisten reichts ja. Der Rest darf dann einfach entsprechend tief in die Tasche greifen um diesen Mangel mit stärkerer Hardware oder OC auszugleichen.
Das Ding mit physx ist relativ einfach.
Kann die Grafikkarte die erweiterte Form nicht berechnen wird es von der CPU erledig. Bis physx 3.0 mit der wohl lausigsten CPU Unterstützung die es gab (kein multithreading, FPU Code), das ging mitte 2010 durch die Presse.
Man könnte meinen das dies inzwischen Geschichte ist aber als ich neulich mal dem Benchmark von "Metro: Last Light" rumspielte zeigte sich trotz aktuellem Physx genau das Gegenteil. Mit der erweiterten Physik fiel die Framerate ins bodenlose und die CPU wurde dabei entlastet, kein Wunder denn in der Physx System Software ist auch nur von einer Unterstützung bis zur SDK Version 2.8.4 die Rede.
Stolze Leistung dafür das die Aussage vor 5-6 Jahren getroffen wurde.
Das hat wohl kaum etwas mit technischen Gründen sondern vielmehr mit fehlenden Interesse an einer deutlichen Verbesserung der Leistung beim Einsatz auf einer CPU zu tuen.
Mich würde es nicht wundern wenn solche produktpolitischen Entscheidungen in vielen Fällen deutlich entscheidener für mangelhaften Multicore Support sind als technische Gründe.
Seitens Spiele Hersteller will man sich einfach die Kosten sparen. Frei nach dem Motte für die meisten reichts ja. Der Rest darf dann einfach entsprechend tief in die Tasche greifen um diesen Mangel mit stärkerer Hardware oder OC auszugleichen.
