A way around RAM limitations for consoles?

[makeitlookreal]

Here is an interesting website discussion how a PC game was created using only 96K of memory. Of course it's only *one* level and obviously not quite the level of detail as a PS3 game.

http://www.gametomorrow.com/blog/

On that site there is a link to a secondary site with even more screenshots.

http://en.wikipedia.org/wiki/.kkrieger

Now, my question is this. Is this a way around RAM limitations or would this only save space on the gaming disk? I'm not sure exactly how this would work, but can it save the ammount of RAM you need for a particular frame of a game?

[RavenFox]

I think someone discussed this on B3D before...hmmm I think. XB does this ring a bell? I think the game took forever to load or something like that.

[Freeman_JI]

You don't get something for nothing! I've tried the kkrieger demo and was impressed by how such nice graphics fit into such a small download/package.

This however is more to do with disk space saving than Ram saving, the required specs for this demo are quite high

* 1.5GHz Pentium 3 / Athlon or faster
* 512MB of RAM
* GeForce 4Ti (or higher) or ATI Radeon 8500 (or higher) graphics card supporting pixel shader 1.3
* DirectSound-compatible sound hardware
* DirectX 9.0b
* Microsoft Windows
* 96KB disk space
Sorry you have storge memory and random access memory confused.


.kkrieger makes extensive use of procedural generation methods: Textures are stored via their creation history instead on a per-pixel basis, thus only requiring the history data (possibly as low as ~300 bytes per texture at any resolution) and the generator code to be compiled into the executable, producing a relatively small file size. Meshes are created from basic solids such as boxes and cylinders, which are then deformed to achieve the desired shape - essentially a special way of box modeling. These two generation processes explain the extensive loading time of the game - all assets of the gameplay are reproduced during the loading phase.


According to the developers, .kkrieger itself would take up around 200-300MB space if it had been stored the conventional way.


just to point out this technology would benefit the xbox360 more so than the PS3

[makeitlookreal]

Ok. I guess I was confused. Your right. This technology would benefit the Wii and 360 more so than the PS3 because the PS3 already has Blu-Ray. But if this technology can help cut down how many artists a dev has to use then it could help everyone.

[xbdestroya]

RavenFox if you have a link to that discussion, feel free to drop it in here. I personally don't remember that conversation - but then again I only click on certain threads as well (here there and everywhere).

But reading it right now I will say a couple of things:

1) compute power required for what they are talking about is immense

2) the poster is Barry Minor in the blog

3) I have recently spoken with someone who believes strongly in tapping Cell for procedural synthesis purposes

4) ...and that this whole thing (as presented by the developer) is more of an alternative to growing code storage needs (think the antithesis of Blu-ray) rather than something to save on RAM while the game is running.

I think that last one is a key point here, since it is of course the key 'hope' held out by the thread concept.

EDIT: Ok, credit to Freeman for beating me out. :smoke:

[xbdestroya]

But if this technology can help cut down how many artists a dev has to use then it could help everyone.

Yes this is true.

I'll go ahead and throw in that the way they're describing it, it actually could assist with the RAM footprint as well since the textures are generated on the fly, rather than at boot/load like in kkrieger. I'm honestly not sure I'm clear on what the trade-offs would be persistance vs bandwidth savings; like would regeneration of textures preclude a consistent experience across re-traced areas?

[makeitlookreal]

Perhaps I am just confused about the way GPU's are setup internally. If you can generate textures on the fly through SPE's can you feed that data strait through to the screen instead of having to load them with all the other regular textures in the VRAM?

For example, the clouds in WarHawk. Do they get stored in the VRAM just like everything else OR can they just be pushed strait to the screen? I mean, if you can generate stuff on the fly and save room in the RAM this would be a great savings and since the PS3's SPE's are pretty powerful you could probably generate a LOT of textures very quickly.

[Beenie Man]

Wasn't the Cell made to do huge multimedia tasks and applications and calculationg things in real time(meaning calculating as the events happen without prescripted CPU usage like Sony and Ken Kutaragi stated last year).

[GTShotoKen]

Wasn't the Cell made to do huge multimedia tasks and applications and calculationg things in real time(meaning calculating as the events happen without prescripted CPU usage like Sony and Ken Kutaragi stated last year).

That's very true.

After reading about this idea I looked up procedural generation on wiki. It said that the limited cache alloted to each SPEs in cell might limit the true abilities for the cell to procedurally generate a large portion of game code, thus limiting the true capabilities of procedural generation on the Cell.

The article itself was very informative though.

Here's the whole article:

http://en.wikipedia.org/wiki/Procedural_generation

The Cell's counterpart to Xenon "cache locking" is each SPE's 256 KiB local store, essentially L2 cache memory which can be accessed directly, rather than being used to speed up access to main memory. This approach has both perks and flaws, as it allows each SPE to work extremely quickly, but only on a small subset of the total data of a program.

However, the limited cache available to the SPEs may be offset by the FlexIO direct connect to the RSX, which allows the Cell to quickly offload the code for the gpu to render.


Edit: I actually remember the whole 96kb shooter from a long while back (before I joined PS3Insider I think). The unrealops website was going crazy over the concept when it was released, so I downloaded it and played it. I was surprised by the graphics, and was even more surprised by how much it hitched up my old system (mainly because I only had 512MB of PC2100 ram). It looked very impressive for its extremely small size, but the action wasn't all that great. Every weapon had the firing effect and the enemies were lame...but the concept was still cool as hell though!!!

[xbdestroya]

The local stores are plenty big to execute procedural generation, it just depends mainly on how the code itself is written. There are certainly ways to get it to operate nicely within the 256KB.

[GTShotoKen]

The local stores are plenty big to execute procedural generation, it just depends mainly on how the code itself is written. There are certainly ways to get it to operate nicely within the 256KB.

That's certainly uplifting. :)

Crap, for some reason I've gotten excited over the Cell and RSX again....:lol:

Time to dig up some more tech articles to read again...for myself mostly, since we already have a decent set of guys to do that (I haven't done that myself in a LONG time though lol).

[makeitlookreal]

XBD,

Can you tell me if it's possible to use this technology to reduce the texture memory foot print in the VRAM? Or is this totally just about the HDD or game disc?

Gaming Guru,

You have to look at it this way too. The CELL has much more than 256K of memory. It has 7 SPEs and one reserved for he OS. You see, the best way to run code of almost any kind on the Cell is to break it down into lots of little pieces of tasks and send them along with all the other bits of tasks to the SPEs and distribute them automatically. This technology would be able to utilize the not just 256K of memory, but potentially even more!

Hopefully, no programmer will leave this task just for a single SPE but will balance and optimize the load by breaking up this task into tons and tons of tiny threads and passing them around.

Imagine six monkeys sitting in a circle. Instead of just one of them putting together a toy you could have each of them put together one tiny part of the toy and then pass it to the next monkey very quickly. They would all be working on multiple toys and distributing the work load efficently. That way if one monkey gets done with his toy another monkey will hand off more work to idle monkey!

[xbdestroya]

XBD,

Can you tell me if it's possible to use this technology to reduce the texture memory foot print in the VRAM? Or is this totally just about the HDD or game disc?

Well, post #6 in this thread basically comprises all the thoughts I have on the matter. I have questions myself honestly, so I'm not sure I'm in the key position to be answering them. But yes those concerns I voice aside, it should be able to help with RAM utilization and bandwidth.

Keep in mind this is not some technique exclusive to Cell or anything, it's just something Cell should excel at.

There's really nothing I can add beyond what Barry Minor himself posts, so before we get too wrapped up in analysis upon analysis, let's be sure to go back to the source and keep things simple. :)

[GTShotoKen]

That's a great analogy MILR, but you worded it like I was a toddler. :lol:

I know exactly how the parallelization of the game code within Cell will allow devs to fit information within the small cache given to each SPE.

I was merely saying that the article was stating that the Cell couldn't produce procedural synthesis on as large of a scale as its power permits because limitations in cache size will eventually cause memory constraints. :)

This however might not be the case at all since the data from cell can be quickly offloaded to the gpu for processing with the FlexIO interface.

Xbdestroya has also said that the 256kb cache of the SPEs will still be more than enough for most procedural synthesis operations, so I guess the Cell is more than up to the job.

[CreativeWriter]

That's a great analogy MILR, but you worded it like I was a toddler. :lol:


That and monkeys don't make toys :laugh: . Seven people in a circle works just as well. An Xbox fan might argue that 3 people in a circle (Xenos) works much better than 7 monkeys (Cell SPEs)... I guess the analogy doesn't consider the PPU either. 7 monkeys pass along parts of a toy to... a great ape? Magilla Gorilla? :spit:
http://www.cfhf.net/lyrics/images/magilla.jpg
Anyone else remember those old cartoons on the USA network? They had cartoon Olympics or something. I was very young.

[frosty]

where's the ultimate wet blanket on this one, I'd like to hear his input on it.

[warmachine]

I think this has already been discussed in some Blu-Ray vs. HD-DVD thread or some thread about compression technology, and afair cpi also explained a lot about the .kkrieger demo.

[makeitlookreal]

Gaming Guru,

I was not purposely trying to explain it in an insulting way. It was very late at night and my mind starts thinking in very abtract and bizzare ways. For some reason, monkeys just came to mind. If I offended you then I do sincerely apologize.

I will try to find CPI's comments about this and post them here.

EDIT: Here is a quote from CPI.

http://www.beyond3d.com/forum/showpost.php?p=735511&postcount=89

Procedurally generated textures by CELL will be stored in memory - either XDR or GDDR3 - if they are to be used by RSX. First of all, RSX can't make a memory request for a block of texels and have Cell then reinterpret that request in a way to generate texels on the fly to fulfill that request. Secondly, even if this was possible, computationally CELL cannot procedurally generate texels at a rate that would come even close to the speed at which you can simply load texels from XDR. Finally, procedural textures which save bandwidth (usually they're used to avoid repetition) have never been even within an order of magnitude as fast as loading normal textures, so you will degrade performance no matter what.

It makes me think that what he is trying to say is that this technology is not going to be practical because generating texels on the fly when they are needed would take much more time than just automatically reading them from normal VRAM or XDR RAM. It would cause a performance problem because of the lag it creates.

[GTShotoKen]

I guess this is why the processor requirement for such tasks are so high.

I'm very curious about the articles written on the approach this rendering because they say that procedural synthesis can be used to update older games with newer, high-quality graphics without adding or rewriting any extra content. Procedural synthesis can also be used to allow the aesthetics of a title to evolve over time, so a game could potentially never look old. This however would require an insane amount of work from coders and alot of complex code.

[jaxmkii]

Kkrieger generates the art assets at run time as part of the loading process turning the stored mathematical descriptions into megabytes of memory resident textures and 3D geometries. The next step in this area is to generate all these art assets on the fly as they are need in a resolution independent way thereby dramatically reducing the memory foot print if the game, off chip memory bandwidth requirements, and finally removing those annoying fuzzy low resolutions textures that are visible when you walk up close to an object. Next generation processors like Cell were designed to excel at these techniques. SPEs are great noise generators that can churn out gigabytes of dynamic textures and procedurally generated geometry on demand. Moving such techniques from load time to run time will dramatically improve the visual quality of games and produce dynamic ever changing worlds that can be different every time you experience them.

this is actualy old news to me... MSFS (00,04,X) uses a crude type of sceanery generator that works simular to this. the program only knows the shape of the terrain and class of land (and all roads if you download the mods) depending on the landclass it will generate farms or forest cityblocks tundra or desert. they managed to fit the entire globe into 4 CDs (2004 edition at least dont know about X)

[cpiasminc]

EDIT: Here is a quote from CPI.

http://www.beyond3d.com/forum/showpo...1&postcount=89
Ummmm... that's not me. Though it does sound like me.

I guess this is why the processor requirement for such tasks are so high.
And why in pretty much every case, it's all pre-calculated and it just sits in memory to be grabbed on demand. .kkrieger takes a good long while to do this, and a "root" instance of everything used at any point in the game is always sitting there in memory, so it has an enormous memory footprint.

Cases like SpeedTree are no exception. Though that's fundamentally not a bad thing because you want determinism, and tools like SpeedTree are specifically designed to give you the same result for a given set of parameters.

The only exceptions I know of this are all offline processes where you can spend a lifetime generating more if you feel like it.

I'm very curious about the articles written on the approach this rendering because they say that procedural synthesis can be used to update older games with newer, high-quality graphics without adding or rewriting any extra content. Procedural synthesis can also be used to allow the aesthetics of a title to evolve over time, so a game could potentially never look old. This however would require an insane amount of work from coders and alot of complex code.
Mostly dreaming from media crazies who try to make more of something than it is -- procedures are just as static as anything else, and it's in our best interests to always produce the same result every time. I think they assumed that certain procedural techniques involve genetic programming, and therefore, automagically evolves... whatever.

In practice, you not only have to generate altered content, but you need to generate the stuff that is associated with that content (e.g. new collision geometry), and new rendering techniques so that it will actually also *look* up to date (and those are things that will never be procedurally generated, and OSes like Vista forbid you from even trying to make it thus). Which is all pretty much tantamount to creating a whole new upgrade package for an old title.

[makeitlookreal]

And all this time I was thinking you were Mintmaster!!!

ARRGG! I am so sorry CPI! I do indeed apologize, but that guy does indeed sound like you in a lot of his posts. I get the feeling you and him agree on a lot of issues, but honestly it blows me away to find out that I was wrong all this time!!!! ARRRGGGG!

[cpiasminc]

I'm called ShootMyMonkey over there (the lord of the creature stories), though now that you mention it, he does seem to have a similar style. The quote you posted... until I followed the link, I seriously thought I did say that. Even the rhetoric which seems very saturated in frustration sounds very much like me. Yeah, I'd probably find myself in the same camp on a lot of things, though I know he and I have dissented on non-computing matters.

[stanDarsh]

You can tell by the red writing in his signature :-p

[xbdestroya]

MILR, Mintmaster is an ex-ATI employee, just to give some info on his background for you. I agree he has a lot to say on a number of topics and I enjoy his posts - but as always, take his opinions in the context of his experience. Mintmaster is good though usually between differentiating between what he thinks and what he knows.

StanDarsh is right though - the giveaway for Cpi is the small red text in the sig. And obviously, for anyone that's followed the 'creature' stories, that should be a lock as well. :)

[Red_Eyes]

Back on topic. The only method to bypass memory limitation is streaming. Streaming textures in and out as the player moves around. Example: Games like GTA and Driver.

[CreativeWriter]

Back on topic. The only method to bypass memory limitation is streaming. Streaming textures in and out as the player moves around. Example: Games like GTA and Driver.

Or Guildwars, right? It's the whole game that's streamed? Or is this a different kind of streaming (textures from a disk vs game code from the net)?

Off topic: I like how everyone just kept right on going after the Magilla Gorilla thing. I'm like a child who wanders into a dentist convention and tries to understand the technical aspects of a root canal. I recognize teeth, but that's about it =).