AMDs "Excavator" - 4. Modul Generation Spekulation

Dann halte ich mich mal besser wieder etwas zurück. ;)
Ich für meinen Teil gehe allerdings davon aus das es relativ egal ist wie gut Excavator wird da er letztendlich doch wieder an der mangelden Software Unterstützung verhungert und damit nur noch mehr Leistung ungenutzt brach liegt. Zumindest haben sie dadurch ein gewisses langzeitnutzungs Potential da mit der Zeit (hoffentlich) immer mehr Leistung nutzbar wird.
 
Ich für meinen Teil gehe allerdings davon aus das es relativ egal ist wie gut Excavator wird da er letztendlich doch wieder an der mangelden Software Unterstützung verhungert und damit nur noch mehr Leistung ungenutzt brach liegt.

wird in jedem fall zutreffen. ob als apu, oder als 4 moduler.
 
Ich kann eurer Argumentation nicht ganz folgen. Steamroller hat eine gesteigerte IPC und die kommt beim User in Form von Kaveri sehr wohl an (dass das meiste davon vom geringeren Takt wieder aufgefressen wird ist eine andere Sache). Ist die APU immer 100% ausgelastet? Nein. Aber das muss sie auch nicht.
 
also ich benötige eine stärkere grafik karte als eine apu hat. ich benötige mehr cpu power da meine cpu bei world of tanks und supreme commander immer auf 100% ist.

die mehr ipc sind im schnitt 7%. in alten anwendungen die nur 1 oder 2 threads nutzen oft gegen 0%. dazu kommt das sie sich nicht so hoch takten lassen wie ein Vishera. dazu kommt das sie nur als 2 moduler verfügbar sind, was sie in modernen games wie battlefield wieder zu langsam werden lässt. battlefield 4 nutzt auch einen FX9590 sehr gut aus.

fazit: eine apu hat kaum nutzen für einen gamer wie mich. auf diese mantle api will ich mich nicht verlassen, da eh die meisten spiele nicht davon profitieren.
das geringere takt potential einer apu stört zusätzlich sehr. mein FX4100 geht mit luft locker auf 5 ghz. jeder piledriver 2 moduler packt das ebenfalls.
ein excavator der overall 10% mehr ipc bringt, wäre cool, aber nicht wenn er wieder nur als apu kommt was sein taktpotential einschränkt bzw keine 4 module auf einem die zulässt.
 
@Starcraftfreak
Jein......die Steamroller Kerne gibt es bisher nur für den Kaveri und dessen Taktfrequenz fällt geringer als die des Richland aus, wodurch die Mehrleistung letztendlich mehr oder weniger wieder aufgefressen wird. Die Stärke des Kaveris liegt allerdings recht eindeutig im kaum genutzten GPGPU Bereich. Beim Rendern von Spielen verhungert die GPU in der max. Ausbaustufe wiederum an der verfügbaren Speicherbandbreite.

@Night<eye>
Wie bekommst du die CPU Auslastung bei Supreme Commander auf 100%? Mehr als 1-2 Kerne werden bei mir bei Supreme Commander 2 nicht genutzt, allerdings spiele ich nur gegen Bots. oO
 
das ist ja das problem. supreme commander unterstützt kein multi core. dadurch hängt das spiel bei amd systemen recht schnell. ich spiele supreme commander 1. das ist noch hardwarelastiger als supreme commander 2. aber selbst supreme commander 2 hängt gegen brutale ki gegner auf großen maps nach ner stunde extrem.
 
Genau das meinte ich. Das sind dann keine 100% sondern bei nem 4 Kerner lediglich etwas um die 25% CPU Auslastung....
Die CPU kann mehr leisten als das Spiel selbst nutzen kann.
 
schon klar. der eine kern der wichtig ist ist zu 100% ausgelastet. genau wie in world of tanks. zz packt keine amd cpu das game auf ultra bei konstanten 60 fps zu halten.
 
wenn er wieder nur als apu kommt was sein taktpotential einschränkt
Jeeiiin, so kann man das nicht formulieren (bzw. kann man natürlich, sieht man ja, ist aber unzutreffend). Die Anwesenheit der GPU auf dem Die ist für die Taktfähigkeit völlig unerheblich. Evtl. hilft es sogar, auf dem Die ungenutzte, kalte Bereiche zu haben, die die Hitze aufnehmen und etwas besser verteilen, so daß die Kühlung besser ist. Das Problem bei Kaveri ist die Fertigung, die nicht auf "taktfreudig" getrimmt ist, sondern nur auf "reicht für den Nominaltakt". Und weil der Grund für diese Fertigung die GPU ist, kann man die zitierte Aussage eben nicht einfach klar mit "Falsch" abbügeln. Aber richtig ist sie auch nicht.
 
4 Ghz == "nicht taktfreudig"? Ja ne, is klar. Und weniger als 250 PS ist "untermotorisiert", weniger als 80qm dann "Kleinraumwohnung".
Ich werd wohl wirklich langsam alt wenn ich mich über solche Perversionen aufrege. ;-)
 
@Night<eye>
Selbst die Intel Fraktion dürfte dabei ohne Übertaktung ihre Probleme haben, was genau genommen ziemlich affig ist wenn man bedenkt wie alt das Spiel ist.
Bei Smishkder max. Anzahl an Spielern auf den großen Maps bricht sie beim mir beim max. Ausbau der Armeen zumindest so stark ein das das sich erst die Spielzeit verlangsamt und dann sichtbar ins Stocken gerät.
 
Das Problem bei Kaveri ist die Fertigung, die nicht auf "taktfreudig" getrimmt ist, sondern nur auf "reicht für den Nominaltakt".

Das wurde behauptet. In den publizierten Benchmarks hat Kaveri immer gut Luft nach oben. Bei mir läuft Kaveri bei mittlerer Lüfterdrehzahl mit 4,2 GHz Basistakt. Mit Trinity ging das nicht. Da bekomme ich nach 2 Minuten Videoencoding die Notabschaltung.
 
1. Warum geht es hier immer so schnell ins Off-Topic und
2. Seit wann sind solche 2 (schlecht programmierten) Spiele eine Referenz? Die sind neu genug um Multicore Support zu haben und WoT wird ja immer noch Programmiert. Ist also nicht so, dass es wie Surpreme Commander nicht mehr weiter Entwickelt wird. Ist jetzt halt die Frage, ob man AMD die Schuld gibt, dass sie eine schlechtere Singlethread Leistung haben oder doch den Entwicklern solcher Software, die im Jahr 2011-2014 (bzw. 2007 für SC) nicht wissen, was mehrere Threads sind.
Warum macht man nicht solchen Firmen die Hölle heiß, dass sie mal die Grundlagen der Informatik lernen (die von heute nicht von 1980) und mal mit neuen Techniken auseinandersetzen sollen. Mal von einem Quadcore ausgegangen und eine Milchmädchenrechnung aufgestellt, könnten solche Spiele 4 mal so viele FPS liefern.

PS: nur mal so als Info: in der Industrie darf die Software-Abteilung oft die Fehler der Hardware ausbügeln.
 
Zuletzt bearbeitet:
Hilft halt nicht wenn man auf "schlechte" Software angewiesen ist sonst wäre X86 mit Alpha auch einfach tot gewesen. Das die Produkte zum Markt passen müssen oder man den Markt anpassen muss ist kein Geheimnis.
Komisch auch das viele RTS schlecht den Grundlagen der Informatik entsprechen die haben nur unfähige Idioten scheinbar oder so ganz trivial ist es doch nicht.
 
@unl34shed
AMD kann man für die mangelhafte Software wohl kaum einen Vorwurf machen und wirklich Druck ausüben könnte aufgrund der Marktanteile höchstens Intel.
Das man AMD hier wohl kaum einen Vorwurf machen kann sieht man bereits am Alter der Spiele die noch heute durch den mangelhaften oder gar nicht existenten Multicore Support so stark limitiert werden. Die Prozessoren von damals waren schließlich entsprechend langsamer.
Für die Qualität der Programme sind immernoch die Software Schmieden selbst verantwortlich.

@Stryki
Oder die BWLer bekommen einfach nur mehr Gehör als für das Spiel gut ist.
Ich erinnere mich noch gut an diverse Sprüche das es doch soooo unmöglich ist die Prozessoren bei Spielen besser auszulasten und oh Wunder.....auf einmal ging es dann doch und das Spielchen wiederholte sich mit jeder Stufe in der die Prozessoren mehr Kerne bekamen. Hier geht es wohl eher um Kosten für neue Entwicklungswerkzeuge und Weiterbildungsmaßnamen anstatt um wirkliche technische Gründe. Wozu investieren wenn es das Alte für die meisten Kunden doch auch noch reicht? Das sieht man ja auch bei der Mantle Geschichte.

Ich bin allerdings gespannt wie sich der APU Ansatz bei Spielen z.B. für Physikberechnungen entwickeln kann. Ich kann mir jedenfalls gut vorstellen das diverse Berechnungen an die GPU weitergereicht werden könnten und hier der gemeinsame Speicherbereich seit dem Kaveri vom Vorteil wäre und hoffe deshalb das Intel auch mit aufspringt denn sonst bewegt sich hier meiner Meinung nach nichts, es sei denn das AMD etwas entsprechendes als Demo entwickelt/entwickeln läßt.
 
Zuletzt bearbeitet:
Ich bin allerdings gespannt wie sich der APU Ansatz bei Spielen z.B. für Physikberechnungen entwickeln kann. Ich kann mir jedenfalls gut vorstellen das diverse Berechnungen an die GPU weitergereicht werden könnten und hier der gemeinsame Speicherbereich seit dem Kaveri vom Vorteil wäre und hoffe deshalb das Intel auch mit aufspringt denn sonst bewegt sich hier meiner Meinung nach nichts, es sei denn das AMD etwas entsprechendes als Demo entwickelt/entwickeln läßt.

Ja, die Entwicklung bei den Spieleengines geht eindeutig in die Richtung Physikeffekte wie Partikelsimulation oder von mir aus auch die Haare von Lara.
Für AMD eine Steilvorlage, wenn sie mit den Konsolen im Rücken da nichts auf die Beine bekommen, kann man ihnen auch nicht mehr helfen.
Ein Antwort auf die Frage, ob ihnen das gelungen ist, kann man aber erst in 2 Jahren geben.
 
Nichts neues dabei...
 
Beruht alles auf der selben China Quelle, die ich vor einer Woche gepostet habe und der Randnotiz von Keller im Interview. Dazu dann noch etwas Phantasie und fertig ist die News ...
 
Hier mal ein Artikel, der einige der bisherigen Spekulationen lustig durcheinander wirft:

http://news.softpedia.com/news/K7-K8-Inventor-Back-at-AMD-Prepares-Excavator-for-2015-441617.shtml

For one thing, AVX 3.2 512-bit extensions, among other things, will be supported. Also, we may see up to 16 cores in a single processor.

In fact, 16-core units could surface as early as this year (2014), once the Steamroller generation of Bulldozer comes forth. Sadly, software still isn't coded for so many different threads, so most of the potential computing power will go to waste, at least at first.

Odds are higher that AMD will try to play it safe and promote the new Bulldozer cores as part of APUs. Steamroller gets Carrizo and Toronto (will come out this year), so Excavator will power the successors of those units.

Die grobe Aussage des Artikels lautet, dass Jim Keller auch die Bulldozer Architektur kräftig überarbeiten wird, so ganz nebenbei.
 
Zuletzt bearbeitet:
Also wenn man das mal wirken lässt, könnte es sein dass AMD mit dieser Methodik die Fesselung an x86 gewaltig aufgeweicht hat. Nicht nur kann man beliebige ISA hinzufügen und Hardware verwenden die keine Altlasten benötigt, man könnte im Prinzip auch x86 durch ARM ISA ersetzen oder durch was völlig neues, ohne dass Programmierer viel an der Software ändern müssten, vermute ich zumindest.
Interessant, diese Spekulation von mir letztes Jahr scheint zuzutreffen, wie die Entwicklung des K12 zeigt. Auch werden ARM-Kernen wohl in Carrizo zum Einsatz kommen - für jeden x86 Core ein ARM Core - um Code zu sichten auf Ausführbarkeit auf GPU oder x86, also auch schon existierender Code.
http://www.gamestar.de/hardware/news/prozessoren/3055961/amd_prozessor_architektur_cheetah.html

Auch wenn da viel durchaeinander gewürfelt wird bei den Codenamen....
 
Müssten die ARMs nicht deutlich schneller sein als der Rest der CPU um den Coder vernünftig zu analysieren? Weil wenn die nur ein ADD sehen, wissen die ja auch nicht, ob das jetzt besser auf der CPU oder GPU ausgeführt wird (also vermutlich auf der CPU, weil schneller getaktet). Die müssten doch irgendwoher erfahren, ob der Code Schleifen enthält, die sich parallelisieren lassen. Wenn die das erst im Nachhinein erfahren, wäre es ja irgendwie Sinnbefreit, oder?
 
Ganz ehrlich, das liest sich für mich eher wie ein Aprilscherz. Wie genau soll das denn effizient funktionieren? Bis die dekodierten Instruktionen samt Operanden vom x86 an den ARM Kern transferiert und dort analysiert wurden, für eine eventuelle Auslagerung auf die iGPU, hätte man die Instruktion auch schon längst im x86 Kern verarbeiten können. Eine Verarbeitung auf der iGPU macht doch eigentlich nur bei vielen zeitnahen Vektorinstruktionen Sinn. Einzelne Vektorinstruktionen, siehe SSE oder AVX, sollte die FPU des x86 Kerns schnell und effizient genug abarbeiten können. Mehrere Vektorinstruktionen müssten eigentlich für eine effiziente Abarbeitung auf der iGPU von der Software oder einem kerninternen Scheduler entsprechend aufbereitet werden.
 
Eigentlich nichts anderes als ein Prefetcher macht, nur eben hier auf einer vorgeschalteten Hardware, die ja eigentlich nichts anderes machen muss als den Code in den Speicher zu laden und zu entscheiden ob der Pointer auf die CPU oder die GPU geschaltet wird. Dank hUMA müssen die Daten nicht erst die schlußendliche Verarbeitungseinheit durchlaufen um in den Arbeitsspeicher zu gelangen, sondern können dort schon bereit stehen.
 
Zurück
Oben Unten