Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: Diese Funktion ist in einigen Browsern möglicherweise nicht verfügbar.
New Horizon schrieb:"Bestätigt"?
100% bestätigt ist das erst wenn es von beyond3d oder digital foundry kommt!
mnk schrieb:der einzige wirkliche unterschied ist, dass ms einen extra chip hat für etwas, was die ps4 über die gpu berechnet. das reine featureset beherrschen dx und opengl gleichermaßen, es ist sogar ursprünglich aus opengl.
inwieweit das jetzt in der zukunft, wenn es stärker genutzt werden könnte, einen vorteil für die x1 bedeuten würde, kann niemand sagen.
Xbox One does, however, boast superior performance to PS4 in other ways. “Let’s say you are using procedural generation or raytracing via parametric surfaces – that is, using a lot of memory writes and not much texturing or ALU – Xbox One will be likely be faster,” said one developer.
http://www.pcgameshardware.de/PlayStation-4-Konsolen-220102/Specials/PS4-Inside-1084325/Nicht nur AMD, auch Sony selbst verriet auf der Games Developers Conference einige Details zur kommenden Playstation 4, speziell zu dem GCN-basierenden Grafikchip. Asynchrone Compute-Nutzung spiele dabei eine wichtige Rolle, so Richard Stenson aus Sonys US-amerikanischem Forschungs-und Entwicklungslabor. Auch sei mit der PlayStation Shader Language PSSL ein über die Möglichkeiten von DirectX 11.2 hinausgehender Standard geschaffen. Man wolle alle Fähigkeiten, welche die Hardware besitze, auch anbieten und dafür PSSL weiterentwickeln.
Der Grafikchip der Playstation 4, für den die Playstation Shader Language PSSL, entwickelt wird, basiert auf AMDs Graphics Core Next-Architektur. Die in der Playstation 4 zum Einsatz kommende Variante beherrscht nicht nur aktuelle Standards wie DirectX 11 oder Open GL 4.3. Sony ist sich sicher, dass einige Hardware-Features nicht einmal im kommenden DirectX 11.2 genutzt werden können. GCN-Hardware Intrinsics wie Ballot, SAD oder auch Sleep seien bereits oder würden bald implementiert.
Als Beispiel für die Möglichkeiten der Playstation-4-Grafik stellte Chris Ho sein Projekt vor. Dabei kombiniert er eine Voxel-Darstellung über Sparse Octree-Berechnung mit den Partially Resident Textures, welche GCN-Chips bieten und die als Tiled Ressources in DirectX 11.2 Einzug halten. Durch die Speicherung in 3D-Texturen kann auf die CPU-intensive Erzeugung des Octrees verzichtet werden, ohne dabei jedoch wesentliche Vorteile der Technik aufzugeben. Eine Live-Demo der Technik zeigte beeindruckende Beleuchtungseffekte und erreichte bereits ohne größere Optimierungen, welche laut Ho noch ausstehen, rund 38 Fps für die laufende Animation. Die Erzeugung des Voxel-Gerüstes benötigt allerdings noch 45 ms (entspricht circa 22 Fps).
Nicht verkneifen konnten sich die Präsentatoren natürlich auch einen kleinen, aber vielfach wiederholten Seitehieb auf die Xbox One: Mehrfach betonte Richard Stenson die Vorteile der massiven Bandbreite, welche GDDR5-Speicher im Vergleich zu DDR3 liefere. In einer der Präsentationsfolien wurde allerdings GDDR5 mit 256-Bit-Anbindung mit einer nur halb so breiten DDR3-Schnittstelle verglichen. Aber auch mit Kritik am eigenen Hause wird bei Sony mittlerweile nicht mehr gespart. Die einfache Programmierbarkeit inklusive der vorhandenen Tools und Compiler sei einer der Gründe und einer der Hauptvorteile, welche Sony bewogen haben, bei dieser Generation der Konsole auf x86-Hardware zu setzen. Zuvor waren insbesondere die Playstation 2 und 3 geradezu berüchtigt für die Komplexität der Programmierung, sofern man die Hardware wirklich komplett ausreizen wollte.
Abschließend betonte Richard Stenson abermals die Bedeutung von Compute-Anwendungen und -Algorithmen für die Zukunft der Grafik - etwas, das auch AMD seit Monaten verstärkt in den Fokus rücken möchte. Laut Stenson hätten sich Grafik und Compute bislang eher toleriert - und das wolle man mit der PSSL ändern. GCN verfügt dazu bereits über gute Voraussetzungen, denn das Compute-/Grafik-Verhältnis läge in gewisser Weise bei 3:1. Neben dem Graphics Command Processor könnten auch die beiden Asynchronous Compute Engines Compute-Workloads anstossen - anders herum ginge das nicht. In einer vorigen AMD-Präsentation wurde zudem verraten, dass kommende Konsolen-Hardware gar über zusätzliche Compute-Queues im Vergleich zu verfügbarer Consumer-Hardware verfügten.
When you see the games you'll be saying, what is the performance difference between them.
New Horizon schrieb:Interessant:
http://www.eurogamer.net/articles/digitalfoundry-vs-the-xbox-one-architects
- Rendertarget muss nicht komplett im eSRAM liegen (anders als noch beim eDRAM)
- Kinect braucht die geringe Latenz des eSRAMs und DDR3-RAMs
- 2 zusätzliche Compute Units hätten weniger Performance als die Takterhöhung um 53Mhz gebracht
- Die Takterhöhung der CPU um 150Mhz war nötig um die Framerate stabil zu halten (zu erhöhen)
- Für manche GPGPU-Berechnungen sind geringe Speicherzugriffszeiten um einiges wichtiger als die Anzahl der CUs
- Durch den neuen Scaler der Xbox One ist es möglich die Auflösung eines Spiels während des Renderings fließend zu wechseln
Klingt seit langem mal wieder etwas positiver und hat auch nicht den faden Beigeschmack von unbestätigten Entwickler-Kommentaren!
Allerdings ist schon auffällig, dass man versucht "a balanced System" als Ausrede für weniger Rohpower zu verwenden. Letztlich würd sich zeigen müssen wie groß der grafische Unterschied letztlich zwischen beiden Plattformen ausfallen wird.
Auffällig finde ich nur, dass die Taktsteigerung der CPU wirklich einen Einfluss auf die Framerate hat! Die 1,6GHz fand ich schon immer extrem gering...man kann nicht alles parallelisieren!
Außerdem scheint der eSRAM wirklich nicht die schlechteste Lösung gewesen zu sein...
Letztlich könnte es dann wirklich hierauf hinaus laufen:When you see the games you'll be saying, what is the performance difference between them.
Allerdings erhält man nicht zuletzt durch Sonys Subvention bei der PS4 mehr Technik für weniger Geld!

Steffko schrieb:Das ist klassisches Damage Control Rumgeschwafel (von vorne bis hinten), was soll daran nun positiv sein? Ist ja nicht so, dass Microsoft mit nem Statement a la "Ehrlich gesagt werfen wir da - im Vergleich zur PS4 - wirklich nen Schrotthaufen auf den Markt" an die Öffentlichkeit gehen würde![]()
"There are four 8MB lanes, but it's not a contiguous 8MB chunk of memory within each of those lanes. Each lane, that 8MB is broken down into eight modules. This should address whether you can really have read and write bandwidth in memory simultaneously," says Baker.
How ESRAM bandwidth is calculated
Memory bandwidth for next-gen consoles is clearly a hot topic in tech discussions. GDDR5 is a known technology and its capabilities in terms of throughput are well-known. ESRAM is a different matter entirely, and especially after Microsoft massively revised Xbox One's bandwidth figures upwards, there have been demands for the tech team to show their calculations.
Here, Nick Baker does just that:
"[ESRAM has four memory controllers and each lane] is 256-bit making up a total of 1024 bits and that in each direction. 1024 bits for write will give you a max of 109GB/s and then there's separate read paths again running at peak would give you 109GB/s.
"What is the equivalent bandwidth of the ESRAM if you were doing the same kind of accounting that you do for external memory? With DDR3 you pretty much take the number of bits on the interface, multiply by the speed and that's how you get 68GB/s. That equivalent on ESRAM would be 218GB/s. However just like main memory, it's rare to be able to achieve that over long periods of time so typically an external memory interface you run at 70-80 per cent efficiency.
"The same discussion with ESRAM as well - the 204GB/s number that was presented at Hot Chips is taking known limitations of the logic around the ESRAM into account. You can't sustain writes for absolutely every single cycle. The writes is known to insert a bubble [a dead cycle] occasionally... one out of every eight cycles is a bubble so that's how you get the combined 204GB/s as the raw peak that we can really achieve over the ESRAM. And then if you say what can you achieve out of an application - we've measured about 140-150GB/s for ESRAM.
"That's real code running. That's not some diagnostic or some simulation case or something like that. That is real code that is running at that bandwidth. You can add that to the external memory and say that that probably achieves in similar conditions 50-55GB/s and add those two together you're getting in the order of 200GB/s across the main memory and internally."
So 140GB-150GB is a realistic target and DDR3 bandwidth can really be added on top?
"Yes. That's been measured."
"Yes you can - there are actually a lot more individual blocks that comprise the whole ESRAM so you can talk to those in parallel. Of course if you're hitting the same area over and over and over again, you don't get to spread out your bandwidth and so that's one of the reasons why in real testing you get 140-150GB/s rather than the peak 204GB/s... it's not just four chunks of 8MB memory. It's a lot more complicated than that and depending on how the pattern you get to use those simultaneously. That's what lets you do read and writes simultaneously. You do get to add the read and write bandwidth as well adding the read and write bandwidth on to the main memory. That's just one of the misconceptions we wanted to clean up."
Goosens lays down the bottom line:
"If you're only doing a read you're capped at 109GB/s, if you're only doing a write you're capped at 109GB/s," he says. "To get over that you need to have a mix of the reads and the writes but when you are going to look at the things that are typically in the ESRAM, such as your render targets and your depth buffers, intrinsically they have a lot of read-modified writes going on in the blends and the depth buffer updates. Those are the natural things to stick in the ESRAM and the natural things to take advantage of the concurrent read/writes."
New Horizon schrieb:Für manche GPGPU-Berechnungen sind geringe Speicherzugriffszeiten um einiges wichtiger als die Anzahl der CUs
New Horizon schrieb:Außerdem scheint der eSRAM wirklich nicht die schlechteste Lösung gewesen zu sein...
New Horizon schrieb:Die Takterhöhung der CPU um 150Mhz war nötig um die Framerate stabil zu halten (zu erhöhen)
M4j0r K03nIg schrieb:Also zu den 1080p,finde frames einfach wichtigerEn Shooter spiel ich lieber mit 720p@60 fps statt 1080p@30...
![]()

DaMeep schrieb:60fps sollen bei einem MP shooter nice to have sein ?
Sicher hilft eine höhere Auflösung auch , grade bei Gefechten auf große Distanz , aber zu allererst muss das ganze doch wirklich 100% flüssig laufen . Worauf man IMO am ehesten verzichten kann sind die teils übertriebenen Effekte , die brauchts in einem MP IMO nicht wirklich .
Wir verwenden essentielle Cookies, damit diese Website funktioniert, und optionale Cookies, um den Komfort bei der Nutzung zu verbessern.
Siehe weitere Informationen und konfiguriere deine Einstellungen