@andreasg
Ich geh mal stark davon aus da du ein PC-Gamer ist denn dann würdest du mit deiner Theorie recht haben. Leider kannst du das nicht auf die Konsolen beziehen.
Ein PC-Game muss für verschiede Systeme ausgelegt werden ( Single/Dual -Core) damit es viele Leute auf ihren PCs zocken können. Ein Konsolen Game hingegen kann perfekt auf die Hardware abgestimmt werden ohne das sich Entwickler gedanken machen müssen was passiert wenn der eine eine SigleCore besitzt und der andere eine DualCore CPU. Es spielt keine Rolle da die Harware gleich bleibt. Von daher sind Multicore CPUs für Konsolen meiner Ansicht die "optimale" Lösung da man dort wirklich alles aus der Hardware rausholen kann.
Außerdem bedeutet 100% Auslasutung nicht die 100%ige Leistung des Systems.
Eigentlich ist die Diskussion mehr oder weniger sinnlos. In unser heutigen Zeit sind 380Watt egal. Jeder der die Konsole kaufen will interessiert es wenig wieviel Strom diese verbraucht!
@Max_Headroom
Du bringst es auf den Punkt ^^
PS3 braucht viel Energie
Moderatoren: Moderatoren, Redakteure
-
andreasg
- Beiträge: 977
- Registriert: 20.08.2006 17:39
- Persönliche Nachricht:
Ja ich bin PC only Gamer.
Die Probleme von Multithreading sind tiefergehend. Und zwar egal ob es ein PC oder eine Konsole ist.
Es ist kein größeres Problem kleine seperate Threads wie User Interface, Physik oder Sound auszulagern. Z.B. hatte schon Morrowind anno 2002 threaded loading. Doppelkern macht somit gerade noch Sinn.
Ein Problem ist die erhöhte Latenz wenn Threads miteinander kommuniziern müssen. Und auch Abstürze oder Deadlocks, Endlosschleifen können hier auftreten. Der nötige Progammieraufwand um hier entgegen zuwirken ist immens, teilweise nicht bewältigbar.
Das Problem, das nicht gelöst werden wird, ist dass manche Abfolgen nicht parallel, sondern hintereinander abfolgen müssen. Hier nützt Multithreading nichts.
Die Probleme von Multithreading sind tiefergehend. Und zwar egal ob es ein PC oder eine Konsole ist.
Es ist kein größeres Problem kleine seperate Threads wie User Interface, Physik oder Sound auszulagern. Z.B. hatte schon Morrowind anno 2002 threaded loading. Doppelkern macht somit gerade noch Sinn.
Ein Problem ist die erhöhte Latenz wenn Threads miteinander kommuniziern müssen. Und auch Abstürze oder Deadlocks, Endlosschleifen können hier auftreten. Der nötige Progammieraufwand um hier entgegen zuwirken ist immens, teilweise nicht bewältigbar.
Das Problem, das nicht gelöst werden wird, ist dass manche Abfolgen nicht parallel, sondern hintereinander abfolgen müssen. Hier nützt Multithreading nichts.
- Max Headroom
- Beiträge: 1856
- Registriert: 05.08.2002 13:11
- Persönliche Nachricht:
;)
@andreasg:
Der ist versehentlich reingerutsch, weil der 4P-Server da eine Fehlermeldung ausgab... und trotzdem kurze Zeit später den Text speicherte. Bis dahin hatte ich ihn im Texteditor überarbeitet, gesplittet und nochmals (sauber) gepostet. Der 4P-Server verträgt meine Megapostings nicht so gerne 

Aber im Grunde geht es schon in die Richtung wie du es schon gesagt hast... langsamere Spiele werden selbst für die Kaffeetasse eine 2048x2048 Textur nutzen. Es ist ein grafischer Overkill, der optimiert eigentlich kaum ein Problem darstellen würde. Ich kann mir gut vorstellen, dass ein Oblivion 2 für den Griff des Schwertes eine Megatextur verwendet. Wozu das ganze ? Weil es einfacher für die Entwickler wird ? Damit der SPeicher ächtzt ? Damit das Ruckeln wieder Einzug in der neuen Generation nimmt ? Who knows... Für Gesichter kann ich mir eine solche voll ausgenutzte Texturauflösugn gut vorstellen, nur ... wozu eine 2048x2048 Textur in Doom 3 ? Für die "besonders metallischen" Wände ? Das Spiel benötigt es nicht
Deshalb stehe ich solchen Textur-Overkills mit gemischten Gefühlen gegenüber. Es ist toll für ein Screenshot, aber zumeist merkt man solche grafischen Finessen sowieso nicht. 720p im Vergleich zu 1080p ist ja auch nicht gleich C64 gegenüber Amiga 

Es geht einfach nicht... schon vom programmiertechnischen Standpunkt ist dies nicht möglich. Frage mal rum, wer schon SMP-Techniken in der Entwicklung hatte... du wirst überrascht sein, WAS man da auslagert. Das Timing/Synchro wird in erster Linie den Strich durch die Rechnung machen. Ausserdem kann eine CPU nur solange rechnen, wie er auch benötigt wird. Ist mal kein Gegner weit und breit, braucht Kern 3 auch keine KI zu berechnen ... was dann ?? Kaffe kochen ? Und wird Kern 4 die GPU unterstützen ? Durch Berechnung von Physikeffekten ? Auch wenn keine Physik weit und breit benötigt wird ? Es wird eine neue Welt werden, das Multicore-Entwickeln. Aber es wird nicht das Non-Plus-Ultra der Erfinder sein. Ein Dual-Core bietet NICHT die doppelte Power... aber es ermöglicht das flüssigere Zusammenspiel aller Komponenten, weil ein bestimmter Threat NICHT mehr in einer Schleife warten muss, bis er rankommt. Dafür wartet er auf der zweiten CPU ... bis seine Berechnung abgefragt wird
... und je mehr Kerne da vorhanden sind, desto mehr Berechnungen kann man auslagern und später mal abfragen. Diese Multithreat-Programmierung wurde damals zur SMP-Zeit (id-Spieler lächeln nun) stiefmütterlich behandelt. Nun geht der Trend dahin, möglichst viele Kerne zu haben, um möglichst viele Aufgaben parallel zu bewältigen. Der Programmierer wird dafür in eine neue Welt eingeführt, doch glücklicherweise haben Hersteller wie Codeworks auch nicht geschlafen und bieten Erfahrung an, die auch kleinere Unternehmen nutzen können. Früher war es ein Abenteuer, SMP-Software zu entwickeln... für eine kleine Schar von 2-CPU Freaks. Früher habe ich mit dem Live-Assemler des Maschinensprachemonitors direkt auf dem Bootblock einer Diskette einen Bootloader geschrieben. Früher locherte man mit den eigenen Taschenmesser Löcher in den Lochstreifen, damit das Programm nicht abstürzte 
Nun ? Jetzt wird es "Mainstream" und auch kleinere Teams werden optimierte Compiler bekommen, die einiges an Arbeit abnehmen. Der C-Compiler ist auch schon ein alter Hut. Hochsprachen wie JAVA nutzt man für Spiele auf Handys. Selbst Festplatten haben eine eigene Intelligenz und verwalten ihren Datenstrom dank NCQ selbst. Heutige Software nimmt sich die Erfahrung der früheren Hardcode-Hacker und bieten Neueinsteigern mehr Service als das Action-Replay Modul vom 64er. Sie nimmt einem viel (Debug-)Arbeit ab ... aber nicht das Denken und Planen der Software selbst

Es ist schon ein Unterschied, ob ich von einer 10 GHz CPU mit 10 Kernen a 1 GHz nur 1 Kern benötige und 9 abschalten kann, oder ob ich eine 10 GHz Heizkörper-CPU per Throtteling auf 4 runterschrauben kann, denn ALLES lässt sich nicht abschalten... einige Bereiche der CPU müssen auch weiterhin erreichbar bleiben... und das frisst auch Leistung. Meine 3GHz Athlon64-Maschine lässt sich von 2GHz reiner CPU-kraft auf 1 GHz runtertakten, nicht drunter... auch wenn meine Maus still steht oder ich in einer puren Linux-Konsole rumwerkele

Deshalb lagern einige Spiele nur einen Bruchteil von den Berechnungen aus. Das Nachladen, die Partikeleffekte oder so. Nur nützt einem eine (!) Dualcore-CPU kaum was, wenn Core 1 das gesammte Spiel und Core 2 gerade mal ein paar Partikeleffekte auf den Screen klatscht. Wäre es nicht wesentlich besser und ökonomischer, wenn CPU 1 das Spiel, CPU 2 die Partikeleffekte und CPU 3 das Laden übernimmt ? Kann CPU 4 nicht auch noch "nebenbei" für die raschere Wegfindung in der KI sorgen und CPU 5 neue Shader-Berechnungen in die GPU laden ? All diese Arbeit wird der ersten CPU abgenommen... in einem Dual-Core System kann nur einer dieser Aufgaben ausgelagert werden. Hier machen MEHR Kerne einen guten Sinn, oder ?
Und weshalb sollte eine Spielkonsole der nächsten (CPU-)Generation (XB360/PS3) nicht den ersten Schritt in diese Richtung machen ? Intel hatte damals mit ihren "virtuellen" Hyperthreat-Kern ja auch neue Wege beschritten, die nun von den Consumern gerne verwendet werden. Bin schon gespannt was passieren würde, wenn man CELL-Boards für den PC kaufen und Windows darauf laufen würde. Kern 1 für Antivirus, Kern 2 für Kompression und Kern 3 für Loops. Kern 4 für Sondberechnung und Requests, Kern 5 für die Services und Kern... ach... Träumen ist schön 
Sorry, der erste Post kannst Du vergessenPuh viel Lesestoff. Da muss man sich ja richtiggehend durchackern.
Und selbst da musst du ja nicht den gesammten Planeten in HDTV darstellen. Es reicht, nur die im Vordergrund befindlichen Figuren bis zu einem bestimmten Abstand in Ultra-Textur Auflösung auf den Screen zu zaubern. Wenn du sehen willst, wie "krass" ein solches MIP-Mapping aussieht, dann schau dir Halo 2 an. Dort werden die Texturen leidern sowas von krass gewechselt, dass es leider schon negativ auffälltJa bei einem Rennspiel geht alles so schnell, dass du keine Ultra High - Res Texturen brauchst, bei einem Rollenspiel schaut das anders aus.
Aber im Grunde geht es schon in die Richtung wie du es schon gesagt hast... langsamere Spiele werden selbst für die Kaffeetasse eine 2048x2048 Textur nutzen. Es ist ein grafischer Overkill, der optimiert eigentlich kaum ein Problem darstellen würde. Ich kann mir gut vorstellen, dass ein Oblivion 2 für den Griff des Schwertes eine Megatextur verwendet. Wozu das ganze ? Weil es einfacher für die Entwickler wird ? Damit der SPeicher ächtzt ? Damit das Ruckeln wieder Einzug in der neuen Generation nimmt ? Who knows... Für Gesichter kann ich mir eine solche voll ausgenutzte Texturauflösugn gut vorstellen, nur ... wozu eine 2048x2048 Textur in Doom 3 ? Für die "besonders metallischen" Wände ? Das Spiel benötigt es nicht
Um wieviel wollen wir wetten, dass in den nächsten 6 Jahren kein Spiel kommen wird, das auch nur annähernd 100% pro Kern nutzen wird ?Mal ein paar Gedanken zu Multicore. Dualcore kannst du nützen. Ein paar kleine Threads auslagern und so. (..) Aber 4 Kerne mit einem Spiel so auszulasten, dass du fast 100 % Auslastung für jeden Kern hast ist ein anderes Lied. Und das ganze noch stabil ohne Abstürze zu halten ist eine ganz andere Geschichte.
Es geht einfach nicht... schon vom programmiertechnischen Standpunkt ist dies nicht möglich. Frage mal rum, wer schon SMP-Techniken in der Entwicklung hatte... du wirst überrascht sein, WAS man da auslagert. Das Timing/Synchro wird in erster Linie den Strich durch die Rechnung machen. Ausserdem kann eine CPU nur solange rechnen, wie er auch benötigt wird. Ist mal kein Gegner weit und breit, braucht Kern 3 auch keine KI zu berechnen ... was dann ?? Kaffe kochen ? Und wird Kern 4 die GPU unterstützen ? Durch Berechnung von Physikeffekten ? Auch wenn keine Physik weit und breit benötigt wird ? Es wird eine neue Welt werden, das Multicore-Entwickeln. Aber es wird nicht das Non-Plus-Ultra der Erfinder sein. Ein Dual-Core bietet NICHT die doppelte Power... aber es ermöglicht das flüssigere Zusammenspiel aller Komponenten, weil ein bestimmter Threat NICHT mehr in einer Schleife warten muss, bis er rankommt. Dafür wartet er auf der zweiten CPU ... bis seine Berechnung abgefragt wird
Nun ? Jetzt wird es "Mainstream" und auch kleinere Teams werden optimierte Compiler bekommen, die einiges an Arbeit abnehmen. Der C-Compiler ist auch schon ein alter Hut. Hochsprachen wie JAVA nutzt man für Spiele auf Handys. Selbst Festplatten haben eine eigene Intelligenz und verwalten ihren Datenstrom dank NCQ selbst. Heutige Software nimmt sich die Erfahrung der früheren Hardcode-Hacker und bieten Neueinsteigern mehr Service als das Action-Replay Modul vom 64er. Sie nimmt einem viel (Debug-)Arbeit ab ... aber nicht das Denken und Planen der Software selbst
... bei Volllast wohlgemerktUnd zum Stromverbrauch gegenüber hochgetakteten Singlecores, bereits bei Quadcores explodiert der Strombedarf wieder, für eine 32 core Architektur möchte ich nicht die Stromrechnung zahlen.
Es ist schon ein Unterschied, ob ich von einer 10 GHz CPU mit 10 Kernen a 1 GHz nur 1 Kern benötige und 9 abschalten kann, oder ob ich eine 10 GHz Heizkörper-CPU per Throtteling auf 4 runterschrauben kann, denn ALLES lässt sich nicht abschalten... einige Bereiche der CPU müssen auch weiterhin erreichbar bleiben... und das frisst auch Leistung. Meine 3GHz Athlon64-Maschine lässt sich von 2GHz reiner CPU-kraft auf 1 GHz runtertakten, nicht drunter... auch wenn meine Maus still steht oder ich in einer puren Linux-Konsole rumwerkele
Hast du gut gesagt. Es sind die Game-Loops, die seit der C64er Zeit ihre Aufgabe erledigen. Früher musste man auf den Vertical-Blank Interrupt warten, der bekannte VBL-IRQ, damit der Gameloop wieder anfangen konnte. Dann durfte die CPU einen neuen Ton abspielen, die KI einen Schritt überlegen und der Spieler einen Knopf drücken. Heute ? Eigentlich wurde der VBL durch reine CPU-Kraft ersetzt, ansonsten ist das selbe los(..)Das Problem, das nicht gelöst werden wird, ist dass manche Abfolgen nicht parallel, sondern hintereinander abfolgen müssen. Hier nützt Multithreading nichts.
Deshalb lagern einige Spiele nur einen Bruchteil von den Berechnungen aus. Das Nachladen, die Partikeleffekte oder so. Nur nützt einem eine (!) Dualcore-CPU kaum was, wenn Core 1 das gesammte Spiel und Core 2 gerade mal ein paar Partikeleffekte auf den Screen klatscht. Wäre es nicht wesentlich besser und ökonomischer, wenn CPU 1 das Spiel, CPU 2 die Partikeleffekte und CPU 3 das Laden übernimmt ? Kann CPU 4 nicht auch noch "nebenbei" für die raschere Wegfindung in der KI sorgen und CPU 5 neue Shader-Berechnungen in die GPU laden ? All diese Arbeit wird der ersten CPU abgenommen... in einem Dual-Core System kann nur einer dieser Aufgaben ausgelagert werden. Hier machen MEHR Kerne einen guten Sinn, oder ?
-
andreasg
- Beiträge: 977
- Registriert: 20.08.2006 17:39
- Persönliche Nachricht:
-
andreasg
- Beiträge: 977
- Registriert: 20.08.2006 17:39
- Persönliche Nachricht:
Update
Bereits die Unreal Engine 3.5 hat "Fully real-time ray tracing global llumination"
http://wiki.beyondunreal.com/wiki/Unrea ... e_Versions
Bereits die Unreal Engine 3.5 hat "Fully real-time ray tracing global llumination"
http://wiki.beyondunreal.com/wiki/Unrea ... e_Versions
- TiggerDeluxe
- Beiträge: 170
- Registriert: 27.02.2006 19:15
- Persönliche Nachricht:
Ein 400 Watt Netzteil sagt nichts über den tatsächlichen Stromverbrauch aus...shaokahn6 hat geschrieben:Aha, dann gehe ich mal davon aus, dass du maximal ein Laufwerk dran hast, keine USB Geräte und eine kleine festplatte?Mein TFT + PC verbrauchen in durchschnitt gerade mal ca. 150 - 180 Watt.
Ansonsten würden diese Werte nicht zustande kommen, denn mein PC braucht ein 400 Watt Netzteil, ich habe drei laufwerke dran, eine interne und eine externe Festplatte sowie natürlich meinen TFT und diversen USB Krims Krams...
Du kannst dir auch ein 10.000 Watt Netzteil in deinen Computer verbauen
Die Fragen die kommen, sind Spitzenlast und Durchschnittslast.
Das Netzteil muss für Spitzenlast ausgelegt sein (das es diese eben auch schafft) - Durchschnittslast ist interessant für denjenigen, der seine Rechnung zahlt!
400 Watt ist also der Wert, den dein Netzteil unter Volllast für längere Zeit liefern kann - nicht der, den er ständig verbraucht.
- Seth666
- Beiträge: 3865
- Registriert: 07.02.2003 11:04
- Persönliche Nachricht:
