Assasin's Creed profitiert von vier cores. Warum?

[BAGZZlash]

Zitat von Neosix

Ist jetzt AC das erste Spiel das bei 4 Kernen Profitiert oder wieso ist die Meldung jetzt so besonders? oO

Meiner Meinung nach ist's in der Tat der erste Shooter, der echt parallelisierten Code ausführt, ja.
Bei RTS-Games wie C&C3 oder Supreme Commander ist das streitig, aber möglich.

[N0Thing]

Zitat von Spasstiger

In Extremsituationen scheint sogar nur ein Quadcore (> 2 GHz) oder ein stark übertakteter Dualcore (Core 2 Duo > 4 GHz) ausreichend hohe Frameraten zu liefern.

Dann scheine ich ja während ich AC durchgespielt habe, nie in eine Extremsituation gekommen zu sein und das mit einem A64 x2 4200+ (und einer 8800GT)

Freut mich aber trotzdem, daß ein weiteres Spiel von weiteren Kernen profitiert, bei Supreme Commander wünsche ich mir das jedes Mal.

[Simon]

Zitat von Brillenschlange92

Die Frage ist, ob die KI im Vergleich zur Grafik ausreicht, die verbleibenden Kerne alle auszulasten?

Es gibt auch noch Collision Detection, die gerade bei so vielen Personen verdammt oft zum Einsatz kommt. Collision Detection & Response läuft komplett auf der CPU und lässt sich auch recht gut parallelisieren. Dann gibt es noch die Berechnung von Animationen, die auf der CPU gemacht werden kann, auch gut parallelisierbar. Decompression von Daten fürs Streaming ist auch auf der CPU. Vernünftiger Mehrkanal-sound braucht auch Leistung.
Also zu tun gibt es für Quadcores mehr als genug

Falls ein Spiel Shadow Volumes wie z.B. Doom3 und Quake4 nutzt (heute eher selten), kann man das auch wunderbar auf mehreren CPUs machen.

[Spasstiger]

Zitat von N0Thing

Dann scheine ich ja während ich AC durchgespielt habe, nie in eine Extremsituation gekommen zu sein und das mit einem A64 x2 4200+ (und einer 8800GT)

Freut mich aber trotzdem, daß ein weiteres Spiel von weiteren Kernen profitiert, bei Supreme Commander wünsche ich mir das jedes Mal.

Im PC-Games-Hardware-Test lag die Framerate auf einem Core 2 Duo E6600 bei 22 fps min, also nicht mehr flüssig (wenn auch noch spielbar). Der Q6600 erreichte 42 fps min.. Mit deinem X2 4200+ wirst du durchaus mal weniger als 20 fps gehabt haben, wenn ich hier selbst feststelle, dass mein Core 2 Duo E4300 @ 3 GHz nicht jede Situation flüssig meistert (sprich mit über 30 fps).

[BAGZZlash]

Zitat von Simon

Collision Detection & Response läuft komplett auf der CPU und lässt sich auch recht gut parallelisieren. Dann gibt es noch die Berechnung von Animationen, die auf der CPU gemacht werden kann, auch gut parallelisierbar. Decompression von Daten fürs Streaming ist auch auf der CPU. Vernünftiger Mehrkanal-sound braucht auch Leistung.
Also zu tun gibt es für Quadcores mehr als genug

Kollisionserkennung per Dreieck ist nicht sonderlich aufwendig. Per Pixel ist es sehr aufwendig, aber das wird bei AC sicherlich nicht gemacht. Übrigens: PhysX sollte per Pixel gekonnt haben, stimmt das? Falls ja, kann man beim CUDA-Port ja auch darauf hoffen. Dekompression spielt eigentlich auch keine Rolle, die GraKa bekommt direkt komprimierte (Textur-)Daten. Beim Sound ist's ähnlich wie bei der Kollisionserkennung: Für "anständig" ist auch mit Quadcore zu wenig Leistung da und bei "gehuddelt" wie bei allen anderen Spielen ist's kein ernstzunehmender leistungskritischer Faktor. Gab' glaub' ich auch auf der 3DC-Hauptseite mal'n Test dazu. Ist aber schon was her, d.h. da waren die CPUs nochmal 'ne Ecke langsamer als heutzutage.
Einzig Animationen - allgemeiner: Geometrie - lasse ich als von Multicore profitierend wirklich zu, allerdings muss auch hier sichergestellt sein, dass es keine Polygonüberlappungen oder so gibt. Immer, wenn sich Modelle gegenseitig beeinflussen, war's das mit der Parallelisierbarkeit. Aber gut, das lässt sich einrichten.
Alles in allem: Keiner der genannten Punkte kann erklären, warum AC so gut auf Multicore skaliert. Frage: Warum sonst? Oder vertu' ich mich?

[O RLY?]

Frag doch die Programmierer
Schließlich wurde das Spiel ja für Current-Gen Konsolen entwickelt und die sind bekanntlich nunmal alle Multi-Core Kisten.

[BAGZZlash]

Zitat von O RLY?

Frag doch die Programmierer
Schließlich wurde das Spiel ja für Current-Gen Konsolen entwickelt und die sind bekanntlich nunmal alle Multi-Core Kisten.

Danke für der Tip. Kann ich nur leider nicht, ich kenn' keinen. Außerdem: Will ich auch gar nicht, ich will hier - im Diskussionsforum - darüber diskutieren.

Zitat von BAGZZlash

Das ist mir alles zu platt, "Das Spiel ist auf mehrere Kerne ausgelegt". Das ist nicht Gegenstand des Threads. Fraglich ist vielmehr, was AC kann, was andere Spiele nicht können.

Ich weiß nicht, ob "können" hier der richtige Begriff ist, denn es ist ja auch eine Designfrage. Wenn ein Hersteller möchte, dass das Spiel auch noch auf Einkernern spielbar bleibt, so muss er eben von vorneherein Kompromisse eingehen.

[robobimbo]

Vielleicht verwendet ja AC schon den neueren Ansatz der "Tasks" - Es werden jeden Menge Tasks erzeugt (viel mehr als es Cores gibt) und die werden dann - je nach Bedarf werden die auf die freien Cores verteilt. Solche Anwendungen skalieren gut mit mehreren Prozessoren, verrecken aber natürliche bei solchen Systemen die nur einen haben, weil dieser Ansatz ja latürnich auch einen gewissen Overhead bedeutet.

Beide Ansätze sieht man bei Intels Threading Building Blocks, sowie in einem MS Vortrag auf der letzten Gamers Developer Conference

Links: http://www.threadingbuildingblocks.org/
http://www.microsoft.com/downloads/i...splaylang%3den

[BAGZZlash]

Zitat von Gast

Ich weiß nicht, ob "können" hier der richtige Begriff ist, denn es ist ja auch eine Designfrage. Wenn ein Hersteller möchte, dass das Spiel auch noch auf Einkernern spielbar bleibt, so muss er eben von vorneherein Kompromisse eingehen.

Ganz sicher skalieren andere Spiele nicht deshalb so schlecht auf Multicoresystemen, weil die Entwickler sich bewusst so entschieden haben. "Können" ist hier ein durchaus rechtfertigbarer Begriff.

[Ectoplasma]

Zitat von robobimbo

Vielleicht verwendet ja AC schon den neueren Ansatz der "Tasks" - Es werden jeden Menge Tasks erzeugt (viel mehr als es Cores gibt) und die werden dann - je nach Bedarf werden die auf die freien Cores verteilt.

Klingt irgendwie unlogisch. Bei einem Spiel gibt es einen Fluss. Wozu sollte es wesentlich mehr Threads als CPUs geben? Was ich meine ist, dass es doch in einem Spiel kaum eine Aufgabe geben kann, die parallel wartet. Auf was denn? Wenn sich Algorithmen parallelisieren lassen, dann hat man eine Menge von Worker-Threads. Die Anzahl der Threads sollte sich nach der Anzahl der CPUs richten. Man hat vielleicht noch mehrere Worker-Thread-Pools. Z.B. für die Physik oder die Grafik. Das war es aber auch. Ein Worker-Thread-Pool der wesentlich mehr Threads als CPUs hat ist z.B. dann wichtig, wenn viele Ereignisse gleichzeitig eintreten (z.B. bei Multi-User-Games). Ich finde den Anzatz mit vielen Threads für ein Game richtig schlecht. Das skaliert auch auf Multicores mieserabel. Man glaubt gar nicht wieviel Zeit dadurch verbraten wird.

Zitat von BAGZZlash

Fraglich ist vielmehr, was AC kann, was andere Spiele nicht können.

fraglich ist vor allem wie man auf solch seltsame ergebnisse kommt. 3 cores bringen kaum mehr als 2, aber mit 4 gibt es wieder einen kleinen schub?

irgendwas muss da doch faul sein, das kann einfach nicht stimmen.

[Simon]

Zitat von BAGZZlash

Kollisionserkennung per Dreieck ist nicht sonderlich aufwendig.

Bei so vielen Leuten, die durch die Gegend laufen und der großen Welt, seh ich das etwas anders. Zumal auch die AI Range Checks und Visibility und ähnliches braucht, was ich da mal mit reingenommen hab.

Zitat:

Dekompression spielt eigentlich auch keine Rolle, die GraKa bekommt direkt komprimierte (Textur-)Daten.

Zumindest bei id's Megatexture stimmt das so nicht. Keine Ahnung, wie das bei AC gelöst ist. Ohne technische Details zum Spiel kann dazu auch keiner was sagen.

Zitat:

Beim Sound ist's ähnlich wie bei der Kollisionserkennung: Für "anständig" ist auch mit Quadcore zu wenig Leistung da und bei "gehuddelt" wie bei allen anderen Spielen ist's kein ernstzunehmender leistungskritischer Faktor. Gab' glaub' ich auch auf der 3DC-Hauptseite mal'n Test dazu. Ist aber schon was her, d.h. da waren die CPUs nochmal 'ne Ecke langsamer als heutzutage.

Sound ist überhaupt nicht mein Gebiet, da müßte man eher Avalox fragen
Gehen wir mal davon aus, dass die Asus Xonar D2 EAX 2 nicht in Hardware kann, also auf der CPU berechnet, dann kostet Sound doch einiges an Leistung, siehe z.B. bei der Computerbase Irgendwo stand auch, dass die Xonar EAX 5 via CPU-Emulation bekommen soll, was nochmal extra kostet.

Zitat:

Einzig Animationen - allgemeiner: Geometrie - lasse ich als von Multicore profitierend wirklich zu, allerdings muss auch hier sichergestellt sein, dass es keine Polygonüberlappungen oder so gibt.

Warum keine Überlappungen bzw. was für Überlappungen meinst du?
Meine XBox ist leider seit 7 oder 8 Wochen in Reparatur, sonst würde ich jetzt nochmal nachschauen, aber so aus dem Gedächtnis heraus kommen sich die NPCs sowieso nicht zu nahe.

Zitat:

Warum sonst? Oder vertu' ich mich?

Naja, was bleibt denn noch über an Aufgaben? Multiplayer?

Ich kann hier problemlos einen 3GHz Core2 Duo nur mit AI und Physik (inkl. Collision Detection & Response) zu ~80% auslasten und die Welt ist weder groß noch stark bevölkert Die Kostens fürs Rendering sind minimal im Vergleich zu allem anderen.

Ohne mehr Details zu AC lässt sich kaum sagen, wo das Spiel wieviel CPU verbraucht

Zitat von Ectoplasma

Klingt irgendwie unlogisch. Bei einem Spiel gibt es einen Fluss. Wozu sollte es wesentlich mehr Threads als CPUs geben? Was ich meine ist, dass es doch in einem Spiel kaum eine Aufgabe geben kann, die parallel wartet. Auf was denn? Wenn sich Algorithmen parallelisieren lassen, dann hat man eine Menge von Worker-Threads. Die Anzahl der Threads sollte sich nach der Anzahl der CPUs richten. Man hat vielleicht noch mehrere Worker-Thread-Pools. Z.B. für die Physik oder die Grafik. Das war es aber auch. Ein Worker-Thread-Pool der wesentlich mehr Threads als CPUs hat ist z.B. dann wichtig, wenn viele Ereignisse gleichzeitig eintreten (z.B. bei Multi-User-Games). Ich finde den Anzatz mit vielen Threads für ein Game richtig schlecht. Das skaliert auch auf Multicores mieserabel. Man glaubt gar nicht wieviel Zeit dadurch verbraten wird.

Ich glaube, er meint einen Thread Pool, nur das seine Erklärung ziemlich falsch ist

[Botcruscher]

Zitat von Gast

fraglich ist vor allem wie man auf solch seltsame ergebnisse kommt. 3 cores bringen kaum mehr als 2, aber mit 4 gibt es wieder einen kleinen schub?

irgendwas muss da doch faul sein, das kann einfach nicht stimmen.

Vermutlich ist die Software fest auf 1,2 oder 4 Cores ausgelegt. Der 3 Core wird nicht verwendet. Dieses "Softwareproblem" macht Tricores noch unatraktiver..

Zitat von BAGZZlash

Ganz sicher skalieren andere Spiele nicht deshalb so schlecht auf Multicoresystemen, weil die Entwickler sich bewusst so entschieden haben. "Können" ist hier ein durchaus rechtfertigbarer Begriff.

Naja, das sehe ich wie gesagt anders.
Wenn ich das Spiel von vornherein so Designe, dass ein beträchtlicher Teil der Leistung für Physik, KI usw. verbraten wird, so kann das natürlich wesentlich besser von weiteren Cores profitieren. Das ist kein Hexenwerk.

Zitat von Botcruscher

Vermutlich ist die Software fest auf 1,2 oder 4 Cores ausgelegt. Der 3 Core wird nicht verwendet. Dieses "Softwareproblem" macht Tricores noch unatraktiver..

kaum vorstellbar, wieso sollte man sowas dämliches machen?

ich vermute mal dass assassins creed deutlich mehr worker-threads als cores verwendet, was auch notwendig ist, da man die auslastung der einzelnen threads kaum ausbalancieren kann, wenn man nicht in jedem thread das selbe macht.

[Botcruscher]

Zitat von Gast

kaum vorstellbar, wieso sollte man sowas dämliches machen?

Weil zum Zeitpunkt der Entwicklung von Tricores noch keine Rede war und man es mal eben so fix zusammengeprogt hat. Die unterschiedlichen Tests zum Tricore von AMD zeigen oft solche Abweichungen.

[Demirug]

Zitat von Gast

ich vermute mal dass assassins creed deutlich mehr worker-threads als cores verwendet, was auch notwendig ist, da man die auslastung der einzelnen threads kaum ausbalancieren kann, wenn man nicht in jedem thread das selbe macht.

Mehr worker threads als cores ist Gift. Das fressen dir die Contextwechsel die Leistung weg.

Zitat von Simon

Ich glaube, er meint einen Thread Pool, nur das seine Erklärung ziemlich falsch ist

Thread Pools sind schon etwas besser. Funktionieren aber in der Regel nur bei Serveranwendungen die viele Clients bedienen gut.

[Neosix]

Aber gerade wenn ein Spiel so viele Threads verwendet, werden diese doch nur vom Betriebsystem verwaltet und da sollte es egal sein ob man 2 oder 6 cores hat, die Last wir dynamisch verteilt. Oder sehe ich das Falsch?

Zitat von Demirug

Mehr worker threads als cores ist Gift. Das fressen dir die Contextwechsel die Leistung weg.

bei einem präemtiven OS wird nach dem ablauf einer zeitscheibe eh immer ein contextwechsel durchgeführt, dieser ist beim wechsel zwischen mehreren threads eines prozesses auch noch vergleichsweise günstig, da glaub ich kaum, dass diese soviel kosten würden. mit einem SC wäre man ja sonst komplett aufgeschmissen