Crysis could be on consoles from Cevart.

[psorcerer]

YOu need to load data much before it's actually used. And where are you going to load it to? VRAM?

Yep, load it to VRAM.

You need that for data that's being rendered right now, not data that might be used at some point in the future.

At some point in the future I WILL need that data in VRAM anyway. And by that time it better be in VRAM already!

This is where you load to system ram, and you can only load so much as what will fit. Which means a platform with more system memory can keep higher-reslution assets (all types of assets) available for use at all times.

You have player that runs forward. You know that in exactly 1 sec you'll need 48mb of VRAM changed to assets of the place player runs to.
So you start loading it from disk to system RAM, it gets there in next 800ms.
Then you load it to VRAM in the remaining 200 ms.
Player still runs in same direction, so you load another chunk and then another chunk and so on.
Good? Good enough.
Now to console: player runs, you need 48Mb changed.
Because in PS3 you can change assets in VRAM not on per-frame basis, but on per-VBO basis, you cunningly load things into VRAM directly, just the moment after GPU finished using it, so you start transfer from HDD and in 1000msec it's there.
Good? Good enough.
But, where is the advantage?

 

[psorcerer]

That pretty much settles it, and what has been said all along to Psorcerer, one has to prefetch the data. One cannot go form HDD to RAM direct to screen/processing since the HDD transfer rate will be the bottleneck. :smile:

Pardon me, but that's what I was saying.
And also I was saying that you can not speed up this using system RAM no matter how hard you try.

 

[Albuquerque]

Yep, load it to VRAM.

Wrong. You're not going to load sound data to VRAM. You're not going to load AI pathing data to VRAM. You're not going to load scripted events to VRAM. You're not going to load object state data to VRAM. You're not going to load full object meshes into VRAM. You're not going to load collision data into VRAM.

You LOAD IT TO SYSTEM RAM, just as you got done saying in your previous post that you're now trying to backpeddle against.

I'm done with this thread; you don't understand, or if you do, you're too illogical or egotistical to admit it.

 

[psorcerer]

Wrong. You're not going to load sound data to VRAM.

I'm talking about renderer.

You're not going to load AI pathing data to VRAM. You're not going to load scripted events to VRAM. You're not going to load object state data to VRAM.

See above.

You're not going to load full object meshes into VRAM.

100% I will.

You're not going to load collision data into VRAM.

I'm talking about renderer.

You LOAD IT TO SYSTEM RAM, just as you got done saying in your previous post that you're now trying to backpeddle against.

You update your physics constraints once in 10 frames - nobody will see the difference. You do AI once in 10 frames - nobody will see the difference etc.
Everything that's not render can be processed much much slower = need much less data pushed back and forth. So you can get it out of the equation.

I'm done with this thread; you don't understand, or if you do, you're too illogical or egotistical to admit it.

You haven't made any decent points throughout the whole discussion, sorry.
Even simplest of things: you need to reserve more memory for updates if you need to hide more latency, thus PC will have some advantage - haven't crossed your mind.
Not good.

 

[pjbliverpool]

It's so unrealistic.
Other memory bus = other GPU.
Not even bus distribution = slowdowns.
So from hardware point of view this split - is most obvious and the cheapest.
And for programmers... who cares?

Like I said, if the balance wasn't feasible in the first place and it was impractical to change the memory sizes then the whole split design concept would have been infeasible.

You do not need it for Cell, you need it when you get out of VRAM boundaries.
So this problem was addressed.

Perhaps you don't need it for Cell, which is exactly why im saying the split is fine. Perhaps sometimes you will want to go into XDR but if this was a case of ALL the time to a significant amount then it would have made more sense to have less XDR and more GDDR3 or simply abandon the multiple pools idea altogether.

Yeah, good! Streaming is the right word. But there is one problem: streaming can be as fast as the slowest link in the chain.
So once again, if you can fit all the world in RAM: you get very fast streaming.
If you don't (huge worlds, anyone?) - you get HDD-speed straming, no matter what.

No, thats incorrect. You fit as much of the world in main memory as possible and then you stream into main memory from the HDD from there. When you eventually reach the point were the HDD can no longer keep the system memory fed - enter a loading screen. With enough RAM and intelligent streaming from HDD to RAM you can create large detailed levels between loading screens. Larger and more detailed than a system with limited system RAM and and a slower HDD/DVD.

Good, when every PC game will target minimum of 512Mb VRAM we will see all these marvels, but not now

You blatently failed to understand what I said didn't you? All of those elements scale within the game. You do not need 512MB to be the minimum as you scale your LOD, texture res, world detail etc... to match the available memory. So we are seeing those "marvels" now.

1. You can save some space.
2. You can load the resources while GPU processes them also: smart work with semaphores.

Oh, you just "save some space" do you? You have completely missed the point. I said WHEN you run out of space in a consoles memory you have to stream from the HDD/DVD. In a PC with 5 times the memory you would continue to stream from the system memory at a much faster rate.

You can't simply answer back "but I will save some space". Or make some obscure statement about loading resources as the GPU processes them even though those resources are coming from were...? Thats right, the DVD because you ran out of space in the memory.

PC has same amount of VRAM. So you'll need to save some VRAM for loading from system RAM also. But you can not do the console tricks here, you'll need to have some spare VRAM that is not processed.

You have decended into talking complete nonesensical rubbish. Firstly, no console has 512MB of VRAM dedicated to that task so your first statement is blatently wrong. Second, once you have used the first 512MB of memory, thats it for the console, over to the HDD/DVD. In the PC, you then move to 1GB+ of available system memory. This is obvious, this is fact, why are you continually trying to argue down obvious facts with vague descriptions of technical processes which most of the time make little or no sense in the context of the discussion?

 

[pjbliverpool]

Or you can just start loading it not 2 sec before it's needed, but - 4 sec.
No loading times, just pure readahead.

Lol, tell you what why don't we save some money and have 16MB of video RAM on RSX eh? Afterall, we can just stream from the DVD into there and it won't matter how slow the DVD is because we will just compensate by starting to stream earlier. Great plan.

Hey maybe we can start the streaming before we even but the game in the drive, then we might not need any RAM at all!

You seem to fail to understand that you don't program games like this: "oh, sh, player runs to the right, I need more data, let's load it from disk!", but: "player starts running to the right, let's do some pre-loading, so that by the time he gets there the data will be in VRAM".

Firstly, thats not remotely what im saying. Secondly, don't you think the pre-loading is going to be limited to how fast you can stream the data into VRAM? Of course it is! And thus if your loading from a HDD you can only load so much data in a given time. Therefore your world must lack detail or your player must move more slowly to compensate. If you can stream that data into VRAM faster, you can have more of it meaning more world detail or faster movement.

Complete rebuild of the engine? Are you kidding?
People who do 2000 DIPs per frame, are not bothered with such low level stuff.

And your proof that it would require a complete engine rebuild?

It's not advantageous, it's just as fast as loading it from HDD through system RAM.

They are already in system RAM. They were loaded there while your GPU was processing what is currently in VRAM. So again, how is it just as fast to load textures from a HDD at 1/10th the speed of system RAM?

You don't even know how good it describes the Gears.

All I know is that statements like that serve no purpose whatsoever other than to display your extreme bias and thus invalidate anything useful you might have otherwise said. Gears of War and God of War are not comparable. Not even remotely.

 

[pjbliverpool]

Not that, what I mean is the HDD is slow and can not load data fast no matter how you do it (using system RAM or no).
So to successfully use HDD you need to load data much before it's actually used.

Err, and don't you think an extra 2GB of fast memory between the HDD and the VRAM might help you start pre loading just a little sooner? Geez!

Just remember: Shadow of The Colossus!

What about it? Poor framerate and very simple graphics by modern standards. What exactly is it supposed to support in your argument.

Ok, slow framerates, framerate drops, GPU stalls, CPU stalls. No wonder that it's so commonly present on PC...

And there you have it, the inevitable decent into mindless drivel. A guess you have never actually seen a PC benchmark then eh?

But how would you take advantage of it, if your world does not fit into the RAM?
To load 40Mb of data from HDD to system RAM you need to spend ~690ms.
How can you reduce this number?

You load into system RAM at the start of the level/area of course. That gives you a huge buffer between the VRAM and the HDD. A buffer which you constantly refresh from the HDD and if you size it all up and precache correctly, you get have a whole level/area with no loading. You can do that with a console too, ona smaller scale because it lacks the huge system memory buffer.

 

[pjbliverpool]

And who exactly made it "sitting in system RAM waiting to transfer"?
Magic?
Didn't it get there by means of "horribly slow" HDD read?

Yes it did. On the initial load. That means when you start the level you have VRAM and system RAM full and ready to go. You then start streaming from HDD to sys RAM (if you even need too) from there. At some point you might catch up with the HDD but the game should be designed to account for that and move to a new loading screen when you do. Or keep the level small/simple enough so that you never catch up. As I said previously, you can do that with a console too, but to a lesser extent becasuse of the lack of memory.

 

[psorcerer]

Perhaps you don't need it for Cell, which is exactly why im saying the split is fine. Perhaps sometimes you will want to go into XDR but if this was a case of ALL the time to a significant amount then it would have made more sense to have less XDR and more GDDR3 or simply abandon the multiple pools idea altogether.

It's hard or even impossible to implement in hardware.
So using the hardware available the system was made with 50/50 split.
Which means that from HARDWARE point it was the only solution possible.
You can't abandon XDR, because you still need some system memory for Cell.
You can not have more than 256mb DDR, because the next step is - 512mb which is too much in terms of cost, although from programmer point of view: 512 DDR + 128 XDR seems to be better solution.

No, thats incorrect. You fit as much of the world in main memory as possible and then you stream into main memory from the HDD from there. When you eventually reach the point were the HDD can no longer keep the system memory fed - enter a loading screen.

Err... free-roaming games = no loading screens.
I thought it should be clear.

With enough RAM and intelligent streaming from HDD to RAM you can create large detailed levels between loading screens. Larger and more detailed than a system with limited system RAM and and a slower HDD/DVD.

No problem with that, agree.

You blatently failed to understand what I said didn't you? All of those elements scale within the game. You do not need 512MB to be the minimum as you scale your LOD, texture res, world detail etc... to match the available memory. So we are seeing those "marvels" now.

Yeah, yeah. Artists make 20000 polygon models instead of 10000, just for the sake of 2% gamers who will see the game on 512Mb VRAM, they'll also draw much more detailed textures, make much more objects, just to please those 2%. Kind of: wasted money?

Oh, you just "save some space" do you? You have completely missed the point. I said WHEN you run out of space in a consoles memory you have to stream from the HDD/DVD.

Why I need to run out of space and only then start loading?

In a PC with 5 times the memory you would continue to stream from the system memory at a much faster rate.

And then "loading screen", got it. But I'm talking about games with no loading screen.

You have decended into talking complete nonesensical rubbish. Firstly, no console has 512MB of VRAM dedicated to that task so your first statement is blatently wrong. Second, once you have used the first 512MB of memory, thats it for the console, over to the HDD/DVD. In the PC, you then move to 1GB+ of available system memory. This is obvious, this is fact, why are you continually trying to argue down obvious facts with vague descriptions of technical processes which most of the time make little or no sense in the context of the discussion?

I think you have a hard time understanding the streaming process, example:
Console = two tanks of water, large = HDD/DVD, small = VRAM. The tanks are connected with thin pipe = HDD interface.
When player is standing still - the water in small tank is reused constantly, no water movement between tanks.
When player starts to run anywhere: water from large tank starts flowing. If player runs fast enough: small tank is empty - out of memory.

PC = three tanks of water, two - same as in the console example, third one is middle size, in between the two. Middle one connects with thin pipe to large one and with very thick pipe to the small one.
Same player, stands still - nothing happens.
Starts running - water starts flowing. The speed depends on thin pipe.
What is the difference: more stable system, if the thin pipe gets stuck for a moment the small tank does not feel anything, until the middle tank depleted.
If player runs faster small tank also do not feel anything for some time.

What can we learn using this: PC system is more tolerant to errors.
1. Unreliable HDD speed can be hidden.
2. Coarse data layout can be also hidden.
That's it.

 

[psorcerer]

Lol, tell you what why don't we save some money and have 16MB of video RAM on RSX eh?

RSX would render 16mb so fast that it's impossible to stick any new data inside.

Afterall, we can just stream from the DVD into there and it won't matter how slow the DVD is because we will just compensate by starting to stream earlier. Great plan.

It also works.

Hey maybe we can start the streaming before we even but the game in the drive, then we might not need any RAM at all!

Pown!

Firstly, thats not remotely what im saying. Secondly, don't you think the pre-loading is going to be limited to how fast you can stream the data into VRAM? Of course it is! And thus if your loading from a HDD you can only load so much data in a given time. Therefore your world must lack detail or your player must move more slowly to compensate. If you can stream that data into VRAM faster, you can have more of it meaning more world detail or faster movement.

Yes you can.
If you have faster sustained rate from the slowest link - you can stream more data.

And your proof that it would require a complete engine rebuild?

I do not think I can share reverse engineered engine internals in public...
Even the fact of the RE itself is kinda illegal, I think, but it's a side effect of the profiler I'm contributing to.

They are already in system RAM. They were loaded there while your GPU was processing what is currently in VRAM.

And how would you load it to VRAM then, if your GPU is constantly processing everything in VRAM?
You set some memory aside and load there.
Then switch to that memory while loading to the now unused one and so on.
Same thing you can do with HDD. Set aside some VRAM and load there.

So again, how is it just as fast to load textures from a HDD at 1/10th the speed of system RAM?

Does not matter because memory is unused anyway. The problem is more latency - more memory set aside. That's the advantage PC can have.

 

[Neb]

Err... free-roaming games = no loading screens.
I thought it should be clear.

Not always, Oblivion is free-roaming game but has loading screens on all versions (although a decent PC they are barely noticable if even).

Yeah, yeah. Artists make 20000 polygon models instead of 10000, just for the sake of 2% gamers who will see the game on 512Mb VRAM, they'll also draw much more detailed textures, make much more objects, just to please those 2%. Kind of: wasted money?

You are really reaching.

'Much more detailed textures', you mean higher resolution textures?

Since that is what makes them look better, resolution (apart from artwork and mapping technique). Since most textures are stretched over and area (ground for example) higher res textures will make them less blurry and at the same time the detail is pronounced much better.
And textures are what fills most of the VRAM.

Really nothing difficult with creating a texture at 2048x2048 pixels and then just have it scaled down based on settings. And not only that but their game will scale better while they get old (still look decent in the future). :smile:

 

[psorcerer]

Err, and don't you think an extra 2GB of fast memory between the HDD and the VRAM might help you start pre loading just a little sooner? Geez!

Yep, because I do not need loading screens.

What about it? Poor framerate and very simple graphics by modern standards. What exactly is it supposed to support in your argument.

It's a living example of how you can do proper streaming.
According to your arguments you can not possibly make a working game with 2.5mb/sec DVD drive.
But here it is: working like a charm. And no loading screens, on 32MB RAM system.

And there you have it, the inevitable decent into mindless drivel. A guess you have never actually seen a PC benchmark then eh?

You know the difference between benchmark and the actual game?
Let's do a quiz: why is it possible on PC to make a benchmark that will run 10 times faster than any game based on SAME engine?

You load into system RAM at the start of the level/area of course. That gives you a huge buffer between the VRAM and the HDD. A buffer which you constantly refresh from the HDD and if you size it all up and precache correctly, you get have a whole level/area with no loading.

You can read from RAM at 2Gb/sec, so you deplete your 2Gb of system RAM in exactly 1 second, how much data you can "constantly refresh from the HDD" in this time? 80Mb? You're joking, right?

 

[Neb]

It's a living example of how you can do proper streaming.
According to your arguments you can not possibly make a working game with 2.5mb/sec DVD drive.
But here it is: working like a charm. And no loading screens, on 32MB RAM system.

I don't think anyone implied it is impossible but that it will limit details since the stream rate is very low. Therfore why the particular game had low-res and empty areas with little objects onscreen.

You can read from RAM at 2Gb/sec, so you deplete your 2Gb of system RAM in exactly 1 second, how much data you can "constantly refresh from the HDD" in this time? 80Mb? You're joking, right?

You really dont get what he explained to you (partial refresh and not whole memory dump?)?

 

[psorcerer]

Not always, Oblivion is free-roaming game but has loading screens on all versions (although a decent PC they are barely noticable if even).

Oblivion is not so free-roaming, because you have loading screens everywhere, and because the world is not seamless at all: all indoors are separate meshes.

You are really reaching.

'Much more detailed textures', you mean higher resolution textures?

Since that is what makes them look better, resolution (apart from artwork and mapping technique).

You can not make more details in texture by upscaling it. So to make texture with twice as resolution you need manual work.

Since most textures are stretched over and area (ground for example) higher res textures will make them less blurry and at the same time the detail is pronounced much better.

That's good but to some extent only. If you have 2048x2048 texture and 1024x768 frame buffer it's kind of waste of space. So you make an atlas: large textures that are composed from smaller ones to save the RAM. There are some bad exceptions, like shadow maps, which need to be large enough for bad light source vs camera positions. Although there are number of tricks to reduce the size.
So if you have excess of memory you can obviously use it for better shadow maps (it will eat your fillrate but I will accept this as an advantage).

Really nothing difficult with creating a texture at 2048x2048 pixels and then just have it scaled down based on settings. And not only that but their game will scale better while they get old (still look decent in the future). :smile:

That's a good point but it's kind of unrealistic from the business point of view: PC game lifetime is much shorter than console one, majority of gamers do not play older PC games. There are numerous reasons for that, but it seems like complete OT.

 

[psorcerer]

I don't think anyone implied it is impossible but that it will limit details since the stream rate is very low. Therfore why the particular game had low-res and empty areas with little objects onscreen.

So on PC it's amount of RAM and not HDD speed which limits details, and on console - HDD? More jokes?

You really dont get what he explained to you (partial refresh and not whole memory dump?)?

But if you can do this "partial refresh" to VRAM directly, where is the disadvantage?

 

[NovemberMike]

Yep, because I do not need loading screens.

Um, everything has loading screens. Even something like GTA has to have it when you start the game up...

It's a living example of how you can do proper streaming.
According to your arguments you can not possibly make a working game with 2.5mb/sec DVD drive.
But here it is: working like a charm. And no loading screens, on 32MB RAM system.

The argument was always a matter of scale. Everyone knows that you can make a seamless game with a dvd drive. The topic here is crysis though, and I fail to see how a PS2 game is a valid comparison.

You know the difference between benchmark and the actual game?
Let's do a quiz: why is it possible on PC to make a benchmark that will run 10 times faster than any game based on SAME engine?

The same reason the Cell does so well in benchmarks? When you can control every variable, you can do very impressive things. Problems start occuring when you have real player involvement, though.

You can read from RAM at 2Gb/sec, so you deplete your 2Gb of system RAM in exactly 1 second, how much data you can "constantly refresh from the HDD" in this time? 80Mb? You're joking, right?

Um, how are you going to read all 2GB (I assume you mean Bytes, and not bits...) to a 256-512MB Graphics card in one second? If I was a dev, I would simply keep a set of information for the area around the player to a certain distance. Really, we aren't talking about dumping all the data in the VRAM anyway. Certain things, like the Player Character, certain enemies and some models and textures are going to be common enough that you want it in the RAM at all times. That means that on a 512 MB Video Card, you might only need a 500-1000MB buffer on the System Ram in order to cover any area the player might move to, and with some intelligent design (ie. Ignoring a cliff the player can't climb until later) you can cut that down even more. I am not a game designer though, so it might be completely different than I am thinking it is.

 

[Neb]

But if you can do this "partial refresh" to VRAM directly, where is the disadvantage?

Umm, since loading directily from HDD to VRAM is to slow as you said yourself 80MB/sec (the weakest link..for PC in terms of data throughoutput)?

You can not make more details in texture by upscaling it. So to make texture with twice as resolution you need manual work.

Who said about anything about upscaling (dont put words in others mouth, will not make you look good)!

The source, the original one is done at 2048x2048 and then through ingame options (engine or by separate texture packs low/high) it is downscaled. This so that users with 512MB graphics cards get better texture detail and those with lower amount of VRAM can play the game at all!

So on PC it's amount of RAM and not HDD speed which limits details...

Unless you whant constant disk trashing ingame then VRAM and RAM is the limiter (preloading textures and data at the beginning as you said yourself? ).

and on console - HDD? More jokes?

PS2 didn't use HDD for caching apart from streaming from optical media so I don't even know how you came to that conclusion.

Neverthless, RAM/VRAM of course, and read speed of the optical media/HDD if the game streams data while playing.

 

[psorcerer]

Um, everything has loading screens. Even something like GTA has to have it when you start the game up...

Unskippable opening movie, anyone?

The argument was always a matter of scale. Everyone knows that you can make a seamless game with a dvd drive. The topic here is crysis though, and I fail to see how a PS2 game is a valid comparison.

It's not a comparison, just example how you can make a lot from so little in PC point of view.

The same reason the Cell does so well in benchmarks? When you can control every variable, you can do very impressive things. Problems start occuring when you have real player involvement, though.

Eh..almost right, but I want to hear other parties.

Um, how are you going to read all 2GB (I assume you mean Bytes, and not bits...) to a 256-512MB Graphics card in one second?

60 fps * 32 mb of unused memory every frame = 1920 MB in 1 second.
Not bad, eh?

If I was a dev, I would simply keep a set of information for the area around the player to a certain distance. Really, we aren't talking about dumping all the data in the VRAM anyway. Certain things, like the Player Character, certain enemies and some models and textures are going to be common enough that you want it in the RAM at all times. That means that on a 512 MB Video Card, you might only need a 500-1000MB buffer on the System Ram in order to cover any area the player might move to, and with some intelligent design (ie. Ignoring a cliff the player can't climb until later) you can cut that down even more. I am not a game designer though, so it might be completely different than I am thinking it is.

If you can cut it to 2Gb overall you do not need to worry about streaming from HDD at all.
Also you don't do hill based visibility tests - too complex.
Just make your world inside a sphere, this way you can cut the barely invisible things, and substitute the long distance ones with decent pictures.

 

[psorcerer]

Umm, since loading directily from HDD to VRAM is to slow as you said yourself 80MB/sec (the weakest link..for PC in terms of data throughoutput)?

It will be slow no matter what. It can be fast if you precache it to RAM once and then do not touch HDD at all.
Or if you do some other PC designs, like: precache all geometry in RAM and stream only texture packs from disk, texture packs are changed only on terrain types crossing. And if you do terrain crossing inside some dungeon (limited textures, all other VRAM is loaded with terrain pack): player won't notice anything.

Who said about anything about upscaling (dont put words in others mouth, will not make you look good)!

Sorry.

The source, the original one is done at 2048x2048 and then through ingame options (engine or by separate texture packs low/high) it is downscaled. This so that users with 512MB graphics cards get better texture detail and those with lower amount of VRAM can play the game at all!

And if you make 2000 textures 1024x1024 instead of 2048x2048 you save hefty amount of artist's work hours -> money saved.

 

[NovemberMike]

Unskippable opening movie, anyone?

That doesn't change the fact that there has to be a loading screen (and that screen is generally in the wrong place to be the movie).

It's not a comparison, just example how you can make a lot from so little in PC point of view.

But it really doesn't. Compare it to Oblivion or Half Life 2 and it looks horrible. It's saving grace is amazing art, but on a technical level it doesn't compare to PC games of similar scope at all.

Eh..almost right, but I want to hear other parties.

Whatever.

60 fps * 32 mb of unused memory every frame = 1920 MB in 1 second.
Not bad, eh?

Wait, what? Are you saying they are going to use different textures every frame or something? And anyway, my point was that if you have 512 MB of vram you aren't going to replace it 4 times over every second.

If you can cut it to 2Gb overall you do not need to worry about streaming from HDD at all.
Also you don't do hill based visibility tests - too complex.
Just make your world inside a sphere, this way you can cut the barely invisible things, and substitute the long distance ones with decent pictures.

What are you talking about? You don't need to completely eliminate grabs from the HDD, you just need to make it so they don't slow the program down...

As for the hill test, I am talking about a scenario where the player can't run up it and the dev knows this. They can simply put a flag up there so that it doesn't start loading the textures up there.