Official speculate before its too late: RSX Spec thread

API support is primarily in the driver not the silicon. The reason the FX series kicked ass in OpenGL and not DX games is because the FX series kicked ass in DX8 class games. Most OpenGL games at the time (arguably still) only required DX8 level features.

But sure, they there is lots of stuff they could take off the chip. Probably the first to go is that sizable chunk just there for SLI.

 

DX is just a software layer, nothing to do with the HW as such. The HW has to be able to perform certain set of functions, but that's got nothing to do with DirectX as such. Just like all our gfx cards can also run with OpenGL, which is totally different than DX. Maybe some shady "DX-only" features might be removed, although I doubt it.

 

I'm sorry but it certainly does not sound like you work in games developpement. Only an idiot devhouse would try and render the whole scene every frame. Games with large environments are sectioned using portals (or similar) and instanced objects are almost always frustum culled. I haven't played GT4 but I'm guessing that it only rendered the current section of track (a few hundred virtual meters), the upcoming track and possibly the previous track to avoid fetching if there's a quick turn-around, or for the rearview mirror.

For the last PS2 game I worked on, we were told (as level artists) to make sure we didn't go over 55-60k visible polys including the SFX and characters for >30fps gameplay, meaning only a couple dozen thousand max for the environment only. We used sectioning and portals just like I described above since we had a total budget of 80-100k polys for just the environment of a whole "level".

Any studio that attempts to render the whole scene like your formula at the top is amateurish.

 

You are very right on the previous part of course - you want to make sure that what is visible during gameplay fits your rendering budget, but I disagree with this final generalization.
Not that that simple formula applies exactly - but still - what will you do if design calls for most/all of the level to be visible at some points? There are different design problems, and not one universal "one fits all" approach. Occlusion methods in particular are often overrated for what they do.

I also agree with Sentinel being off on what GT renders or how fast, but that's a different issue - I've seen their PA scans among other things.

 

I guess you,re right in those regards. If the nature of the environment is arena-like, then of course most of it will need to be rendered (what's inside the frustum and isn't occluded anyway). I'll clarify/correct my early statement by applying it mostly to environments with winding coridors/tunnels, city streets (to some extent) and racing games, like GT4.

 

The restrictions you were given sound pretty low - even if your programming team did what I always do and divide the numbers by two before telling the art team (damn, now the cat is out of the bag...)

 

Even racing games can be an exception when you have nutty artists design Yokohama stage where you can see practically the entire city from the bridge. Although in the end it was never the rendering budget that was the problem but that's another story.

If divided by two, wouldn't that make it 110k @ 60? That should be pretty decent/above average unless I'm eading that >30 wrong.

 

Possibly they are, but I guess its understandible given the amount of post-processing, number/quality of particle effects and other factors. I guess because even though it was developped with PS2 in mind, no risks could be taken, especially when porting it to the three other platforms, no unwanted surprises with how large meshes are loaded or whatnot.

Anyway, I'm not a programmer. Just stating the limitations that were given to us when integrating our levels for what was said "a poly-pushing engine".

I feel what I said earlier still stands though. Unless it's a very specific case, like arena-based environments, levels need to be cut up, and far from all of the 100k polys will be rendered if it's a well-designed engine.

That's the perfect example as an exception. I haven't tried the game, but I'm guessing they still did some trickery when viewign the city from the bridge, like mesh replacement when driving through a trigger while you weren't lookign in that particular direction. That's just a guess though.

 

Actually I was referring to our game in this case, I don't recall GTs Yokohama too well but I think they made it more closed off - their worst case track was Monaco IIRC.

Well there's a couple of things we do - the bridge is LODed when you see it from the other side of the city - and we are able to cull most of the underground tunnel part when you're outside, though that makes only small part of the stage.
Small dynamic objects are distance culled too - but there's not much to be done about stage geometry.

Of course you're right about stuff being cut up into pieces - we require it for vertex compression to work right, among other things. It's a double edged sword - makes things faster when things are getting culled(especially rendering wise), but when you have most of it on screen your CPU load starts to hurt.

 

Isn't that the fault of the architects that built Yokohama rather than the artist that reproduced it too faithfully? For once, anyway...

Well I guess so... I'd prefer to target a more ambitious number though, rather than just being above average - because the average is kind of low

 

What game?

I did not know you are making racing game! Are you allowed to say what it is?

 

Hi im new here, i was wondering if RSX is indeed a multi core GPU, since it's pushing a theoretical power of 1.8tflps..........a 7800GTX don't even come close to that number, heck 4 7800 GTXs don't even come close to 1.8tflps of power ( i think ) so could it be possible that sony just used nvidia existing technology and combined it the technology of cell with to make a multicore GPU that can push this number? i don't know, im not tech savy so i might be totally wrong, so correct me here if i saying random things lol

 

The 1.8tflop number is just marketing and funny math.
They are counting all of the fixed function operations and internally on NVidia hardware almost everything in fp.

 

Yes... please! No more 1.8TFlop questions - they're making me crazy.

BUT, welcome to the forum Random.

 

PS3 is closer to HALF a TFLOP of peak theoretical *programmable* performance, not 1.8 ~ 2 TFLOPs.

TFLOP consoles won't happen until Xbox3 and PS4 in 5-6 years, and even those will be peak theoretical TFLOPs

 

Here, I was going to start a new thread for this but I figure this thread is traffic-heavy enough that the chances of a good answer from someone will be just as high. Plus if someon has the answer readily enough, no reason to start a thread.

My question revolves around the PS3 Blu-ray playback demo featured at CES.

Here are the relevent stats:

Now, what I'm wondering here is to what extent RSX is helping with the processing of the output signal, and how? We're not talking about help from hardware on the decode side, are we? I guess what my question boils down to is: is this indicative of any remaining PureVideo logic on-chip?

 

I doubt it, the SPUs should be more than capable...

 

That's what I'm thinking. Well not even just thinking, that's just the case flat-out. So what exactly is it that the RSX is contributing there in the 'image processing'?

 

Fancy texture effects!?

 

They may have left PureVideo in .. might not be removable without heavy modification of the original G70/G71/G80/G99 design just as AVIVO actually relies on the shader pipelines to perform its functions.