Foren Aktuelles Erstellen Mitglieder Anmelden

Allerlei Technikdiskussionen

Benutzer, welche sich diesen Thread anschauen:

Mich würde interessieren, was z. B. Glod zu der RAM-Geschichte sagt. Vielleicht revolutioniert MS ja gerade wirklich das komplette Computing mit der One? Oder Penello legt einen pil nach dem nächsten hin.

Ansonsten hab ich mich eben mal durchgelesen. Die steigende Ineffizienz bei mehr CUs ist ja absoluter Quatsch, so wie er es darstellt.
 
Im Grunde hat er ja nicht gelogen und vermutlich das wiedergegeben was er zuvor erfragt hat (zumindest bei der Bandbreite), aber mit dem Verhalten eines, ich nenne es jetzt einmal "Autoverkäufers". Weshalb ich es auch als PR Fail betrachte.

Zum einen natürlich die theoretisch sehr hohe Bandbreite des eSRAM (wo der Praxis Wert wohl irgendwo zwischen den ursprünglichen 107 GB/s und den theoretischen 204 GB/s liegt - vermutlich sogar mehr am Ursprungswert) und zum anderen das Addieren dieser.

Eine kombinierte Bandbreite wäre vielleicht möglich, aber das ist wiederum mehr Theorie als Praxis.
Ein User im Beyond3D Forum hat da ein gutes Beispiel gebracht...

The combined bandwidth maybe possible. Perhaps there are cases where the ROPs are rendering out of the SRAM while the ALUs use the main memory bandwidth for a GPGPU computation. If you can execute out of both pools of RAM simultaneous, then I say you can add the bandwidth.


Am Papier ergibts ne tolle Zahl und man kann ja von der Theorie träumen, aber was dann tatsächlich vor Ort, sprich in der Praxis bei den Entwicklern passiert, ist ein ganz anderes Thema. Da sehe ich in Microsofts Architektur eher einen Flaschenhals für die Entwickler, nicht im technischen Sinne, sondern mehr in der Handhabung der Technik, im Vergleich mit Sonys Lösung.

Dann kommt noch hinzu, dass der Großteil dieser theoretischen Bandbreite (204 GB/s von 272 GB/s) nur auf 0.621 % des für die Entwickler zur verfügung stehenden Speichers zutrifft (32 mb aus insgesamt 5152 mb).

Zimtzicke schrieb:
Mich würde interessieren, was z. B. Glod zu der RAM-Geschichte sagt.

Glods Post zum eSRAM im Spoiler...
Glod schrieb:
MachtAG schrieb:
Keine Ahnung aber vllt. haben sie beim fertigen Prozessor einfach gemerkt das er eben schreiben und lesen kann zur selben Zeit. Kann doch passieren, ich weiß leider nicht wie ein Chip gebaut wird oder geplant wird, aber ich weiß wenn ich ein Rezept für ein Gericht schreibe, kommt manchmal auch was anderes am Ende raus.

Ok, ich versuche mal, das zu erklären. Ich hoffe, ich kriege es einigermaßen verständlich hin.

Zunächst einmal muss man sagen, dass Hardware per se wirklich äußerst simpel ist. Das gilt nicht für die darin umgesetzten mathematischen Algorithmen (ich habe z.B. keinen Schimmer, was da in einer Grafikkarte letztendlich wirklich abläuft, da ich keine Ahnung von den Bildverarbeitungsalgorithmen habe, die da implementiert wurden), aber die reine Hardware mit ihren Elementen ist simpel.

Das gilt gerade insbesondere für RAM. Ein RAM ist einfach nur ein Riesenhaufen sogenannter Flipflops, in die man was schreiben und dann wieder lesen kann. Natürlich kann man damit auch eine Menge Schabernack treiben und viele lustige Möglichkeiten zusammenbauen. Man kann unterschiedliche Schreib-/Lese-Modi wie z.B. Single, Pipeline und Burst einbauen. Man kann Test-Modi nutzen. Es gibt Möglichkeiten, die Energiezufuhr zum RAM runterzufahren, um Strom zu sparen usw. usw. Und natürlich kann man RAMs intern auch beliebig komplex gestalten, mit Swap-Pages und hast du nicht gesehen.
Das ist alles eine Menge Fachchinesisch und im Grunde auch völlig uninteressant. Denn unterm Strich lässt sich jeder RAM auf das folgende Bild runterbrechen:

single-port-ram-vlog.GIF


Was du hier siehst, sind die Ein- und Ausgänge eines sogenannten Single-Ports-RAMs. Die Ports haben die folgende Bedeutung:

DATA[7:0] : Das ist der Dateneingang des RAMs in diesem Fall mit einer Breite von 8 Bit (Bit 7, Bit 6, Bit 5... Bit 0)

ADDR[5:0] : Das ist die Addresse, über die man dem RAM sagt, welche Stelle im RAM geschrieben oder gelesen werden soll. Die Adresse hier hat 6 Bit

WE : Über dieses Signal wird dem RAM gesagt, ob er Daten in den RAM schreiben oder vom RAM lesen soll. Das ist nur ein Bit. Hat es den Wert '1' schreibt man, hat es den Wert '0' liest man (kann auch andersrum sein).
Da der Schreib- und Lesezugriff auf den RAM nur über dieses Signal gesteuert wird und dieses Signal immer nur einen Wert haben kann, ist sichergestellt, dass man diesen RAM zu einem bestimmten Zeitpunkt immer nur lesen ODER schreiben kann. Das ist auch so gewollt, denn wenn man eine Adresse gleichzeitig schreibt und liest, kann man nie sicher sein, was man letztendlich gelesen hat und was danach im RAM steht.

CLK : Das ist einfach der Takt, der den RAM antreibt. Ohne den geht gar nix

Q[7:0] : Das ist der Datenausgang ebenfalls wieder mit einer Breite von 8 Bit. Im Falle eines Lesezugriffes erscheinen hier die Daten.

Wie gesagt: Das ist die Basisform eines RAMs. Egal, was der sonst noch bietet - diese Grundfunktionalität ist auf jeden Fall drin. Und wie ich schon erwähnt habe, kann man diesen RAM immer nur schreiben ODER lesen. Beides gleichzeitig ist nicht möglich.
Natürlich hat man aber sehr viele Szenarien, wo man gerne eine Adresse lesen und gleichzeitig eine andere schreiben möchte. Schon aus Geschwindigkeitsgründen ist das wünschenswert. Wie muss man das nun lösen? Ganz einfach. Man braucht dafür mindestens einen Dual-Port-RAM und der sieht dann schlicht und ergreifend so aus:

true_dpram_sclk_vhd.gif


Es ist alles zwei Mal da - unterteilt in Port A und Port B. Das ist der ganze Trick. Und anders ist das nicht machbar. Je nachdem, wieviele Operationen ich an einem RAM parallel machen möchte, brauche ich dafür entsprechend viele Ports. Wir haben hier im Design z.B. einen RAM, der hat einen Schreib- und 64-Leseports. Wir können da also in einem Schritt gleichzeitig 64 Werte auslesen. Ist alles machbar. Aber man braucht die Ports.

Und um jetzt den Bogen zu der MS-Aussage mit dem RAM zu schlagen: Bevor die den eSRAM eingebaut haben, haben sie natürlich die Datenblätter dazu gelesen. Und in jedem Datenblatt befindet sich so ein Bild, wie das, was ich oben eingefügt habe. Man kann anhand dieser Ports sofort erkennen, ob man einen RAM gleichzeitig schreiben und lesen kann, oder nicht. Man wird da später keine geheimen Supermodi finden. Ohne entsprechende Ports geht da nix. Und die kennt man, bevor man den RAM überhaupt ins Design einbaut.




Was die andere Sache mit den freien Slots betrifft, die ebenfalls aufkam:

Wie ich oben schon schrieb, ist der Takt der Motor des RAMs. Ein Taktsignal sieht so aus:

clock.gif


Es handelt sich einfach um ein Signal, welches in regelmäßigen Abständen seinen Zustand von '0' auf '1' und dann wieder zurück ändert. Den Übergang von '0' auf '1' nennt man eine steigende Taktflanke, den Übergang von '1' auf '0' eine fallende Taktflanke.
Der Takt steuert die Speicher im RAM. In den meisten Fällen ist es so, dass die Speicher bei jeder steigenden Taktflanke Daten lesen/schreiben können. Zu allen anderen Zeitpunkten passiert in den Speichern nichts. Diese Zeit ist dann dafür da, dass die Logik rechnen kann.
Die Anzahl der steigenden Taktflanken pro Sekunde ergibt also die maximal Geschwindigkeit mit der ein RAM arbeiten kann. Will man diese Geschwindigkeit erhöhen, muss man einen schnelleren Takt wählen. Beispiel:

Ein Design läuft mit einer Frequenz von 1 MHz. Das bedeutet, dass dieses Design in einer Sekunde 1 Mio steigende Taktflanken kriegt. Ein RAM kann pro Sekunde also theoretisch 1 Mio Mal geschrieben/gelesen werden. Mehr ist da nicht machbar. Das ist Physik.
Will man öfter auf den RAM schreiben, muss man die Taktfrequenz erhöhen. Stellt man z.B. 2 MHz ein, dann hat man pro Sekunde 2 Mio steigende Taktflanken, was natürlich ein ganzer Zacken mehr ist. Die heutigen Designs laufen mit vielen hundert MHz oder gar GHz, was hunderte Millionen oder gar Millarden von steigenden Taktflanken in einer Sekunde bedeutet. Ordentlich Bums auf dem RAM also.
Aber wie erwähnt: Der RAM kann nur zu jeder steigenden Flanke arbeiten und zu anderen Zeitpunkten ist das nicht möglich.

Jetzt mal zu den freien Slots. Auf meinem Bild da oben sehen wir 6 steigende Taktflanken, also 6 Zeitpunkte, zu denen man auf den RAM zugreifen kann. Nun ist es bei einem Programmablauf selten so, dass zu jedem möglichen Zeitpunkt auf den RAM zugegriffen wird. Da müssen intern Sachen berechnet werden, eine Komponente wartet auf Daten von einer anderen Komponente etc.
Sagen wir in unserem Beispiel schreibt ein Programm zu den Flanken 1, 2 und 5. Bei den anderen Flanken ist es beschäftigt.
Nun ist es natürlich möglich, dass ein anderes Programm genau die freien steigenden Flanken 3, 4 und 6 nutzt, um ebenfalls auf den RAM zugreifen zu können. Das ist alles machbar und im Grunde kein großer Deal. ABER es erhöht die Durchsatzrate des RAMs nicht. Denn egal, wieviele Programme auf den RAM zugreifen und freie Taktflanken dafür nutzen - sie ändern nichts an der Gesamtzahl an Taktflanken, die für den RAM zur Verfügung stehen. Diese Zahl bleibt fix und deswegen bleibt auch die Durchsatzrate des RAMs fix.

Ich bin mir nicht sicher, ob das jetzt alles verständlich war, aber ich hoffe, ich konnte einigermaßen gut erklären, warum beide Aussagen:

a) Wir haben zufällig festgestellt, dass man gleichzeitig lesen und schreiben kann
b) wir können durch die Nutzung freier Slots die Durchsatzrate dramatisch erhöhen

kompletter Bullshit sind und entweder völlig falsch übersetzt, aus dem Zusammenhang gerissen oder absolut dümmliches PR-Gelaber sind.




 
Ja das mit dem RAM ist schon ziemlich cool. Im Grunde sagt er ja Folgendes:

Hey, ich habe ein Auto, dass 150 km/h Spitze fahren kann. Und ich habe eins, dass 250 Spitze fahren kann. Wenn ich die mit einem Abschleppseil verbinde, dann kann ich 400 km/h fahren. Jippie!

:lol:
 
Naja, ganz so stimmt das aber nicht. So wie ich das verstanden habe hängt die GPU an den GDDR3 und am eSRAM; je über einen eigenen Bus und somit wohl auch eigenen Port. Dass man das nicht einfach zusammenrechnen kann ist klar (nach der Rechnung hätte die 360 ja irgendwo etwas um die 256GB/s)... Das heisst aber nicht dass der eSRAM nicht etwa einiges an Bandbreite wettmachen kann indem darauf z.B. der Framebuffer oder ähnliches ausgelagert wird.

Ich verbessere also mal dein Beispiel so wie ich es verstehe: Es ist eher so, als hätte man nen Roller (GDDR3) und ne Ferrari (eSRAM); der Roller fährt 50 aber die Ferrari 300; wenn letztere jetzt aber den Roller im Schlepptau hat schauen im besten Fall höchstens 230 raus. Dazu kommt noch, dass die Ferrari auf ner Bergstraße fährt und daher nur sehr gute Fahrer (Programmierer) wirklich die Spitzengeschwindigkeit erreichen, wenn überhaupt (die Begründung für die neue Angabe des Durchsatzes kann ja Schwachsinn sein, aber die Daten an sich könnten ja theoretisch stimmen). Erschwerend kommt hinzu, dass in die Ferrari nur 2 leute und ne Handtasche passt (Framebuffer z.B. ) , die schweren Koffer müssen auf den ,recht großen, Roller geladen werden (Texturen, Geometrie, Shader etc.). Das erschwert das fahren der Ferrari halt immer weiter.

Sony setzt da einfach auf nen Porsche, der fährt zwar "nur" 280, is aber auf der Autobahn und hat nen riesigen Kofferraum. :D
 
Glod schrieb:
Ja das mit dem RAM ist schon ziemlich cool. Im Grunde sagt er ja Folgendes:

Hey, ich habe ein Auto, dass 150 km/h Spitze fahren kann. Und ich habe eins, dass 250 Spitze fahren kann. Wenn ich die mit einem Abschleppseil verbinde, dann kann ich 400 km/h fahren. Jippie!

:lol:

Das hat Cerny aber auch gesagt. ;)
 
Cerny hat in ner Präse ne Gegenüberstellung der veschiedenen RAM-Lösungen gezeigt und dort auch die Bandbreiten addiert.

War aber eher nebenbei als HInleitung, wieso man sich für das GDDR5-Modell entschieden hat.
 
Trayal schrieb:
Was hat er gesagt?

ps4-dual-architecture.jpg


[vid]http://www.youtube.com/watch?v=JJW5OKbh0WA[/vid]


el_barto schrieb:
Cerny hat in ner Präse ne Gegenüberstellung der veschiedenen RAM-Lösungen gezeigt und dort auch die Bandbreiten addiert.

War aber eher nebenbei als HInleitung, wieso man sich für das GDDR5-Modell entschieden hat.

Naja, er hat eben gesagt, dass man natürlich eine solche Lösung hätte implementieren können - sich dagegen aber entschieden hat - nicht weil es kein Sinn macht oder man die Bandbreiten nicht addieren kann - sondern weil man eben mit den Entwicklern geredet hat und diese eben eine unified Lösung bevorzugten, weil man mit dieser einfacher entwickeln kann und das volle Potential eben gleich zu Beginn der Gen nutzen kann.
 
Ja, und trotzdem war es nebenbei als Hinleitung aufs eigentliche Thema - der Architektur der PS4.

Es ist und bleibt halt Blödsinn. Oder genauer gesagt ein idealisierter Wert, den man abseits von Benchmarks in realen Situationen nicht wirklich oft haben wird. Prinzipiell kann man natürlich Daten über eSRAM- und DDR-Bus gleichzeitig schicken und hätte dann tatsächlich diesen Maximalwert als Durchsatz.
Bringt mir aber nix, wenn ich z.B. Texturen und Meshes lesen will, die halt mal aufgrund ihrer Größe im RAM zu finden sind und nicht im eRSAM, der mehr oder weniger als eine Art "personalisierbarer" Cache dienen wird.

Weiß nicht, worauf du mit "aber Sony macht das auch so!" mal wieder raus willst...
 
Als theoretischer Spitzenwert lasse ich derartige Aussagen ja gelten. Ist immerhin auch so und bei MS nicht anders, aber wo es nicht mehr passt, war es eben in Panellos Beispiel, da er dies als Vergleich zur Speicherlösung der PS4 herangezogen hat, mit der Intention darauf zu verweisen, dass man doch die performantere Lösung hat. Das ist auf die Art und Weise nicht vergleichbar.
Was anderes wärs gewesen wenn da jetzt zB 88 GB/s + 100 GB/s eDRAM = 1088 GB/s mit 68 GB/s + 204 GB/s = 274 GB/s verglichen werden würden. Das wäre eine vergleichbare Situation (sogar eine recht Interessante), während vorheriges mehr Bauernfängerei ist.

Aber danke für das Video. Das kannte ich von voller Länge noch gar nicht. Gleich mal komplett ansehen. :)
 
Gerade die Präsentation angesehen und eigentlich lustig, dass das Bild hier gepostet wurde, in Zusammenhang mit Panellos Aussage. :D

Das Bild der Präsentation hat ohne Cernys Vortrag eine ganz andere Bedeutung. Er verdeutlichte, dass man sich trotz der verlockenden Zahl rechts (1088 GB/s - großer Memory Pool mit bereits mehr Bandbreite und der kleinere Memory Pool mit wesentlich mehr Bandbreite als die X1 verfügt) für die kleineren Zahl links (176 GB/s) entschieden hat und begründete dies sowohl während der Vorstellung beider Systeme als auch danach.
 
Trayal schrieb:
Gerade die Präsentation angesehen und eigentlich lustig, dass das Bild hier gepostet wurde, in Zusammenhang mit Panellos Aussage. :D

Das Bild der Präsentation hat ohne Cernys Vortrag eine ganz andere Bedeutung. Er verdeutlichte, dass man sich trotz der verlockenden Zahl rechts (1088 GB/s - großer Memory Pool mit bereits mehr Bandbreite und der kleinere Memory Pool mit wesentlich mehr Bandbreite als die X1 verfügt) für die kleineren Zahl links (176 GB/s) entschieden hat und begründete dies sowohl während der Vorstellung beider Systeme als auch danach.

Yo. Lustig. Weil eigentlich hat er gesagt, dass wenn man das rechte System verstanden hat und es nutzen kann eben diese Bandbreite nutzen könnte. Man sich aber dagegen entschieden hat, da man Day One schon 176 GB/s den Entwicklern zur Verfügung stellen wollte und diese eine solche Lösung auch haben wollten.
 
Dixxhead schrieb:
Naja, ganz so stimmt das aber nicht. So wie ich das verstanden habe hängt die GPU an den GDDR3 und am eSRAM; je über einen eigenen Bus und somit wohl auch eigenen Port. Dass man das nicht einfach zusammenrechnen kann ist klar (nach der Rechnung hätte die 360 ja irgendwo etwas um die 256GB/s)... Das heisst aber nicht dass der eSRAM nicht etwa einiges an Bandbreite wettmachen kann indem darauf z.B. der Framebuffer oder ähnliches ausgelagert wird.

Na klar, kann er das. Genau zu dem Zweck ist er ja verbaut worden. Das durch den RAM ein Performande-Schub erreicht werden soll/kann, ist klar.

Ich verbessere also mal dein Beispiel so wie ich es verstehe:

Jo, auch ein guter Ansatz. Aber letztendlich müsste man noch die Größenverhältnisse beider Speicher berücksichtigen und da wird aus dem Roller im Grunde ein großes Wohnmobil. Bergab mit Rückenwind wird das ordentlich flutschen. Aber auf der Geraden oder gerade bei längeren Steigungen wird's für den Ferrari übel. :D
 
@hana-bi: weil cerny das mit dem ram fälschlicherweise so gesagt hat, ist es jetzt weniger falsch, wenn penello das sagt? du immer mit deiner "aber! aber! aber!" schiene...
 
Dixxhead schrieb:
@Hana-Bi: Hmm, bin ich mir jetzt nicht ganz sicher, dass er das so gesagt hat.

Hat er schon so gesagt, das stimmt schon. Nur hats Hana-Bi aus dem Kontext gerissen, um was auch immer ausdrücken zu wollen. :D

Der genaue Wortlaut...

To compare these two architectures: The one on the left has a 176 GB/s for any access, the one on the right has 88 GB/s if the data is in system memory or a 1000 GB/s if the data is in that tiny eDRAM. On first glance the architecture on the right looks far superior to the one on the left.

Sure it takes a while to figure out how to use it but once you understand how to use that little cache of VRAM you can unlock the full potential of the hardware. But to our new way of thinking, the straight forward approach on the left is definitely advantageous. It gives us excellent day 1 performance and we can find other features for the programmers to explore in later years. So in other words, 176 is much larger then 1088.

So here you can see the impact of the straight forward and familiar architecture Playstation 4 has had on time to triangle...

PS1 -> 1 to 2 months
PS2 -> 3 to 6 months
PS3 -> 6 to 12 months
PS4 -> 1 to 2 months

It's basically back to where it was on PlayStation 1. It's great to be able to leverage the fact that almost all 3rd party teams allready have sophisticated graphic engine that runs on PCs. And the familiar architecture has also been a great benefit to indie-developer. Not only titles are much easier to bring for PS4 but conceptually driven titles can be created on PS4 without any significant time spend on studying the tech details of the platform.

Now as I said earlier we also worked hard to ensure that the console has a rich feature set, which grow over the years and support the overall evolution of gaming. And our work there on this rich feature focused on making sure that for those teams that were interested in investing the time, the GPU could be used for far more then conventional graphics. Principally we enhanced the GPU to make the use of asynchronous fine-frain compute practical on the plattform. So the asynchronous refers to the GPU doing many tasks which is not directly related to graphics.

Physics simulation, collision detection, ray casting for audio, decompression and the like. And these operations are fine grained meaning that there will be many small world simulation tasks running on the GPU simultaneously alongside rendering of the game scenes. So the concept is that as game developers learn to use these techniques later on in the console life cycle, we will see richer and even more interactive worlds.


Zuvor erwähnte Cerny nämlich auch, als Einleitung zu dieser RAM geschichte: We didn't want the hardware to be a puzzle that the developers would need to solve in order to make quality titles. Worauf er sich wieder auf den Cell bezog, dessen Handhabung ihm wie ein Rubiks Cube vorkam (er war ja Teil des ICE Teams, zusammen mit einigen anderen 1st Partys, die auf den Cell geschult wurden bevor überhaupt die nötige Software zur Hardware der PS3 geschrieben wurde, geschweige denn die 3rd Partys schon etwas davon wussten).

...and just to give a specific example, this gets technicle very quickly so please forgive me. The architecture that we ended up for Playstation 4 uses a 256 Bit Bus and a type of memory found in top of the line graphics card called GDDR5. In comination with this wide bus and this fast memory gives us a 176 GB/s, which and many of you will have my word for it, is quite a lot. So with that much bandwidth straight forward programming techniques usually result in some pretty impressive graphics. We knew that there was an alternative architecture that would be a bit easier to manufacture. In this architecture wie would use a narrower 128 Bit Bus who drop the bandwidth down to 88 GB/s which is not particularly good in next generation terms and therefore we would really hurt the graphic performance. So we use some very fast on-chip memory to bring the performance back up. If we used eDRAM for this on-chip memory, we knew that bandwidths as much as 1000 GB/s would be archivable. The catch though would be that this on-chip memory would be very small and each game team would need to develop special techniques in order to manage it.


Im Zusammenhang dieser Präsentation bleibend, zielte Cerny darauf ab, dass er und sein Team den Wünschen der Entwickelt gefolgt sind, die sie anhand ihrer Umfragen und den ellenlangen Meetings/Präsentationen mit ihnen ermittelt haben.

Ua...

* Ein einheitlicher, großer und schneller Speicher
* Eine starke GPU, die nicht zu sonderbar daher kommt, sondern mehr konventionell ist

Dennoch wollte er seine easy to learn und difficult to master Philosophie mit einbringen und daraus entstand der Asynchronous Fine Grained Compute Fokus. Den die Entwickler über die Jahre entdecken können, statt einer komplizierten Speicherlösung.
 
mnk schrieb:
@hana-bi: weil cerny das mit dem ram fälschlicherweise so gesagt hat, ist es jetzt weniger falsch, wenn penello das sagt? du immer mit deiner "aber! aber! aber!" schiene...

Ist es denn tatsächlich "fälschlicherweise" gewesen? Wenn hier die Techniker-Ecke im Forum sagt: "Das geht nicht!" Dann stimmt das wohl - egal ob Sony oder MS was gegenteiliges sagen?

Mehr will ich dazu nicht sagen. Mir fehlt das technische Know-How dafür, aber ich bin dann doch jemand der Leuten eher glauben schenkt, welche auch aktiv an einer Konsolenhardware arbeiten.
 
Trayal schrieb:
@Hana-Bi

Der Kontext war ein gänzlich anderer. Darum gehts.

Was habe ich denn aus dem Kontext gerissen?

Er sagt: "Once you understand how to use that eDRAM you can unlock the full potential of the console" - sie wollten aber ein "straight-forward approach" mit "excellent day-one performance".

Er sagt doch genau das was MS auch sagt: es ist möglich eine solche Bandbreite zu erreichen, dies ist aber nicht die Philosophie der PS4 gewesen, welche eben auf die Wünsche der Devs mit einer unified RAM Lösung eingegangen ist. Aber das habe ich schon gestern geschrieben, deswegen weiß ich wirklich nicht was ich da aus dem Kontext gerissen haben könnte. :?
 
Zurück
Oben