News Intel Nova Lake aus N2P-Fertigung: 8P+16E-Kerne samt 144 MB L3-Cache werden ~150 mm² groß

Piktogramm schrieb:
Es ist also prinzipiell kaum ein Nachteil die Aufgaben auf noch langsamere Kerne zu verteilen.
Dafür gibt es Nachteile E-Cores mit solchen Aufgaben zu belasten. Die Kerne wären belegt und sollte es etwas zu berechnen geben, müsste ein teurer Kontextwechsel erfolgen.
Die Theorie verstehe ich. In meiner Vorstellung sollten bei 12 bis 38 E-Kernen aber immer ein paar übrig sein, die den Kleinkram berechnen können, ohne dass das System die "snappy-ness" in den wichtigen Prozessen/Threads verliert.

Allgemein gefällt mir das ge-fach-simple in diesem Thread sehr gut. :bussi:
 
Piktogramm schrieb:
Bei Darkmont und den dreigeteilten Decodern stelle ich mir SMT auch schwer vor und die Kürzungen die Intel zuletzt bei der Softwareentwicklung betrieben hat passt nicht zum Aufwand der getrieben werden muss um SMT über P&E-Cores gescheit zu verwalten.
Lip Bu Tan sagte ja, die Zukünftigen Architekturen werden wieder Simpler.
Dazu wieder SMT.
Noch klarer kann man die Abkehr von Royal Core (Also P + E + Low Power) Kernen nicht machen.
 
Cr4y schrieb:
Die Theorie verstehe ich. In meiner Vorstellung sollten bei 12 bis 38 E-Kernen aber immer ein paar übrig sein, die den Kleinkram berechnen können, ohne dass das System die "snappy-ness" in den wichtigen Prozessen/Threads verliert.
Ich formuliere es mal so: Fast jedes IO hat einen memcpy(3) in den Userspace zur Folge, und wenn es klappt das der dazugehörige Prozess auf dem selben Core liegt wie der Kernelthread der das kopiert hat, liegen die Daten mit hoher Wahrscheinlichkeit schon in den richtigen Caches.
 
@Cr4y
Das für 0815 Heimanwender die Prozessoren so fett werden, dass da Zweifel sowieso zu viel CPU-Threads zur Verfügung stehen.. sei es drum :)
Die Option ein bis zwei CPU-Dies schlafen zu legen und nur die LPE-Cores aktiv zu halten finde ich dennoch nicht verkehrt.


@Nighteye
Wer kennt es nicht, die simplere werdenden Architekturen :)
Weil Intel mit Ihren Pcores mit 8fach Decode, 12fach µOpcache nicht schon ultra breite, komplexe Prozessoren bauen, die dennoch langsamer sind als Apples P-Designs. Als ob sich der Laden leisten könnte simplere Architekturen anzustreben.
Zudem die E-Cores mit ihren 3x3 Decodern haben im Vergleich zu den P-Cores die simpleren Decoder. Das Clustern der kleinen Decoder ist schon recht elegant. Da SMT einzubinden wird schwieriger und da gescheites Scheduling zu betreiben ebenso.
 
So wie es aussieht, wird Nova Lake das nächste Desaster im Desktop und wegen fehlendem HT auch im Server Bereich.
Jetzt nicht Mal wegen eventuell fehlender Leistung,sondern weil abzusehen ist,das die CPU Gen auf dem zugehörigen Chipsatz auch nur max 2 Jahre hält.
Lip Bu Tan hat ja nun andere Prioritäten gesetzt.Aber durch seine Aussagen, sind kundige Anwender schon gewarnt.
Zusammen mit der Speicherkriese kann da nichts gutes bei rauskommen.
Da kann sich AMD mit AM 5 mal locker zurücklehnen. Neue CPUs wird man da eher los, wenn Kunden zur Zeit schon laufende Systeme haben.
Kunden die Nova Lake nutzen wollen, müssen sich neben der CPU wieder neue Mainboards beschaffen und vermutlich kommt man um hochgetakteten DDR5 RAM auch nicht herum, will man von der Rechenleistung profitieren.
Es wird wohl noch schlimmer laufen als beim Core Ultra 200.
Gute CPUs ,die sich in den Regalen langweilen, auch weil sie 1 Jahr zu spät kommen.
 
Artanis90 schrieb:
@Volker Volker kannst du eigentlich mal erklären warum DDR6 für NVL-S jetzt nicht kommt? Es hieß doch in den Gerüchten es würde so kommen und falls nicht wäre das ein erstes Flop-Signal. Und was ist mit PCIe6?

Davon hört man auch nichts, anscheinend kommt es nicht und es kommt nur DDR5+PCIe5, wie Arrow-Lake.

DDR5: JEDEC verabschiedet finale Spezifikationen

https://www.computerbase.de/news/arbeitsspeicher/ddr5-spezifikationen-jedec-4800-6400-mhz.72847/

Im günstigsten Fall sollen erste Kits mit 5.600 MHz noch gegen Ende dieses Jahres ausgeliefert werden. Mit DDR5-6400 und 64 GB beziehungsweise 128 GB je Modul ist laut der Asgard-Roadmap frühestens 2022 zu rechnen,
https://www.computerbase.de/news/ar...-128-gb-und-6-400-mhz-fruehestens-2022.76349/



Schau mal: Hier lagen ca. 1,5 Jahre dazwischen und DDR6 wurde noch nicht final spezifiziert.

ChatGPT sagt: Die finale Spezifikation von DDR6 wird sehr wahrscheinlich im Jahr 2025 veröffentlicht, mit starkem Fokus auf die zweite Jahreshälfte, bevor Hardwarehersteller Tests und Implementierungen in 2026 durchführen.....

Es bleibt spannend, weil weiterhin unklar ist was nach Zen6 und Nova Lake passiert.
 
Piktogramm schrieb:
Bei Darkmont und den dreigeteilten Decodern stelle ich mir SMT auch schwer vor

Ich nicht. Bei 2-fach SMT einen Thread mit zwei decodern laufen lassen und einen mit einem. Wer gerade zwei bekommt, kann man dann von so Dingen abhaengen lassen wie der Anzahl von Befehlen dieses Threads im Reorder buffer (wer weniger Befehle im ROB hat, muss aufholen und bekommt mehr Decoder).

Aber der Teufel steckt bei sowas sicher im Detail. Es wird schon einen Grund haben, warum die Apple Mikroarchitekturen kein SMT haben; und vermutlich hat Intel SMT bei den P-Cores abgeschafft, um beim IPC wieder aufholen zu koennen. Bisher hat das aber noch nicht funktioniert.
 
@mae
Also drei Decoder dynamisch umverteilen anhand der Auswertung der getaggten CPU-Threads im Allocate/Rename würde ich als "schwer" bezeichnen.
 
stefan92x schrieb:
Du kennst also schon Veröffentlichungstermine der beiden Architekturen, dass du das so absolut sagen kannst?
Du hast meine Aussage falsch verstanden. Laut dieser News hier, kommen Intels High-End-modelle zuerst und dazu gehören die big LLC-CPUs. Daher die Aussage, dass bei Intel die big LLC-CPUs zuerst kommen, also bezogen auf Intels Portfolio. Bei AMD wissen wir, dass X3D-CPUs aufgrund des höheren Packagingaufwandes eben nicht zuerst kommen, bezogen auf AMDs Portfolio. Wenn AMD also in gewohnter Manier 2026 die normalen CPUs bringt und erst (viel) später die X3D-CPUs also vielleicht erst 2027, dann wäre Intel mit big LLC zuerst dran obwohl AMD die Zen 6 Non-X3D-CPUs vielleicht sogar noch vor Intel Nova Lake auf den Markt bringen könnte...
 
  • Gefällt mir
Reaktionen: stefan92x
Piktogramm schrieb:
@mae
Also drei Decoder dynamisch umverteilen anhand der Auswertung der getaggten CPU-Threads im Allocate/Rename würde ich als "schwer" bezeichnen.

Wenn das zu schwer sein sollte, koennen sie den dritten Decoder abwechselnd den einzelnen Threads zuweisen, und das Umschalten an geeigneter Stelle machen (z.B. wenn der branch predictor vorhersagt, dass ein Sprung durchgefuehrt wird).

Was auch noch ginge: 3 Threads pro Core unterstuetzten; aber wenn nur zwei davon verwendet werden, wird man trotzdem mit dem dritten Decoder was sinnvolles machen wollen.

Jedenfalls erscheint mir als schwierige Sache, wie man drei Decoder auf einem Thread arbeiten lassen kann, und das haben sie geloest (anders als offenbar (noch) die Leute bei AMD fuer Zen 5 mit zwei Decodern). Wenn man das geschafft hat, erscheint es mir nicht so schwer, weniger als drei Decoder auf einem Thread von zweien arbeiten zu lassen, und auch das Einsetzen eines Decoders fuer verschiedene Threads ist nicht schwer, die Decoder muessen sowieso immer wieder andere Speicherbereiche decodieren.
 
foofoobar schrieb:
Ich lehne mich mal aus dem Fenster und behaupte das man die Instruktionen nicht taggen braucht sondern nur die Daten.

Hier was zu den Dekodern von Zen5:

https://chipsandcheese.com/p/a-video-interview-with-mike-clark-chief-architect-of-zen-at-amd
Wie willst du mit überschaubarem Aufwand Daten taggen bei einem µProzessor?

Gerade beim Gespräch welches du verlinkt hast, wird davon gesprochen, dass µOps getaggt werden über div. Queues.

Edit: Und dieses Interview. Das klingt so, als hätte AMD nicht geplant die beiden 4fach Decoder jeweils nur einem CPU-Thread zu spendieren. Entweder eine Kommunikationsupsi, oder aber es gab den Plan wirklich die Decoder dynamisch zuzuordnen und es hat dann praktisch doch nicht geklappt.
mae schrieb:
Wenn das zu schwer sein sollte, koennen sie den dritten Decoder abwechselnd den einzelnen Threads zuweisen, und das Umschalten an geeigneter Stelle machen (z.B. wenn der branch predictor vorhersagt, dass ein Sprung durchgefuehrt wird).
Die Decoder dynamisch umwidmen bedingt dann auch, dass die jeweils folgenden µOp Queues irgendwie damit umgehen können müssen. Kompetetive Queues sind aufwendig, das dreifach zu implementieren wäre echt hart und widerspricht der hier im Thread getätigten Aussage, dass die Designs simpler werden sollen absolut. Statisch partitionierte Queues sind simpler aber bedingen für jeden CPU-Thread das Schrumpfen um die Hälfte mit entsprechenden Verlust. Bei der aktuellen Größe der µOpQueues würde eine statische Halbierung zudem zu sehr kleinen Queues je CPU-Thread führen.

Auch bei Branches jeweils fröhlich die Decoder umzuwidmen. Der Trick ist ja eben, dass bei den Branches spekulativ weitergemacht wird. SMT wird ja dadurch witzig, dass bei einer Fehlvorhersage auf einem CPU-Thread bedingt Queues und Pipelines invalidiert werden müssen und bis die richtigen µOps aus dem Decoder laufen der zwiete CPU-Thread die Ressourcen vom Prozessor voll nutzen kann. Dazu braucht es aber auch ne µOpQueue samt breitem Renamer, der das Backend entsprechend füttern kann.

mae schrieb:
Was auch noch ginge: 3 Threads pro Core unterstuetzten; aber wenn nur zwei davon verwendet werden, wird man trotzdem mit dem dritten Decoder was sinnvolles machen wollen.
CPU-Threads mit einem 3fach Decoder ohne µOpCache.. Lass mal stecken. Das ist so ARM Cortex A75 Niveau und soooo viel Zeit um auf Computer zu warten habe ich nicht. :)
Da wäre es Imho sinnvoller Inspiration bei Zen5 zu suchen. 2fach SMT mit einer Decoderbreite von 4 wobei jeder Decoder eine eigene Queue und einen eigenen leinen Op-ROM bekommt. Dafür aber ohne µOpCache.
Imho wäre das aber immer noch weniger Elegant, als die jetzigen 3x3 Decoder von Skymont.

mae schrieb:
Jedenfalls erscheint mir als schwierige Sache, wie man drei Decoder auf einem Thread arbeiten lassen kann, und das haben sie geloest (anders als offenbar (noch) die Leute bei AMD fuer Zen 5 mit zwei Decodern). Wenn man das geschafft hat, erscheint es mir nicht so schwer, weniger als drei Decoder auf einem Thread von zweien arbeiten zu lassen, und auch das Einsetzen eines Decoders fuer verschiedene Threads ist nicht schwer, die Decoder muessen sowieso immer wieder andere Speicherbereiche decodieren.
Mir fehlt der Glaube beim "nicht so schwer". Decode der E-Cores bei Intel ist derzeit echt verdammt elegant. Eine Decode Stufe, die bis zu 9 µOps durchschleust, recht effizient arbeitet ohne µOp-Cache und minimalen µOp-Queues. Dabei ist das Ganze mächtig genug, dass falsch vorhergesagte Sprünge halbwegs verkraftbar sind, solang sich das richtige Target im L2 befindet.
Mit SMT braucht die Lösung mehr Logik, dickere Queues.
 
Syrato schrieb:
Wenn jemand nur LoL spielt, dann reichen 8 Kerne auch die nächsten Jahre.
Wenn jemand nur LoL spielt, hat man mit 8 Kernen ZU VIEL für die CPU bezahlt.
Bloß weil es vereinzelt Spiele gibt, die mit mehr als 8 Kernen etwas anfangen können, heißt das noch lange nicht, dass das allgemeingültig wird. Selbst für Spiele wie Anno 1800 muss man nicht gleich mit mehr als 8 Kernen, oder überhaupt 8 Kernen kommen. Ja, ich weiß, dass riesige fortgeschrittene Maps die CPU stark belasten, aber nicht jeder ist in dieser Blase gefangen, nur mit max. Details spielen zu müssen.

Mediendesigner schrieb:
so ein quatsch, selbst cs2 profitiert von mehr kernen aber ob es reicht ist ja eh ansichtssache.
Stimmt, CS2 kann von mehr als 2 Kernen durchaus profitieren. Du darfst gerne Benchmarks posten, mir fällt es schwer in der Hinsicht vernünftige Daten zu finden.
Was durchaus passieren kann, ist der Irrtum z.B. eine Mehrleistung zwischen einem 7700X und einem 7950X als Vorteil durch die zusätzlichen Kerne zu werten, während es dann eher an der höheren Taktfrequenz durch das bessere Binning resultiert. (Zumindest für Spiele, die stark vom Takt profitieren)

Dedenne1987 schrieb:
Das könnte Ende 27 anders aussehen. Ich denke mindestens MS haut da eine neue Konsole raus. Und ich denke „nur“ 8 Kerne wird das Teil nicht haben.
Nach den ganzen Verschiebungen unterschiedlichster Hardware wegen der RAMpocalypse würde es mich überraschen, eine neue Xbox Konsole schon Ende 27 kommen würde, selbst wenn sich die Lage in 2027H2 einigermaßen stabilisiert.
Aber egal, wann es herauskommt, wenn diese Konsole mehr als 8 Kerne beinhaltet, wird das eine geringe Rolle spielen, sollte diese Konsole laut den Gerüchten vielmehr ein PC als eine reine Konsole darstellen und dann folgen die Regeln für PC-Spieleentwicklung. In dieser Hinsicht geht Valve den intelligenteren Weg. Ihre Steam Machine ist kein Leistungsknaller, aber diese bietet ausreichend Leistung für jene, die sich keine Gedanken um das ganze PC-Drumherum machen, aber einfach Spiele genießen möchten und nicht zu viel dafür zahlen wollen (gut, der letzte Punkt ist gerade problematisch, aber Microslop wird davon auch nächstes Jahr (falls nächstes Jahr) betroffen sein, aufgrund der stärkeren Hardware wahrscheinlich noch stärker).
Im Vergleich dazu gehe ich jede Wette ein, dass die PS6 niemals mehr als 8 Kerne haben wird. Wozu auch? Die jetzige kann nur 6 der 8 Kerne für Spiele einsetzen, der Rest ist für das OS. Viel intelligenter wäre es, wenn 2-4 LPE-Kerne (je nachdem, ob SMT ja oder nein) auf den Chip kommen, welche sich um das OS kümmern. Ein getrennter RAM für das OS gibt es ja schon seit der PS4 Pro für die Pro Modelle, eigene LPE-Kerne sind nur der logische nächste Schritt.

Ripcord schrieb:
Läuft das OS dann allgemein stets nur auf einem einzigen Kern?
Sollten sogar zwei sein, was immens klingt.

scryed schrieb:
Am PC will ein größeres os mit betrieben werden hinzu kommen diverse Programme im Hintergrund ... Auch gibt es Leute die streamen oder ihre Sachen aufzeichnen
Und wo ist das Problem mit 8C-CPUs? Scheduling gibt es nicht umsonst und CPUs werden gerade bei Spielen nicht komplett in Anspruch genommen. Man muss die Spiele selbst heute suchen, die 8 Kerne so stark beanspruchen, dass andere Dinge davon negativ beeinflusst werden.
Diese Sache mit dem größeren OS ist übrigens irrelevant. Es ging nie darum, wie groß das OS ist, sondern wie es mit den Ressourcen umgeht und für Programme alles einteilt. Es spielt auch eine Rolle, wie sicher man sein System haben will/muss
Und zuletzt zum Streamen/Aufzeichnen, ich weiß ja nicht, ob du eine gewisse Ahnung davon hast, aber sofern man keine Benchmarks aufzeichnen will, wird man IMMER auf 60 fps limitieren, oder hast du auf irgendwelchen Streaming-Seiten mehr als 60 Hz Videos gesehen? Für das eigene Spielgefühl wird man vielleicht auf 60er Vielfachen limitieren (also 120, 180, 240 Hz) und schauen, dass es keine großen Ausreißer gibt, aber über diesen Punkt weiß ich nichts direkt.

scryed schrieb:
Mehr Kerne kann dazu führen daß die CPU Kühler bleibt
Das ist eine viel zu stark vereinfachte Darstellung. Ein einzelner Faktor bestimmt das Gesamtergebnis nicht so stark, wie du es hier darstellen willst.
Es stimmt ja so weit, dass mehr Kerne weniger hoch takten müssen, daher deren Vcore niedriger ausfällt und somit weniger Abwärme produzieren. Gilt ja auch für Anwendungen wie Spielen, wo die Auslastung niedriger ist, aber durch das Scheduling die Last zwischen Kernen springt, damit keine hohen Hotspots entstehen.
Was du jedoch ignorierst, dass es letzten Endes immer davon abhängt, wie diese CPU designt ist, auf welchen Verbrauch/TDP ist es eingestellt? Es bringt für die Kühlung rein gar nichts, wenn man die CPU mit durchgehend 250 W grillt. Ob mit 16 oder 32 Kernen, es bleiben 250 W. Bei leicht niedrigeren Lasten kann man wieder mit Hotspots argumentieren, aber hier spielt auch die Architektur eine große Rolle. Man sehe sich nur Intels Core-Aufteilung seit Arrow Lake an. Zwischen den P-Cores liegen die E-Cores, damit sich die stärkere Abwärme der ersteren nicht zu sehr sammelt.
Wenn du lieber doppelt so viele Kerne haben möchtest, damit die Last ständig umverteilt wird und somit weniger Hotspots entstehen, ist das ja schön und gut, ist aber wiederum nur ein Thema für jene Enthusiasten, die keine Kompromisse eingehen wollen und das empfinde ich persönlich so langweilig.

Cr4y schrieb:
Ich glaube, dass LPE-Cores im Desktop überflüssig sind.
Das kann man ja so sehen, aber es sollte dennoch nicht egal sein, ob ein Gesamtsystem 20, 60 oder gar 100 W verbraucht. Das Vorhandensein von LPE-Cores wird diesen Unterschied zwar nicht begünstigen, aber auch LPE-Cores sind ein Teil des Ganzen.
Viel schwerwiegender ist ein anderer Punkt. Wieso sollten sie die LPE-Cores entfernen, wenn sie so einen CPU-Tile auch für mobile Geräte anbieten wollen und das kann ja auch für den größten Tile zählen und dort sind LPE-Cores durchaus relevant. Dann müsste Intel einen separaten Desktop-Tile entwickeln. Ob das so Sinn ergibt, muss so oder so Intel zeigen.

Nighteye schrieb:
Meine Partnerin zockt auch noch im gleichen Raum wie ich. Sind dann 200W Menschen.
Auch hier kommen mehr Faktoren zusammen, als nur die Abwärme von Geräten und Lebewesen. Ich weiß ja nicht, wie eure Wohnung ist, aber je nach Lage (Süd - Nord, Dachgeschosswohnung) und Architektur/Bau (Altbau oder abgedichtet) habt ihr vielleicht einfach Glück und die richtigen Bedingungen. Schon das Lüften (eh kloar!) kann diese von dir genannten Faktoren mehr als ausgleichen, wenn die Bedingungen draußen passen.

Nighteye schrieb:
Schon mein Staubsauger verbraucht 700W.
Und? Gibt der 700 W Abwärme von sich? Ich glaube nicht Tim.

Nighteye schrieb:
Noch klarer kann man die Abkehr von Royal Core (Also P + E + Low Power) Kernen nicht machen.
Gar nichts ist klar. Ich weiß ja nicht, was sich Tan mit diesen Worten eigentlich gedacht hat, aber egal wie man zu der jetzigen Architektur steht, man redet NICHT die jetzigen und erst recht kommende Produkte im Vorfeld schlecht. Die müssen auch Nova Lake gut verkaufen wollen. Ich weiß auch nicht, wo sein Problem ist. Das Fehlen von HT ist primär im Server-Segment ein Problem, aber Panther Lake wurde positiv aufgenommen. Hat sich jemand über fehlendes HT beschwert?
Arrow Lake auf dem Desktop ist nicht populär, aber das liegt vorwiegend an der schlechten Spieleleistung. Anwendungen laufen darauf ganz ordentlich, trotz fehlendem HT und das ist für Spiele auch nicht gerade förderlich. Apple (oder auch Qualcomm) braucht auch kein SMT/HT, um Leistung zu liefern. AMD Ansatz passt, weil ihr SMT gut funktioniert und sie diese Architektur auch für Server kombiniert verwenden können. Wenn Intel wegen Servern HT wiederbringt, ist das ja schön und gut, aber dann sollte man damit erst herausrücken, wenn Nova Lake langsam weniger relevant wird und nicht, wenn wir noch nicht mal wissen, wie diese Architektur aussehen wird!
Und noch weniger bedeutet das, dass man sich von der hierarchischen Aufteilung verabschiedet.
 
Deinorius schrieb:
Wenn jemand nur LoL spielt, hat man mit 8 Kernen ZU VIEL für die CPU bezahlt.
Ich habe nur geschrieben, DANN REICHEN 8 KERNE AUCH DIE NÄCHSTEN JAHRE!, nicht mehr und nicht weniger!
Zur info, 2008 unterstütze LoL 1 Kern, 2012 2 Kerne und seit ~2019 bis 4 Kerne.

Und zu Anno 1800, die CPU Auslastung hat nichts mit den Details der Grafik zu tun!, aber wenn man 15 Millionen Einwohner hat, merkt man einen Unterschied!

Ob P, E, low Power, HT, ARM, Windows, Linux, Wasse- oder Luftkühlung, für jedes Szenario gibt es bessere und schlechtere Möglichkeiten.

Ich drehe einem Verwandten und Bekannten auch kein Gaming PC mit Wasserkühlung, Linux (z.B. Nix OS) an und sage, ich helfe dir bei allem, immer... 🙃.

Zuverlässigkeit & Bedienbarkeit sind in meiner Welt Trumpf!
Und bei der jetzigen Hardwarelage ist die CPU das kleinere Übel. Wenns Geld auf Kante genäht ist, wartet man halt länger mit der Anschaffung!
 
Deinorius schrieb:
Und? Gibt der 700 W Abwärme von sich? Ich glaube nicht Tim.
Die elektrische Leistung die ein Staubsauger aufnimmt wird kurzfristig nahezu komplett in Wärme umgesetzt. Da lässt die Physik nicht mit sich diskutieren. Viele Staubsauger nutzen nur nicht annähernd die Leistung, die auf dem Typenschild steht.

Deinorius schrieb:
Im Vergleich dazu gehe ich jede Wette ein, dass die PS6 niemals mehr als 8 Kerne haben wird. Wozu auch? Die jetzige kann nur 6 der 8 Kerne für Spiele einsetzen, der Rest ist für das OS. Viel intelligenter wäre es, wenn 2-4 LPE-Kerne (je nachdem, ob SMT ja oder nein) auf den Chip kommen, welche sich um das OS kümmern. Ein getrennter RAM für das OS gibt es ja schon seit der PS4 Pro für die Pro Modelle, eigene LPE-Kerne sind nur der logische nächste Schritt.
Die PS4 hat zwar einen ARM Co-Prozessor mit 256MB Ram, aus dem ein eigenes Betriebssystem läuft, in dessem Kontext läuft aber kein Spiel. Weder PS4 noch PS5 haben eigenen RAM für das OS, in dessen Kontext die Spiele laufen. Wenn das OS Daten in den Speicher lädt oder Daten zwischen CPU und GPU umwidmen will ist der Witz ja gerade, dass dies mittels ZeroCopy sehr schnell geht. Extra RAM für den Betriebssystemkontext wäre da die Antithese.

Bei einer Konsole sehe ich LPE-Kerne auch allenfalls als Lösung im Softoff Updates zu ziehen oder Ähnliches. Bei einer Spielekonsole wären Konstrukte, wo LPE-Kerne mit allenfalls zweitklassiker Anbindung an E- bzw. P-Kerne bzw. deren Caches eher eine Quelle für ungewünschte Latenzen.

Da die zukünftigen Konsolen sowieso wieder auf AMD setzen werden, wird sich das Problem eh nicht stellen. Ich sehe da ZenXC Kerne und davon 8..12.
 
Zurück
Oben