Bagel seed
Veteran
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.
liquidboy said:
It's not a simple laptop type GPU switching thing. The patent calls for completely seamless rendering switch with no hiccups and provisions for SLI.
Special Sauce(tm) says hi.
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...
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.
They going to run fiber to everyone's house by then?
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.
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.
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.
THIRTYTWO MB ESRAM
32MB SRAM is at least 85 mm², right? Probably more than that.....
They already solved that.
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.
It's ESRAM, which should be a form of 1T-SRAM. The density is comparable to eDRAM, so 32MB ~ 32 mm^2
For games, it'd be your immediate snapshot for example.
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 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.
You don't need that for games. He is just hinting at an architecture with an higher efficiency I guess.