"Programming the PSP"

[Panajev2001a]

User clip plain function is loaded onto GPU of PSP.

As for this, it is the mechanism which can be appointed the 3D game developer draws to where from somewhere of the systems of coordinates of GPU. Having played the 3D game, distant 3D object, a certain distance goes out in boundary and/or appears probably those like the drawing boundary line which is not visible have been perceived. Among such drawing boundaries, the distant clip plainness "Far Clip Plane", the clip plainness of point of view side is called "Near Clip Plane".

As for the drawing boundary line other than "Far" and "Near", there is also a drawing boundary line of angle of view. 3D graphics is the case that it indicates the image which is caught from the camera which is installed in point of view in the monitor, but naturally it has appeared in the camera, (= angle of view) outside is not visible. In other words you do not draw the object which is outside this angle of view and the て there is no hindrance. This the clip of angle of view is plain.

As a basic decision of the optimization in the world of 3D graphics, there are some where "you do not draw any which are not visible". Then, it will try any which is outside the clip plainness not to draw...... with the idea which is said is born.

With GPU of PSP, clip plain function can be made effective/invalid. If it makes invalid, it meaning that clip plain processing is abbreviated, that much it becomes light, but there is a possibility those which are not visible wastefully being drawn. If it makes effective, it meaning that clip plain processing is done, this becomes the overhead, but that much, wasteful drawing decreasing, room is born in GPU, perhaps) (. It should use which, it depends on the design and the scene of the 3D game.

It sounds to me that all clipping planes are user-definable.

Well, I hope so, because as I wrote in my previous post it would become a mess if you had to do clipping in Software.[/quote]

 

[GameCat]

Looking at those slides, it definitely looks like only front plane clipping is dones properly, even when clipping is enabled. Maybe they have guard band clipping? Not doing clipping right just seems to strange to be true, what are you supposed to do, transform and clip all objects that intersect the view frustum planes in software?

On the bright side, mip selection doesn't seem to be broken this time

 

[Panajev2001a]

Looking at those slides, it definitely looks like only front plane clipping is dones properly, even when clipping is enabled. Maybe they have guard band clipping? Not doing clipping right just seems to strange to be true, what are you supposed to do, transform and clip all objects that intersect the view frustum planes in software?

That would be dumb, as you would have to have code that constantly checks for that and sends some polygons to the T&L on the GPU and some to the VFPU for T&L and clipping.

 

[kaching]

So I guess none of the developers from around these parts actually went to this session at GDC, who could then fill in the blanks based on what was actually said in the presentation...?

 

[Simon F]

Well I guess those games will have to be written by someone different to the games I've examined then....

Well, please talk some more about this issue: I sense that for you it is a pretty nasty one.

Well it all depends if you have a game where you want to look closely at something relative to the size of the models without having it disappear due to the near clip plane.

Sticking to an old game since that's less likely to upset developers, in Tomb Raider you could easily get projected vertices of some visible polys that had X and Y coordinates > 50,000! . The software port didn't actually clip those but instead assumed a huge guardband region. If, OTOH, we had thrown the polys away all sorts of strange things would have occured such as being able to look through walls!

[Warning it's early and I'm getting up every few hours during the night so the following may be off by a small factor but...]

The impression I get from the slides is that if you set your near clip plane to "X" units (eg 10 cm) and your field of view was, say, 90 degrees, then your models must not have nearby polygons with dimensions larger than 4096/2/480*X (eg 42 cm). Major structures like walls and floors etc would have to be diced up which'd be a nuisance for things in the distance which didn't need it.

You would have to do T&L with the CPU: with 2.6 GFLOPS you pack more power than the Dreamcast, so you could do that, but clipping would hit you and on the Dreamcast clipping is done by the PVR2 CLX chip IIRC.

No, there was no "clipping" per se on Dreamcast but it did support 'rather large' guardbands in that all post projection coordinates supplied to CLX were floating point. The SH4 code could thus be limited to just doing front plane clipping so, rather than also doing an expensive XY clip, it could just do gross rejection for completely off-screen polys.

Actually, this PSP system is beginning to sound a lot like Elan (our T&L chip for Naomi 2) which did front plane clipping and off-screen rejection except that it didn't throw away polygons that could be onscreen! It also could autonomously interpret display lists.

Hmm, from those slides, I think I understand where the problem with clipping on PSP is. Wouldn't automatic subdivision take care of those large polygons poping in and out when they get close to the camera?

Automatic by whom, the game software? If you meant the PSP hardware I suppose you could treat a polygon as a simplified "patch" and tessellate it, but, AFAICS, it would be cheaper to put in clipping hardware.

So I guess none of the developers from around these parts actually went to this session at GDC, who could then fill in the blanks based on what was actually said in the presentation...?

My "reliable source" did. He was amazed how the Sony PR engine somehow managed to make all the negatives in the system look like positives....

I'd say "Deja Vu" except that only applies when you think something is happening again, not when it actually is...

 

[kenneth9265_3]

Okay for those of us that are not as well educated in the the fine art programing and developing....How powerful is this PSP supose to be? Is it a PS2 handheld or what? :?

 

[VNZ]

In the light of this, the PSP feels remarkably much like a library-driven, slower, PS2. Which in no way is a bad thing for a freakin' handheld, but the hype-machine have indeed suggested more advanced hardware features.

Hopefully the full hw specifications will be released at/around E3, together with some high profile game previews.

 

[MfA]

I do not understand why they would force this kind of hack though.

Why did they do it like that the last time?

 

[Squeak]

Automatic by whom, the game software? If you meant the PSP hardware I suppose you could treat a polygon as a simplified "patch" and tessellate it, but, AFAICS, it would be cheaper to put in clipping hardware.

Unless the auto tessellation hardware could be used for a lot of other things, as opposed to hw-clipping.

 

[notAFanB]

so in conclusion, the PSP appears to be hacked together with buzzwords masking it's deficiencies (and overall weirdness), in an pathetic attempt at avoiding critisism for their ineptness at HW design?


sounds about right.

 

[darkblu]

I do not understand why they would force this kind of hack though.

Why did they do it like that the last time?

sometimes (but just sometimes) i get the strange feeling sony (not just scei, because sony's palmos handhelds exhibit the same 'treats') have a thing for hacks.. or maybe i should mildly call them ad-hocs. maybe there's something in their corporate culture which forces their engineering departments to focuse on the big picture and leave details for the last moment when they just come up with the first implementation that comes to mind/fits their timeframe, leaving a bitter taste in developers' mouths later on..

ps: obliged to say that i'm not a ps2/psp developer and the taste comment could be considered a pure speculation on my side.

 

[Panajev2001a]

Well I guess those games will have to be written by someone different to the games I've examined then....

Well, please talk some more about this issue: I sense that for you it is a pretty nasty one.

Well it all depends if you have a game where you want to look closely at something relative to the size of the models without having it disappear due to the near clip plane.

Sticking to an old game since that's less likely to upset developers, in Tomb Raider you could easily get projected vertices of some visible polys that had X and Y coordinates > 50,000! . The software port didn't actually clip those but instead assumed a huge guardband region. If, OTOH, we had thrown the polys away all sorts of strange things would have occured such as being able to look through walls!

[Warning it's early and I'm getting up every few hours during the night so the following may be off by a small factor but...]

The impression I get from the slides is that if you set your near clip plane to "X" units (eg 10 cm) and your field of view was, say, 90 degrees, then your models must not have nearby polygons with dimensions larger than 4096/2/480*X (eg 42 cm). Major structures like walls and floors etc would have to be diced up which'd be a nuisance for things in the distance which didn't need it.

You would have to do T&L with the CPU: with 2.6 GFLOPS you pack more power than the Dreamcast, so you could do that, but clipping would hit you and on the Dreamcast clipping is done by the PVR2 CLX chip IIRC.

No, there was no "clipping" per se on Dreamcast but it did support 'rather large' guardbands in that all post projection coordinates supplied to CLX were floating point. The SH4 code could thus be limited to just doing front plane clipping so, rather than also doing an expensive XY clip, it could just do gross rejection for completely off-screen polys.

Actually, this PSP system is beginning to sound a lot like Elan (our T&L chip for Naomi 2) which did front plane clipping and off-screen rejection except that it didn't throw away polygons that could be onscreen! It also could autonomously interpret display lists.

Hmm, from those slides, I think I understand where the problem with clipping on PSP is. Wouldn't automatic subdivision take care of those large polygons poping in and out when they get close to the camera?

Automatic by whom, the game software? If you meant the PSP hardware I suppose you could treat a polygon as a simplified "patch" and tessellate it, but, AFAICS, it would be cheaper to put in clipping hardware.

So I guess none of the developers from around these parts actually went to this session at GDC, who could then fill in the blanks based on what was actually said in the presentation...?

My "reliable source" did. He was amazed how the Sony PR engine somehow managed to make all the negatives in the system look like positives....

I'd say "Deja Vu" except that only applies when you think something is happening again, not when it actually is...

Thank you Simon, excellent post .

I think there might be something more to it, if clipping can be done only on the front plane why would they bother talking about user selectable clip-planes if the only thing you can do is to either turn all clipping off or all clipping on ?

The GS's real problem was mip-mapping's implementation which was broken and no-one uses it really ( most people seem to do something on the VUs to calculate Mip-mapping LOD's selection ).

It lacked some features, but it is not that the pixel pipeline had them, but they were broken or implemented badly.

Clipping not being done on the GS was apparently a design decision since day one.

Apparently Sony, during this past year, went back to the SoC and added some more RAM ( either more e-DRAM [better] or some external RAM [not as good, IMHO ) so they were not afraid to make changes to the physical chip.

It is impossible that if the solution to this clipping problem were to T&L in Software all polygons or doing something clunky that seriously kills performance ( developers say that the machine is not too tough to handle, compared to PlayStation 2 and is more similar to the GCN ) that Sony's first party developers and closest third parties would have not notice it.

 

[Fafalada]

In the light of this, the PSP feels remarkably much like a library-driven, slower, PS2.

Not in the slighest. The design is much closer to GCN then any other desktop console.

Which in no way is a bad thing for a freakin' handheld, but the hype-machine have indeed suggested more advanced hardware features.

Really? I could have sworn that all the PR to date has mentioned only features that have actually been shown by now. Or are you refering to hype dreamed up by people that had no actual knowledge in the first place?

Why did they do it like that the last time?

There's a difference between hacking your way around running out of die space - and - dumb implementation of basic features while at the same time you are cramming in every (redundant)T&L thing known to man.

Plus, I'm sorry, but none of the GS inconsistencies were half as dumb as this.
Hey, maybe next we'll learn that we can render compressed textures only on every second pixel on screen.

 

[darkblu]

It is impossible that if the solution to this clipping problem were to T&L in Software all polygons or doing something clunky that seriously kills performance ( developers say that the machine is not too tough to handle, compared to PlayStation 2 and is more similar to the GCN ) that Sony's first party developers and closest third parties would have not notice it.

Pana, if we assume those slides tell the whole truth then i'm affraid developers would have little options but to either:

* actually do sw clipping to ensure primitives fit the 4096 range, or
* build their whole engines on top of coord systems spanning not more than 4096 units in each direction

now, regarding the first option, whether clipping in sw would imply that the whole transform and lighting process would have to be done in sw, too, or there'd be some read-back mechanism between the cpu and gpu - we're yet to see. and re the second option, well, it's hardly an option.

 

[Panajev2001a]

It is impossible that if the solution to this clipping problem were to T&L in Software all polygons or doing something clunky that seriously kills performance ( developers say that the machine is not too tough to handle, compared to PlayStation 2 and is more similar to the GCN ) that Sony's first party developers and closest third parties would have not notice it.

Pana, if we assume those slides tell the whole truth then i'm affraid developers would have little options but to either:

* actually do sw clipping to ensure primitives fit the 4096 range, or
* build their whole engines on top of coord systems spanning not more than 4096 units in each direction

now, regarding the first option, wtheter clipping in sw would imply that the whole transform and lighting process would have to be done in sw, too, or there'd be some read-back mechanism between the cpu and gpu - we're yet to see. and re the second option, well, it's hardly an option.

Reading back polygon data would be waste of memory bandwidth: you'd be better to flag the triangles/primitives that would go out of the coordinate system and tessellate/subdivide them.

Alternatively you could take the primitives that would cause the problem and T&L them in Software with the capable VFPU.

The Dreamcast had a Vector FP engine that peaked at 1.4 GFLOPS: with 2.6 GFLOPS the VFPU should be able to do all T&L itself, but if they built a very capable T&L unit on the GPU is because they want you to do most of the work on the GPU saving RAM-to-GPU bandwidth.

 

[marconelly!]

so in conclusion, the PSP appears to be hacked together with buzzwords masking it's deficiencies (and overall weirdness), in an pathetic attempt at avoiding critisism for their ineptness at HW design?

Yah, that about wraps it up for PSP. The wretched machine will largely be rejected by developers, and industry leading handheld using PVR-MBXâ„¢ (what else!) will come in the very next day to replace it

Or... maybe not Seriously, though, from what I've seen of the available videos of the running PSP software, it looks pretty damn fine, and there's nothing that suggest any deal breaking visual issues.

My "reliable source" did. He was amazed how the Sony PR engine somehow managed to make all the negatives in the system look like positives....

So, does he confirm there are no user selectable clip planes (only the near clip?) What are those other negatives?

 

[Fafalada]

now, regarding the first option, whether clipping in sw would imply that the whole transform and lighting process would have to be done in sw, too

Guys, there ARE clip algorithms that work in object space you know.
That doesn't make the whole process any less dumb though - if I am forced to clip my polys on the CPU for 4 planes out of 6, my clip subroutine pretty much won't change at all if I include the last 2 planes in it too.
It just makes the GPU clip feature redundant - like I said originally.

 

[Panajev2001a]

Guys, there ARE clip algorithms that work in object space you know.
That doesn't make the whole process any less dumb though - if I am forced to clip my polys on the CPU for 4 planes out of 6, my clip subroutine pretty much won't change at all if I include the last 2 planes in it too.
It just makes the GPU clip feature redundant - like I said originally.

You would be able to clip the polygons before the T&L then if you do it in Object space... I am not sure of the speed as I have never done clipping in Object space, I should read-up on it a bit...

For the Curved Surfaces you would just tessellate them a bit finer I would guess as Tessellation and T&L for them is done on the GPU and I am not sure how efficient would it be to read back vertices from the GPU to main RAM.

What would you do for curved surfaces ?

I was not thinking about it.... well this makes me a bit calmer...

The VFPU should be able to nicely do all the clipping you want and still have some power left for physics and custom T&L ( like you do on the GCN having Flipper and Gekko collaborate ).

I know that your code would not change much from soing 4 to 6 clip planes, but the VFPU would clip against 4 planes faster than against 6.

 

[VNZ]

In the light of this, the PSP feels remarkably much like a library-driven, slower, PS2.

Not in the slighest. The design is much closer to GCN then any other desktop console

Well, as far as the rasterizer goes it doesn't seem too different from the GS, feature-wise. At a glance, I might add. Perhaps I'm missing some obvious features here (except for texture-compression and proper stencil support.. oh well). I mean, the emphasized features so far are in the T&L department, quite possibly not hardwired.

 

[Fafalada]

I am not sure of the speed as I have never done clipping in Object space, I should read-up on it a bit...

It's not much different really. All polygon clipping is ASS-slow compared to the rest of the pipeline, a few cycles of difference won't even make a dent.

I know that your code would not change much from soing 4 to 6 clip planes, but the VFPU would clip against 4 planes faster than against 6.

At an average 50-100 clipped polygons per frame, the difference is again so tiny it makes it all but irellevant.

What would you do for curved surfaces?

Erhm... Pray? :?

I mean, the emphasized features so far are in the T&L department, quite possibly not hardwired.

Eh? The T&L is obviously fixed.

But if you must talk about features - GC rasterizer doesn't have stencil support, does that mean we should compare it to GS?
Anyway, T&L for all the talk is still crippled compared to PS2, although a bit less so then the GC was.
The biggest thing I see is "smarter" display lists, which is a step up from both desktop consoles, and it's just nice to have because it lightens the cpu load.