Archived

This topic is now archived and is closed to further replies.

Concurrency

This topic is 5676 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I apologize in advance for my self-taught graphics programming Ok, so good programming means making the GPU run alongside the CPU. The question is how to go about doing this. As I understand (using DirectX as the example) GPU "calls" like DrawIndexedPrimitive are queued, allowing other CPU processing to occur along side the GPU. EndScene() waits for the queue to empty before going on, but hopefully all of the CPU updating has occurred along side the graphics stuff, so neither processor has to wait for the other very long. Question 1: Is this correct? Is there anything to add to this? Question 2: What is a good programming structure to deal with concurrency? Here is the solution I am currently considering (and sort of using). It would make sense that if GPU stuff is queued, it should be called first. So when I first initialize my world I create the first frame by simply calling Update(

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites