Outcast 1.1 im Technik-Test: Trotz Multi-Threadings ist ein 5-GHz-Prozessor ratsam

@Raff ist bei Outcast die IPC oder sind eher die Kerne wichtig ?
IPC.
IPC ist immer wichtiger. Deshalb hat Bulldozer ja die Probleme: 65% IPC per Core, dafür 2x so viele Cores bringt nur in den wenigsten Fällen was und wird auch in Zukunft wenig bringen.

IPC ist nur dann weniger wichtig wenn die Parallelisierung fast perfekt funktioniert. Deshalb warten hier schon einige Leute (mich eingeschlossen) sehr gespannt auf Benchmarks zur Kernskalierung.
Aber Parallelisierung geht nur bei einfachen, immergleichen Programmen oder Rechenschritten gut. Bei komplexen, dynamischen Aufgaben ist der "Reibungsverlust" durch das Aufsplitten einer Aufgabe auf viele Cores wesentlich größer - deshalb wird das Spiel wohl nicht besonders gut skalieren auf mehrere Cores. Und weil natürlich eigentlich nur wenige Tasks parallelisiert sind, nicht die gesamte Engine von Grund auf umgeschraubt wurde für 8 Kerner und Co.
sry. aber steht auf meiner "brauchichnicht- liste" ganz oben
nene.gif
........weil potthässlich und ewig langweilig.....wem,s gefällt o.k, aber ich finds echt so überflüssig wie ne blinddarmentzündung
"Schön" ist es nicht - außer man vergleichts mit so manchen Indie-Spielen heutzutage.
Aber langweilig ist es bestimmt nicht. Die Genres haben sich nicht so dermaßen weiterentwickelt seither, dass es plötzlich langweilig wäre.
Nur weil es alt ist. Das ist, als würde man sagen "Blade Runner" oder "Alien" sind schlechte Filme, nur weil sie alt sind. Im Gegenteil, sie sind immer noch genial.
Und der Vergleich passt auch: Die erwähnten Filme waren wesentlich gehaltvoller als 90% der Grütze die heutzutage im Kino läuft (1000x Explosionen und 2 gesprochene Sätze, fertig ist der Superhelden oder Michael Bay Film).
Ähnlich sind Spiele oft heute (COD), Outcast sticht gerade deshalb hervor. Es gibt wenige Spiele aus den späten 90ern die man heutzutage noch "schön" finden würde, aber tatsächlich hatten die wenigstens noch Gameplay.
Und weiter? Was bringt es dir, wenn die Engine keine MultiCores nutzt?
Ich bin neugierig, hast du nichtmal die Überschrift ganz gelesen?
5Ghz CPUs gibts ja nur bei AMD
lolaway2.gif
biggrin1.gif
lolaway2.gif
Ach nö, das ist eine 5 Ghz taktende Heizung.
5 Ghz gehen auch bei Intel ;)
Nur sind 5 Ghz bei AMD natürlich nicht mit 5 Ghz bei Intel zu vergleichen (wohl eher so ~3.5, tut aber nix zur Sache, ich bin sicher Raff und Co jagen die nächsten Tage mehrere CPUs durch die Benchmarks, inklusive Core/Modulskalierung
 
Zuletzt bearbeitet:
Sehr fazinierend: Bei mir wird der i7 nur geringfügig belastet. Kein einziger Thread wird zu 100% ausgelastet. Alle Threads laufen bei ~15%

Du hast 8 Threads. 100 durch 8 ergibt 12,5. Folglich dürfte 1 Kern immer zu 100% ausgelastet sein und windows schiebt den zugehörigen Thread ständig zwischen den Kernen hin und her.


Zur Benchmark Thematik...

Nutzt das Game überhaupt aktuelle CPU Architekturen effizient aus? Nutzt es aktuelle Befehlssätze. Denn es ist ja nicht nur die Rohleistung, die bei CPUs ansteigt, es ist vor allem auch die Effizienz.
Wenn eine CPU also nicht mit den richtigen Befehlen gefüttert wird, kann sie auch nicht ihre volle Leistung auf die "Straße" bringen.
 
Nutzt es aktuelle Befehlssätze. Denn es ist ja nicht nur die Rohleistung, die bei CPUs ansteigt, es ist vor allem auch die Effizienz.
Wenn eine CPU also nicht mit den richtigen Befehlen gefüttert wird, kann sie auch nicht ihre volle Leistung auf die "Straße" bringen.

Auf einer der vorherigen Seiten wurde gesagt das es keine aktuellen Befehlssätze unterstützt.
 
In 15 Jahren wird wieder gebencht. Da eiert man dann rum wieso es in der Standartauflösung 4K nicht mit 60 FPS läuft mit nem i7 9970X (oder so).:ugly::ugly:
 
lol.... CPU Limit bei so einem Game... Deren Ernst? Nein, Danke!:daumen2:

die komplette engine läuft nur und zwar ausschließlich über die cpu.
das ist auch das einzige spiel der geschichte mit so einer technik. (ausser die zeit vor gpu beschleunigern)

IPC ist nur dann weniger wichtig wenn die Parallelisierung fast perfekt funktioniert.

wird es bei echtzeitanwendungen nie geben. ist ein grundgesetz. multiple threads zeitgleich zusammenführen resultiert immer in einem erheblichen verlust.
und oft ist es sogar so das mehr kerne die speicherverwaltung erheblich verlangsamen wodurch ein 4 kerner dann zum beispiel schneller ist als ein 8 kerner.

da gibt es hunderte beispiele zu dem thema - lernt jeder besserer coder in der schule.

und ja klar ist die IPC leistung viel viel wichtiger; sonnst hätten wir ja einfach 50 atoms in der kiste :).
 
Zuletzt bearbeitet:
Auf einer der vorherigen Seiten wurde gesagt das es keine aktuellen Befehlssätze unterstützt.
In 15 Jahren wird wieder gebencht. Da eiert man dann rum wieso es in der Standartauflösung 4K nicht mit 60 FPS läuft mit nem i7 9970X (oder so).:ugly::ugly:
Prinzipiell eine gute Sache:
Hier sieht man mal, wie sich die CPU Performance weiterentwickeln würde, wenn nicht ständig zusätzliche Befehle und Funktionen hinzukämen (ISSE,AVX, QuickSync, iGPU, VT...).
Also die Entwicklung der reinen Rohleistung, ohne Optimierung.
Was durchaus als Beispiel verwendet werden darf, wenn eine neue Prozessorgeneration kommt, einen Haufen neuer Befehle mitbringt und die Leute sagen "brauch ich nicht, ich will lieber mehr Tempo".

Outcast kann also nicht als Beispiel gelten, wie gut sich die CPUs an und für sich weiterentwickelt haben, aber man kann es als Beispiel verwenden die ROHLEISTUNG einer CPU zu messen. Abgesehen davon natürlich ist es eh interessant, dass wenn ein Spiel nicht für eine CPU geschrieben ist, man sehr gut auch sieht, dass es nicht immer automatisch anzunehmen ist, dass ein neuer Prozessor den erhofften Geschwindigkeitsgewinn bringt.

Hier würde mich etwa mal interessieren, wie sich mein Tualatin (Pentium 3 S) schlagen würde :)
die komplette engine läuft nur und zwar ausschließlich über die cpu.
das ist auch das einzige spiel der geschichte mit so einer technik. (ausser die zeit vor gpu beschleunigern)
stimmt bis auf wenige Ausnahmen (Comanche 3 usw).
Auch ID Softwares "Trinity" klang mal interessant. Sollte die Engine für eine Mischung aus Egoshooter und Rennspiel in Open World werden, wurde dann aber zugunsten von Quest und später Doom 3 aufgegeben. Damals wollte man irgendwie noch innovativ sein :D In der Tech 6 versucht man vermutlich die ungenutzte CPU Leistung wieder für Voxel zu verwenden.
Minecraft und andere Spiele nutzen meines Wissens nach wieder zum Großteil die CPU für Voxel, hier kann ich mich aber irren.
Außerdem kam auf der PCGH ab und an eine Meldung zu einer Voxelengine

wird es bei echtzeitanwendungen nie geben. ist ein grundgesetz. multiple threads zeitgleich zusammenführen resultiert immer in einem erheblichen verlust.
und oft ist es sogar so das mehr kerne die speicherverwaltung erheblich verlangsamen wodurch ein 4 kerner dann zum beispiel schneller ist als ein 8 kerner.
Ja ich kenne Amdahls Law eh
zwinker4.gif

da gibt es hunderte beispiele zu dem thema - lernt jeder besserer coder in der schule.

und ja klar ist die IPC leistung viel viel wichtiger; sonnst hätten wir ja einfach 50 atoms in der kiste
smiley.gif
.
Das ist eher was für die Uni, denn für die Schule denke ich
zwinker4.gif



Tatsächlich ist es schon möglich, aber nicht bei derzeitiger Softwarearchitektur - eine Many Core CPU (100+) ist ja schon in entwicklung samt Software dazu. Funzt dann halt wie eine GPU
 
Zuletzt bearbeitet:
Schon kar das Outcast du CPU nutzt und das es sich hier um Voxelgrafik handelt.
Ergebnis bleibt aber gleich. Outcast schaut dämlich aus und belastet die Hardware.
Als Crysis 1 rauskam, belastete es auch die Hardware, aber da war es okay, oder wie?
Und ob es dämlich aussieht, liegt im Auge des Betrachters.
Voxel haben nach wie vor viele Vorteile.
Allein optisch würde ich Voxel+Raytracing immer dem heutigem Standard - Polygon+Rasterisierung - vorziehen. Von entsprechenden "Hitboxes" ganz zu schweigen. Keine Ahnung, warum es immer noch keine Beschleuniger dafür gibt. Polygonbeschleuniger waren damals offenbar der einfachere/bequemere Weg, also ein Ansatz der sich zu der Zeit leichter technisch umsetzen ließ.

Ich hab grad das Video gesehen und dachte ich bin bei irgendeinem PCGH Retro Video gelandet.

Naja Mal ganz ehrlich, schön und gut ist es ja um zu zeigen was ohne Grafikkarte möglich ist.

Aber mal im Ernst WAS NÜTZT MIR DAS ? Sieht doch aus wie Minecraft oder ein Computerspiel aus den frühen 90ern :confused:
Das IST Retro.
Was NÜTZEN Dir Computerspiele im Allgemeinen? Sie machen Spaß und das gleiche gilt für Outcast im speziellen.
Btw: Du kennst keine Computerspiele aus den frühen 90ern, wie es mir scheint...

Ach das ist doch die alte Voxel-Grafik..... keine GPU nur CPU Power wird gebraucht, das läuft auf ner Single CPU genauso gut denke ich mal.
Nein, es läuft auf einer Single-CPU schlechter da - man lese den Text - mit Version 1.1 Multithreadunterstützung kam.

@Raff ist bei Outcast die IPC oder sind eher die Kerne wichtig ?
Ganz klar die IPC.
Das gilt aber immer. Der Verwaltungaufwand für die Threads steigt mit der Anzahl der Threads, so das man irgendwann keinen Leistungsgewinn mehr durch weitere Parallelisierung bekommt (Die vernünftige Anzahl an Threads ist allerdings abhänging von der Software, also von Programm zu Programm unterschiedlich).
Auch hier steht im Test, das es keinen großen Unterschied mehr zwischen 4 und 8 Threads gibt, was allerdings wohl eher daran liegt, das die Unterstützung für mehr als 4 Threads noch buggy ist...
Also lieber auf IPC setzen.

Du hast 8 Threads. 100 durch 8 ergibt 12,5. Folglich dürfte 1 Kern immer zu 100% ausgelastet sein und windows schiebt den zugehörigen Thread ständig zwischen den Kernen hin und her.
Autsch.
Dir ist schon klar, das jeder Thread "seinen" CPU-Kern zu 100% auslasten kann?
Was Du hier vorrechnest ist absoluter Humbug.
Du wirst in diesem Spiel warscheinlich einen Thread für die Grafik haben, optimalerweise sogar einen für die Voxel (noch besser wohl mehrere Threads für die Voxel) und einen für die Polygone.
Dann kommt ein Thread für den Sound, einer für die K.I., einer für das Spiel selbst bzw dessen "Mechaniken"...
Und jeder dieser Threads landet auf einem (virtuellen) Kern. Da schiebt Windows nichts hin und her.
 
Zuletzt bearbeitet:
Übrigens ist die neue, bilineare Texturfilterung für die szenenabhängig starken Slowdowns verantwortlich. Den Verdacht hatte ich seit ein paar Tagen – und nun auch mal Zeit, das zu testen. Man kann den Filter im Launcher ausknipsen. Benchmarks an der fiesen Ranzaar-Stelle zufolge, bringt Point Sampling auf den Meshes zwischen 20 und 30 Prozent höhere Bildraten – zumindest auf meinem Phenom II X6 @ 4 GHz (24-25 statt 18-19 Fps). Und das, obwohl die Engine anscheinend schon mit Point Sampling eine perspektivische Korrektur der Texturen vornimmt. Das ist schon hart: Im Grunde total simple bilineare Filterung kostet auf der CPU mehr als 16:1 HQ-AF im schlimmsten Fall auf einer modernen Grafikkarte.

MfG,
Raff
 
Das ist schon hart: Im Grunde total simple bilineare Filterung kostet auf der CPU mehr als 16:1 HQ-AF im schlimmsten Fall auf einer modernen Grafikkarte.

Ja schon wirklich übel. An solchen Sachen merkt man dann erst wie stark aktuelle CPUs in Punkto Leistung hinter Grafikkarten zurück stehen, alleine schon wenn es um solch "simple" Sachen wie AF geht.

Ich fände es ja wirklich mal spannend wenn die Engine von Outcast umgeschrieben würde um auch die Grafikkarte mit in die Berechnungen ein zu beziehen, das würde einen gewaltigen Sprung in Sachen Leistung bringen.^^
Leider wird sich wohl niemand für ein so altes Spiel einen solchen Aufwand machen.
 
GPU-Beschleunigung wird's für dieses Spiel mit an Sicherheit grenzender Wahrscheinlichkeit nicht geben, aber womöglich Verfeinerungen des Multi-Threadings. Das scheint noch nicht ganz rund zu laufen (siehe FX-Resultate).

Apropos: Der gestrige Patch scheint etwas Performance rauszuholen, wenn ich die Bildrate hier an meinem Privatrechner mit den Benchwerten vergleiche. Oder es liegt an den anderen Unterschieden (Geforce statt Radeon, Windows 7 statt Windows 8, nicht identisches Savegame). Jedenfalls läuft's hier recht deutlich besser mit 18-19 statt 14-15 Fps. :daumen:

MfG,
Raff
 
Können Voxel grundsätzlich von aktuellen GPU Beschleunigern betrieben werden?

Hmm, eine gute Frage. Outcast ist in diesem Zusammenhang übrigens nicht das einzige Spiel was beim Terain auf Voxel setzt. Das recht aktuelle Spiel "Planet Explorers" verwendet ja ebenfalls bei der Landschaft eine Engine die selbige auf Voxel-Basis darstellt. Trotz allem fallen die Systemanforderungen recht moderat aus:

Empfohlen:
CPU: 3.0 GHz Dual Core
RAM: 4GB DDR3
GPU: DX11 kompatibel
HDD: 2GB

Ich würde also annehmen das dort die Berechnung über die GPU erfolgt, oder aber das Voxel-Terain für sich genommen ist nicht so leistungsintensiv und kann über die CPU berechnet werden, während Charaktere, Gebäude, ect. über die GPU berechnet wird.
 
Hi Raff!

Wie siehts jetzt aus? Wurden deine Benchmarks mit oder ohne VSync gemacht (siehe 'John Preston'/#48)? Und wie ist bei dir der FPS-Unterschied dann?
Und wie sieht die Grafik im Vergleich mit neuer bilinearer Texturfilterung und ohne diese aus? Scheint ja ca. 20 Prozent Mehrleistung zu bringen, oder?
 
IPC ist nur dann weniger wichtig wenn die Parallelisierung fast perfekt funktioniert. Deshalb warten hier schon einige Leute (mich eingeschlossen) sehr gespannt auf Benchmarks zur Kernskalierung.
Aber Parallelisierung geht nur bei einfachen, immergleichen Programmen oder Rechenschritten gut. Bei komplexen, dynamischen Aufgaben ist der "Reibungsverlust" durch das Aufsplitten einer Aufgabe auf viele Cores wesentlich größer - deshalb wird das Spiel wohl nicht besonders gut skalieren auf mehrere Cores.

Gerade pro Pixel abläufende Grafikberechnungen, wie sie für eine Voxelengine typisch sind, lassen sich sehr gut parallelisieren. Ich erinnere in diesem Zusammenhang an Larrabee.


Können Voxel grundsätzlich von aktuellen GPU Beschleunigern betrieben werden?

Seit DirectX 10 kann man nahezu alle Berechnungen in Shadern ablaufen lassen. Aber man müsste eine entsprechende Engine erst einmal entwicklen und würde in der Gesamtleistung weit hinter der Performance einer Polygon-Engine zurückbleiben. Technisch interessant (aber praxisfern) wäre eine Version für Xeon Phi.
 
Technisch interessant (aber praxisfern) wäre eine Version für Xeon Phi.
Das hatte ich mir auch schon gedacht. 60 Kerne mit insgesamt 240 Threads (5110P) und 8 GB RAM sind ja schon ganz nett. Und das müsste eigentlich recht gut auf der Kiste skalieren, sofern einem die Speicheranbindung keinen Strich durch die Rechnung macht. Das kann leider etwas tricky werden bei dem Teil.
 
Schlampig Programmiert würd ich mal sagen... genauso wie z.B. Metro. Schaut dämlich aus, verschlingt aber unmengen an Ressourcen.
Ich seh schon die Überschriften von Leuten - die mir mit Outcast-Benchmarks weismachen wollen, das alles unter i7 CPUs sowieso nix taugt.

Sorry aber Metro Redux ist alles andre als ein Hardwarefresser...und sieht sehr geil aus
 
Gerade pro Pixel abläufende Grafikberechnungen, wie sie für eine Voxelengine typisch sind, lassen sich sehr gut parallelisieren. Ich erinnere in diesem Zusammenhang an Larrabee.




Seit DirectX 10 kann man nahezu alle Berechnungen in Shadern ablaufen lassen. Aber man müsste eine entsprechende Engine erst einmal entwicklen und würde in der Gesamtleistung weit hinter der Performance einer Polygon-Engine zurückbleiben. Technisch interessant (aber praxisfern) wäre eine Version für Xeon Phi.

Danke, dann müssen wir uns wohl oder übel mit Polygonen begnügen.:D
 
Mal ne andere Frage, laufen dann in dem Spiel eigentlich downsampling optionen auch wenn das Bild nicht von der Graka berechnet wird?
Ich meine das Bild wird von der CPU berechnet, durch die GPU geschleift und hochskaliert, sollt ja eigentlich gehen oder denkfehler?
 
Zurück