Predict: The Next Generation Console Tech

Sony sure loves that Linux. It'll be interesting to see if they go dual boot having XMB and Other OS again. I hope they combine them though to switch on the fly.

 

Yep, quite a compelling vision. It does look like a son of Cell; an application level Cell so to speak. ^_^

If they do pursue that route, it may take years to realize. It looks hot and expensive too. Perhaps we will see a simplified first cut first ?

 

I see. Then Shifty is probably right. Without further info from Sony, it's perhaps for Big.little stuff or other future use.

EDIT: hmph, I haven't hot dock a Vaio Z before. Not sure if the GPU will switch over seamlessly. Probably not ?

 

While the PS4 specs sound convincing, the Durango ones do not. I mean, all the millions MS is supposed to be spending and all the people they have hired to launch such a modest specs... Don´t get it.

 

Also if we still believe in their roadmap Cloud Sauce will come soon in 2015/16. So they don't have to worry about a potentially weak box...

 

They going to run fiber to everyone's house by then?

 

On Vita, you can switch seamlessly between the web browser and game, but when one is running, the other quits automatically. This should allow the game to use as much resources as possible. They may be able to add a snapshot feature to preserve app state later.

As I recall, the Sony engineers said at Vita launch that the web browser can't coexist with the game. But there is a backdoor. You can launch the web browser via the Twitter app while a game is active. However, at this point, the web browser will run out of memory if the pages are too complex.

For a start, they should just freeze the app state and swap, instead of attempting true multitasking. Hopefully, the high memory bandwidth and storage throughput is fast enough.

 

Beta launch in 2015. Xbox Live Diamond subscribers trial run @ $50 / mo. MS partners with cable companies to work with the infrastructure.

Yeah hopefully they can figure out true multitasking by PS4. If it doesn't, NBD but MS will surely have PiP, video chat, browsing and all while gaming.

 

So the App state assuming you can pause/resume anywhere, and you don't force developers to jump through hoops is pretty much all of memory.
On a 4GB box you have to store and recover that, being nice and putting that copy on the fast part of the HD or SSD you have transfer it off to resume your game at say 100MB/s, so you'd be looking at ~40 seconds to save/resume a game, far from instantaneous from game to browser or browser to game. Now yes maybe you drop that to only save/resuming 1GB, that's still 10s.
And that's before the security guys get a hold of your proposal and decide that you can't store the unencrypted game memory on the HD.

 

They already solved that.

 

Which is also included in the Yukon document.

Here´s an interesting paper written by a spanish forumer. He´s an engineer, but has not insider info nor something, I hope he has not problem with me posting his articles, I wouldn´t hasve done it, but XpiderMX has already posted some of his info and apparently he has no problems with it:

http://josepjroca.wordpress.com/2013/01/14/construyendo-a-durango-i/

He believes the leaked Yukon document implies the GPU clock will be half the CPU one. The Yukon document claimed the CPU cores will be 2.0 Ghz and the GPU clock was going to be 1 Ghz. If the Jaguar cores run at 1.6 Ghz, it seems likely (following this logic) that the GPU clock speed will end up at 800 Mhz.

 

32MB SRAM is at least 85 mm², right? Probably more than that.....

 

It's ESRAM, which should be a form of 1T-SRAM. The density is comparable to eDRAM, so 32MB ~ 32 mm^2

 

Cool, they must have solved that after I lost my Vita. ^_^

I am also wondering if they will take the Vita memory card to the general Android platform to safeguard their content eventually.

They will have to figure out a way, including ceding control to the game/app to decide what to save. Or via more hardware assisted solution (working memory + compression ?). Or both. For web browser, you really only need to save the opened URLs, scroll position, input fields, and credentials. For games, it'd be your immediate snapshot for example.

Some stuff can also unload asynchronously (if at all) because an app typically doesn't need to take all 4Gb at once. I believe there is a memory upper bound for apps on Vita.

 

If it's a form of eDRAM than density may be even better than that. IBM claims a density of >11 Mbit/mm² for eDRAM on their 32 nm process.

 

I really think people should move away from flops as a measure of performance, especially for the Durango. I think everyone is privy to the fact that not all flops are equal, and Durango flops are the "best" flops you'll seen yet. If my understanding of some general technical details are correct, they're substantially better.

Bkilian? What say you?

 

Ahh it sounds so easy if I told you how many man hours most game developers waste on getting save games to restore state, and that's usually only at specific points, you wouldn't believe me.
Games aren't browsers that can be restored from URL and a page position, with the user not caring about the discrepancies.
Restore anywhere in a game (short of just dumping memory) is at best hard and in the case of retrofitting it, probably hard enough it's not feasible, so I don't think a platform owner could practically dictate it to developers.

Of course the easy answer is just to reserve a shit load of memory for the OS and apps, as various Durango rumors suggest.

There are other possible solutions, you could have a specific shared transient memory pool that the OS reserves the right to flush, say 1GB, games would be responsible for responding to requests and restoring it. In principle that's fine, but IMO it's a testing nightmare.

 

Could you share with us something more? Have they considerably change the GNC architecture?

 

Yes it's definitely easier if it's hardware assisted ^_^ and yes, not all 4Gb blindly.
How efficient is compression these days for compressing memory image ?

If it's easier to throw away app states, then the OS can exploit this characteristic too. Basically try to keep game state in-memory where possible.

 

I think they mentioned low latency... since access to data is shorter and quicker, if they are in the fast pool of memory. The FLOP meaning stays the same unless the operations are higher level.