Edit - Actually mVecticeArray is set correctly. So, it must be how I'm drawing it... Am I using vertex arrays wrongs here for quads?

Edit 2 - I found my problem! I was specifying that each Vertex had 4 components in the vertext pointer >.< Stupid mistake. Thanks for all your guys help!

Great to hear you found the problem!

OneSadCookie Wrote:You say there's no benefit, but have you tried enabling the MP engine?

UPDATE: I finally downloaded Xcode 2.4.1 today so I could get the updated headers containing kCGLCEMPEngine, because I just *had* to see if it really did anything for me (and it was about time to upgrade tools). Turning on the MP engine has produced no noticeable benefit from what I've seen so far. I haven't tested with multiple objects being drawn, but single models being drawn with varying amounts of triangles each doesn't show any improvement in frame-rate at all, with or without VBOs and with or without MP being turned on or not. I tested up to 75k tris, which yields approx 20 fps, which is still actually pretty good IMHO. There's about 50% processing space left on both procs too. Realize that this is not testing any other scenarios, and I might not be setting up the environment correctly, or even testing correctly, so my observations here have to be taken with some skepticism as to whether or not MP really helps with VBOs on a GMA 950. So far for me, the verdict is: Still no benefit...

This kind of makes sense when I think about it since there's no VRAM for VBOs to cache to in the first place (on the GMA950).

The issue isn't one of VRAM, the issue is that when you call glDrawElements without a VBO, the T&L must be done there and then, before glDrawElements returns. When you use a VBO, the T&L can be deferred until later. In the single-threaded case, it won't be, but in the multithreaded case, it can, and can be done on the other thread, leaving more time on your main thread for you.

Whether it *is* or not is a slightly different question

Ooh, that's interesting info.

Well, my app is already threaded, and I'm not really doing anything in my main thread anyway except calling OpenGL so I might not ever see any benefit. glDrawElements with interleaved arrays is indeed my weapon of choice BTW. All movement and other calculations are done in the sim thread.

I can't imagine there is any point in *not* having MP enabled is there? I figure I'll just leave it on from now on, and turn it off from time to time to see if there is any difference under different conditions, keeping in mind what you're saying about the T&L deferral.

Yes, the MP engine is likely to slow you down if you're not using it correctly (it actually does substantially more work than the non-MP engine, it just does less of it on your main thread).

Remember that in order to hit the fast path, you need all your data in VBOs (including the index data), avoid calling any glGet functions, or anything that synchronizes with the CPU (ReadPixels without a PBO, Finish, etc). There's an apple technote about it: http://developer.apple.com/technotes/tn2006/tn2085.html

Okay then, I'll be sure MP stays optional and keep an eye out for any gains or losses. Thanks for the info on that!

Yeah, everything is VBO'd including indices -- 2 VBOs per poly mesh 1) interleaved geometry and 2) unsigned int indices (might get a little more performance in immediate mode using shorts here though). And I always cache (shadow) the opengl state. No `get' calls and absolutely no push/pop attribs.

I'm not too worried about performance right now since I'm trying to get all my other dominoes lined up, but I'm definitely keeping an eye out for fast path techniques, so I really appreciate the tips!