Ratchet and Clank not doing LOD on SPUs *

:oops: The VU's, certainly one of them (forget which) were the Vector units of the PS2. Without them, you got no graphics at all! That's like saying the vertex units of NV2a in the XBox aren't essential!

I think its the VU1 your refering to, the VU1 was used relativly early on in PS2s life cycle and it was only towards the end of its life that developers started to use the VU0. Many developers had claimed that most of the "untapped" power in the EE was hidden in the VU0 but it was'nt used a whole lot by developers and many smaller dev houses never used it at all. Its just a shame the EE was such and arse to code for, if it was eaier we would of seen more games utilising the VU0.
 
I was refering to the series, that being part 1, 2 and 3. Not the multiplayer game. Since you were refering to R&C PS2 versions, I was replying to the parts 1-3. I guess I should have worded that more carefully. My comment in regards to the series, that being part 1, 2, 3, still stands though.



I still find it very interesting about your thoughts on the PS2 laser's getting old and not being able to read the data fast enough causing the slowdown. I would say my PS2 (Fat) is all of 6 years old., I never heard of that before, makes me want to go out and by a Slim now, even the though the old Fatty still works.
 
JNewt427,

Not sure if the weakest link was the laser about the slowdown, but it was the laser that broke soon after. I also noticed that slowdown was only apparent in games that relied on streaming, the Jak and Ratched series being two of them. None of the slowdows that I had in those games (more like more popups) were present on the newer "thick" PS2 that I bought later.

In the case of Deadlock, could be that they over did the engine a bit. I never really played that one though... Maybe also because of it's multiplayer aspect?

In anycase, Naughty Dog's Jak 2 and 3 did have very ugly tearing. I really hope we can expect Insomniac to go for constant 60 fps at no slow down at all. If not, I'd be very disappointed as well.

*fingers crossed* :D


almighty,

See my reply on the VUs. A common missconception, but discussed ages ago countless times here at b3d.
 
I'm quite surprised to hear this. Could it be by any chance because of your PS2? I noticed slowdowns in some games on my launch PS2 that relied on constant streaming - the weakest link there being the laser that was obviously getting old and couldn't stream quick data enough. This sounds much like it. Not any slowdowns at all on a flawless PS2 though...

It may have been the Jak series though (dunno why I mix Jak and RC visuals/gameplay!). But yes I had the non-slim PS2 and it was bought 2003 so the laser may have been worn out. :smile:
 
I still find it very interesting about your thoughts on the PS2 laser's getting old and not being able to read the data fast enough causing the slowdown. I would say my PS2 (Fat) is all of 6 years old., I never heard of that before, makes me want to go out and by a Slim now, even the though the old Fatty still works.



What he says is true, sometimes it's also due to dust
 
almighty said:
most of the "untapped" power
Most of the untapped power in PS2 was "hidden" by people having super fast VU1 subroutines spending a few cycles per vertex, and then stalling 10x as long waiting on misdirected and badly synchronized data transfers.

VU0 never got high utilization in micro mode because the design basically makes it impossible, but it got TONS of utilization in macro mode - some of the earliest PS2 techdemos - (from that infamous batch that was 100% realtime but some bitter people still accuse it of lies) - were running completely on VU0 macro with no VU1 at all.
 
I think you're approaching this from the wrong angle. It isn't so much that SPUs are *required*, but that they're better at it than anything else in the system. It's not that you couldn't do without any SPU culling, it's that you have to somehow lighten the vertex throughput requirements in other ways, since RSX is otherwise limited. And yeah, you could do it on the PPU if you really wanted, but even a single SPU will do it significantly faster and because simple things like skinning are easy to turn into several independent jobs, it's more of a "why wouldn't you?" question.

I am not really asking which unit or job distribution is more suitable for backface culling (though it is actually an interesting question by itself). The real question is whether SPU populated CELL has provided any significant performance improvements in terms of gfx yet compared to non-CELL alternatives (before someone objects, I know time time time, hence I say yet).

I have to admit though, I find your comments regarding SPU usage really confusing. Here is what I remember, please correct me if I am wrong:

You said many many times, culling/skinning is easy, even PPE or a single SPUsaid backface can do it.
You said somewhere, EDGE demo was using so many SPUs (each of which can process 750k triangles at 60Hz) because it was a show for "tech people". Now you say "why wouldn't you given that it is easy to parallelize?".

Now it is really obvious that computational complexity of backface culling is linear. I am not proficient in CELL programming but if one SPU is enough for the job I say it is not wise to divide it. As 256k is not enough for geometry, you need to hide memory latency by streaming and it needs to be synchronized properly etc. The last thing I would want to do here is doing other jobs on spare cycles of each SPU as opposed to completely dedicating one to culling. Alternatively of course, CELL's memory bandwidth and latency can be so great(?) I wouldn't care and any trivial implementation would suffice. CELL masters here can clarify I suppose.

You are truly smoking some bad stuff… :LOL:

R:FOM as far as I can tell doesn’t have an inch of popins or draw distance problems (with nice Multi-sampling to boot) on my TV(s).

Is that so? I suggest you create a game in Manchester (32), walk around south of the map (big opening). Look for barrels, grass, even breakable windows etc. It is really hard to miss unless you are in the middle of heated combat.

Ok just to give you some reference point of view here - a 300MHZ VU unit can do BF culling at a rate of ~500k*60 triangles/sec.

Thanks a lot. That's what I was after. Have you been using culling often on PS2?
And any insight regarding 750k*60 triangles/sec/SPU value which is at least at a significantly higher clock speed?


Don't confuse disagreement with defensiveness. You've posted a thought, and people are disagreeing and saying why. That's the nature of discussion! It's not a moatter of defending a console, but discussing the ideas and trying to open people up to ideas that they may not have considered - both ways.

We are indeed discussing something but I cannot honestly say every one of the replies here is objective (at least on the first page). I even got a negative rep for my initial comment.

If there not using the SPU's for geomrety thats great news, R&C has loads of onscreen activity and geometry so programmed correctly it meens that RSX is more then capable on its own.
That's my thought exactly. Personally wouldn't like to find out first generation games had already been using CELL heavily for gfx. :)
Give it time.
Give me a break.
 
You said many many times, culling/skinning is easy, even PPE or a single SPUsaid backface can do it.
You said somewhere, EDGE demo was using so many SPUs (each of which can process 750k triangles at 60Hz) because it was a show for "tech people". Now you say "why wouldn't you given that it is easy to parallelize?".
The whole set of things EDGE does is a little larger than just backface culling, and it's one thing to spread the task out across 2 or 3 SPUs for a few microseconds (that too, not all at once) which is a different thing entirely from the fatalist assumption to which I was responding in that other thread (the fatalist assumption being that it will take up all the SPUs for the entire 16 milliseconds of the frame time).

The real value of culling on the SPUs wouldn't be for the big polygons on giant flat walls, so much as the dense mesh portions like characters where several thousand large verts, to account for a single object of which you can have several.

Thanks a lot. That's what I was after. Have you been using culling often on PS2?
And any insight regarding 750k*60 triangles/sec/SPU value which is at least at a significantly higher clock speed?
I believe the biggest blocking issue if it was taking a long time to do all the culling would be a data moving issue. When you're talking about tasks that can totally be encapsulated in the 256k memory block with no repetitive DMA accesses, I've seen cases where 1 SPU beats out the VUs by 35:1. Otherwise, we also have to assume that the SPUs aren't just busy backface culling and doing nothing else -- they may only have a few milliseconds to spare out of the 16 in a frame. I don't know the context of the 500k triangles on the VUs, but I would have to guess that the thing there is that the VUs aren't really busy with anything other than geometry processing throughout the course of a frame.

I'd add, though, that I don't think there was any big value to backface culling with PS2. The thing is the additional work associated with culling wasn't worth it, because the fillrate of GS was so high (in a lot of cases I'd worked on, it was faster NOT to bfcull). Saving 1 triangle per failed test only counts for so much, and you also have to figure that meshes weren't as hefty then both in terms of geometry data and in terms of texel/pixel fillrate. The only reason it comes up as a beneficial option for PS3 is because the RSX's vert moving capacity is piss-poor, so anything you can do to save on vertex data sent down the pipe is a good thing, since you've got a CPU with enough FP capacity to eat a few million polygons for breakfast.

That said, you do have to prioritize.
 
Last edited by a moderator:
Full Story http://ps2.ign.com/articles/661/661501p1.html

But Yes I have the older "Fat PS2",, and like I said it is very common for me when I played. Just wanted to post a link that Others indeed have brought up this issue.

Somehow I find you're stretching very far to try to find examples of slow down. An occasional heavy battle (which IIRC happens maybe 3 or 4 times in Deadlocked) being slowed down to around 25-30fps is far from "unplayable".

Seriously, this is a MINOR issue, not even relevant really.
 
Somehow I find you're stretching very far to try to find examples of slow down. An occasional heavy battle (which IIRC happens maybe 3 or 4 times in Deadlocked) being slowed down to around 25-30fps is far from "unplayable".

Seriously, this is a MINOR issue, not even relevant really.

A minor issue to you maybe, but not for me. Besides other posters have lead me to believe that it is my (old) PS2 as being my main problem and not the game itself and I thank them for making me aware of an an issue that I had no knowledge of, this in conjuction with the games normal heavy battle slowdowns to me made the game look like it was in slow motion "unplayable". You should really read the entire thread next time and post accordingly.
 
Speaking to this...

OK guys,

I can speak to this:

1. We have tried out a few different LOD methods that we like for different reasons, including our announced support for texture streaming, and we've decided that not doing the work for LOD on the SPUs is a win for us right now. We're always re-evaluating everything, so this is subject to change, but what we've got looks pretty good and is fast. We might go over the details at a later time.

2. Let me say very clearly, we find the SPUs very flexible. We do in fact do some graphics pre-processing on them, including work for culling and clipping and RSX data building as I've mentioned elsewhere. At the same time, graphics alone don't make a game, and we've got lots of other systems running on the SPUs. The SPUs are absolutely central to how we write everything now - it's no longer a matter of "porting" things to the SPU - the SPUs are where everything should go by default. We've still a lot we can do, but we're definitely taking advantage of the Cell.

3. Insomniac does not use EDGE. Although Insomniac did participate in its development (a few of the Insomniac engine guys spent quite a lot of time over at our pal Naughty Dog's place, doing what they could to help them put it together in the early days), but it's simply turned out very different from where we want(ed) to go with the engine and our current tech is very much Insomniac's own.

Mike.
 
Last edited by a moderator:
Thanks Mike, that puts an end to speculation on that part.
 
3. Insomniac does not use EDGE. Although Insomniac did participate in its development (a few of the Insomniac engine guys spent quite a lot of time over at our pal Naughty Dog's place, doing what they could to help them put it together in the early days), but it's simply turned out very different from where we want(ed) to go with the engine and our current tech is very much Insomniac's own.

Mike.

Ok, interesting details on EDGE, but what cool things can you say about ICE-y things ;) ?
 
Back
Top