How big a OS footprint does the 360 have?

[heliosphere]

32MB is an incomprehensibly huge amount of space for what is essentially almost no real actual work. Ok, so the OS presents function calls to render 3D graphics and presumably, sound streams, loading and saving data to disk and flash, some I/O and so on.

As others have pointed out it's not that unreasonable when you look at what they need to keep in memory. There's going to be a fair amount of memory used for render targets that they draw the in-game pop-up blades on before compositing them over the game's output. There's another chunk for textures for fonts and graphics used by the UI. There'll be buffers for playing audio for custom soundtracks and voice chat. Add in some working memory and the code and you can see how that 32MB starts to get used up. They're probably not using all the reserved memory right now but by reserving more than they strictly need they leave room for adding new functionality in the future. If after a year or two it turns out they don't need all 32MB they can always reduce it and give games released later in the console's life cycle a bit more memory to play with.

 

[scooby_dooby]

The dashboard is more of an application and can take all the ram it wants as it runs exclusively. "OS GUI components" would include the in game pop-ups and the guide button blades.

Ok, but the point stands. MS has stated a portion of the reserved space is to give them the headroom to add future functionality.

 

[Shifty Geezer]

Edit : I'm responding to the wrong thread.

 

[Guden Oden]

As others have pointed out it's not that unreasonable when you look at what they need to keep in memory.

Like hell it isn't. A render target for the blade huh? Why would it need to rendertarget it to begin with when it could just draw it straight into the framebuffer. And textures and fonts don't require megabytes of memory. What textures by the way, I'd rather seen a smaller memory footprint and no ugly crappy fake brushed metal background on the blade. Audio buffers need only a couple kilobytes at most each. Insignificant.

but by reserving more than they strictly need they leave room for adding new functionality in the future.

There's that side of the issue, yes I agree. Then there's going completely overboard as well. 32MB is a *HUGE* amount of memory when one really looks at it. Today when a friggin graphics card control panel on the PC consumes roughly half that much people tend to get their perspective rather distorted. Therefore one should take a step back, look at what software used to look like in the past when people's computers did not have memory installed that ranged in the hundreds of megabytes, or even thousands for some.

Why would a 360 need to reserve memory for holding graphics in memory constantly just for the custom blades, when it pauses a game as soon as the blade pops up on screen anyway? It could load the gfx, fonts and such nearly instantly from HDD or flash when it needs to be used, no problem.

 

[Titanio]

Back in the day, I had an Amiga A500 with 1 MB RAM using the over-expensive official CBM Ram extension. As an experiment once I got it multitasking upwards of 20 applications including a demanding 8 track audio program called OctaMED. OctaMED never showed any signs of faltering while the other apps, though running extremely slowly, didn't suffer either. Damned impresssive OS.

See how your Amiga does decoding a 1080p video stream with one of the new audio codecs That's the type of thing even a mid-end PC today would struggle to do alongside anything else, like running a high-end game.

Doesn't PSP manage a fair bit with only 8 MB RAM reserved, including updates like Flash support up and coming?

A single 1080p buffer on PS3 will occupy 8MB. And the OS will probably need to maintain at least two (one for each supportable screen).

Are 8 1080p screens really going to need to be preserved in RAM during a game?

No, but at least two. + buffers for at least one PSP, I'd imagine, although their contribution is much smaller, obviously. Possibly more, but at least two.

What exactly is PS3's OS supposed to be doing while games are running? I'm still unsure on this matter.

So far they've announced "Digital Video, Digital Audio, Digital Photograph, Computer Entertainment, Video Communication, Internet Access" as being things you'll be able to enjoy simultaneously with gameplay. To concretise that, it seems many of these things will be doable via pop-windows on one screen, or spread across two. It seems quite possible that with a blu-ray movie copied to the hard disk, PS3's OS will need to be able to decode and display that 1080p stream to the second screen - with resource reservation that implies. Even if 1080p movie playback isn't supported while games are running, if the media is to be upscaled, a 1080p memory footprint probably needs to be reserved. The system is supposed to also act as a media server to local or remote PSPs, and obviously that needs to be available at all times.

There have been rumours about other things, like PVR and video blogging, served off your own machine - but we'll see how that pans out.

Just checking my current PC I'm using about 30 MB with a graphics application, web editor and Flash editor program concurrently. PS3 isn't going to be that sort of thing while gaming, is it?!

No, but it could be doing many of the above mentioned tasks simultaneously. Some may be one by one, but others would need to be available at all times. And you have to reserve based on the worst case. That might be a 1080p stream with HD audio being decoded; two PSPs being served media (one remote, one local), perhaps with transcoding, custom track playback for a game, multi-way video chat, and as rumoured, PVR and video/blog serving all at once. A REAL worst case scenario could be if "one-by-one" functions had to be available to two users at once, such that a web browser, for example, could be open on both screens simultaneously, or whatever.

It's all mindless conjecture until we know what these resources are for, and then we can have a fair discussion as to whether these are useful, desirable features and whether we think they are implemented efficiently.

The simple fact is that when you're dealing with HD, and possibly also HD media, RAM requirements can go way up. Like I showed already, a simple buffer for the OS would require as much RAM as PSP's entire OS, simply because of the resolution.

And yeah, we're not totally aware at all of what the PS3 OS is supposed to be able to do alongside games, but from what's been suggested to date, it should be fairly evident the requirement will be steeper than any previous system.


edit - I see your point, Guden, about blending overlays or whatever onto the existing buffer versus reserving a seperate one, but AFAIK reserving the buffer is what's been done in other systems (like PSP). I don't know if there are complications that prevent simply drawing to the existing framebuffer. Asides from that, though, even if you could get away with not reserving a buffer for the "game screen", whole seperate buffers for the second screen and any PSPs would be required on PS3.

 

[heliosphere]

Like hell it isn't. A render target for the blade huh? Why would it need to rendertarget it to begin with when it could just draw it straight into the framebuffer. And textures and fonts don't require megabytes of memory. What textures by the way, I'd rather seen a smaller memory footprint and no ugly crappy fake brushed metal background on the blade. Audio buffers need only a couple kilobytes at most each. Insignificant.

You can't just draw straight into the framebuffer because Xenos can only render to EDRAM, the framebuffer that's displayed has to be resolved from EDRAM to main memory. Games nowadays can do all kinds of crazy things with post-processing effects, multiple render targets, HDR tone mapping, etc., not to mention complexities with predicated tiling on 360. The simplest way to avoid running into problems playing nicely with a game's rendering is to render all the UI into an offscreen render target and then do a final composition pass before present using the UI and frame buffer as textures when drawing to EDRAM. I don't know for sure that's what they're doing with the 360 HUD stuff but I suspect it's something like that.

Textures and fonts can easily require MBs of memory, it all depends what's being stored. As well as backgrounds and UI elements the 360 presumably has to store the little pictures for people's gamer tags, icons for the memory cards and HD etc., have enough space to store complex fonts for languages like Japanese and probably a fair bit else. That all mounts up, espescially when you have to make sure everything looks good in HD resolutions. Audio buffers can need quite a bit more than a few KB when you're dealing with compressed audio.

I agree that 32MB is a lot of memory but I don't think it's as unreasonable as you seem to, espescially given that some of it is there for future proofing. Times have moved on from the days of the Amiga and 32MB just isn't that much any more, hell it's hard to find a PC graphics card with less than 128MB these days. That's not all due to programmer laziness, it's a result of much higher expectations on what a system has to do nowadays.

Why would a 360 need to reserve memory for holding graphics in memory constantly just for the custom blades, when it pauses a game as soon as the blade pops up on screen anyway? It could load the gfx, fonts and such nearly instantly from HDD or flash when it needs to be used, no problem.

You can't rely on the HDD being present and there is no flash memory other than what the firmware is stored on. Some of the gfx you need are not known when the system starts up (gamer tag pictures and the like) so not all of them can be stored in the system flash memory. Even if that were not the case if you didn't reserve the memory in advance you'd have to have a way to notify the game that it had to make more memory available. It's simpler for everyone if the memory is reserved in advance rather than the game having to potentially find MB of free memory at any arbitrary point in time. Also, not all HUD elements pause the game - things like sign on notifications, instant message notifications and unlocked achievement notifications can all pop up onscreen during gameplay without pausing.

 

[Barbarian]

I probably will if it turns out to be true!
These numbers seem a bit too rumor-esque at the moment methinks so I wait a while for confirmation before going ballistic on this one.

Well, all I can say is, brace yourself for the truth ....

 

[idsn6]

Hi.

This March, I attended a tech talk at the University of Maryland by Paolo Malabuyo ("Lead User Experience Program Manager in the Entertainment Experience Group at Microsoft") on the development of the 360. He spoke about the standard design choices with prototypes, the "inhale" theme, non-gaming features, Apple design influence, and so on, but also mentioned that the 360 OS occupied a memory footprint of 2.5 MB (prompting the question from the audience, "When are you planning on doing something similar with Windows?").

This number apparently includes the blade interface, which is vector-based and so takes up very little space.

 

[pipo]

Also, not all HUD elements pause the game - things like sign on notifications, instant message notifications and unlocked achievement notifications can all pop up onscreen during gameplay without pausing.

This is also true for the dashboard. As far as I know the dev decides if he wants to pause his game or not...

And on the 2.5MB topic; I'm pretty sure it was the graphics limit.

Edit - found it:

On the original XBOX there were 45 screens that needed to fit on 250MB while on the new design and complexity of the system there were 450 screens. These screens had to fit on 2.5MB. To accomplish this was quite a feat.

http://experienceucd.com/index.php?option=com_content&task=view&id=20&Itemid=48

 

[Fafalada]

You can't just draw straight into the framebuffer because Xenos can only render to EDRAM, the framebuffer that's displayed has to be resolved from EDRAM to main memory. Games nowadays can do all kinds of crazy things with post-processing effects, multiple render targets, HDR tone mapping, etc., not to mention complexities with predicated tiling on 360.

This is all irellevant if you are just overlaying items on top of final rendered image. OS only needs to know where the framebuffer ready for scanout is located and composite it with the rendering.

That said - OS clearly needs to know something about each game for this (FB address at least). And since CRT circuits usually have compositing capabilities of their own, and if you have a mode for blending two buffers reserved, you can then keep OS completely separate from the App (as far as rendering goes) - but it will cost some extra reserved memory.

Not that I would know what MS is doing, but it really comes down to either OS cooperating with the apps a bit(which could cost some flexibility in terms of how render buffers are setup), or wasting more precious memory.

 

[Titanio]

Hi.

This March, I attended a tech talk at the University of Maryland by Paolo Malabuyo ("Lead User Experience Program Manager in the Entertainment Experience Group at Microsoft") on the development of the 360. He spoke about the standard design choices with prototypes, the "inhale" theme, non-gaming features, Apple design influence, and so on, but also mentioned that the 360 OS occupied a memory footprint of 2.5 MB (prompting the question from the audience, "When are you planning on doing something similar with Windows?").

This number apparently includes the blade interface, which is vector-based and so takes up very little space.

In the context of the figure for Xbox, I think that's talking about storage space required not in RAM, but in persistant storage. The RAM requirement would go beyond the assets used to generate the display (in the Xbox's case, probably big textures/graphics etc - since they had a HDD - in 360's case, vector graphics).

 

[PiNkY]

Yeah 2.5MB is propably close to 360's eeprom size. Not all units come with a hard drive and you can still use the dashboard without a memory card present...

 

[idsn6]

http://experienceucd.com/index.php?option=com_content&task=view&id=20&Itemid=48

Yep, almost identical presentation. I think he's even wearing the same outfit.

And yes, that figure being the amount in ROM and not RAM makes perfect sense.