views:

248

answers:

1

I am new to iphone and haven't done any threading on it at all. It seems that calls to drawElements are taking a big chunk of my processing time, so it makes me think that a large amount of rendering is being done before the code is allowed to continue past the call.

does anyone know how the parallelism of openGL works? or how it works on the iphone? how much is done synchronously compared to asynchronously? is it worth making a rendering thread that queues all the calls to GL? is threading even that good on the iphone? or is it so terrible that even if it was a good idea in theory, the terrible threading means you should not bother? (not making a judgment, as I said, i haven’t tried threading at all on the iphone).

has anyone tried this before?

basically, is the cpu just sitting there doing nothing while the GPU does stuff with a call to DrawElements/Arrays?

+2  A: 

OpenGL ES on iPhone is a bit of both: synchronous & asynchronous (deferred renderer). Each call consumes a small amount of CPU to move memory around and prepare the GPU, but you're right. The CPU is just sitting there sometimes, but when it is, the bus is typically saturated.

If you have other things that aren't too memory intensive, then you can probably get a small boost by running your calculations in a separate thread. I wouldn't suggest moving your rendering code and I'd really watch out for concurrent memory operations. RAM on iPhone is a big bottleneck for rendering as it is.

Pestilence
thanks for your insight! I am rendering static buffered objects, so theoretically all the indices, vertices and textures should already be loaded onto the video chip? so there wouldn't be much memory usage? or does the iphone use shared memory.
matt
The iPhone does use shared memory.I found this guy's blog posting awhile back when I wasn't gaining any advantage from utilizing VBOs. I still use them, because they may eventually get accelerated, but they're not faster nor leaner. http://blackpixel.com/blog/399/iphone-vertex-buffer-object-performance/
Pestilence
One thing that does really help is interleaving your mesh data. You can't move it closer to the GPU, but you can move related data closer together.
Pestilence
thanks, I was already interleaving my vertex data so I wouldn't know how much difference it made, all I know is using VBOs didn't make any difference, and I tried using BYTES instead of floats for normals and that actually seemed to slow it down...I downloaded the nvidia Tristripper tool, it looks really cool, I converted everything to tri strips, seemed to make a tiny difference... I'll try using it's vertex reordering function to see if that speeds it up, also I might try ditching using indexes.
matt