Concurrency

It''s not so much about structuring your code... The problem is that certain calls to the GPU stall the pipeline and the GPU has to WAIT for the CPU to finish. That''s fine during load-time setup but it can be a killer in realtime.

For example, when you lock a vertex buffer in order to render it the GPU has to wait until it''s unlocked. If you do some complex operation between the Lock/Unlock calls, your FPS will drop drastically. A better approach is to save stuff to RAM first and then copy it to the vertex buffer quickly. Actually if you declare the buffer as MANAGED, DirectX does all that for you.

Picture a software renderer with full decoupling. That means that all your AI/Processing/etc is done in a separate thread. You render your scene as many times as you can in your rendering thread while the other thread is doing the processing. Once the processing is ready, the rendering thread updates its information and renders the new frame as many times as it can while the processing thread is working on data yet again. If your rendering thread can do 3 frames while you prepare the next frame, that''s great. But you have to make sure that the rendering thread isn''t waiting for the processing thread, or the whole purpose of two separate threads is lost.

This is why when you declare your d3d objects as MANAGED, you only get pointers to system memory and then when you''re done the updated data is sent to the GPU. Technically once you declare your stuff as MANAGED, you''re fine. However, you should still look out for potential stalls and fix them or work around them.

Another big thing is balancing the GPU and the CPU. If your GPU can render 50 frames while the CPU only prepares one, you waste a huge amount of power. So you might consider increasing the models poly count and render only a couple of frames while preparing the next one. You don''t need 500FPS, you only need about 60 for the person not to notice stalls. So if you get your 500 consider increasing the model detail.

From the book Inner Loops: "Premature optimization is the root of all evil." It was said in a different context but I would still consider hunting pipeline stalls only after you''re done with most of the engine. You should just look out for potential problems while designing the code, once everything is written hunt for small problems.

Thank you very much for your reply. It is extremely helpful and even comforting to me since this is my first large project. I''m building a cycling simulator for indoor bike training and have been having phenominal success. My lack of experience, however, had me hanging up on these types of issues.