PS4 PlayStation 4 - Main discussion thread

Noodles

Super Moderator
Premium Supporter
Feb 28, 2011
44,892
UK





In preparation for tomorrow's announcement, Sony Playstation have released a video which looks back at the evolution of Playstation games and how they pushed the boundaries of play with their innovative titles.



You can watch a global livestream broadcast of the PlayStation Meeting this Wednesday (February 20th, 2013) starting at 6:00pm EST, 3:00pm PST and 11:00pm GMT at these links...

US: https://us.playstation.com/meeting2013/
UK: http://uk.playstation.com/meeting2013/

UPDATE:

8492670863_9a2f640988_z.jpg

A press release reveals the machine will include an 8-core 64-bit x86 "Jaguar" CPU developed by AMD and a Radeon GPU with the capability of terrorizing televisions with 1.84 TFLOPS of gaming goodness.

PlayStation 4 includes a Blu-ray drive that spins game discs a brisk 6X and 8X for DVDs. Additional specs in the release note the, already revealed, 8GB of unified GDDR5 RAM along with 802.11n WiFi capability, USB 3.0 ports, Bluetooth 2.1 and ports for optical audio, HDMI and even legacy analog AV hook-ups. Though the console will have internal storage, Sony did not detail its size.

Sony's plan is to launch its new PlayStation 4 console this holiday season. No specific date or price was revealed during the reveal event.

The PS4's main features include:

  • - New DualShock 4 controller with built in touchpad
  • - Dramatically improved graphics and processing power
  • - Based on same X86 chips used in desktop computer to help game developers
  • - 3D camera that can track the controller, and the player
  • - Games can also be played on Sony's Vita handheld console

8492669461_b49583fd3c_z.jpg

The future of PlayStation is all about great games and entertainment, and at PlayStation Meeting 2013, we brought some of the brightest and most creative minds from the development community on stage to unveil the games that will define PS4. A partial initial lineup for PlayStation 4 includes first-party games from Guerilla Games (Killzone: Shadow Fall), Sucker Punch (inFamous Second Son), Evolution Studios (Driveclub), and Japan Studio (Knack), as well as titles from our partners such as Activision/Bungie (Destiny), Blizzard Entertainment (Diablo III), Capcom (Deep Down), and Ubisoft (Watch_Dogs). PlayStation also reinforced its commitment to self-publishing and the independent development community by having Jonathan Blow onstage who gave a sneak peek of his upcoming title The Witness. Finally, the incredible minds at Media Molecule and Quantic Dream gave glimpses of their conceptualization process and the future of gameplay with some remarkable footage. We only scratched the surface at the event, and will have many more exciting titles to come.

8493773646_10ac209e68_z.jpg

Our next generation console will change the way you interact with friends while you play. PlayStation 4 lets you instantly share images and videos of your favorite gameplay moments on Facebook with a single press on the DUALSHOCK 4 controller’s “share” button. You can also broadcast while you play in real-time through Ustream, allowing friends to comment or jump into your game in new ways.

With PlayStation 4 we also want you to access your games quicker than ever before. PS4’s “suspend mode” eliminates the load time on your saved game and allows you to immediately return to where you left off by pressing the power button. PlayStation 4’s background downloading and updating capability also allows you to immediately play digital titles as they download, or update the system when the hardware is powered off.

8493772456_34a85b7767_z.jpg

8493772390_9edab1aa58_n.jpg
8493772388_932586c069_n.jpg

DUALSHOCK 4 adopts the familiar form factor of the DUALSHOCK 3 wireless controller with some key enhancements:
  • - Motion control is enabled by a new highly sensitive six-axis sensor
  • - Dual analog sticks fine-tuned for better precision plus improved surface materials and shape for more delicate manipulation
  • - L2/R2 buttons on the top of the controller employ a curved design for easier, smoother interaction
  • - A new “Options” button combines the functions of the DUALSHOCK 3’s “Select” and “Start” buttons for operating in-game menus

You can see more images of the new DUALSHOCK 4 controller here.
 

Attachments

  • PS.png
    PS.png
    54.7 KB · Views: 7,024
Last edited:
New PS4 OS Images Surface - Tablet/Phone

Store on Tablet

ps4storetablet.jpg


Messages

9351643099_6d5b84557e_z.jpg


Iphone

8524895711_448c46e34c_z.jpg


playstation-4_2013_07a6ugb.png


playstation-4_2013_076yuc5.png


playstation-4_2013_07e9uz0.png


playstation-4_2013_07mmua8.png


playstation-4_2013_073yuro.png


8526009794_1220ca4c19_o.jpg


---------- Post added at 04:43 PM ---------- Previous post was at 04:34 PM ----------

Just FYI, most of these are showing off the tablet look, the last one is full PS4.
 
Last edited:
In Cerny we trust!The cloud computing is really just for AI and online.I don't think it was ever intended to try and boost graphics,just for quicker match making and other little things.I would love to see Sony use it though.
 
AMD: PlayStation 4 supports hUMA, Xbox One does not

Article from Germany's biggest and very reputable IT news site,

http://www.heise.de/newsticker/meld...et-Unified-Memory-Xbox-One-nicht-1939716.html

Translation said:
Although both upcoming game consoles Xbox One and PlayStation 4 are based on AMD hardware, only PlayStation 4 incorporates hUMA [Heterogeneous Uniform Memory Access] for supporting a shared memory space. This was explained by AMD's Senior Product Marketing Manager Marc Diana to c't [big German IT magazine] at gamescom. This should put the 3D-performance of PlayStation 4 much farther ahead of Xbox One than many have expected so far. AMD sees hUMA as a key element for drastic performance improvements in combined processors. AMD's upcoming Kaveri desktop processors support hUMA as well.

Behind the scenes, c't could hear from developers that the 3D-performance of PlayStation 4 is very far ahead of Xbox One.

Back in April, AMD manager Phil Rogers explained to c't that hUMA improves 3D-performance in particular. "Game developers have been eager to use very large textures for years. Until now they had to resort to tricks in order to package parts of larger textures into smaller textures. That is because today a texture has to be located in a special place of physical memory before the GPU can process it. With hUMA, applications can work with textures much more efficiently". AMD will give more details on hUMA at its upcoming developer conference in November.

Update

hUMA: Heterogeneous Uniform Memory Access (Yes, people already made tons of "sense of hUMA" jokes)

http://arstechnica.com/information-...orm-memory-access-coming-this-year-in-kaveri/

Even with the integration of GPUs and CPUs into the same chip, GPGPU is quite awkward for software developers. The CPU and GPU have their own pools of memory. Physically, these might use the same chips on the motherboard (as most integrated GPUs carve off a portion of system memory for their own purposes). From a software perspective, however, these are completely separate.

This means that whenever a CPU program wants to do some computation on the GPU, it has to copy all the data from the CPU's memory into the GPU's memory. When the GPU computation is finished, all the data has to be copied back. This need to copy back and forth wastes time and makes it difficult to mix and match code that runs on the CPU and code that runs on the GPU.

The need to copy data also means that the GPU can't use the same data structures that the CPU is using. While the exact terminology varies from programming language to programming language, CPU data structures make extensive use of pointers: essentially, memory addresses that refer (or, indeed, point) to other pieces of data. These structures can't simply be copied into GPU memory, because CPU pointers refer to locations in CPU memory. Since GPU memory is separate, these locations would be all wrong when copied.

hUMA is the way AMD proposes to solve this problem. With hUMA, the CPU and GPU share a single memory space. The GPU can directly access CPU memory addresses, allowing it to both read and write data that the CPU is also reading and writing.

hUMA is a cache coherent system, meaning that the CPU and GPU will always see a consistent view of data in memory. If one processor makes a change then the other processor will see that changed data, even if the old value was being cached.
As well as being useful for GPGPU programming, this may also find use in the GPU's traditional domain: graphics. Normally, 3D programs have to use lots of relatively small textures to apply textures to their 3D models. When the GPU has access to demand paging, it becomes practical to use single large textures—larger than will even fit into the GPU's memory—loading the portions of the texture on an as-needed basis. id Software devised a similar technique using existing hardware for Enemy Territory: Quake Wars and called it MegaTexture. With hUMA, developers will get MegaTexture-like functionality built-in.

Update 2:

Well explained:

On a classical system you have a RAM pool and a VRAM pool that are physically speperated. Copying data from one pool to the other creates latency. The GPU is very good ad hiding latency. What it needs most is high bandwidth. The CPU on the other hand is extremely sensitive to latency. The CPU needs extremely low latency to work efficiently. Copying data from the RAM (CPU) to the VRAM (GPU) creates latency, but that's okay for the GPU. Copying data from RAM (CPU) to VRAM (GPU) and back to the RAM (CPU) creates even more latency. It's too much for the CPU. The copying alone takes longer than the computation wich makes this roundtrip highly ineffective.

Xbox360 and older APUs have a unified RAM. This means that the RAM is no longer physically seperated, but even though it's the same RAM chips, the system still distincts between memory partition for the differenct processors. You still need to copy the data between CPU partition and GPU partition, but this will be much more efficient than copying it between physically seperated pools. But it's still too much latency for a CPU, GPU, CPU roundtrip.

PS4 will have hUMA wich means that you no longer need a distinction between CPU partition and GPU partition. Both processors can use the same pieces of data at the same time. You don't need to copy stuff and this allows for completely new algorithms that utilize CPU and GPU at the same time. This is interesting since a GPU is very strong, but extremely dumb. A CPU is extremely smart, but very weak. Since you can utilize both processors at the same time for a single task you have a system that is extremely smart and extremely strong at the same time.

It will allow for an extreme boost for many, many algorithms and parts of algorithms. On top of that it will allow for completely new classes of algorithms. This is a game changer.

Update #3

Further evidence: Sony joined the HSA (Heterogeneous System Architecture) Foundation originally co-founded by AMD while Microsoft has not:
http://hsafoundation.com

Update #4

To summarize the evidence so far: we have an article from a respected source, echoing Senior Product Marketing Manager Marc Diana in saying that PS4 implements their hUMA architecture while the XB1 does not. This is followed by the deduction that PS4 will have a significant performance boost over XB1 because of that. It remains unclear what the AMD representative said verbatim. We can only say that c't is as reputable as it gets in the space of German IT publications; that does not make them infallible, of course.

In addition, Sony is part of the HSA consortium while Microsoft is not. Of course, we don't know the political implications of such a membership which may play a significant role along purely technological reasons.

Technology-wise, we can say with certainty that PS4 indeed is a hUMA architecture. Everything we have heard since the release from official sources, especially PS4's Onion/Garlic memory bus layout and the volatile tag on cache lines, confirms that. In addition, Sony has actually advertised this fact quite aggressively, beginning with the Havok GPGPU demo at the PS4 reveal.

We don't know much what the Xbox One does beyond what the leaked documents tell us. And those are ambiguous and not very detailed. At first, it sounds unexpected for it to not support hUMA. Microsoft certainly has implemented a more custom memory system than Sony to manage its DDR3/ESRAM layout, including its DMEs. There is no clear indication about which features of a hUMA architecture might be lacking. Maybe not all memory clients and pools are cache-coherent system wide. The GPU does seem to have to flush its caches when it synchronizes with other clients. However, the article on vgleaks is neither very detailed nor clear, nor do we know if its author recited the original sources correctly. So the relationship between a hUMA feature set and the XB1 is unclear.

Politics-wise, AMD certainly wants to push hUMA since it is part of its own upcoming end-customer products. This would be reason alone to champion the PS4 independent of what the XB1 does, since AMD won't profit from what Microsoft has done with its memory subsystem.

Apart from that, developers at gamescom seem to acknowledge anonymously that the PS4 has a clear 3D-performance advantage over the Xbox One which is certainly a result of many factors, not least because of its beefier GPU and its straight-forward, high-bandwidth GDDR5 setup.

Update 5:

Got a response from the author of the heise.de article.

Edit: Article is accurate as it is presented.

http://en.wikipedia.org/wiki/C't

c't – Magazin für Computertechnik (magazine for computer technology) is a German computer magazine, published by the Heinz Heise publishing house. Originally a special section of the electronics magazine elrad, the magazine has been published monthly since December 1983 and biweekly since October 1997. […]

The magazine is the second most popular German language computer magazine with a sold circulation of about 315,000 (as of March 2011; printed circulation: 419,000). With 241,000 subscriptions it is the computer magazine with the most subscribers in Europe.

Update #6:

The Verge reported back in June on all topics AMD and seems to have included the XB1, although we haven't, again, a direct quote.

That might sound suspiciously vague, but we spoke to AMD and it's actually true. The AMD chips inside the PlayStation 4 and Xbox One take advantage of something called Heterogeneous Unified Memory Access (HUMA), which allows both the CPU and GPU to share the same memory pool instead of having to copy data from one before the other can use it. Diana likened it to driving to the corner store to pick up some milk, instead of driving from San Francisco to Los Angeles. It's one of AMD's proposed Heterogeneous System Architecture (HSA) techniques to make the many discrete processors in a system work in tandem to more efficiently share loads.

http://www.theverge.com/2013/6/21/4452488/amd-sparks-x86-transition-for-next-gen-game-consoles

Update #7:

Apparently, AMD's spokesperson was not supposed to say what he said, so AMD dismissed having said anything.
http://www.nowgamer.com/news/2052820/ps4_vs_xbox_one_amd_retracts_performance_comparison.html

Update from the Heise author:

He had a phone call with AMD and he says that they left open whether Marc Diana's statements are true or untrue. He also says that AMD made pretty clear that they're not allowed to talk about PS4 or Xbox One

"AMD ließ auch während eines Telefongespräches offen, ob die Behauptungen von Marc Diana der Wahrheit entsprechen oder nicht. Besonderen Wert legte das Unternehmen vor allem auf die Aussage, dass die Firma keine Aussagen zu den Produkten seiner Kunden treffen darf – also auch nicht zu Sonys Playstation 4 oder Microsofts Xbox One."

http://www.heise.de/newsticker/meld...et-Unified-Memory-Xbox-One-nicht-1939716.html
 
  • Like
Reactions: hiratafabio
Cerny: PS4 devs will get more out of the hardware in "year 3 or 4"

"We set our target at 10 times the PlayStation 3's performance, because that's what we felt we needed to achieve in order to differentiate the titles," Cerny said. "When I did pitches to developers about the hardware, I talked about what I call the Akihabara test. Akihabara is a electronics district in Tokyo, it's just full of stores where you can buy just about anything you plug into a wall socket. I knew that at some point, there'd be out on the sidewalk a PlayStation 3 and PlayStation 4, and they might even be showing the same game, and the PlayStation 4 had to be powerful enough that when people walked by, they had to look at the PlayStation 4 and say, 'Wow, I have to have that.'

"Believe it or not, at the PlayStation 3 launch, I was hearing a lot about how PlayStation 3 graphics aren't really different from PlayStation 2," Cerny said. "I think that speaks to both how large people's expectations are, and also how launch titles are not fully exploiting the hardware."
Cerny clarified that developers aren't having any trouble grokking the architecture of the PS4 — being easily understandable to devs is one of the console's core philosophies. But it may take time for them to learn how to fully utilize the tweaks Sony made to the architecture they're already familiar with.

"It's a supercharged PC architecture, so you can use it as if it were a PC with unified memory," Cerny said. "Much of what we're seeing with the launch titles is that usage; it's very, very quick to get up to speed if that's how you use it. But at the same time, then you're not taking advantage of all the customization that we did in the GPU. I think that really will play into the graphical quality and the level of interaction in the worlds in, say, year three or year four of the console."

http://www.polygon.com/2013/8/27/46...ore-out-of-the-hardware-in-year-three-or-four
 
Thanks for the articles, it's interesting to see the kind of tech inside the box. I would hope they focus on really harnessing the power of the system rather than sitting back saying they got better hardware than M$.
 
Thanks for the interesting articles! I´m looking Forward to my PS4 but it´s still interesting to see what M$crosoft is planing for their XB1
 
SCE Japan/Asia press conference to be held on 9/9 [JP launch date will be announced]

http://commu.jp.playstation.com/blog/details/20130821_scej_pc2013.html

Japanese details on PS platforms incoming.

Update:
http://stream.wsj.com/story/latest-headlines/SS-2-63399/SS-2-305764/

Sony said it will announce the launch timing of the PS4 in Japan at a Sept. 9 news conference. Sony declined to say when the launch date would be, but the expectation is that Japan will not be first this time around.
 
PlayStation 4 hUMA implementation and memory enhancements details - Vgleaks

As we promised in our previous article, we present new information about the enhancements in the memory system in PlayStation 4.

http://www.vgleaks.com/more-exclusi...plementation-and-memory-enhancements-details/

Bypass Bits

- If many of these sorts of compute shaders are being run simultaneously, there is “cross talk” in that one compute dispatch may forcé an invalidate or a premature flush of another dispatch’s SC memory

- As a result of this (and other factors), it may be optimal to bypass either the L1, or the L2, or both

Bypassing all caches for the accesses to the shared CPU-GPU memory (effectively making the data UC rather than SC) will remove the need for the invalidates and writebacks of L1 and L2
At the same time, there will be more – perhaps much more – traffic to and from system memory
- It is possible to change the V# and T# definitions on a dispatch by dispatch basis when exploring these issues and tuning the application

- However, in order to allow for a more stable and debugable programming approach

Two override bits have been added to the draw call and dispatch controls
The L1 bypass bit specifies that operations on GC and SC memory bypass the L1 and go directly to L2
The L2 bypass bit specifies that operations on SC memory bypass the L2, using the new “Onion+” bus
This allows the application programmer to use same shader code and V#/T# definitions, and then run the shaders with several different cache flush strategies. No recompilation or reconfiguration is required

Four Memory Buffer Usage Examples

1) Simple Rendering

- Vertex shader and pixel shader only; the pixel shader does not direct memory accesses

- Vertex buffers (RO)

- Textures (RO)

- Color and depth buffers are written using dedicated hardware mechanisms, not memory buffers

2) Raycast

- In order to compute visibility (“can the enemy see the player”) or sound effect volume (“is there a direct path from audio source to player”), sets of 64 rays are compared against large triangle databases

- Triangle databases (RO)

- Input rays (SC)

- Output collisions (SC)

- The raycast probably doesn’t use much SC data and could potentially entirely bypass L2

3) Procedural Geometry (e.g. water surface)

- The CPU maintains a high level state of the water (ripples, splashes coming for interactions with game objects). The GPU generates the detailed water mesh, with is used only for rendering

- Input: water state as maintained by CPU (SC)

- Output: detailed water surface (GC)

4) Chained compute shaders

- Compute shaders write semaphores for the CP to read, enabling other compute dispatches (and perhaps draw calls) to run. They also add packets to compute pipe queues (perhaps packets that kick off more compute dispatches)

- Various buffers (RO, PV, GC, SC)

- Semaphores (UC)

- Compute pipe queue (UC)

- NOTE that CP does not have access to the GPU L2, so semaphores and queue contents must either be assigned the SC memory type (visible to the CP only after a L2 writeback) or the UC memory type (which bypases the L2)

- Using UC can allow for greater flexibility, e.g. a compute dispatch can have several stages that send and receive semaphores. Using SC requires the dispatch to terminate before the semaphore is visible externally

Strategies for Scalar Loads

- In addition to the “gather read” and “scatter write” loads into VGPRs (Vector GPRs), the R10xx core also supports scalar reads and writes into SGPRs (Scalar GPRs)

Typically, scalar reads are used to load T#, V#, and S# structures, as well as any other data that applies to the wavefront as a whole (as opposed to the vector reads that load data on a thread-by-thread basis)
- These read operations use the L2, but instead of the L1 they use a different cache called the “K-cache”. There is one 16 KB K-cache for each three CU’s

The K-cache must be invalidated when there is the possibility that it may contain “stale” data, e.g. a later draw call or dispatch uses the same location in the T# (etc) ring buffer as an earlier call
K-cache invalidation takes 1 cycle but dumps all data, resulting in a high cost
The most straightforward way of reducing the invalidation count is to use larger ring buffers for the scalar input data to the draw calls and dispatches

Performance

- Performance of the L2 cache operations is much better on Liverpool than on R10xx

- The L2 invalidate typically takes 300-350 cycles

All in-flight memory transactions must settle before the invalidate can be completed
A small overhead (about 75 cycles) is required to locate and invalidate the lines
This results in the direct cost listed above. There is also an indirect cost, in that invalidated SC data must potentially be reloaded
- The cost of an L2 writeback depends on the amount of data that must be written back to system memory

The Onion bus can support 10GB/sec, which means 12.5 bytes/cycle (0.2 lines/cycle)
If we attribute 160 GB/sec of the Garlic bus to the GPU, the bus can support 200 bytes/cycle (3.125 lines/cycle)
- If there is only a little SC dirty data present in the L2, the writeback is fairly fast

4K bytes worth of dirty Onion SC lines will take perhaps 500 cycles (Onion bottleneck PLUS small overhead to locate lines PLUS latency to system memory)
20K bytes worth of dirty Garlic SC lines will take about the same time
- Worst case L2 writeback cost is basically the Onion or Garlic cost of writing 512 KB (about 40,000 cycles and 3,000 cycles respectively)

Additional Optimizations

- There are additional further optimizations in the L1 and L2 caches

- The L2 cache has dirty state tracking

If the L2 has performed no reads from SC memory since the last invalidate, it will ignore any requests to invalidate
If the L2 has performed no writes to SC memory since the last writeback, it will ignore any requests to perform a writeback
This will help performance in the situation where multiple pipes are requesting invalidates and writebacks, e.g. several compute pipes are separately dispatching compute shaders that use SC memory
- The L1 cache can be invalidated “once per CU”

A dispatch may send multiple wavefronts to a single CU
Using this option, the invalidate of GC/SC occurs only on the first wavefront of the dispatch

Added Custom Direct X 11 support: Can utilize the Direct X 11 feature set

Developers will be able to take advantage of Microsoft’s latest industry standard DirectX API — DirectX 11.1, but Sony has taken the time to improve upon it, pushing the feature set beyond what is available for PC games development.

Those improvements include better shader pipeline access, improved debugging support features out the box, and much lower level access to the system hardware enabling developers to do “more cool things.” That’s achieved not only through an modified DirectX 11.1 API, but also a secondary low-level API specifically for the PS4 hardware.

http://www.geek.com/games/sony-iimprove-directx-11-for-the-ps4-blu-ray-1544364/

I also noticed that Xbox One GPU is DirectX 11.1+ & PS4 GPU is DirectX 11.2+

DirectX_11.2__PS4-pcgh.jpg
 
I'm not sure why people would want to do that, I suppose to save space on the main drive, but what if if that ext HD isn't always connected or dies?