PSP restrictions & possibilites in numbers

[Grom]

Hi, guys

At first, thanks for a great work - PSPSDK.

I'm playing with it now. My job is to determine the performance of PSP to make 3D games.

At this time, I found that I can draw ~30K of textured lit triangles at 20 fps. Is it a limit or I can draw more triangles at 20 fps?

I'm using Holger's PSPgl.
And right now my demo consists of 64 3D tanks turning over themselves. So as you can figure out, trinagles are not so big.

Please, give me any real info about PSP performance.

Thanks in advance.

[jsgf]

Well, its fairly hard to tell what you're actually measuring. 30k triangles/frame sounds a bit low, but I haven't really done a lot of benchmarking yet.

If you use the my PSPGL (http://www.goop.org/psp/gl), you can use the PSP_statistics extension to get a bit of information about how long the library is spending waiting on the hardware vs. total time. This will tell you whether you're CPU bound or GE bound.

Are you using begin/end or vertex arrays? In general, vertex arrays will give you the best performance. With goop.org PSPGL, you can use compiled vertex arrays and vertex array objects to put the array data into the GE's VRAM, which may or may not help.

Are you using indexed arrays or not? What primitive are you drawing (tris, strips or fans)?

What kind of textures are you using? Are you using mipmaps? goop.org PSPGL supports texture objects, and will put your textures into VRAM which could give you some performance improvement. It does not currently swizzle textures, which people say give a performance boost.

What kind of texture format are you using? In general the PSP is happier with fewer bits/pixel. Rather than using 32-bit RGBA, try a 16-bpp format, or use an indexed 8 or 4bpp format.

How many lights are you using? It seems that using 4 lights is more than 4x the cost of using a single light. Are you using spotlights or directional?

[Grom]

I'm using a vertex array. It is compiled.
My model is an indexed mesh with 410 faces and about 500 vertices and I draw it as tris.

Texture is a raw 128x128 RGB file withour mipmaps.

There is only one directional light.

So new questions here:
Will mipmaps increase speed of rendering?
Do you have any information about vertex cache? Maybe I need to sort vertices&indices in a specific order?
Does texture switch have a big effect to perfomance?

Please tell me which perfomance do you have if you think 30K is a bit low.

P.S. To be honest, I have built my sample on you sample "test-bezier". I ported it to C++, added model and removed a bezier mesh (but I plan to turn it on again). My task is to discover how many details I can have in scene with heightfield and some war units like tanks, troops.

[jsgf]

I'm using a vertex array. It is compiled.
My model is an indexed mesh with 410 faces and about 500 vertices and I draw it as tris.

Well, that should be about the best case for vertex performance.

So new questions here:
Will mipmaps increase speed of rendering?

Maybe. It depends on how much you're scaling down your textures. If there's a fairly high texel:pixel ratio, then mipmaps will help a lot (and swizzling, when I implement it). The easy way to check is to turn off texturing altogether and see what difference it makes; if there's hardly any effect, then mipmapping won't help much either.

The ODE test programs use large polys for the sky and ground, textured with a single repeating texture. With mipmapping off, this poly causes significant slowdown just by itself. I'm pretty sure its a result of scaling a largish texture down by a big factor.

The PSP has an on-chip texture cache, which is 8k (I think). The more texels you can fit into this cache, the better, so using denser texel formats should help. Swizzling factors into this because it increases the cache's locality of reference.

Do you have any information about vertex cache? Maybe I need to sort vertices&indices in a specific order?

Not that I know of, but I wouldn't be surprised if there were a cache. Ordering your triangles into strip order (even if you don't use strips) could help. It would be an interesting experiment.

Does texture switch have a big effect to perfomance?

Not on its own; changing textures is just a matter of updating some registers to point to the new texture image for each mipmap level. You also need to flush the texture cache on each switch, so that's some cost. I wouldn't switch textures on every triangle, but if you can draw reasonably large batches with each texture it shouldn't be an issue.

Please tell me which perfomance do you have if you think 30K is a bit low.

I'm guessing, really. If you're using CVAs and/or VBOs, then you should be getting pretty close to maximum transform performance. The interesting thing to measure is how long your program is spending waiting for the GE hardware, vs being CPU-bound. Are you displaying the performance graph from test-bezier?

Also, using bezier patches seems to be a very efficient way of introducing triangles. The lighting cost for bezier patch tris was much lower than with explicitly specified triangles. They would seem to be the the way to go if you want to subdivide even a flat surface for better quality lighting.

[Grom]

OK, I will try to make my best on the PSP. I will report here about my achievements. I also ask you to post here your own info and tricks about PSP possibilities.

[Grom]

-- posted 2 times by a mistake --
please,delete this message

[CyberBill]

Most 3D engines on the PSP are seeing performance around 1mil polys a second. You are seeing about 600,000 polys a second (30k * 20fps)... Definately some room for improvement. :)

However most games are not a bunch of models, its mostly ground terrain and stuff.

[Grom]

I have interesting problem.

Bezier patches a good for heightfield terrain. But how to calculate a height at this landscape? My tank now sometimes fly over landscape and sometimes running beneath it.

There is also another problem:
PSPglreport an error here:

Code: Select all

glEnable(GL_DEPTH_TEST)
glClearColor(0,0,.5,.1)
glEnable(GL_NORMALIZE)
*** GL error 0x0500 ***
main (536): GL error 0x0500
glEnableStatsPSP(GL_STATS_TIMING_PSP)
glEnable(GL_SCISSOR_TEST) 

and here

Code: Select all

glEnable(GL_LIGHTING)
*** GL error 0x0502 ***
glDisable(GL_BLEND)
display (312): GL error 0x0502
glEnable(GL_LIGHTING) 

jsgf, could you please help me with these problems. I think that is why I have a cap of 30K tri/sec. It just write to log errors!

[jsgf]

I have interesting problem.

Bezier patches a good for heightfield terrain. But how to calculate a height at this landscape? My tank now sometimes fly over landscape and sometimes running beneath it.

Yeah, you're doing to have to do your own subdivision of the bezier patch for the purposes of collision detection. This is pretty easy: it amounts to finding a series of midpoints of lines (look for "bezier surface subdivision" and/or "De Casteljau's Algorithm").

There is also another problem:
PSPglreport an error here:

Code: Select all

glEnable(GL_DEPTH_TEST)
glClearColor(0,0,.5,.1)
glEnable(GL_NORMALIZE)
*** GL error 0x0500 ***
main (536): GL error 0x0500
glEnableStatsPSP(GL_STATS_TIMING_PSP)
glEnable(GL_SCISSOR_TEST) 

and here

Code: Select all

glEnable(GL_LIGHTING)
*** GL error 0x0502 ***
glDisable(GL_BLEND)
display (312): GL error 0x0502
glEnable(GL_LIGHTING) 

jsgf, could you please help me with these problems. I think that is why I have a cap of 30K tri/sec. It just write to log errors!

I doubt it. If you were getting an error every frame, but actually it would go much more slowly. If you're only getting the error on startup, then it shouldn't have an overall effect.

The GL_NORMALIZE error is expected, because the PSP doesn't seem to have normalization (or maybe its on all the time; I haven't investigated this yet). My current tree doesn't report an error for this; you should probably update your copy.

I'm not sure what your second error is. Does it really correspond to the glDisable(GL_BLEND)? Or LIGHTING?