Foren Aktuelles Erstellen Mitglieder Anmelden

Grafikunterschied - An die Experten

Benutzer, welche sich diesen Thread anschauen:

gqyaZAM.png


Demnach ist der GPU an drei RAM-Sets angebunden.
Dem nicht coherenten DRAM Access mit 68 GB/s, der den coherenten mit 30 GB/s inkludiert und den eSRAM.

Im direkten Vergleich mit dem Bus-System der PS4 würde das dann also so aussehen...

XBone
Anbindung für den CPU: Unbekannt (tippe aber darauf, dass es sich irgendwo in der Gegend von PCIe oder dem schnelleren Bus der PS4 befindet)
GPU to 8 GB DDR3: 68 GB/s
CPU Cache Coherent mit 30 GB/s, ohne bypass
32 MB eSRAM mit 109GB/s, als Cache für den GPU

PS4
Anbindung für den CPU: 20 GB/s
GPU to 8 GB GDDR5 über Garlic: 176 GB/S
CPU Cache Coherent mit 10 GB/s über Onion, ohne bypass
CPU Cache Coherent mit 10 GB/s mit bypass, ohne flush, via Onion+


Auch interessant, dass Microsoft nun endlich die GPU Power rausgerückt hat. Damit haben wir nun...

XBone
1,31 TFLOPs
Shader Cores 768
TMUs 48
ROPs 16
40,9 GTexel/s
13,6 GPixel/s

PS4
1,84 TFLOPS
Shader Cores 1152
TMUs 72
ROPs 32
57,6 GTexel/s
25,6 GPixel/s


mnk schrieb:
interessant auch, dass die ps4 von der architektur her deutlich mehr auf gpgpu ausgerichtet ist. das könnte auf lange sicht für die ps4 ein weiterer vorteil sein, vor allem wenn sich gpgpu auch auf dem pc stärker durchsetzt.

Jop, sogar sehr deutlich.

XBone: 2 ACEs (AMDs Asynchronous Compute Engines) * 2 Queues = 4 Compute Queues
PS4: 8 ACEs * 8 queues = 64 Compute Queues

Das sollte einen als PS4 Besitzer aber eigentlich überhaupt nicht freuen, denn damit sinken die Chancen erheblich, dass man die Compute Power der PS4 bei Multi-Plattformern jeweils wirklich erleben wird.
Zudem noch dazu das Problem existiert, dass GPGPU zwar in der Forschung nicht mehr wegzudenken ist, aber eine große Herausforderung und Neuland für die Entwickler darstellt. Da kommts wohl ganz auf Sonys feature set an, wie sehr es von den Entwicklern dann schlussendlich angenommen wird.
Großen GPGPU Einsatz werden wir damit wohl hauptsächlich bei Exklusiv-Titel erleben. :traurig:
 
Ich habe nicht den technischen Überblick, aber bestätigt sich der Vorschsprung der PS4 gegenüber der Xbone in dem maße, wie es in den Leaks schon zu erkennen war? Oder wird er noch größer? Oder nur in einigen Bereichen?

Und ja, wenn der Unterschied zu groß wird, werden die Sony-Studios den Unterschied alleine aus dem Kasten prügeln müssen.
 
Es sind genau die Zahlen die seit Monaten durchgekaut werden.
Es hat sich nichts verändert. Die XBox One ist genau so stark wie ständig besprochen.

Einzige was man grad sieht ist das die PS4 in Sachen GPGPU wohl auch noch ne ecke besser ist als die One.

Der Soundchip der One könnte dem der PS4 überlegen sein da wir von dem eigtl keinerlei Informationen haben.
 
Allerdings hat die X1 einen dreimal so großen Durchsatz von der GPU zum RAM, wenn auf die Kohärenz mit dem Cache der CPU geachtet wird (10GB/s vs. 30GB/s).
Das könnte einen Vorteil der X1 bei Algorithmen bedeuten, wenn CPU und GPU gleichzeitig auf Daten rechnen sollen und die damit im Cache der CPU vorhanden sind. Achtet man da dann nicht auf die Kohärenz, kann das unschöne KOnsequenzen und falsche Registerinhalte bedeuten, da unter Umständen im RAM alte Werte sind, die nur im Cache aktualisiert wurden.
Evtl. reichen da 10GB/s. auch locker für derartige Berechnungen, aber ansonsten ist in dieser Teildisziplin die X1 tatsächlich ein wenig überlegen und man sollte bei der PS4 erst RAM-Adressen an die GPU geben, wenn die CPU fertig ist und die Daten nicht mehr im Cache hat.

Aber das ist nur ein Anwendungsfall, der im Moment eh noch keine großartige Relevanz hat (die momentan gängige Situation sind ja noch kompltt getrennte RAM-Pools) und imo von den vielen Nachteilen der X1 überschattet wird...
Der massiv schlechtere Pixel- und Texeldurchsatz z.B. wird davon auch nicht besser...
 
.hack//Haseo schrieb:
Der Soundchip der One könnte dem der PS4 überlegen sein da wir von dem eigtl keinerlei Informationen haben.

Ob das aber wirklich viel bringen wird, wage ich zu bezweifeln. Auf dem PC wird seit Vista ja der Sound nur noch über die CPU berechnet und EAX ist schon länger tot.
Ich würde es mir wünschen, wenn die Entwickler wieder mehr in Richtung Sound machen würden, aber ich bezweifle es.
 
Trayal schrieb:
XBone
ROPs 32 16


Das sollte einen als PS4 Besitzer aber eigentlich überhaupt nicht freuen, denn damit sinken die Chancen erheblich, dass man die Compute Power der PS4 bei Multi-Plattformern jeweils wirklich erleben wird.



muss nicht unbedingt sein. stell dir vor, auf dem pc setzt sich das auch weiter durch und kommt dort vermehrt zum einsatz. jetzt entwickeln die devs von multiplats auf dem pc als lead, nutzen dort gpgpu und können natürlich recht einfach auf die ps4 portieren, die ihnen die selben möglichkeiten bietet. aus der wäsche schaut dann die x1.

zum thema audiochip: die ps4 hat ebenfalls einen dedizierten audio-chip, über den aber relativ wenig bekannt ist.
 
@el_barto

Wenn CPU und GPU miteinander arbeiten ist eher die Latenz entscheidend und dafür ist ja Onion da, während für nicht Latenz sensitives Garlic mit der vollen Bandbreite zur Verfügung steht.

Onion+ ist in der Hinsicht imo viel interessanter. Es ermöglicht es dem GPU ja seinen Cache zu bypassen.

Cerny hat das mal anhand eines Beispiels erklärt ->

Cerny: The GPGPU for us is a feature that is of utmost importance. For that purpose, we’ve customized the existing technologies in many ways.

Just as an example…when the CPU and GPU exchange information in a generic PC, the CPU inputs information, and the GPU needs to read the information and clear the cache, initially. When returning the results, the GPU needs to clear the cache, then return the result to the CPU. We’ve created a cache bypass. The GPU can return the result using this bypass directly. By using this design, we can send data directly from the main memory to the GPU shader core. Essentially, we can bypass the GPU L1 and L2 cache. Of course, this isn’t just for data read, but also for write. Because of this, we have an extremely high bandwidth of 10GB/sec.

Also, we’ve also added a little tag to the L2 cache. We call this the VOLATILE tag. We are able to control data in the cache based on whether the data is marked with VOLATILE or not. If this tag is used, this data can be written directly to the memory. As a result, the entirety of the cache can be used efficiently for graphics processing.

This function allows for harmonization of graphics processing and computing, and allows for efficient function of both. Essentially “Harmony” in Japanese. We’re trying to replicate the SPU Runtime System (SPURS) of the PS3 by heavily customizing the cache and bus. SPURS is designed to virtualize and independently manage SPU resources. For the PS4 hardware, the GPU can also be used in an analogous manner as x86-64 to use resources at various levels. This idea has 8 pipes and each pipe(?) has 8 computation queues. Each queue can execute things such as physics computation middle ware, and other prioprietarily designed workflows. This, while simultaneously handling graphics processing.

This type of functionality isn’t used widely in the launch titles. However, I expect this to be used widely in many games throughout the life of the console and see this becoming an extremely important feature.






Diese Daten von MS bestätigen damit auch den Leak im März, bezüglich des Speichersystems der XBone.

durango_memory.jpg

http://www.vgleaks.com/durango-memory-system-overview/


Dort sollte man auch vor allem das hier beachten...

There are two types of coherency in the Durango memory system:

Fully hardware coherent
I/O coherent
The two CPU modules are fully coherent. The term fully coherent means that the CPUs do not need to explicitly flush in order for the latest copy of modified data to be available (except when using Write Combined access).

The rest of the Durango infrastructure (the GPU and I/O devices such as, Audio and the Kinect Sensor) is I/O coherent. The term I/O coherent means that those clients can access data in the CPU caches, but that their own caches cannot be probed.

When the CPU produces data, other system clients can choose to consume that data without any extra synchronization work from the CPU.

The total coherent bandwidth through the north bridge is limited to about 30 GB/s.

The CPU requests do not probe any other non-CPU clients, even if the clients have caches. (For example, the GPU has its own cache hierarchy, but the GPU is not probed by the CPU requests.) Therefore, I/O coherent clients must explicitly flush modified data for any latest-modified copy to become visible to the CPUs and to the other I/O coherent clients.

The GPU can perform both coherent and non-coherent memory access. Coherent read-bandwidth of the GPU is limited to 30 GB/s when there is a cache miss, and it’s limited to 10 – 15 GB/s when there is a hit. A GPU memory page attribute determines the coherency of memory access.






@mnk
Mea culpa. Da habe ich den GPU der XBone versehentlich etwas aufgewertet. :)
 
Ist zwar PS4 spezifisch, aber auch hier nochmal, wo wir hier ja bereits über Speichermanagement faseln...

Trayal schrieb:
Playstation 4 und hUMA...
http://www.vgleaks.com/playstation-4-includes-huma-technology/

Vorsicht, nur etwas für technisch Versiertere. Den Rest könnte es erschlagen. Dafür allerdings wirklich sehr interessant.




Das erklärt auch wieso GG passendes memory mapping als so wichtig bei der PS4 Entwicklung angeprangert hat.
 
M4j0r K03nIg schrieb:
Warum denn gleich 8 GByte? Was kann man mit dem Rest des speichers anfangen?

es sollten doch ursprünglich sogar mal 16 sein, wenn ich mich recht entsinne.

vielleicht legt das os dort auch zusätzliche daten ab, damit es schneller booten kann aus dem stand-by heraus, quasi windows readyboost.
 
Zurück
Oben